Nonces, Replay and Ordering

Every transaction from an account carries a counter. It solves two problems and creates one.

What it solves

Replay. A signed transaction is valid data. Without a counter, anyone could rebroadcast it and have it execute again. The nonce ensures each is accepted once.

Ordering. Transactions from an account execute strictly in nonce order. Transaction five cannot execute before transaction four, regardless of fees.

Both properties are necessary and the second is the source of the confusion.

The stuck queue

If transaction four offers too low a fee to be included, transactions five and six cannot execute either, no matter what they offer.

This produces a situation where a user submits a high-fee transaction, sees it pending indefinitely, and cannot understand why. The answer is an earlier transaction they have forgotten about.

How to fix it

Find the lowest pending nonce for your address. Most wallets show it in advanced transaction details; explorers show it too.

Fix that one first. Either replace it with a higher fee, or cancel it by sending a zero-value transaction to yourself with the same nonce.

The queue behind it then processes in order.

Attempting to speed up a later transaction while an earlier one is stuck achieves nothing and costs a fee.

Replacement mechanics

A replacement uses the same nonce with a higher fee. Most implementations require the increase to exceed a threshold, commonly around ten percent, or the replacement is rejected.

You pay the replacement fee, not both.

Cross-chain replay

The same signed transaction being valid on two chains is a real problem when a chain splits.

Chain identifiers included in the signed data prevent it: a transaction signed for one chain identifier is invalid on another. A split executed without this protection exposes users to having transactions replayed on the other chain, and it has cost people money.

This is why any announced chain split should be met by moving nothing until replay protection is confirmed.

Practical notes

Do not manually set nonces unless you understand exactly what you are doing. A gap in the sequence blocks everything after it until it is filled.

Clearing a wallet’s local cache does not cancel a transaction. It removes it from your view; the network still has it and will execute it when conditions allow. This produces genuinely unpleasant surprises.

Withdrawals from a venue do not involve your nonce at all, because the venue signs from its own accounts. That is one reason withdrawals from platforms such as exchanges that let you specify the network are simpler than self-initiated transfers, and it is why the categories of error differ between the two.