You hit "confirm" on a transaction. Minutes pass. Then an hour. The status reads "pending" and it's not moving.
This happens more than people expect, and the mental model most have for why it happens is incomplete. Transactions don't get stuck because something is broken — they get stuck because of how the mempool works, and because fee markets are competitive.
The Mempool: Where Transactions Wait
When you submit a transaction, it doesn't go directly to the blockchain. It enters the mempool — short for memory pool — a holding area that every node maintains locally. Think of it as a public waiting room where submitted transactions sit until a miner or validator decides to include them in the next block.
That decision is economic. Validators sort pending transactions by fee. On Ethereum post-EIP-1559, each block has a base fee — a minimum price that adjusts algorithmically based on how full recent blocks have been. If your transaction's maximum fee is below the current base fee, it literally can't be included. If your max fee covers the base fee but your priority fee (the tip to validators) is low relative to competing transactions, you get deprioritized.
The result: your transaction waits, getting skipped block after block, until fees drop enough that your bid becomes competitive — or until you intervene.
On Bitcoin, there's no EIP-1559 base fee, but the logic is the same. Miners order by fee rate (satoshis per byte of transaction data), and low-fee transactions wait behind higher-paying ones.
Nonce Problems: The Other Way Transactions Get Stuck
On Ethereum, there's a second failure mode that has nothing to do with fees: nonce ordering.
Each Ethereum wallet tracks a nonce — a sequential counter for how many transactions you've sent. Transaction number one gets nonce 0, number two gets nonce 1, and so on. The rule is strict: transactions must be processed in order. If nonce 4 is pending and you submit a transaction with nonce 6, that nonce 6 transaction won't process — not because of fees, but because the network won't skip ahead. It's waiting for nonce 5 first.
This is easier to trigger than it sounds. Submitting two transactions quickly, fumbling a cancel, or switching between dApps that track nonces differently can create gaps that freeze everything queued after the gap.
What Happens If You Just Wait
A pending transaction can resolve on its own — or it can be evicted from the mempool.
If network congestion clears and fees drop, your transaction may eventually become competitive and get included in a block. This can take minutes, hours, or in rare cases days. During calm periods, low-fee transactions tend to clear. During a popular NFT mint or a network stress event, the mempool can fill so quickly that low bids have no realistic chance until conditions change.
The other outcome: nodes clean their mempools. Bitcoin Core drops unconfirmed transactions after 72 hours. Ethereum nodes have their own thresholds. When a node drops your transaction, it disappears from that node's mempool — but the signed transaction data still exists, and it can be rebroadcast. Someone (you, or anyone with the signed transaction hex) can resubmit it. Whether it gets picked up depends on whether the fee is now competitive.
That detail matters: a dropped transaction isn't permanently dead. The cryptographic signature remains valid. It can reenter the network.
How to Speed Up or Cancel
You don't have to wait. There are two standard interventions.
Speed up via replace-by-fee (RBF): Submit a new transaction with the exact same nonce but a higher fee. Most wallets offer this explicitly — MetaMask's "speed up" button handles it automatically. When validators see two transactions with the same sender and nonce, they include the higher-paying one; the lower-paying one becomes invalid the moment either is mined. The key is using the same nonce — that's what makes the new transaction a replacement, not an addition.
Cancel: Submit a transaction using that same stuck nonce, sending 0 ETH to your own wallet, with a fee high enough that it gets mined quickly. Once this "cancel" transaction lands on chain, your original is permanently invalid — same wallet, same nonce, nonce now used. It can never be processed. The tradeoff is that you pay a small fee for the cancel transaction itself.
One thing can go wrong with a cancel attempt: if you're too slow and your original transaction gets mined first, your cancel fails instead. You can't undo a transaction that's already confirmed.
On Bitcoin, there's an additional approach available to recipients: CPFP (Child Pays for Parent). If you're waiting to receive a payment that's stuck, you can spend the unconfirmed output in a new transaction with a high fee. Miners are incentivized to mine both transactions together — the child spends an output that only exists if the parent is mined first, so they include both. The combined fee rate across the parent and child is what matters.
Where the Constraints Actually Sit
The mempool isn't a single shared object — it's local to each node, and there's no central authority. Different nodes may have slightly different pending transaction sets depending on propagation timing. Fee estimation tools (like Etherscan's Gas Tracker) aggregate across many nodes, but estimates vary.
On Layer 2 networks — Arbitrum, Optimism, Base — transactions go to a sequencer rather than an open mempool. Sequencers typically process in order of arrival, not by fee bid. Stuck transactions are rare on L2s, but sequencer downtime creates its own delay — and a centralized sequencer can, in principle, reorder or delay transactions in ways that an open L1 mempool can't. Different mechanism, different risks.
EIP-1559 made Ethereum fee dynamics more predictable than they used to be. The base fee is visible, algorithmic, and transparent — but predictable doesn't mean stable. A high-demand event can push the base fee up many multiples in the span of a few blocks.
Timing
Now: RBF is the standard fix for stuck Ethereum transactions. CPFP is the Bitcoin-native tool for recipients. Both work reliably under normal conditions.
Next: Intent-based systems — CoW Protocol, UniswapX — abstract the fee and nonce problem away from users. You sign an intent; a solver handles the mechanics. This doesn't change the underlying mempool, but it removes users from having to manage it directly.
Later: Account abstraction (ERC-4337) could meaningfully change transaction submission — paymasters sponsoring fees, batching reducing nonce complexity. Still early, but directionally relevant if adoption grows.
Confirmation and Invalidation
Confirms the mechanism: Transaction eventually mined as fees drop, or replaced successfully via RBF, or dropped from mempool after timeout and rebroadcast succeeds.
What changes the picture: On L2s with centralized sequencers, a stuck transaction is a censorship concern, not a fee market concern. The diagnostic and the remedy are different there. Same label — stuck — but a structurally different problem.
Boundary
This covers Ethereum and Bitcoin specifically. Solana doesn't use a mempool in the same sense — transactions succeed or fail near-instantly at the protocol level, by design. The nonce mechanism described here is specific to EVM chains.
None of this constitutes advice on when to speed up, wait, or cancel. That depends on urgency, fee costs, and context that's outside the scope of a mechanism explanation.
