§ บทความ · พื้นฐาน

My Bitcoin transaction is pending — what to do in 2026

Bitcoin transaction stuck in the mempool? Here's how to verify what actually happened, when to wait, when to bump the fee, and how to never end up here again.

โดย dont-trust-verify · เผยแพร่ 11 พฤษภาคม 2569

🇺🇸 EN content เปิดหน้าภาษาอังกฤษ →

You sent a Bitcoin transaction. Your wallet says “pending”. Three hours pass. Six. Twelve. The block height keeps climbing on every site you check, but your transaction is still not in any block. The recipient is asking. You start to wonder if you lost the coins.

This is the single most common moment of Bitcoin anxiety, and almost every time it ends fine — but only if you understand what’s actually happening and don’t make a panic decision that turns a recoverable situation into a real loss. This guide walks through the four things to verify, when to wait vs act, and the two specific actions (RBF, CPFP) that get a stuck transaction confirmed.

TL;DR. A “pending” transaction is sitting in the mempool waiting for a miner to include it in a block. The reason it’s slow is almost always one of: (1) the fee was below the current mempool clearing rate; (2) the network is busy; (3) the transaction has a chain of unconfirmed parents that miners haven’t picked up. Verify the txid on mempool.space first — that tells you what miners actually see. Then choose: wait, bump the fee via RBF (sender-side, takes minutes), or use CPFP (recipient-side, also minutes). Coins never disappear from a stuck transaction unless you broadcast a double-spend yourself.

Step 1 — Get the txid and look at it on a public explorer

A “pending” status in your wallet is your wallet’s view of the world. To verify what miners and the rest of the network see, copy the transaction ID (txid) — a 64-character hex string — from your wallet and paste it into any public explorer.

mempool.space is the most useful explorer for this because it shows you what’s in the current mempool, what fee rate is needed for inclusion in the next 1, 2, 3, and 6 blocks, and where your transaction sits relative to other unconfirmed transactions. You can paste the txid directly into the search bar at the top.

What you’re looking for, in order:

  1. The transaction exists in the mempool. If mempool.space can’t find the txid at all, your wallet may not have actually broadcast it — try opening the wallet’s “rebroadcast” menu, or wait a minute and check again. Rare but happens; usually the wallet’s reconnection fixes it.
  2. The fee rate, in sat/vB. This is the only thing miners care about. A 1 sat/vB transaction during a busy period will sit for hours; a 50 sat/vB transaction during the same period will be in the next block.
  3. The estimated confirmation window. Mempool.space shows blocks in 1-block units with the fee thresholds for inclusion. If your transaction’s fee rate is above the “next block” line, you’re in the next block (10 minutes average). Below the “6 block” line, you’re an hour+ away. Below the “24 block” line, this is a problem.
  4. Whether RBF is enabled. Look for the “RBF” or “replaceable” flag in the transaction details. If yes, you can fix this from the sending wallet (Step 4 below). If no, you’d need the recipient to act with CPFP.

You can also paste any txid into our Bitcoin address validator to sanity-check the outputs — useful if you’re worried the destination address was somehow wrong (it almost never is, but a five-second check is worth peace of mind).

Step 2 — Determine why it’s stuck

There are really only three reasons a Bitcoin transaction sits in the mempool for an unusually long time. Each has a different remedy.

Reason 1: Your fee was below the current clearing rate. This is by far the most common. Your wallet estimated the fee using a stale snapshot of mempool conditions, or you picked the “economy” preset thinking nothing of it, and then the mempool got busy. The transaction is valid, miners just have higher-fee transactions to mine first.

Reason 2: The mempool is genuinely full. Bitcoin’s mempool can fill up during ordinals frenzies, ETF flow events, or coordinated bot activity. Even reasonable fee rates can lag for an hour or two during these. Less common in 2026 than in 2023–2024, but still happens. Check mempool.space’s “vBytes per second” chart — if it’s spiking, you’re in this scenario.

Reason 3: Your transaction has an unconfirmed parent. If your transaction spends an output from another transaction that hasn’t confirmed yet, miners typically wait for the parent. Sometimes a wallet auto-chains transactions before older ones confirm; sometimes you spent change from a previous send while it was still pending. Mempool.space shows the parent chain in the transaction detail view.

Step 3 — Decide whether to wait

Before doing anything else, look at the next-block fee rate on mempool.space and compare it to your transaction’s fee rate.

The reason waiting is the right default: every action you take has some risk (wallet bugs in RBF, fee-bumping miscalculation, missed change output). Doing nothing has zero downside if the transaction will eventually confirm.

Step 4 — Fix it from the sender side (RBF)

If your wallet broadcast the transaction with RBF enabled (Replace-By-Fee, the BIP-125 flag that signals to the network “I may replace this with a higher-fee version”), you can do exactly that. Most modern wallets (Sparrow, Electrum, Bluewallet, Wasabi, recent Trezor Suite, recent Ledger Live) support RBF out of the box.

The mechanics:

  1. Open the pending transaction in your wallet.
  2. Find the “increase fee” or “bump fee” menu.
  3. The wallet computes a new fee — typically you accept it or set a custom fee rate.
  4. The wallet signs and broadcasts the replacement transaction. The new transaction has the same inputs as the original but a higher fee, so miners pick it instead.
  5. The replacement appears in the mempool. The original transaction is now economically unconfirmable — any miner including the original gets less fee than including the replacement.

You can simulate this in a wallet-agnostic way using our RBF Fee Bumper tool — paste the original transaction’s hex, choose a new fee rate, and the tool produces the replacement PSBT for you to sign on your hardware wallet. Useful when your sending wallet’s UI doesn’t expose RBF clearly.

How much to bump: at minimum, your new fee rate must exceed the new next-block rate on mempool.space, plus enough to cover the size of the replacement transaction itself. Use our Fee estimator to get a fee rate that matches your urgency without overpaying.

Step 5 — Fix it from the receiver side (CPFP)

If your transaction does NOT have RBF enabled (some older wallets, some hardware wallets in their default mode), the sender can’t replace it. But the recipient can speed it up using Child-Pays-For-Parent (CPFP) — spending the output of the pending transaction with a new, higher-fee transaction. Miners look at the combined fee rate of the parent and child together when deciding whether to mine.

The mechanics:

  1. The recipient sees the pending transaction’s outputs in their wallet (most wallets show pending received funds even though they’re not confirmed).
  2. The recipient creates a new spend of one of those outputs to an address they also control (a self-send is fine).
  3. The new transaction’s fee rate is set high enough that the combined fee rate (parent + child / parent + child vBytes) exceeds the current clearing rate.
  4. Miners mine both transactions together. Both confirm in the same block.

CPFP works for any pending transaction where you control at least one output. It’s the only option when the sender refuses to act, or when the original transaction doesn’t have RBF enabled. The trade-off is that you pay the extra fee yourself (the sender doesn’t), so it’s mostly useful when you’re the recipient and need the money soon.

Common worries — addressed

“Can I lose the coins?” No. A transaction sitting in the mempool can only have three outcomes: (a) it confirms in a block, and you have the coins where they were sent; (b) it gets replaced by a higher-fee version of itself, and you have the coins where they were sent (possibly minus extra fee); (c) the mempool eventually drops it (typically after 2 weeks of no confirmation) and the inputs become spendable again, exactly as if you’d never broadcast it. There is no fourth outcome where coins vanish.

“Will my wallet show the wrong balance forever?” No. Once the transaction confirms — or gets dropped from the mempool — your wallet rescans and the balance reflects reality. The intermediate “pending” balance is your wallet being optimistic; the actual UTXO set on the network is authoritative.

“Someone said I should pay them to get my transaction unstuck.” This is a 100% rate scam. There is no service that can speed up a Bitcoin transaction faster than RBF + mempool dynamics will. Anyone DMing you offering “transaction acceleration” is trying to steal your money — they have no power over the mempool that you don’t already have through your wallet. Block them.

“Should I just send the recipient a new transaction with a higher fee?” No, do not double-spend. If your original transaction does eventually confirm later, both will be valid — the recipient gets paid twice. If your wallet allows it, use RBF on the original transaction. If not, ask the recipient to do CPFP. If neither is possible, wait for the original to drop from the mempool (~2 weeks), then send a new one.

How to avoid being stuck next time

Three habits that eliminate the panic-pending cycle:

  1. Always send with RBF enabled. Some wallets default to off; turn it on globally in settings. This makes every transaction recoverable.
  2. Use real-time fee estimation. Don’t accept your wallet’s static “low / medium / high” presets without checking the actual mempool. Our Fee estimator pulls live mempool.space data and gives you a sat/vB number for the urgency you actually need. The difference between paying for 1-block vs 6-block confirmation can be 5–10x; pay only what you need.
  3. Don’t spend unconfirmed change. If you send a transaction and immediately try to send another using the change output, both will be stuck if the first one’s fee was low. Wait for the first to confirm, or use a wallet that lets you batch into a single transaction.

When to ignore “pending” entirely

Lightning Network transactions don’t go through the mempool — they’re instant settlements between channel peers, and “pending” doesn’t really apply. If you’re paying or receiving over Lightning and something looks slow, the answer is rarely a fee issue and almost always a routing or channel state issue. Different problem, different tools — start with our BOLT-11 invoice decoder or Lightning address verifier to confirm the destination is well-formed.

A genuinely stuck Lightning payment is rare in 2026 — modern wallets like Phoenix and Wallet of Satoshi auto-retry and surface failures within seconds. If a Lightning payment is “pending” longer than two minutes, it almost certainly failed silently — cancel and retry rather than waiting.

The on-chain pending pattern, on the other hand, is just Bitcoin’s normal blockspace auction working as designed. The fee market is the priority queue; you bid for inclusion. Once you understand that, “pending” stops being scary and becomes just a status — and the right action is almost always one of three things: wait, RBF, or CPFP. Don’t trust the panic — verify the txid first.