You sent Bitcoin and the transaction has been "unconfirmed" for hours. Don't panic. The coins aren't lost. Here's exactly what's happening and the two clean ways to fix it.
You hit Send. The transaction "broadcast successfully." Your wallet shows a transaction ID. Six hours later it's still unconfirmed. Your friend on the receiving end is asking what happened. The mempool says the network is congested. You start googling "Bitcoin transaction stuck" at 11pm and end up in five-year-old Reddit threads.
Stop. Take a breath. Your Bitcoin is not lost. A stuck transaction is one of the most common, most fixable problems in Bitcoin, and in 2026 the tools to handle it are built right into every modern wallet. This article explains what's actually happening and walks you through the two reliable fixes: Replace-By-Fee (RBF) and Child-Pays-for-Parent (CPFP).
When you broadcast a Bitcoin transaction, it doesn't go straight into a block. It goes into a giant waiting room called the mempool — a global, distributed pool of pending transactions that every Bitcoin node maintains. Miners pick transactions out of the mempool to include in the next block they mine. They get paid the transaction fees of whatever they include, so they pick the highest-fee transactions first.
If you broadcast at a fee rate of 5 sats/vByte, and the mempool is busy with transactions paying 30 sats/vByte, miners ignore yours. It just sits there. Bitcoin produces a new block roughly every 10 minutes; if your transaction's fee rate is below the threshold for inclusion, it can sit in the mempool for hours or even days.
Eventually one of three things happens:
Option 3 is what this article is about.
Before you do anything, confirm the transaction is in the mempool and unconfirmed. Don't act on guesses.
If status is "In mempool" and your fee rate is below the current "low priority" line shown on the mempool.space dashboard, your transaction is stuck. Move on.
Replace-By-Fee is the cleanest fix, and the one most modern wallets handle automatically. It works like this: you create a new version of the same transaction, paying the same recipient the same amount, but with a higher fee. The new transaction replaces the old one in the mempool. Miners pick up the new one because it pays better. The old one is forgotten.
RBF only works if the original transaction was broadcast with RBF enabled (technically: with the "BIP-125 signaling" flag). Most modern wallets enable this by default. If your wallet didn't, you can't RBF — you'll have to use CPFP (next section) or wait.
Look at mempool.space and identify the fee rate of the lowest-fee transaction in the next block (the rightmost column of the mempool blocks visualization). Bump your transaction to at least that rate, ideally a notch higher to be safe. There's a minimum bump rule too: your replacement must pay at least 1 sat/vB more in absolute fee than the original, plus enough to cover the new transaction's bytes. Wallets handle this math for you.
If RBF isn't available — either because the original wasn't RBF-enabled or because you're the receiver and it's the sender's transaction that's stuck — CPFP is your fallback.
The idea: you create a new transaction that spends the change output from the stuck transaction. The new transaction has a very high fee. Miners realize they can't mine your child transaction without first mining the parent (because the child references an output that doesn't exist on-chain yet). So they're forced to include both transactions in the same block, and the high child fee subsidizes the low parent fee.
You can only CPFP if you have an unconfirmed change output of your own to spend. If your stuck transaction had no change output (you sent your full balance), you can't CPFP from the sender side — only the receiver can.
If someone sent you Bitcoin and their transaction is stuck, you can speed it up yourself by spending the incoming output before it's confirmed (this is called spending an "unconfirmed input"). Your wallet has to support this — not all do.
If you're using an older wallet without RBF or CPFP buttons, you have three options:
Sort of, but only via RBF, and only by sending the bumped transaction to yourself instead of the original recipient. This is sometimes called "RBF to self" and it effectively cancels the original send. You can only do this if the original was RBF-enabled and is still unconfirmed. Once a transaction has even one confirmation, it's final.
If your transaction sits unconfirmed for ~14 days, most node operators will drop it from their mempools, and your wallet will eventually reflect the funds as spendable again. This is rare but it happens during extreme congestion events. The transaction never "happened" from the network's perspective.
For sellers and merchants accepting unconfirmed transactions, yes — an RBF-enabled transaction can technically be re-sent to a different recipient before it confirms. That's why responsible merchants wait for at least one confirmation before releasing goods. As an individual user sending and receiving normally, RBF is purely a benefit; ignore the noise.
Yes. There's no downside for you as the sender, and it gives you the option to bump the fee if needed. Modern wallets default it on. (For the deeper context on fees themselves, see our network fees primer.)
No. Lightning payments either succeed or fail in seconds; there's no "stuck pending" state to worry about. Stuck transactions are an on-chain phenomenon. (See our Lightning intro for context.)
Your Bitcoin is fine. The blockchain is doing exactly what it was designed to do. Now you have the tools to make it move at the speed you want it to.