Nonces: why Ethereum transactions wait in line

On Bitcoin, two unrelated payments from the same wallet can confirm in any order. On Ethereum, they can't: every transaction from an address has a number, and the network processes them strictly in sequence. That number is the nonce, and it explains some of the most confusing moments in an Ethereum wallet — a transaction that won't confirm, followed by every later one getting stuck behind it.

What the nonce is

For an ordinary Ethereum account, the nonce is a counter: the number of transactions that address has sent. The first transaction uses nonce 0, the next uses 1, and so on. Each transaction you sign includes its nonce, and the network will only accept nonce n after nonce n − 1 has been included.

It does two jobs:

• Replay protection. A signed transaction can't be submitted twice, because once nonce 5 is used, any other transaction with nonce 5 from that address is invalid.
• Ordering. Transactions from one account execute in exactly the order you intended, which matters when one depends on another — approve, then swap.

Why one stuck transaction blocks the rest

The ordering rule has a side effect. If nonce 5 is sitting in the mempool with a fee too low to be picked up, nonce 6, 7 and 8 can't be included either — no matter how much they pay. They wait in line behind it.

That's why a single underpriced transaction can make a wallet look frozen. Nothing is lost; the queue is simply blocked at one position.

Unblocking the queue

Because each nonce can be used only once, you fix a stuck transaction by replacing it:

• Speed it up: sign a new transaction with the same nonce and a higher fee. Nodes replace the old version, and whichever gets included first wins.
• Cancel it: sign a transaction with the same nonce that sends nothing to yourself, with a higher fee. When it confirms, the original can never confirm.

Replacements generally need a meaningfully higher fee than the original to be accepted. Stuck transactions and replace-by-fee covers the equivalent tools on Bitcoin.

Common nonce problems

• "Nonce too low". A transaction with that nonce has already been used — often because another wallet or device sent from the same address.
• Gaps. A transaction with nonce 9 when the account is only at 7 will wait until 7 and 8 exist. Usually a sign that something was dropped or signed elsewhere.
• Two devices, one account. If two apps send from the same address at once, they can both pick the same nonce; one transaction will fail.

How other chains handle it

• Bitcoin and other UTXO chains don't have account nonces. Each transaction spends specific coins, and a coin can only be spent once — that's what prevents replays and double-spends.
• Solana uses a recent blockhash instead: a transaction is valid only for a short window. For signing that takes longer — like collecting approvals on two devices — it offers durable nonces, stored in a special account.

Smart accounts have nonces too

Smart-contract accounts built on ERC-4337 don't send ordinary transactions. They sign user operations, which a bundler submits through a shared EntryPoint contract. Each account still has a nonce, tracked by the EntryPoint, with the same replay protection. The standard also allows several independent nonce sequences per account, so unrelated operations don't have to wait for each other. Account abstraction from first principles explains the bigger picture.

Nonces in SSP

On Ethereum and the other EVM chains SSP supports, your SSP account is an ERC-4337 smart account controlled by your 2-of-2 multisig. Every operation includes its nonce, and both SSP Wallet and SSP Key sign over it — so an approved operation can't be replayed, and can't be reused in another position in your history.

One practical consequence: your account contract is deployed by the first operation you send from it. That first send includes the deployment, so it uses noticeably more gas than the sends that follow. That's expected, and it happens once per account per chain.

The honest summary

The nonce is a counter that makes every Ethereum account process its transactions once, and in order. That protects you from replays and keeps dependent transactions in sequence — at the cost that one underpriced transaction can hold up everything behind it.

When that happens, don't send more transactions on top. Replace the stuck one with the same nonce and a higher fee, or cancel it, and the queue clears.