An Ethereum transaction that stays pending blocks everything the account sends afterward. The reason is the nonce, a sequence number that forces transactions from one account into strict order.
Nonces enforce order absolutely
Each account carries a counter, and every transaction it sends specifies the next expected value. A transaction with a higher value cannot be included until the gap is filled.
This prevents replay, since a signed transaction is valid only at one position in the account's sequence and cannot be resubmitted later.
It also means one underpriced transaction blocks the queue behind it, even if later transactions offer generous fees.
Underpricing is the usual cause
Inclusion depends on the fee a transaction offers relative to what others are offering at that moment, and the required level moves with demand.
A transaction priced against conditions that then changed sits in memory pools waiting for demand to fall back to its level.
It may eventually confirm, or it may be dropped when nodes evict low-priority entries to make room, at which point it disappears without ever failing.
Cancellation is actually replacement
There is no instruction that removes a pending transaction. The only mechanism is broadcasting a different transaction with the same nonce and a sufficiently higher fee.
Nodes accept the replacement and discard the original, and whichever is included first invalidates the other permanently.
A cancellation is therefore a replacement that does nothing useful: a transfer of zero value to the sender's own address, occupying the nonce so the original cannot confirm.
The fee increase has to clear a threshold
Nodes require a replacement to exceed the original by a meaningful margin, not merely by the smallest possible increment.
The rule exists to prevent the network being flooded with trivially different versions of the same transaction, which would waste relay capacity.
Wallets that offer a speed-up button are performing exactly this operation, resubmitting the same transaction at a higher fee under the same nonce.
Wallet state and node state can diverge
Wallets track the next nonce by asking a node, and different nodes may disagree about whether a pending transaction exists.
A wallet that resets its nonce tracking can produce a transaction reusing an already-consumed value, which is rejected, or skipping one, which never confirms.
Advanced wallet settings expose the nonce manually for this reason, since resolving a stuck queue sometimes requires setting the value deliberately rather than trusting an estimate.