Skip to content
Financial Context Wiki

How to recover from a wallet nonce gap

Find the first missing EVM account nonce, decide whether to replace or cancel it, and prevent queued transactions across wallets or devices.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

On an EVM-compatible chain, transactions from one externally owned account (EOA) execute in nonce order. If the next executable nonce is absent or stuck, transactions with higher nonces can remain queued even when their fees are high. Recover the lowest unresolved nonce first: confirm the chain and sender, compare confirmed and pending nonce data, then either replace the intended transaction or compete with it using a cancellation transaction at the same nonce.

A cancellation is not a protocol-level undo. It is usually a 0 ETH transfer from the account to itself that competes for the same nonce. Whichever valid transaction is included first wins; a confirmed transaction cannot be canceled this way.

This procedure applies to ordinary EVM EOA transactions. Smart-account or account-abstraction operations may use contract-defined nonce schemes, while UTXO networks use a different transaction model.

Why a nonce gap blocks the queue

An EOA’s nonce is a sequential counter. Only one transaction at a given nonce can execute, and the account cannot execute nonce 26 before nonce 25. Nodes therefore separate immediately executable transactions from higher-nonce transactions queued for future execution.

The queue is not one global, authoritative mempool. Each RPC node sees and retains a different subset of pending transactions. A transaction may appear in a wallet but not on an explorer, or appear through one RPC and be absent through another. That can mean it was never broadcast, was dropped from a node’s pool, or has not propagated to the service being queried.

eth_getTransactionCount with latest returns the count at the latest block state; for an EOA, interpret it as the next nonce after confirmed transactions. The same call with pending asks one node for its pending-state view. A difference between the two suggests that node knows about pending transactions, but it does not prove that every public node knows about them.

Diagnose before signing

  1. Stop sending from the affected address on every device and application. Record the network, chain ID, sender address, transaction hashes, nonces, recipients, values, calldata, gas limits, and fee fields.
  2. Verify that the wallet, explorer, and RPC all refer to the same chain and sender. A nonce belongs to an account on one chain, not to a wallet installation.
  3. Query eth_getTransactionCount for both latest and pending, preferably through two independent RPC providers. Treat disagreements as evidence of different mempool views, not as proof that on-chain state is inconsistent.
  4. Inspect the sender’s transactions by nonce. If available, a node’s transaction-pool API can distinguish executable pending entries from future queued entries. Public RPC providers often disable this non-standard API.
  5. Starting at the latest value, find the first nonce with no confirmed transaction. Determine whether a known transaction at that nonce is still visible, was dropped, or was only created locally.

Do not act from a wallet’s status label alone. The confirmed nonce, transaction receipt, and block inclusion on the correct chain are the decisive evidence.

Replace or cancel the first unresolved nonce

To preserve the original action: use the wallet’s speed-up function, or rebroadcast a transaction with the same sender, nonce, recipient, value, and calldata but competitive fees. Review every field before signing; changing the payload turns it into a different action.

To abandon the original action: while it is still unconfirmed, send a 0 ETH transfer from the address to itself using the same nonce and competitive fees. This only attempts to make the self-transfer win. The original can still confirm first, so never assume cancellation succeeded until the replacement has a receipt and the original remains unconfirmed.

Replacement admission is node policy, not a universal percentage. Both maxPriorityFeePerGas and maxFeePerGas may need to rise for an EIP-1559 transaction, and maxFeePerGas must remain usable under the current base fee. Wallet estimates and client rules differ; a replacement transaction underpriced error means the receiving node did not accept the replacement under its current policy.

After the lowest nonce confirms, recheck the receipt, latest, balances, and every higher-nonce transaction. Queued transactions may become executable immediately, while transactions dropped by all relevant nodes may need deliberate rebroadcasting. Never resend them blindly: first confirm that an earlier copy was not included.

Example

An address has confirmed transactions through nonce 24, so latest is 25. One RPC reports pending as 25, while the wallet lists nonce 26 and nonce 27 as queued. No provider can find a broadcast transaction at nonce 25.

The owner first verifies the correct chain, sender, and recorded payloads. If there was a desired transaction at nonce 25, the owner reconstructs and broadcasts that action at nonce 25 with current fees. If there was no desired action, the owner may instead submit a 0 ETH self-transfer at nonce 25. Increasing the fee of nonce 27 alone cannot close the gap.

Once nonce 25 is included, the owner checks its receipt before touching nonce 26 or nonce 27. Those transactions are then reviewed individually because either may have been dropped or may execute quickly after the gap closes.

Risks and stop conditions

  • A replacement can race the original. Assume the original recipient, value, and contract call may still execute until on-chain evidence shows otherwise.
  • Confirm the full sender address, chain ID, nonce, and calldata on a trusted display. Malware or an untrusted “recovery” site can substitute a transfer or approval.
  • Keep enough native currency for the replacement fee. Gas is charged for the transaction that is included, even if a contract call later reverts.
  • Do not reveal a seed phrase or private key to recover a nonce gap. No legitimate RPC, explorer, or support agent needs it.
  • If the address is compromised, repeated public replacements can become a fee race with an attacker. Stop using the compromised device and follow an incident-response plan instead of improvising larger fees.
  • If RPC providers disagree, the original recipient is unknown, the payload cannot be reconstructed, or a large contract interaction is at stake, pause and obtain expert help before signing.

For repeated use across devices or automated signers, prevent recurrence with one nonce allocator per account and chain, serialized signing, durable records of reserved nonces and hashes, and reconciliation against both confirmed state and the broadcaster’s pending pool. Merely resetting a wallet’s local activity history does not change on-chain state or other nodes’ mempools.

Common misconceptions

  • “A higher fee on nonce 27 lets it skip nonce 25.” It may improve priority only after earlier nonces are executable; it does not repair the gap.
  • “Not found means canceled.” A node may have dropped the transaction while another node, builder, or counterparty still has it. A signed transaction can be rebroadcast.
  • “A 0 ETH self-transfer reverses the original.” It only competes for the same nonce and has no effect after the original is confirmed.
  • “pending is the network’s final answer.” It is the queried node’s pending-state view and can differ across providers.

Sources

Navigation

Search the wiki...