In Ethereum, clients must monitor for the successful progpagation of transactions (each with a nonce) in order to broadcast a new transaction (with a later nonce).

If, due to low gas or some other reason, the earlier transaction is not sufficiently propagated, the client must issue a replacement transaction with that nonce (and ensure it propagates) before a transaction with a later nonce will be accepted.

This limits the utility of pre-signed and offline signed transactions.

Polkadot has taken some steps towards more flexible transaction validity but must transactions still be ordered primarily by nonce?

Another way to phrase this question would be: can a later-nonced transaction ever take priority over a lower-nonced, but perhaps faulty or non-existent transaction?

1 Answer 1


For a default Substrate node, Polkadot and Kusama chain using the CheckNonce signed extension, the answer is "no".

What it actually does is the following -

  1. If the tx-nonce < account-nonce, it rejects the transaction as stale
  2. If the tx-nonce > account-nonce, it places a requirement on this tx to only execute after tx-nonce - 1

So basically the way it is implemented is that you can send transactions with nonce 3, 2 and then 1 and the transaction pool ordering will ensure it executes in the order of 1, 2 and finally 3.

The logic itself for the default CheckNonce signed extension can be found here,


you will see the requires step that points to the previous transaction to complete first, before this current is executed.

Any other Substrate-based chain can obviously can add their own requirements and signed extensions with completely different logic and not use the above, this is just the shipped version that gets used in the Kusama and Polkadot deployments.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.