A transaction sitting in "pending" is one of the more frustrating experiences in crypto — especially when you're waiting to complete a swap, bridge funds, or confirm an urgent payment. The wallet shows it submitted, the money left, but nothing confirms. Meanwhile, block explorers show the transaction hanging in the mempool.
There's a reason this happens. And there are specific steps that can move it forward. The mechanism isn't complicated once you understand what the mempool is doing — and why your transaction is stuck there in the first place.
Why Transactions Get Stuck
Every blockchain has a mempool — a waiting room for unconfirmed transactions. When you submit a transaction, it doesn't go directly to the chain. It enters the mempool and waits for a miner or validator to include it in a block.
The deciding factor is almost always the fee. Validators pick transactions from the mempool to maximize revenue, so higher-fee transactions get included first. When network congestion spikes — during a popular NFT mint, a market crash, or a major protocol launch — competition for block space intensifies. Transactions with fees below the clearing threshold fall to the back of the queue. If gas prices stay elevated long enough, your transaction might sit untouched for hours or even days.
How to Speed Up on Ethereum (and EVM Chains)
Post-EIP-1559, Ethereum transactions have two fee components: the base fee (mandatory, burned, set algorithmically by the network based on demand) and the priority fee — also called the "tip" — paid to validators and your main lever for queue position.
To speed up a stuck transaction, you need to resubmit a new transaction with the same nonce as the stuck one, but with a higher fee. The nonce is a sequence number that ensures transactions process in order. Because the network only accepts one transaction per nonce, a higher-fee version with the same nonce effectively replaces the original — once the new transaction is included, the old one becomes invalid.
Most wallets abstract this. MetaMask has a "Speed Up" button that does exactly this behind the scenes. If you're setting it manually: increase your max priority fee (tip) by at least 10-15%. Many nodes won't relay a replacement unless the new fee is at least 10% higher than the original.
How to Speed Up on Bitcoin
Bitcoin has two mechanisms, and neither is automatic.
Replace-by-Fee (RBF) lets you rebroadcast a transaction with a higher fee — but only if the original was marked as RBF-eligible when first broadcast. Not all Bitcoin wallets do this by default. If your transaction is RBF-eligible, wallets like Electrum let you create the replacement directly.
Child-Pays-for-Parent (CPFP) works differently. If you control an output from the stuck transaction, you can spend that output in a new transaction with a high fee. Miners optimizing for revenue will include the parent transaction alongside the child, since they can't include one without the other. CPFP is also available to recipients: if you're waiting on an incoming payment that the sender stuck with a low fee, and you control the destination address, you can initiate CPFP yourself.
Where Constraints Live
Nonce ordering is the binding constraint on EVM chains. You can't skip a nonce. If nonce 47 is stuck, nonce 48 cannot confirm until 47 is resolved — even if nonce 48 has a much higher fee. A single stuck transaction can block every subsequent transaction from that address. This is why catching it early matters.
The replacement fee threshold also matters practically: most nodes won't relay a replacement unless the new fee clears at least 10% above the original. Submitting a replacement with only a marginal bump often means that replacement also gets stuck.
What's Changed
EIP-1559 made the base fee more predictable. The fee adjusts automatically each block, so temporary congestion often self-corrects faster than under the old first-price auction system. Sometimes the right move is to wait out a short spike rather than overpay to jump the queue — especially if the transaction isn't time-sensitive.
Private mempools — services like Flashbots Protect — submit transactions directly to block builders, bypassing the public mempool entirely. This removes front-running risk and can be useful for high-value or time-sensitive transactions.
What Would Confirm This Works
The confirmation signal is simple: transaction status changes from pending to confirmed on the block explorer, with a block number assigned. If you submitted a replacement, the original disappears from the mempool and only the replacement shows — that's expected, not an error.
What Would Invalidate the Approach
Speed-up methods fail in specific scenarios:
- The wallet doesn't support replacement transactions — verify this before relying on the approach
- The original transaction was already included before the replacement broadcast — both can't execute for the same nonce, and only one wins
- The nonce is stuck due to a wallet synchronization bug, not mempool positioning — replacement won't help until the wallet state corrects itself
- On Bitcoin, RBF fails if the original wasn't flagged RBF-eligible at the time of broadcast
Timing Perspective
Now: Check the block explorer first. Confirm the transaction is genuinely pending in the mempool — not already included but delayed in your wallet's display. The block explorer is authoritative; the wallet UI sometimes lags.
Next: If the network is temporarily congested and the transaction isn't time-critical, waiting 15-30 minutes often costs nothing. Fee spikes are usually short. If it is time-critical, submit the replacement immediately.
Later: Wallet improvements — better gas estimation, automatic RBF flagging, one-click speed-up buttons — are reducing how often this situation occurs. The underlying mechanism is stable, but the tooling is becoming more accessible.
What This Doesn't Cover
This explanation addresses pending transactions in the public mempool on EVM chains and Bitcoin. It doesn't apply to stuck off-chain transactions — Lightning channels, Layer 2 operations, and exchange-internal transfers have different resolution paths. It also isn't a guide for failed transactions. A transaction with status "reverted" on-chain has already been processed; it didn't succeed, but it isn't stuck. That's a separate problem requiring different analysis.
The mechanism works as described. Whether it resolves quickly depends on network conditions and wallet support — both of which you can verify before committing to a path.
