In this track: Ethereum protocol concepts
Account nonce versus transaction nonce
A submitted nonce is checked against the account’s execution state.
A numbered request must match the next accepted ticket in that account’s sequence.
Nonce 4 is ready. Try submitting nonce 5 before including it.
A simplified local queue for ordinary account transactions. This model omits fee and other admission checks, and never signs or sends anything.
Separate state and proposal
The account has a current nonce in state. A transaction contains a proposed nonce that must satisfy the applicable rules when executed.
Explain pending ordering
Transactions with later nonces can wait behind earlier ones in local pools. A pool’s contents are local observations rather than one globally identical queue.
Do not count all activity
Receiving ETH or appearing in a token log does not simply increment an EOA’s transaction sequence. Nonce changes follow specified processing rules.
Keep application nonces distinct
Signed orders or permits can maintain their own counters or used identifiers. They do not automatically share the transaction nonce namespace.
Map the protocol concept
state expects nonce n
transaction proposes n
accepted execution advances the account sequence
application signature nonces remain a separate designA conceptual model. Exact fields, limits and processing rules must be checked against the intended network fork.
Is an application order nonce necessarily the account transaction nonce?
Applications can define separate replay-control state.
Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.