RPC error -32000: nonce too low
Last updated:
At a glance
| Property | Value |
|---|---|
| Applies to | Ethereum, Polygon, BNB Smart Chain, Base and Robinhood Chain |
| JSON-RPC code | -32000 (upstream) |
| Origin | The network, passed through |
| Retryable | Not unchanged — rebuild with a fresh nonce |
| Related check | eth_getTransactionCount(address, "pending") |
Cause
Every account has a strictly increasing nonce. A submission whose nonce is at or below the account's current value is rejected by the node: either the transaction was already included, or another one took that slot. Triport classifies this as a network-level answer and passes it through rather than retrying elsewhere, because a resubmission would be rejected identically.
Solution
- Read the current nonce with eth_getTransactionCount at the pending tag and rebuild the transaction from it.
- If you are broadcasting concurrently, serialise nonce allocation per address — two workers reading the same pending count is the usual cause.
- Before resending, check whether your original transaction is already mined: a receipt means there is nothing to resend.
- To replace a stuck transaction deliberately, reuse its nonce with a higher fee instead of taking a new one.
Example
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32000,
"message": "nonce too low"
}
}FAQ
- Does Triport retry a rejected submission on another node?
- No. A nonce answer is the network's state, identical everywhere, so retrying elsewhere would only waste time and rate budget.
- Why did this appear under concurrency?
- Two senders read the same pending nonce and built two transactions for the same slot. One of them wins; the other gets this answer.