Skip to content

Transactions

Applies to Prerequisites
v1 Requirements

Transaction overview

To broadcast a transaction request, it must be cryptographically signed. Thanks to Qredo's custody suite, only transactions that meet the conditions of the approval policy will be signed.

Note

By using Qredo's MPC network to sign your transactions, you remove the single point of failure of a private key-based signature system, futhermore, the custody rules remove the single point of failure that exists by allowing just one party to approve the signature being applied.

The choice is yours

While not recommended, you can choose to set up custody rules that require only one approval should you wish.

Within Qredo, a transaction is an instruction to a smart contract that may be signed (if the trusted parties approve it) and ready to be broadcast.

When you create transactions from the Web App or Partner interfaces, Qredo handles:

  • the responsibility for collecting the required approvals
  • signs the transaction
  • and then broadcasts the transaction

choose entity

If you are using Qredo API v1, Qredo handles:

  • the responsibility for collecting the required approvals
  • signs the transaction
  • returns it to you

Therefore, the API flow ends when the transaction is approved and signed and ready to broadcast.

Transact types

Many digital assets are traded on EVMs. Due to the London hard fork, EVM transactions fall into two classes:

Prior to the fork, gasPrice included the ETH paid per gas for the transaction and the ETH received by the miner. Within EIP-1559, the concept of gasPrice evolved to be the ETH paid for the transaction.

This means that users forming a transaction request must determine whether they require an EIP-1559 transaction or a legacy transaction.

Type 2

An EIP-1559 or Type 2 transaction allows the sender to state:

  • how much gas they are willing to spend
  • what proportion of that spend is the validator's "tip"
  • how much they are willing to pay for that gas
{
  to: "Address of recipient's Wallet.",
  gasLimit: "Maximum gas units the sender is willing to pay to have their transaction included.",
  maxFeePerGas: "Optional: Maximum amount the transaction initiator is willing to pay in ETH for each unit of gas. If passed, then `maxFeePerGas` must, at minimum, equate to the block's (base fee per gas + tip required) for the transaction to be included in the block.",
  maxPriorityFeePerGas: "The maximum fee (per each unit of gas) to be included as the validator's tip.",
  nonce: "Transaction nonce; a sequencially-incrementing counter which indicates the transaction number from the account.",
  value: "Amount of ETH to transfer to recipient address in gwei."
}

The total fee, therefore, is the (units of gas used in the transaction) * (base fee per gas + maxPriorityFeePerGas). The base fee per gas is a property of the Ethereum protocol and varies to control spikes in demand.

If the resultant total fee is less than the (maxFeePerGas * units consumed), then the difference is refunded. However, be aware that if the gasLimit that you set is too low for your transaction to succeed, the gas burned in attempting to complete that transaction up to that limit, is lost.

Legacy transactions

Both Type 0 and Type 1 transactions allow the sender to state:

  • how much gas they are willing to spend
  • how much they are willing to pay for that gas
{
  to: "Address of recipient's Wallet.",
  gasLimit: "Maximum gas units the sender is willing to pay to have their transaction included."
  gasPrice: "The maximum amount of ETH that each unit of gas costs for the transaction and mining fees."
  nonce: "Transaction nonce; a sequencially-incrementing counter which indicates the transaction number from the account.",
  value: "Amount of ETH to transfer to recipient address in gwei."
}

The total fee is the (units of gas consumed * network gas price). The network gas price is a variable property that depends upon the Ethereum network itself.


Last update: 2022-11-23