An EVM transaction nonce identifies an account’s position in its transaction sequence. For an ordinary Ethereum sender, the next transaction must match the account’s current nonce. A bot must coordinate nonce allocation, track every transaction hash assigned to each nonce and reconcile inclusion before retrying. A pending nonce is a node’s view; replacing a transaction uses the same nonce, while a new nonce creates a separate attempt.
Separate chain state, pending state and your own reservations
An exchange client order ID identifies an exchange request. An Ethereum account nonce participates in transaction validity. Reusing a trading intent at a different nonce can execute the trade again, so nonce management does not replace the durable intent record described in crypto workflow idempotency.
For an ordinary externally owned account, or EOA, a transaction must have the nonce expected by the execution state. Geth’s transaction precheck and state transition checks that equality and increments the sender nonce before a message call executes. An included call that reverts still consumes its nonce. A rejected submission that never enters the chain does not.
Read these three values separately:
| Value | What it describes | What it cannot prove |
|---|---|---|
| Account nonce at latest | The next nonce in the endpoint’s current canonical head state | That this head is final or that no transaction is pending |
| Account nonce at pending | The endpoint’s proposed next state, including the transactions it considers | That every provider sees the same candidates |
| Locally reserved nonce | A slot your system has assigned to an intent or signed attempt | That the transaction was broadcast, accepted or included |
The Execution APIs nonce reference defines pending as a client-built sample next block, usually using its local mempool. It also distinguishes latest from safe and finalized state. Calling a latest result “confirmed” should not silently imply finality.
The method’s historical name, eth_getTransactionCount, is potentially misleading. EIP-7702 authorization processing can increment an authorizing account’s nonce, including when another account submits the transaction. The examples below exclude delegations and authorization-list changes. Smart-account operation nonces and chain-specific extensions require their own model.
Follow nonce 41 through a gap and a replacement
Consider a hypothetical Ethereum bot using one ordinary EOA. Its current account nonce is 41. It reserves 41 for token approval A, 42 for swap B and 43 for an independent transfer C. The numbers are decimal: an RPC response of 0x29 means 41; 0x2c means 44.
Assume the calls are otherwise valid, balances and block space are sufficient, no reorganization occurs during this timeline and provider P builds pending state from the contiguous executable candidates it holds. Provider Q has a different pool. Real endpoint behavior must be checked rather than inferred from this table.
| Time | Observation or action | Latest account nonce | P’s pending nonce | Operational meaning |
|---|---|---|---|---|
| 09:00 | Nothing has been broadcast | 41 | 41 | Local reservations do not change network state |
| 09:01 | P accepts A at 41; Q has not seen it | 41 | 42 | Q can still report pending 41 |
| 09:02 | P receives C at 43 before B | 41 | 42 | Missing 42 prevents C from joining the executable sequence |
| 09:03 | P receives B at 42 | 41 | 44 | P now holds the contiguous sequence 41, 42, 43 |
| 09:04 | P drops A; Q still holds A | 41 | 41 | P’s lower pending value does not invalidate A everywhere |
| 09:05 | P accepts replacement A2 at 41 | 41 | 44 | A and A2 remain competing candidates until inclusion resolves them |
| 09:06 | A2 succeeds in the canonical chain | 42 | 44 | Slot 41 is consumed by A2, not both candidates |
| 09:07 | B is included but its swap reverts | 43 | 44 | Failure consumes 42; it does not hold the nonce sequence at 42 |
| 09:08 | C succeeds | 44 | 44 | All three reserved slots have canonical outcomes |
Geth’s txpool inspection methods distinguish pending from queued transactions and group candidates by sender and nonce. These are non-standard methods; a managed provider may not expose them. The gap and provider-pool observations in the table apply that documented distinction under the stated assumptions.
There are four signed candidates, A, A2, B and C, but only three consumed nonce slots: 41, 42 and 43. The final next nonce is 41 + 3 = 44. A2 and B have different business outcomes even though both advance the sequence. A’s disappearance from P at 09:04 never established cancellation.
Approval and swap also have separate economic lifecycles. The token allowance guide explains the permission created by an approval. A later failed swap does not undo an earlier successful approval. Conversely, replacing an approval with a different action may leave a queued swap without the permission it needs.
Replacement competes for the same slot
A replacement preserves the sender and nonce while changing signed transaction fields, producing another hash. A fee-only replacement should preserve the approved destination, value and calldata. Changing those fields changes what may execute and needs a corresponding decision record.
“Cancellation” describes the purpose of a competing transaction. Broadcasting it does not erase the earlier candidate from every participant’s pool. If the original wins inclusion first, the cancellation cannot reverse that completed action. Track both hashes until the chain evidence resolves the slot.
Pool admission is also separate from consensus validity. Geth exposes a configurable replacement percentage through txpool.pricebump, with a documented default of 10%. That configuration does not establish a universal bump rule across providers, clients or transaction types. Confirm the endpoint’s required fee fields and inspect rejection responses.
For a hypothetical type-2 replacement, raising maxFeePerGas from 40 to 48 gwei and maxPriorityFeePerGas from 2 to 2.4 gwei raises each cap by 20%. This is arithmetic, not a guarantee of admission or inclusion.
Under EIP-1559’s fee calculation, if the inclusion block’s base fee is 28 gwei, the effective price is 28 + min(2.4, 48 − 28) = 30.4 gwei. At an illustrative 50,000 gas used, the execution fee is 50,000 × 30.4 × 10⁻⁹ = 0.00152 ETH. The 48 gwei cap is not automatically the amount paid. A higher cap still needs sufficient balance and does not bypass a nonce gap.
Coordinate all writers before allocating another nonce
Two workers can both read pending 44 and both choose 44. An RPC read is an observation, not an allocation lock. Use one coordinated allocator for every writer sharing a chain and sender, including manual wallet actions and maintenance scripts.
Persist a reservation before signing or broadcasting. A useful unique key is chain, sender and nonce; attach the business intent separately, and keep all replacement hashes under that reservation. One storage claim should own advancement of the slot. The implementation must prevent an expired or restarted worker from independently submitting a conflicting plan.
After a restart, simply taking the larger of a provider’s pending value and a local counter can hide a missing lower slot. Reconcile each unresolved reservation first. If local 43 exists but 42 was never submitted, moving to 44 leaves the gap in place. If an untracked wallet already used 42, reconstruct that outcome before assuming the old plan can continue.
Rebroadcasting the same signed bytes preserves the hash and nonce. Constructing a new transaction at a fresh nonce is a different action. An uncertain response to the first broadcast is therefore a reason to recover the original attempt, not automatically a reason to create a second trade.
Reconcile business success separately from nonce consumption
The transaction receipt API looks up a hash and returns a receipt or a not-found result. A null result alone does not distinguish an unseen transaction, an unconfirmed candidate or a provider observation problem. A recent receipt also requires checking that its block remains canonical under the chosen confirmation policy.
EIP-658 defines the receipt’s top-level success or failure status. In the timeline, B’s failure means its intended swap did not complete, while its included nonce was consumed. Record both facts. Do not wait for 42 to become reusable or mark the swap successful merely because the account nonce advanced.
Ordering does not enforce business dependencies. If C needs tokens bought by B, B’s revert does not automatically stop C from being included and failing too. Gate dependent actions on the actual prerequisite outcome rather than only on nonce progression. The table deliberately made C independent to expose that difference.
Likewise, a successful top-level transaction is only the start of economic reconciliation. Verify expected recipient amounts and relevant contract outcomes. The rebasing and transfer-fee token guide covers why token behavior can make a nominal amount an incomplete description of what arrived.
An expired swap remains a nonce-management concern until its fate is known. The DEX deadline and slippage guide explains that contract expiry is checked at execution; reaching the deadline does not remove a signed transaction from every pending pool.
Use a recovery worksheet before resuming the sender
Keep this record for the lowest unresolved nonce before allowing more work to accumulate behind it:
| Evidence to retain | Decision it supports |
|---|---|
| Chain, sender, intent and reserved nonce | Whether this slot belongs to the action being recovered |
| Every signed hash and decoded economic fields | Whether a replacement preserved or changed permission |
| Endpoint, observation time and head block | Whether differing pending values describe comparable state |
| Broadcast attempts and exact responses | Which candidate may already have propagated |
| Receipts, canonical block references and status | Which candidate consumed the slot and with what result |
| Prerequisite outcome, expiry and fee budget | Whether another attempt remains authorized and useful |
Validate recovery in a controlled environment with two workers allocating together, a lost broadcast response, a restart with an unbroadcast reservation, a dropped label at only one endpoint and an included revert. Also remove a recently observed block from the test chain to verify that tentative inclusion returns to reconciliation when reorganized away.
The acceptance condition is concrete: every reserved nonce has an explained state, every competing hash remains attached to that slot and business success comes from the intended on-chain outcome. When the lowest slot is uncertain, resolve that uncertainty before adding more signed work behind it.