Confirm Transaction
The transaction pool contains all transactions (signed and unsigned) broadcasted to the network that has been received and validated by the local node. There is an exceptional case that the network is overloaded with transactions, and the transactions are not put into the pool.

The transaction pool checks for transaction validity. Example validity checks are:
- Checking if the Transaction Index (nonce) is correct.
- Checking if the account has enough funds to pay for the associated fees.
- Checking if the signature is valid.
The transaction pool also regularly checks the validity of existing transactions within the pool. A transaction will be dropped from the pool if it is found to be invalid or is an expired mortal transaction. Take an example of unsigned transactions which are put into the pool and waiting for signing before being checked for validity. If it hasn’t been signed for a certain period of time (also called time-out), it will be automatically canceled by the system. In case it is signed, the transaction must be charged with a fee before it is included in the block.
If the transaction is valid, the transaction queue sorts transactions into two groups:
- Ready Queue - Contains transactions that can be included in a new pending block. It means that these transactions are used to construct a block. The transactions must follow the exact order in the ready queue since transactions in the front of the queue have a higher priority and are more likely to be successfully executed in the next block.
- Future Queue - Contains transactions that may become valid in the future. For example, a transaction may have a
nonce
that is too high for its account. This transaction will wait in the future queue until the preceding transactions are included in the chain.
It is noted that when nodes pick and include transactions in a new pending block, transactions can be overridden with a new one that is charged with a higher fee.
As to revenue sharing, there are 2 types of tnx: tnxs from whitelisted smart contract address and tnxs from unwhitelisted smart contract address. Both of them come into the future queue. Then based on the criteria of agreeing on sharing revenue with the network:
- The tnxs from whitelisted smart contract address will be put into the ready queue first.
- The tnxs from unwhitelisted smart contract address is held in the future queue for a default delay time before being put into the ready queue.
The
ValidTransaction
struct defines the requires
and provides
parameters to build a dependency graph of transactions. Together with priority
(discussed below), this dependency graph allows the pool to produce a valid linear ordering of transactions.For runtimes built with FRAME, the nodes order transactions with an account-based system. Every signed transaction needs to contain a nonce, which is incremented by 1 every time a new transaction is made. For example, the first transaction from a new account will have
nonce = 0
and the second transaction will have nonce = 1
.As a result, all transactions coming from a single sender will form a sequence in which they should be included.
Transaction
priority
in the ValidTransaction
struct determines the ordering of transactions that are in the ready queue. If a node is the next block author, it will order transactions from high to low priority in the next block until it reaches the weight or length limit of the block.For runtimes built with FRAME,
priority
is defined as fee
that the transaction is going to pay. For example:- If we receive 2 transactions from different senders (with
nonce=0
), we usepriority
to determine which transaction is more important and included in the block first. - If we receive 2 transactions from the same sender with an identical
nonce
, only one transaction can be included on-chain. We usepriority
to choose the transaction with a higherfee
to store in the transaction pool.
Last modified 10mo ago