Crypto Transaction Says “Nonce Too Low”? Prove Which Nonce the Account Already Used

“Nonce too low” is an EVM ordering error, not a signal to keep adding one until the transaction works. The network is telling you that the transaction was signed with a nonce below the state the receiving node accepts for that account. Before signing again, capture three values: the rejected transaction's nonce, eth_getTransactionCount for latest, and eth_getTransactionCount for pending. Those values show whether the nonce has already been confirmed, is occupied in the pending sequence, or disagrees with the wallet or RPC view.

The error means the signed transaction is behind the account state

The current Ethereum execution API lists Nonce too low as a transaction-submission error, and Base documents the practical meaning directly: a transaction using a nonce that has already been used is rejected. The remedy is not to change gas first. Establish the correct nonce state for the exact sender on the exact EVM chain.

This is the transaction nonce, not the signature nonce

EVM transactions contain an account transaction nonce used for ordering and replay protection. That is different from the cryptographic nonce involved internally in some signature algorithms. A wallet error saying nonce too low during eth_sendTransaction or eth_sendRawTransaction is about the sender account's transaction sequence.

Take the Three-Nonce Snapshot before changing anything

Record three numbers from one chain and one sender address.

• N — Signed nonce: the nonce inside the rejected transaction or transaction request.
• L — Latest count: eth_getTransactionCount(sender, "latest"), representing the confirmed account state at the latest block.
• P — Pending count: eth_getTransactionCount(sender, "pending"), representing the next count in the pending view known to that RPC endpoint.
• Also record chain ID, sender address, RPC endpoint and any transaction hash already produced.

Do not add one to eth_getTransactionCount

A persistent bad answer in older forum posts is to call eth_getTransactionCount and then add one. Ethereum's JSON-RPC specification already defines the returned transaction count as the account value used for the transaction nonce, and current Ethers documentation describes getTransactionCount as the value used as the nonce. Adding one blindly can create a gap and turn a nonce-too-low problem into a nonce-too-high or queued-transaction problem.

Pattern A: N is lower than L

If the rejected transaction has N < L, that nonce is behind the confirmed account state. A transaction with that sequence number has already advanced the account. Do not keep rebroadcasting the same signed raw transaction: its nonce is embedded in the signature. Rebuild the intended action from current state and let the wallet or library assign a fresh nonce, or explicitly use the correct next nonce only if you manage nonces yourself.

Example: signed 42, latest 43, pending 43

Nonce 42 is stale because the confirmed count has already advanced to 43. The clean next nonce is 43 according to this snapshot. Before recreating the action, inspect what transaction consumed nonce 42 so you do not accidentally repeat a transfer, approval, swap or contract call that already succeeded.

Find what consumed the old nonce before repeating the action

Search the sender's recent transactions on the correct network explorer or through your transaction records and find the transaction using N. A nonce proves ordering, not business intent. If nonce 42 already executed the exact transfer you were trying to send, rebuilding the same payment with nonce 43 could pay twice. Confirm destination, value, token action and status first.

A failed mined transaction still consumes its nonce

An EVM transaction that was included in a block but reverted still advanced the sender's nonce even though the intended contract state change failed. This is why a retry of an old signed transaction can return nonce too low after the earlier attempt shows failed. Diagnose the revert separately, then create a new transaction with the current nonce only if retrying is justified.

Pattern B: L is lower than P and N is below P

When P > L, the RPC endpoint knows about a contiguous pending sequence beyond the confirmed state. If your new transaction uses one of those occupied nonces, you may be colliding with a transaction already in that sequence. First determine whether you meant to create a new transaction or replace an existing one.

Example: signed 43, latest 43, pending 45

The chain has confirmed through nonce 42, while this RPC's pending view has advanced the next available nonce to 45. Nonces 43 and 44 are therefore accounted for in that pending sequence as seen by this endpoint. A brand-new action should not casually reuse 43. If your intention is specifically to replace the transaction at 43, replacement rules apply instead of normal new-transaction nonce assignment.

Replacement and new send are different operations

A replacement deliberately uses the same nonce as an existing pending transaction and changes the transaction or fee terms so a node will accept it as a replacement. A new send should use the next available nonce. Nodes can return errors such as replacement transaction underpriced when the same nonce is reused without a sufficient fee change. Do not solve every same-nonce conflict by incrementing the nonce, because that can leave the original pending action alive.

Pattern C: N equals P

If the signed nonce equals the pending count returned by the same RPC immediately before broadcast, the nonce appears to be the next available one in that endpoint's view. A subsequent nonce-too-low error means your snapshot and submission path disagree. Recheck the exact sender, chain ID and RPC, then query again before signing another transaction.

A fast account can change between reading and broadcasting

The nonce is state, not a permanent wallet setting. Another process can submit or confirm a transaction after your application reads P but before it broadcasts. This race is common when scripts, bots, backend workers, scheduled jobs or two application instances share one EOA. The correct fix is coordinated nonce allocation, not a retry loop that repeatedly calls getTransactionCount.

Concurrent senders need one nonce authority

If multiple workers sign from one EOA, reserve nonces atomically in one shared system or serialize transaction creation. Alchemy's current concurrent-transaction guidance explicitly states that fully signed transactions still require the sender to manage sequential nonces. A process-local counter is insufficient when several machines or containers can sign from the same account.

Ethers already uses the pending nonce when populating normal transactions

Current Ethers v6 documentation says signer.populateTransaction fills a missing nonce using signer.getNonce("pending"). If an application manually overrides that field with a cached value, it can defeat the library's normal behavior and create the error itself. Prefer automatic nonce assignment for ordinary sequential sends unless the application has a deliberate nonce manager.

Viem exposes the same underlying account count

Viem's getTransactionCount returns the number of transactions an account has sent and supports the pending block tag. This is the same JSON-RPC concept, not a separate wallet counter. If an application uses Viem, query the intended block tag and avoid mixing a cached counter from one service with broadcasts through another without coordination.

Different RPC endpoints can disagree about pending transactions

Confirmed state converges through the chain, but pending transaction pools are node or provider views. Geth's txpool documentation describes pending and queued transactions in the local transaction pool, while Alchemy notes that its pending-transaction subscription reports transactions in the Alchemy mempool. A failover setup can therefore read P from one pending view and broadcast through another. Use a consistent submission path or a nonce manager that reconciles provider changes.

When RPCs disagree, anchor on confirmed state before acting

Compare L from reputable endpoints first. If confirmed counts disagree, verify chain ID and block height because one endpoint may be stale or connected to the wrong network. If L agrees but P differs, the disagreement is likely about mempool visibility. Do not overwrite an existing transaction merely because one provider cannot see it; search for the known hashes and wait briefly for propagation before deciding.

The same address has a separate nonce on every EVM chain

Ethereum Mainnet, Base, Arbitrum, Polygon and testnets maintain independent account state. The same 0x address can therefore have nonce 200 on one chain and nonce 3 on another. Always record the chain ID with the nonce snapshot. Copying a cached nonce from another network is not valid nonce management.

Hardware wallets do not require exposing the key to repair this

The transaction nonce is public chain state. If a hardware-wallet front end has stale activity or repeatedly proposes an old nonce, you can verify the correct account state through a block explorer or RPC and use another compatible interface that keeps signing on the hardware device. Do not export the seed phrase or private key merely to solve a nonce error.

Wallet users should repair evidence, not manually count upward

For an ordinary self-custody wallet, first inspect recent and pending transactions from the same address on the exact network. If an older transaction already used the rejected nonce, let the wallet rebuild the intended action after its state refreshes. Use custom nonce controls only when you understand whether you are creating a new action or replacing an existing one.

Developers should log the nonce before signing

For every outgoing transaction, persist sender, chain ID, assigned nonce, unsigned intent, signed transaction hash, broadcast endpoint and final transaction hash or error. That record turns a vague production complaint into a deterministic question: which worker reserved N, what did it sign, and did another transaction from the same account consume N first?

Do not reuse a raw signed transaction after the nonce is consumed

Changing a nonce changes the signed transaction. You cannot repair an already signed raw transaction by editing its nonce field after signing and keeping the old signature. Reconstruct the transaction with current state and sign again through the legitimate signer.

Pattern D: N is greater than P

That is not nonce too low according to the captured state; it is a future nonce or nonce-gap pattern. Later nonces can queue behind missing earlier ones on nonce-ordered EVM accounts. Move to the separate nonce-too-high or pending-queue diagnosis instead of increasing N further.

A compact repair sequence

Use this in order and stop when the pattern is proven.

• 1. Confirm the exact EVM chain ID and sender address.
• 2. Record the rejected transaction nonce N before discarding anything.
• 3. Query eth_getTransactionCount for both "latest" and "pending" through the RPC used for submission.
• 4. If N < L, find the confirmed transaction that consumed N and decide whether the intended action already happened.
• 5. If L <= N < P, inspect the pending transaction using that nonce before choosing replacement or a new send.
• 6. If N = P but broadcast says nonce too low, refresh the snapshot and check for concurrent senders or RPC disagreement.
• 7. If N > P, stop: this is a nonce-gap or nonce-too-high branch.
• 8. Rebuild and re-sign only after you know whether the old action executed, failed, remains pending or was never accepted.

Four mistakes that make nonce recovery worse

Avoid these shortcuts.

• Adding one to every getTransactionCount result without understanding what the RPC already returned.
• Increasing nonce repeatedly until an error disappears, which can create gaps and queued transactions.
• Resending the same payment with a new nonce before checking whether the old nonce already executed it.
• Running several independent nonce counters for one EOA without atomic coordination.

What this page deliberately leaves to neighboring guides

If a lower pending transaction is blocking several later transactions, the queue guide owns the oldest-first recovery. If the error is nonce too high, the missing earlier nonce is the primary problem. If you are deliberately canceling or replacing one pending transaction, the cancellation guide owns the control decision. If the transaction was mined with status failed and gas was charged, the failure-receipt guide owns the retry decision.

What can change after August 7, 2026

Wallet interfaces, provider mempool visibility and replacement policies can change, but the core evidence remains stable: an EVM transaction contains a sender nonce, eth_getTransactionCount exposes the account count at tags such as latest and pending, and the signed transaction cannot be repaired after signing without creating a new signature. Recheck client-specific replacement rules before forcing a manual replacement.

Sources checked on August 7, 2026

Primary protocol, client and library documentation was prioritized over forum shortcuts.

• Ethereum Execution APIs — eth_sendRawTransaction error definitions — https://ethereum.github.io/execution-apis/api/methods/eth_sendRawTransaction/
• Ethereum.org — JSON-RPC eth_getTransactionCount — https://ethereum.org/developers/docs/apis/json-rpc/
• Base documentation — troubleshooting nonce gaps and nonce too low — https://docs.base.org/base-chain/network-information/troubleshooting-transactions
• Geth — txpool namespace and pending/queued transaction inspection — https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool
• Ethers v6 — provider and signer nonce behavior — https://docs.ethers.org/v6/api/providers/
• Viem — getTransactionCount — https://viem.sh/docs/actions/public/getTransactionCount
• Alchemy — pending, mined, dropped and replaced Ethereum transactions — https://www.alchemy.com/docs/ethereum-transactions-pending-mined-dropped-replaced

FAQ