Skip to content
Financial Context Wiki

Nonce namespaces in crypto

A practical guide to Ethereum account nonces, application-level replay nonces, ERC-4337 key and sequence lanes, and proof-of-work block-header search nonces.

Updated

For educational purposes only; not transaction or signature advice. The word nonce names several unrelated fields; verify the exact chain, account, contract, domain, EntryPoint or block-header specification and canonical state before allocating, replacing or reusing one.

Direct answer

A nonce is a value whose meaning comes from a specific protocol namespace. It does not always mean a random number or a universal value “used once.” On Ethereum, an externally owned account’s state nonce orders and validates that sender’s transactions. A contract can maintain separate application nonces in storage for permits or signed intents. ERC-4337 smart accounts can use a structured UserOperation nonce with parallel key and sequence lanes. In Bitcoin proof of work, the block-header nonce is a bounded search field used while trying candidate hashes.

These values are not interchangeable. An Ethereum account nonce does not protect an arbitrary typed-data signature unless the application verifies its own domain and replay field. A PoW header nonce does not order account transactions. The same numeric nonce used by different senders, contracts, chains or lanes describes different state.

How it works

  1. Identify the namespace before reading the number: EOA transaction, contract-account state, application storage, ERC-4337 UserOperation, or a named PoW block header. Pin chain ID, fork and protocol version, account or owner, verifying contract and domain, EntryPoint, or header format as applicable.
  2. Read authoritative state at an explicit block tag. Separate the canonical EOA account nonce from a provider’s pending count, an application’s nonces(owner) storage value, an ERC-4337 key and sequence, and a miner’s local header-search counter. Independent RPC agreement does not replace canonical receipt and state verification.
  3. Build the signed lineage. Record sender or owner, chain and domain, nonce, payload, deadline, verifying contract, transaction or message hash and every replacement. For Ethereum transactions, chain-domain rules such as EIP-155 supplement the account nonce; the nonce alone is not complete cross-chain replay protection.
  4. Allocate within the correct lane. Coordinate concurrent EOA signers so each canonical sequence is assigned once; preserve gaps and same-nonce replacement lineage. For an application or smart account, follow its contract’s atomic check-and-increment and lane rules rather than assuming one global counter.
  5. Submit under the correct admission rules. Execution-client pending and replacement policies are local; ERC-4337 bundlers validate UserOperation objects under EntryPoint and account rules; an EIP-712 or permit signature may be relayed inside someone else’s transaction. None of these local acceptance paths proves canonical inclusion.
  6. Track the complete outcome. Distinguish rejected, pending, queued, replaced, included successfully, included with status = 0, removed by reorganization and finalized. An included Ethereum transaction advances the sender’s account nonce even when EVM execution reverts; an application storage nonce updated inside the reverted call rolls back.
  7. Reconcile before retrying. Verify canonical receipt, block hash, sender nonce, application storage, ERC-4337 event or receipt and finality. For PoW, verify the complete header and target rather than the nonce alone; if the finite nonce field is exhausted, miners alter other header-affecting data to create a new search space.

Worked examples

  • Included revert consumes the EOA nonce. The canonical sender nonce is 12. A transaction with nonce 12 is included with status = 0, uses 50,000 gas at 30 gwei, and costs 50,000 * 30 gwei = 0.0015 ETH. Its contract changes revert, but the canonical sender nonce becomes 13. If a reorganization removes that block, the nonce can return to 12; the wallet must recheck the full transaction lineage.
  • Application and relayer nonces are separate. An owner has EOA account nonce 18; an ERC-2612 token reports nonces(owner) = 7; the relayer’s EOA nonce is 42. A successful permit consumes application nonce 7, making it 8, while inclusion makes the relayer nonce 43 and leaves the owner’s EOA nonce at 18. If the whole call reverts, the relayer nonce still becomes 43, but the token’s storage update rolls back to 7.
  • ERC-4337 lanes. Under the packed teaching expression nonce = (key << 64) | sequence, key 5 and sequence 9 give 5 * 2^64 + 9 = 92,233,720,368,547,758,089; sequence 10 gives 92,233,720,368,547,758,090. Independent key 6, sequence 0, gives 110,680,464,442,257,309,696. Parallel use still depends on the smart account’s validation logic and is separate from the bundler’s EOA transaction nonce.
  • PoW search nonce. Bitcoin’s header nonce is 32 bits, so it has 2^32 = 4,294,967,296 numeric candidates. At a hypothetical 100 TH/s, scanning that numeric space takes 4,294,967,296 / 100,000,000,000,000 = 0.00004294967296 seconds = 42.94967296 microseconds. Miners vary coinbase extraNonce, time or the transaction set to change the Merkle root and obtain new headers; this field is not account replay state.

Risks

  • Confusing EOA, contract, application, ERC-4337 and PoW nonce namespaces.
  • Reading the nonce from the wrong chain, fork, contract or EntryPoint.
  • Using a stale, inconsistent or malicious RPC response.
  • Concurrent signers allocating the same EOA transaction nonce.
  • A nonce gap blocking later local transaction candidates.
  • Treating a provider’s pending nonce as canonical state.
  • Forgetting that an included revert consumes EOA nonce and gas.
  • Failing to restore nonce and candidate lineage after a reorganization.
  • A same-nonce replacement missing the target node’s fee policy.
  • Assuming replacement globally deleted the old signed transaction.
  • Correlating equal numeric nonces from different senders or domains.
  • Omitting chain ID or another required signature-domain separator.
  • Failing to check and increment an application nonce atomically.
  • Wrong ERC-2612 owner, deadline, domain separator or token contract.
  • Replaying an application signature across chain, contract or version.
  • Misreading a contract account’s state nonce as a generic call counter.
  • Packing the wrong ERC-4337 nonce key or sequence width.
  • Mixing the bundler EOA nonce with a smart account’s UserOperation nonce.
  • Proxy upgrades or storage collisions changing application-nonce behavior.
  • Treating a finite PoW search nonce as authorization, replay state or proof by itself.

Common misconceptions

  • Every field called nonce has the same meaning and is globally used once.
  • A larger nonce makes a transaction safer, faster or more final.
  • An Ethereum transaction that reverts does not consume its sender nonce.
  • A nonce alone prevents every cross-chain, cross-contract and typed-message replay.
  • Every ERC-4337 smart account has one linear counter identical to an EOA transaction nonce.

Sources

Navigation

Search the wiki...