What Is a Transaction Nonce?

Every account on an Ethereum-style network carries a small piece of bookkeeping that most people never notice until something goes wrong: the nonce. It is one of the least glamorous fields in a transaction, yet it quietly enforces order and prevents a whole category of attacks. When a transaction refuses to confirm, or a wallet warns that a nonce is “too low,” understanding this counter is usually the fastest route to a fix. This article explains what a nonce is, how the network uses it, and how it connects to fees and the pending-transaction pool.

What a nonce actually is

According to the Ethereum documentation, a nonce is “a counter that indicates the number of transactions sent from an externally-owned account or the number of contracts created by a contract account.” In plain terms, it is a per-account tally. The first transaction you ever send from an account uses nonce 0, the next uses nonce 1, and so on. The count belongs to the account, not to the network as a whole, so two different accounts can each have a transaction with nonce 5 at the same time without any conflict.

There are two flavours worth separating. For an externally owned account (a normal wallet controlled by a private key), the nonce counts transactions sent. For a contract account, the nonce counts the number of other contracts that contract has created. Most everyday users only deal with the first kind. To see how accounts and keys fit together, our explainer on public and private keys covers the wider picture.

It helps to be precise about the value. The nonce is the count of transactions already sent and confirmed, which also happens to equal the sequence number of the next transaction you can send. A brand-new account that has never transacted has a nonce of 0, so its first transaction carries nonce 0; after that transaction confirms, the account’s nonce becomes 1, ready for the next. The number only advances on confirmation, not merely on broadcast, which is an important distinction when several of your transactions are waiting at once.

Why the network needs a counter at all

The nonce solves two problems at once. The first is ordering. Because transactions from a single account must be processed in strict nonce sequence, the sender can be sure that, say, an approval executes before the swap that depends on it. Without an enforced order, transactions broadcast at nearly the same moment could land in an unpredictable sequence.

The second is replay protection. The documentation notes that “only one transaction with a given nonce can be executed for each account,” which protects “against replay attacks where signed transactions are repeatedly broadcast and re-executed.” Once a transaction with nonce 7 is confirmed, any other transaction from that account carrying nonce 7 is invalid forever. That single rule means a valid signed transaction cannot be captured and re-submitted to drain an account a second time.

This second job is easy to underrate. Because every transaction is signed, a signature by itself does not become dangerous if someone copies it: the embedded nonce ties that signed message to exactly one slot in the account’s history. Rebroadcasting a confirmed transaction simply fails, because its nonce has already been used. It is a quiet but foundational security property, and it is one reason the same signed data cannot be weaponised across time.

How the nonce moves through a transaction’s life

When you build a transaction, your wallet reads your account’s current confirmed nonce from a node and assigns the next value. The transaction then carries that nonce as one of its signed fields, alongside the recipient, value, gas limit, and fee parameters. Because the nonce is inside the signed data, it cannot be altered without invalidating the signature. The full journey from signing to confirmation is covered in how a transaction gets confirmed.

Once broadcast, the transaction sits in the pending-transaction pool until a validator includes it in a block. A node will only mark a transaction as ready for the next block if its nonce follows on directly from the account’s last confirmed nonce. This is where the two states in a node’s pool come in.

Pending versus queued: the nonce gap

Nodes sort an account’s waiting transactions into two buckets. A pending transaction has a nonce in correct sequence and is eligible for the next block. A queued transaction has a nonce that is out of order, because an earlier nonce is missing, so the node holds it back until the gap is filled.

Imagine your account’s next expected nonce is 10. You send transaction 10, but you set its fee too low and it stalls. You then send transactions 11 and 12. Those two cannot execute, because the network will not skip nonce 10. They sit queued behind the stuck transaction. The practical lesson is that a single stalled low-nonce transaction can freeze everything you send afterwards. The waiting area itself is explored in what is the mempool.

Fixing a stuck transaction with the same nonce

Because only one transaction per nonce can confirm, you fix a stuck transaction by replacing it rather than sending a new one. This technique is often called replace-by-fee. You resubmit a transaction that reuses the exact same nonce as the stuck one, but with a higher fee, so validators prefer it. When the replacement confirms, it consumes that nonce and the original is discarded.

There are two common uses:

• Speed up: resend the same intended action with the same nonce and a higher fee.
• Cancel: send a zero-value transaction to your own address with the same nonce and a higher fee, so the nonce is consumed by a harmless transaction.

One critical detail: you must reuse the same nonce. If you accidentally use the next nonce instead, you create an additional transaction rather than a replacement, which can spend more than you intended. And once a transaction is confirmed on chain, it is final; replace-by-fee only works while a transaction is still pending.

Why replacements can be rejected

You cannot replace a transaction with one that offers only a trivially higher fee, because that would let anyone spam the network with cheap rewrites. Client software enforces a minimum increase. In Go Ethereum, the default is set by a parameter that requires the replacement to bid a certain percentage more than the original; its default is a 10% higher price. Submit a replacement below that threshold and the node returns a “transaction underpriced” error and keeps the original. When a replacement will not go through, the usual answer is simply to raise the fee further and try again.

Getting the fee right is its own topic. The fee you attach is split into components under the current fee model, which we break down in gas limit vs gas price.

Common nonce errors and what they mean

Most wallets manage nonces automatically, and for everyday use you never need to touch the field. Manual nonce control becomes useful mainly when clearing a jam, and some wallets expose an advanced setting for exactly that. For a grounding in how the whole ledger fits together, see our guide to how blockchains work.

How wallets handle nonces for you

Behind the scenes, a wallet builds each transaction by asking a node for your account’s current nonce and assigning the next value. Most of the time this is invisible and correct. It can drift, though, in a few situations worth knowing about. If you use the same account across two wallets or devices, each may track the nonce independently and produce a clash, where both try to use the same number. If a wallet’s connection to a node is stale, it may read an out-of-date nonce. And if you have broadcast several transactions that are still pending, the wallet has to decide whether to number the next one on top of the pending ones or reuse a pending nonce to replace.

The practical guidance is simple. Let the wallet manage the nonce unless you have a specific reason not to, and if you do edit it manually, only ever set it to the number of a stuck transaction (to replace it) or to the next expected value (to continue). Setting an arbitrary future nonce just parks the transaction in the queued state, where it will sit uselessly until the gap in front of it is filled. If your account is behaving strangely after a suspected compromise, nonce confusion is a symptom rather than a cause, and the priority is the response steps in wallet compromised: what to do.

The takeaway

The nonce is a simple counter with an outsized job. It guarantees that an account’s transactions execute in a known order and that no signed transaction can ever be replayed. It also explains one of the most common frustrations in crypto: a low-fee transaction stalling and dragging everything behind it. Once you know that transactions execute strictly by nonce, the fix follows naturally: reuse the nonce, raise the fee, and let the replacement take the slot.

Sources

• Ethereum Accounts — ethereum.org
• Transactions — ethereum.org
• Command-line Options (txpool.pricebump) — go-ethereum
• EVM transaction pool: pending vs queued — Chainstack Docs