Crypto Transaction Says “Nonce Too High”? Find the Gap Before the Transaction

A transaction nonce that is too high is ahead of the EVM account's usable sequence. The fix is usually not to increase gas or keep changing the nonce until the error disappears. Find the first missing nonce before the transaction. If the high-nonce transaction was never accepted, rebuild it with the correct next nonce. If a node kept it as a queued future transaction, decide whether you still want that transaction before you fill the gap that could eventually make it executable.

The direct answer: a higher nonce cannot skip the missing sequence

Ordinary EVM transactions from one externally owned account are ordered by that account's nonce. A transaction that needs nonce 23 cannot execute while nonce 20 is still the next required position. Some clients or RPC paths may reject a future nonce; others can retain future transactions in a queued pool. Either way, the sequence must become contiguous before the high transaction can execute.

The error message is not proof that the transaction entered the mempool

Treat 'nonce too high' as a diagnosis trigger, not as a universal transaction status. The Ethereum execution interface recognizes a nonce-too-high validation condition, while Geth separately documents a queued pool for transactions scheduled for future execution. Your RPC provider, wallet or simulation layer may therefore surface an error even though another client could retain the same future transaction. Record the transaction hash only if one was actually returned.

Use the First-Missing-Nonce Audit

Build the sequence from the account state forward.

• Sender — the exact EVM address that signed the transaction
• Chain — the exact network and chain ID
• Target nonce T — the nonce inside the transaction that failed or queued
• Confirmed frontier C — eth_getTransactionCount(sender, "latest")
• Pending frontier P — eth_getTransactionCount(sender, "pending") from the RPC you are diagnosing
• First missing nonce M — the lowest nonce at or above C that is not already covered by a valid contiguous pending transaction
• High-transaction state — rejected, unknown, pending, queued, replaced or already mined
• Intent — whether you still want the high-nonce transaction to execute

Query the confirmed nonce first

Ethereum's JSON-RPC method eth_getTransactionCount returns the number of transactions sent from an address at a requested block state. With the latest tag, the result describes the confirmed chain state seen by that RPC. That value is the next nonce required if no earlier pending sequence is being considered.

Then query the pending view from the same RPC

The pending tag adds the RPC node's view of pending state. Current Base documentation explicitly describes eth_getTransactionCount with pending as the value to use for the next transaction when pre-confirmed or pending transactions exist. Compare latest and pending rather than using one value without context.

Foundry users can inspect both frontiers without signing anything

Current Foundry Cast supports a block tag on its nonce command. With an RPC URL configured, query the same sender twice: `cast nonce <ADDRESS> --block latest` and `cast nonce <ADDRESS> --block pending`. These are read-only checks; they do not repair or broadcast a transaction.

Worked example — confirmed 18, pending 20, target 23

Suppose latest returns 18, pending returns 20 and the transaction was signed with nonce 23. The RPC already sees a contiguous pending sequence covering 18 and 19, so the first missing nonce is 20. Nonces 20, 21 and 22 must be accounted for before nonce 23 can execute. Fixing nonce 23 first does not remove that gap.

Worked example — confirmed 18, pending 18, target 23

Here the RPC sees no contiguous pending transactions beyond confirmed state. The gap starts immediately at nonce 18. If the nonce-23 transaction was rejected and you only intended one transaction, discard that signed transaction and create a fresh one using the correct next nonce rather than fabricating five unnecessary transactions.

A high transaction that was rejected is simpler than one that was queued

If eth_sendRawTransaction returned an error and no transaction hash or node evidence shows the transaction was accepted, treat the signed payload as unusable for the current sequence. A transaction's signed nonce cannot be edited in place; build and sign a new transaction with the correct nonce.

A queued future transaction is a latent transaction

Geth's txpool documentation separates pending transactions from queued transactions that are scheduled for future execution. A queued nonce-23 transaction is not executable while the lower sequence is incomplete, but it should not be forgotten. If it remains in a node's pool and the missing nonces later become valid, it can move toward execution.

Inspect the node's queued pool when you control the RPC

Geth exposes txpool_content and txpool_inspect as non-standard RPC methods. Their queued section is organized by sender and nonce, which makes it useful for proving that a future transaction is actually retained by that node. Public RPC providers may not expose the txpool namespace, so lack of txpool access is not proof that no queued copy exists elsewhere.

Decide whether the high-nonce transaction is still wanted before filling the gap

This is the safety step most generic nonce guides omit. If nonce 23 contains a transfer, approval or contract call you no longer want, blindly submitting nonces 20, 21 and 22 can eventually make 23 executable. Record the recipient, value and calldata before repairing the lower sequence.

If the queued high transaction is wanted, repair from the first missing nonce

Start at M, the first missing nonce. If a legitimate transaction for M exists but is pending with an inadequate fee, use the wallet's supported replacement or speed-up path. If no transaction for M was ever created and you actually intended an operation at that position, create the intended transaction with M. Re-check the frontier after each resolution instead of filling the whole range blindly.

If the queued high transaction is unwanted, do not activate it accidentally

Before closing the lower gap, determine whether your wallet or node can replace the unwanted queued transaction at the same nonce with a harmless intended replacement. Same-nonce replacement rules are client-specific and normally require a sufficiently higher fee. The replacement itself will remain unable to execute until earlier nonces are resolved, but preparing it first can prevent the original future action from becoming the winning transaction when the gap closes.

Cancellation does not delete a nonce from Ethereum

Wallet cancellation is normally another transaction competing at the same nonce. MetaMask documents cancellation as a same-nonce replacement, commonly a zero-value transaction to the sender with a higher fee. The sequence still contains that nonce; the goal is for the replacement to be included instead of the unwanted original.

Do not solve nonce too high by repeatedly subtracting one

The right nonce is not found by trial and error. Query account state, inspect known pending transactions and identify the first missing position. Repeated manual edits can create duplicate intents, replacement conflicts or a second gap.

Do not add one to eth_getTransactionCount

The transaction count returned by the RPC is already the account nonce value for that state. Current Base and Viem documentation both use the transaction count itself as the nonce reference. Adding one blindly can skip the next required position and create the exact high-nonce problem this page is repairing.

Higher gas does not make a future nonce executable

A fee increase can help a valid transaction compete for inclusion or satisfy same-nonce replacement rules. It cannot allow nonce 23 to execute before nonce 20, 21 and 22 are resolved. Base's current troubleshooting documentation states that later nonces queue behind an earlier missing or pending nonce regardless of their fees.

Check the chain before diagnosing the sequence

The same 0x address can have independent nonce histories on Ethereum, Base, Arbitrum, Polygon, BNB Smart Chain and other EVM networks. A nonce that is correct on one chain can be far ahead on another. Query eth_chainId and the transaction count from the exact network where the transaction was meant to execute.

Check the sender, not only the connected wallet label

A wallet can contain several accounts, imported keys and hardware accounts. The nonce belongs to the signing address on that chain. If a backend or wallet switched signer accounts, comparing the transaction to another account's transaction count produces a meaningless diagnosis.

RPC disagreement can make the gap appear or disappear

The pending view is tied to what a particular node or provider sees. Ethereum Execution API discussions note that a pending block or mempool view is not a globally synchronized object, and transactions can be replaced, dropped or visible through one route but not another. If two RPCs disagree, keep the confirmed latest value as the stable anchor and investigate where the pending transactions were actually broadcast.

Private submission paths make pending counts less portable

A transaction sent through a private relay or provider-specific route may not appear in another public node's mempool. A backend that reads the pending nonce from provider A but submits through provider B can therefore build a sequence from two different views. Use one coordinated nonce allocator and reconcile against receipts and confirmed state.

A backend can create nonce gaps after a crash or failed broadcast

A common automation failure is allocating nonce 40 locally, incrementing the local counter to 41, and then failing to broadcast 40. The next worker submits 41, which is now ahead of the network sequence. Persist nonce allocation carefully and mark a nonce as truly in flight only when the submission state is known.

Multiple workers need one nonce authority

Two services signing from the same EOA should not independently guess the next nonce. Coordinate allocation atomically or serialize signing through one service. Otherwise one worker can jump ahead while another holds or loses the missing transaction, creating both nonce-too-low conflicts and nonce-too-high gaps.

A mined failed transaction still advances the nonce

If a transaction was included in a block but the contract execution reverted, the account nonce was still consumed. Do not recreate a supposed 'missing' nonce that already exists in confirmed history. Check the receipt first. The separate failed-transaction guide owns the question of whether the contract action should be retried.

A dropped pending transaction can reopen a gap

A wallet or backend may believe nonce 20 is pending while the RPC that later receives nonce 21 no longer has 20 in its executable pool. If 20 was never confirmed and is no longer available to that node, the sequence can appear as a future-nonce gap. Re-broadcast or replace the intended nonce-20 transaction rather than increasing nonce 21's fee.

MetaMask custom nonce is an advanced repair tool, not a default setting

MetaMask currently allows custom nonce editing in advanced transaction details and documents it mainly for speeding up or cancelling pending transactions. Manual nonce editing is useful when you have already mapped the queue. Turning it on before you know the first missing nonce makes it easier to create another gap.

Smart-account and UserOperation nonces are outside this article

ERC-4337 smart accounts and other account-abstraction systems can use nonce structures that do not behave like the single sequential EOA transaction nonce described here. If the error comes from a bundler, UserOperation or smart-account SDK, follow that system's nonce documentation instead of forcing an EOA repair.

An exchange withdrawal nonce is normally not yours to repair

If a centralized exchange is sending from its own hot wallet, the exchange controls the signing key and transaction sequence. A receiving user cannot fix that sender's nonce from a personal wallet. Use the exchange withdrawal status, TXID and support workflow instead.

Use five final verdicts

Finish the audit with a specific state.

• REBUILD AT NEXT NONCE — the high transaction was rejected and only one intended action needs to be sent.
• GAP STARTS AT M — one or more lower nonces are missing; repair from the first missing nonce.
• QUEUED AND WANTED — the high transaction is retained for future execution; preserve it while resolving lower nonces in order.
• QUEUED AND UNWANTED — prevent accidental activation by replacing or otherwise neutralizing that same future nonce before deliberately closing the gap.
• RPC / SIGNER MISMATCH — the apparent gap changes across providers, chains or sender accounts; reconcile the environment before signing again.

The safe nonce-too-high procedure

Use this order.

• 1. Record chain ID, sender, target nonce, recipient, value, calldata and any returned transaction hash.
• 2. Query eth_getTransactionCount for latest and pending from the same RPC.
• 3. Inspect explorer history and, where available, the node's pending and queued txpool entries.
• 4. Find the first missing nonce rather than focusing on the highest transaction.
• 5. Decide whether every already-signed future transaction is still wanted.
• 6. If the high transaction was rejected, rebuild the intended action with the correct next nonce.
• 7. If it is queued, repair or replace from the lowest missing nonce while protecting against accidental execution of unwanted future transactions.
• 8. Re-query the account state after each confirmed or replaced nonce instead of assuming the whole local queue is still accurate.

Why this page is separate from nonce too low

Nonce too low means the submitted transaction is behind the account state accepted by the node; the earlier nonce has already been consumed or is otherwise no longer valid for that transaction. Nonce too high is the opposite sequencing problem: the transaction is ahead of at least one required position. The repair direction therefore reverses—from finding what already used the nonce to finding what is missing before it.

Why this page is separate from the pending-queue guide

The existing pending-queue guide starts from the symptom that one older transaction is blocking later sends and maps the entire queue. This page starts from the explicit high-nonce condition and owns the narrower task of locating the first missing nonce, distinguishing rejected from queued future transactions and deciding whether a retained high transaction should ever become executable.

What can change after August 8, 2026

Wallet controls, RPC error codes, pending-state implementation and transaction-pool policies can change. The durable EVM evidence is the sender, chain, signed nonce, confirmed transaction count and the existence or absence of a contiguous lower nonce sequence. Recheck client-specific replacement and mempool rules before forcing manual nonce repairs.

Sources checked on August 8, 2026

Primary Ethereum specification, client, wallet and library documentation was prioritized.

• Ethereum.org — Transactions — https://ethereum.org/developers/docs/transactions/
• Ethereum.org — JSON-RPC eth_getTransactionCount — https://ethereum.org/developers/docs/apis/json-rpc/
• Ethereum Execution APIs — eth_sendRawTransaction — https://ethereum.github.io/execution-apis/api/methods/eth_sendRawTransaction/
• Ethereum Execution APIs — nonce error-code consistency discussion — https://github.com/ethereum/execution-apis/issues/817
• Base documentation — Troubleshooting Transactions — https://docs.base.org/base-chain/network-information/troubleshooting-transactions
• Base documentation — eth_getTransactionCount — https://docs.base.org/base-chain/api-reference/ethereum-json-rpc-api/eth_getTransactionCount
• Geth — txpool namespace — https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool
• MetaMask — Customize a transaction nonce — https://support.metamask.io/configure/transactions/how-to-customize-a-transaction-nonce/
• MetaMask — Speed up or cancel a pending transaction — https://support.metamask.io/manage-crypto/transactions/how-to-speed-up-or-cancel-a-pending-transaction/
• Viem — getTransactionCount — https://viem.sh/docs/actions/public/getTransactionCount
• Foundry — cast nonce — https://getfoundry.sh/reference/cast/nonce/

FAQ