Pending, Dropped and Replaced Ethereum Transactions

One counter, one order

Ethereum is an account-based chain. Each account has a nonce, defined by ethereum.org as “a sequentially incrementing counter which indicates the transaction number from the account”. The first transaction from a new account uses nonce 0, the next uses 1, and so on.

The rule that follows is strict: a block cannot include a transaction with nonce N unless the account’s nonce is already N. The nonce is part of the signed transaction, so a miner cannot reorder an account’s transactions at will. It can only include the next one in sequence.

That single rule explains the three states users see.

Pending: in the pool, not in a block

A pending transaction is one that at least one node has accepted into its mempool but no block has included. The wallet’s “pending” label is a report from whichever node it queried, not a global status.

Why a pending transaction stays pending:

• The fee is below the market. Block space is scarce; builders prefer transactions that pay more.
• The account has a nonce gap. A lower nonce is missing, so this transaction cannot be included yet even if it pays well.
• The chain is congested. A sudden demand for blockspace raises the fee needed to be included promptly.

With EIP-1559-style fees, a transaction carries a max fee and a priority fee. If the base fee rises above the max fee, the transaction cannot be included until the base fee falls or the transaction is replaced with a higher cap.

Dropped: evicted from one pool

“Dropped” is the most misunderstood state. It usually means a node removed the transaction from its mempool, not that the network rejected it. Common causes are:

• Underpriced eviction. Pools have limits, and low-fee transactions are evicted first when the pool is full.
• Node restart or configuration change. An in-memory pool does not survive a restart unless it is persisted.
• Replacement. A different transaction with the same nonce was accepted, making the old one invalid.
• Expiry policies. Some clients drop transactions after a period without inclusion.

Crucially, a dropped transaction can still be mined. Other nodes may still hold it, and a builder may include it. The only reliable evidence is the account’s on-chain nonce: if the nonce has advanced past the transaction’s nonce without that transaction being included, it can never be mined.

Replaced: same nonce, higher fee

A replacement is a second transaction from the same account with the same nonce and a higher fee. Because the nonce is the same, only one of the two can be included. The first to be mined wins; the other becomes invalid.

Geth, the reference Ethereum client, enforces a price bump on replacements. Its --txpool.pricebump setting defaults to 10%, and the check requires the new fee to be strictly more than 10% above the old one. A replacement that raises the fee by exactly 10% can be rejected as “replacement transaction underpriced”; a slightly larger increase is accepted. Other clients have their own policies, and the mempool is not a single global queue, so a replacement may be accepted by one node and rejected by another.

A cancellation uses the same mechanism. A zero-value transfer to your own address, with the same nonce and a higher fee, consumes the nonce if it is mined first. The original transaction then cannot be included. This is not a protocol-level cancel; it is a race that the replacement usually wins because it pays more.

Worked example

Suppose an account’s nonce is 7 and the user sends three transactions:

• Nonce 7: a swap, fee 20 gwei, included in block 100.
• Nonce 8: a transfer, fee 8 gwei, sits in the pool while the base fee rises to 25 gwei.
• Nonce 9: another transfer, fee 30 gwei, queued behind nonce 8.

Nonce 9 pays more than enough, but it cannot be mined because nonce 8 is missing. The account’s on-chain nonce is 8, so the wallet shows two pending transactions.

To unblock the queue, the user replaces nonce 8 with the same transfer at 25 gwei. If the old fee was 8 gwei and the node requires a 10% bump, the replacement must be above 8.8 gwei; 25 gwei clears it easily. Once the replacement is mined, the account nonce becomes 9 and the queued nonce 9 can be included. The original 8-gwei transaction is now invalid forever.

What to check before replacing

1. Confirm the account nonce on-chain. A block explorer’s “nonce” field for the address is the authoritative next value. If it is already past the stuck transaction, the transaction is dead and no replacement is needed.
2. Use the same nonce, not a new one. A replacement with a different nonce is a separate transaction; it neither cancels nor accelerates the stuck one.
3. Budget for the fee. The replacement pays gas even if it is a zero-value self-transfer.
4. Expect propagation delay. A replacement broadcast to one node may take time to reach builders. Wallets usually rebroadcast, but there is no guarantee of instant global replacement.
5. Do not send a second payment to the recipient as a “fix”. If the original later lands, the recipient receives both.

Why this matters beyond a stuck trade

Nonce mechanics are the reason a wallet can show a transaction that is neither confirmed nor failed. They are also the reason a “cancelled” transaction can still appear later, and the reason a low-fee transaction can block everything behind it. Reading the nonce turns a confusing wallet state into a specific, checkable condition: either the next nonce is missing, or it is not.

The order rejection guide covers the exchange-side version of the same lesson: a rejected or stuck order is usually a rule being enforced, not a random failure. On Ethereum, the rule is the sequence.