Why Is My Bitcoin Transaction Stuck? A 2026 Recovery Playbook

A Bitcoin transaction is usually "stuck" because its fee rate was too low for current mempool demand, not because the network lost or cancelled it. The transaction is still valid and still waiting in at least one node's mempool, either for congestion to clear or for the sender to raise its effective fee with Replace-by-Fee or Child-Pays-for-Parent.

Today's live mempool snapshot (May 11, 2026)

As of early May, mempool.space shows the network running relatively calm: the recommended next-block fee is 1 sat/vB and the mempool holds roughly 76,108 unconfirmed transactions at about 210 MB out of Bitcoin Core's default 300 MB ceiling, and the minimum relay fee is 0.1 sat/vB (source: Mempool.space). 

However, in a situation where the next-block fee is 3 sat/vB while half-hour, hour, and economy bands all sit at 1 sat/vB, almost any fee at or above 3 sat/vB should clear within the next few blocks; transactions sitting below 1 sat/vB are the ones most likely to feel stuck. During a spike day those bands separate by an order of magnitude and stuck-transaction reports surge.

This guide is written for retail users whose BTC transaction is sitting unconfirmed longer than expected and who need a calm, step-by-step diagnosis before taking action. It does not cover Lightning payment failures, smart-contract stuck transactions on other chains, or exchange-side deposit delays beyond the pending-on-chain case. Every protocol constant is cited to Bitcoin Core or a BIP; every volatile figure carries a May 11, 2026 date-stamp.

What you will learn:

• How to tell whether your transaction is actually stuck or just slow

• The six reasons a transaction sits in the mempool for hours

• The correct order of recovery moves: wait, RBF, CPFP, abandon, rebroadcast, contact exchange

• Wallet-specific guidance for Sparrow, Electrum, BlueWallet, Ledger Live, and custodial exchange wallets

• When Bitcoin Core expires an unconfirmed transaction from its mempool (336 hours)

• The three things panicking senders do that make recovery harder, not easier

Protocol behavior (mempool policy, RBF rules, CPFP mechanics, descendant limits, the 336-hour expiry) is stable and cited to source. Mempool size, fee bands, and clearing estimates are live at May 11, 2026 and should be reread against mempool.space before acting on an urgent send.

How to tell if your transaction is actually stuck

A transaction is not stuck just because it hasn't confirmed yet. Bitcoin's 10-minute block interval is the mean of a probability distribution: single-block gaps of two minutes and forty minutes both occur regularly, and a perfectly fine transaction can easily wait 20 to 45 minutes during calm periods before its first confirmation. Calling anything under roughly 60 minutes "stuck" usually means the sender is anxious, not that the transaction is in trouble.

A more useful frame: a transaction is stuck when its fee rate is below the current clearing price across most miners' mempools and it shows no realistic path to confirmation in the sender's required time window. That is a decision trigger, not a timer. A 1 sat/vB transaction that would normally wait 6 hours is not stuck during a calm window like today's snapshot; the same transaction during an inscription-driven spike where next-block runs 80 sat/vB and economy runs 15 sat/vB is functionally stuck because the mempool will clear faster-fee work first indefinitely.

The three-minute diagnosis

Before touching any recovery tool, run through a short check in a block explorer that shows fee rate and mempool position.

1. Copy the transaction ID (txid) from your wallet's pending-transaction screen.

2. Paste it into mempool.space or another explorer that shows mempool depth (source: Mempool.space).

3. Note three numbers: the transaction's fee rate in sat/vB, the current recommended next-block fee rate, and the transaction's approximate position in the mempool backlog.

If your fee rate is at or above the current next-block rate and the transaction has been broadcast for under 30 minutes, the answer is "wait." If your fee rate is below the current economy band and the explorer shows your transaction deep in the backlog with no near-term path to the front, the answer is probably "intervene." For the live data source itself, see Bitcoin mempool, and for how to read the unconfirmed-state display in an explorer, see how to use a bitcoin block explorer.

What "stuck" does not mean

A stuck transaction is not a failed transaction. Three confusions happen often enough to deserve naming.

• Lost funds. The BTC is still in the unconfirmed state, visible on the blockchain or at least in some node's mempool. It has not been "sent to a stranger" and it has not evaporated.

• Reversed transaction. Bitcoin does not have bank-style reversal. A transaction either confirms (irreversible) or sits unconfirmed until it expires. Confirmed transactions are not cancellable.

• Exchange error. If the transaction was a deposit to an exchange and it sits pending on-chain, the exchange cannot credit the account until the block confirms and the required confirmation count accumulates. That's normal, not a bug. For the confirmation-count framing, see bitcoin confirmations.

Six reasons a Bitcoin transaction gets stuck

The same symptom (pending for hours) has different causes, and the correct response depends on which one you're dealing with.

1. Fee rate too low for current demand

This is, by a wide margin, the most common cause. The sender picks a sat/vB below the mempool's current clearing price, and higher-fee transactions keep arriving and keep getting mined first. The wallet's estimate may have been reasonable 20 minutes before broadcast but is now stale because congestion rose. For the fee-market mechanics behind this, see why are bitcoin fees so high; for the fee-selection logic before broadcast, see how to choose bitcoin fees.

2. Mempool congestion raised the dynamic minimum relay fee

Bitcoin Core's default mempool cap is 300 MB (-maxmempool=300) and its default minimum relay fee is 1 sat/vB (minrelaytxfee) (source: Learn Me a Bitcoin). When the mempool fills, nodes evict the lowest-fee-rate transactions and raise their dynamic minimum to slow new low-fee traffic. A transaction broadcast at 2 sat/vB during calm conditions can fall below the minimum relay fee after a surge; some nodes drop it entirely, others hold it but deprioritize it. Same txid, different fortunes across the network.

3. RBF was not signaled at broadcast

If the wallet didn't mark the transaction as replaceable at broadcast time, the sender cannot use RBF to bump the fee later. Under BIP-125, a transaction signals opt-in replaceability by setting any input's nSequence below 0xfffffffe (source: GitHub). Wallets like Sparrow and Electrum ship with RBF on by default; Ledger Live historically shipped with it off; BlueWallet exposes it as a toggle. A non-signaling transaction is still eligible for CPFP if the user controls a child output, but the one-click bump path is gone.

4. Descendant or package limits hit

Bitcoin Core caps unconfirmed transaction packages: a maximum of 25 descendants and 101 kvB of total descendant size per mempool entry (source: Learn Me a Bitcoin). A user chaining many unconfirmed transactions off one stuck parent can hit this limit and find new children get rejected. This is a niche cause for retail users but a common one for high-volume wallets and exchange hot-wallet operations.

5. Dust or below-minimum outputs

A transaction with outputs below the node's dust threshold is rejected as non-standard by most relay policies. These are usually caught at broadcast time and never enter the mempool, but a custom-built transaction or an older wallet version can occasionally produce one that propagates partially before being dropped.

6. Never actually broadcast

A transaction signed in an offline or air-gapped wallet that was never successfully pushed onto the wire can look pending in the wallet UI forever. The wallet knows about it; the network doesn't. Block explorers will return "transaction not found" for the txid because no node has seen it. This is the one case where the fix is usually trivial: rebroadcast via any online node or public RPC endpoint. For the underlying transaction lifecycle, see how bitcoin transactions work.

The recovery decision tree

The order of moves matters. Users who start with CPFP when RBF was available usually pay more than they needed to; users who start with panic rebroadcast usually make the problem worse.

Step 1: Verify state before acting

The first action is always to look up the txid in a block explorer and confirm what's actually happening. Three possibilities.

• Transaction is in the mempool at a visible fee rate. This is a fee-bumping problem. Go to step 2.

• Transaction is not found on any explorer. It was never relayed, or was dropped by every node you're checking. Go to step 5 (rebroadcast or abandon).

• Transaction shows as confirmed. It isn't stuck; the wallet is out of sync. Refresh the wallet's connection to its node, or force a rescan. Confirmed transactions are irreversible (source: Bitcoin Dev Docs).

Step 2: Decide whether to wait

If the transaction has been pending under 30 minutes and its fee rate is at or above the current economy band, wait. If the payment is non-urgent (self-transfer, savings move, consolidation), wait longer; most transactions at 1-3 sat/vB confirm within 6 hours without intervention. If the payment is time-critical or the fee is clearly below the clearing price, move to step 3.

Step 3: Replace-by-Fee (RBF) if available

RBF works when two conditions are met: the original transaction signaled replaceability via nSequence, and the wallet supports building a replacement. Under BIP-125, the replacement must satisfy five rules:

1. Each original transaction must signal replaceability explicitly or through inheritance.

2. The replacement may only include an unconfirmed input that was already included in one of the originals.

3. The replacement must pay an absolute fee at least as large as the sum paid by the originals.

4. The replacement must cover its own bandwidth at the node's minimum incremental relay fee rate (Bitcoin Core default incrementalrelayfee = 1 sat/vB).

5. The replacement plus its evicted descendants must not exceed 100 total transactions (source: GitHub).

The practical effect: pick a new sat/vB above the current clearing price, confirm the wallet is proposing a total fee higher than the original in absolute sats, and broadcast. One RBF bump is usually enough; serial bumping every 10 minutes is unnecessary and sometimes counterproductive because each bump evicts the previous version and forces the network to re-accept the new one. For more on the replace-versus-boost decision, see RBF vs CPFP.

Step 4: Child-Pays-for-Parent (CPFP) if RBF not available

If the original transaction did not signal RBF, or if the wallet doesn't expose RBF for exchange-originated sends, CPFP is the next move. The mechanism: the sender creates a child transaction that spends one of the parent's outputs (usually the change output) at a fee rate high enough that the combined package is attractive to a miner. Miners implementing ancestor fee rate selection evaluate the pair as a unit (source: Bitcoin Optech), so a low-fee parent plus a high-fee child can clear together even though neither would clear alone.

CPFP requires the user to control a spendable output from the parent transaction. For a payment sent to someone else, only the recipient can CPFP (by spending the output they just received). For a self-send or for a transaction with a change output back to the sender's own wallet, CPFP is within reach. The child's fee has to be large enough that (parent fee + child fee) / (parent vsize + child vsize) exceeds the current next-block rate. Most wallets that support CPFP calculate this automatically once the user picks a target fee rate.

Step 5: Abandon and rebroadcast (or wait for expiry)

If the transaction never entered the mempool or was dropped from every node, the funds are not stuck on-chain; they're tied up in the sender's wallet as pending. Bitcoin Core's abandontransaction RPC marks the transaction as abandoned in the local wallet so the inputs become spendable again (source: Bitcoin Dev Docs). This is a local wallet operation only: it does not cancel the transaction on the network. If any node still holds the transaction in its mempool, it can still confirm. Bitcoin Core's default mempoolexpiry of 336 hours (14 days) is the backstop (source: GitHub); after that, every default-configured node drops it.

For users not running Bitcoin Core directly, the wallet equivalents are "remove from wallet" or "mark as cancelled" options in Sparrow, Electrum, and some others. If the wallet doesn't expose this and the transaction is truly dropped everywhere, the pragmatic move is to wait out the 14-day expiry before trying to spend the same UTXOs, because double-spending a still-pending transaction risks confusing wallets and counterparties.

Step 6: If this was an exchange deposit, contact the exchange

A deposit that's pending on-chain but late is primarily an on-chain waiting problem, not an exchange problem, and the exchange cannot credit the deposit faster than the block confirms. But if the transaction confirmed hours ago and the exchange still hasn't credited the funds, that's a support ticket, not a fee-bumping exercise. Provide the txid, the deposit address, and the confirmation count from a public explorer; most exchanges resolve missed-credit cases within a day. If your stuck transaction is specifically an exchange Bitcoin withdrawal, the same RBF and CPFP tools apply once the exchange has broadcast.

Wallet-specific guidance

The mechanics above are protocol-level. The button that implements them varies by wallet.

Two practical notes. First, a transaction sent from a custodial exchange wallet is usually non-replaceable and non-bumpable from the user's side, because the exchange controls the inputs and the broadcast. The exchange's own operations team can bump, rebroadcast, or wait on your behalf, but the user-facing UI typically doesn't expose those options. Second, a non-custodial wallet that didn't signal RBF at broadcast can still use CPFP as long as the wallet or a paired wallet can create a child transaction spending a change output.

For the full custodial versus non-custodial framing, see custodial wallet vs self custody.

Blofin's operational lens on stuck deposits

BloFin's deposit engineering treats pending BTC deposits as observed-but-provisional until the transaction confirms and accumulates the required confirmation depth for the deposit tier. When we see a deposit that's broadcast but not confirming for hours, the first thing our deposit flow checks is the on-chain fee rate relative to the live mempool clearing price, because that's almost always the answer. From the operator side, the most useful thing a user can provide on a support ticket is the txid plus the current fee rate visible in mempool.space; that pair turns a "why is my money stuck" question into a one-line diagnosis.

The asymmetry worth internalizing: a user who underpays by 2 sat/vB on a deposit can spend an afternoon or an evening waiting unnecessarily, but a user who CPFP-bumps at 80 sat/vB during a calm window is paying 20x the economy rate for no real benefit. Match the intervention to the actual mempool state, not to the panic level.

What not to do when a transaction is stuck

Three patterns consistently make stuck transactions harder to resolve, not easier.

1. Don't re-send the same payment with the same UTXOs. Signing and broadcasting a second transaction that spends the same inputs creates a double-spend. Whichever transaction confirms wins; the other is rejected. This usually works out fine with RBF-signaled replacements, but with a mix of wallets and a non-RBF original it can result in both transactions lingering while nodes disagree, and the sender's wallet may show confusing balances until one side resolves.

2. Don't panic-spam RBF bumps. Each RBF replacement evicts the previous one and propagates a new transaction across the network. Bumping every 5 minutes at increments of 1 sat/vB wastes fees (each bump must exceed the last by at least the incremental relay fee threshold) and can occasionally cause wallets to lose track of which version is current. One decisive bump to a rate that clearly beats the next-block band is usually enough.

3. Don't enter your seed phrase into any "transaction accelerator" service. A legitimate accelerator service may have mining relationships that let it prioritize submission of specific txids, but it never needs your seed phrase, your private keys, or your wallet password. Any service asking for those is a scam using stuck-transaction anxiety as the pressure vector. Bitcoin transactions are irreversible once confirmed, and scam losses are almost never recoverable in practice. For the broader pattern of panic-driven scams in crypto, see common bitcoin scams; for the general rule on addressing mistakes, see common bitcoin mistakes.

The transaction accelerator question specifically

Some accelerator services are real. They typically work by submitting your transaction's details to mining pools that have out-of-band submission channels, which can occasionally improve a transaction's chance of inclusion in the next few blocks. Three cautions apply.

First, no accelerator can override Bitcoin's consensus rules. If your transaction's fee rate is so low that no profit-maximizing miner will include it, the accelerator cannot force the issue; it can only forward the transaction to the miner's mempool, which most miners would sync anyway. Second, accelerators charge a fee on top of the on-chain fee, often payable in a separate method. The total cost can exceed what a simple RBF bump would have cost. Third, the scam concentration in this category is high because it targets panicked users; for any service you haven't used before, read recent independent reviews, avoid any site demanding private keys or seed phrases, and assume anything promising "guaranteed next-block confirmation" is lying.

The honest default: if you can RBF or CPFP, use those first. Accelerators are a last resort for transactions where RBF and CPFP are both unavailable and waiting isn't acceptable.

When Bitcoin Core gives up on an unconfirmed transaction

Transactions don't sit in the mempool forever. Bitcoin Core drops an unconfirmed transaction from its mempool after mempoolexpiry hours, which defaults to 336 hours, or 14 days GitHub. Most nodes on the network run default configurations, so after two weeks an unconfirmed transaction is effectively gone from the public mempool.

Three implications for a sender.

• You have a natural backstop. If a transaction sits unconfirmed and un-bumped for 14 days, the network lets it go. The inputs become unambiguously respendable without creating a double-spend risk, because no miner holds the expired transaction anymore.

• Some nodes may hold it longer. Operators can set mempoolexpiry higher for their own nodes. A transaction you think is expired may still be live on a few custom nodes; the practical effect is small because miners overwhelmingly use default or shorter expiry.

• Rebroadcast resets the clock. If you rebroadcast an expired transaction, it re-enters the mempool with a fresh 336-hour window. This is useful if network conditions have finally improved; it's a waste if the fee rate is still below the clearing price.

For the chain-level distinction underneath mempool behavior, see bitcoin blockchain.

FAQ

Why is my Bitcoin transaction unconfirmed for so long?

Almost always because its fee rate is below the current mempool clearing price, which is the number miners use to pick transactions for each block. Wallet estimators can lag during fast-changing demand, so a rate that looks reasonable at broadcast can be uncompetitive by the time the next block arrives. Check your transaction's sat/vB on mempool.space against the current next-block rate. If you are clearly below, decide between waiting, RBF, or CPFP based on how urgent the payment is and which tools your wallet exposes.

Can I cancel a stuck Bitcoin transaction?

Not in the bank-transfer sense. If the transaction is already confirmed, it is irreversible under Bitcoin's consensus rules and cannot be recalled. If it is still unconfirmed and signaled opt-in RBF, you can replace it with a higher-fee transaction that spends the same inputs to different outputs, effectively cancelling the original. If it did not signal RBF and never reached the mempool, you can mark it abandoned in your local wallet and respend the inputs. There is no universal cancel button, only these specific paths.

What happens if my stuck transaction never confirms?

Bitcoin Core's default mempool expiry is 336 hours, or 14 days, so after two weeks most nodes drop the transaction from their memory. At that point the inputs are respendable without double-spend risk because no miner will include the expired version. Some node operators set longer expiry times, but miners overwhelmingly use the default. If you need the funds before the 14-day window, use RBF or CPFP to bump the fee, or rebroadcast after fees drop. Confirmed transactions are permanent; dropped unconfirmed ones are effectively gone.

Do transaction accelerators actually work?

Some do, for specific cases. A legitimate accelerator forwards a transaction to mining pools that accept out-of-band submission, which can occasionally improve inclusion odds in the next few blocks. None can override consensus: if your fee rate is far below what any miner would choose, an accelerator cannot change that. The category is also heavy with scams that exploit stuck-transaction panic. Never enter a seed phrase, private key, or wallet password into an accelerator site. If RBF or CPFP is available, use those first; accelerators are a last-resort option, not a default.

Should I rebroadcast my stuck Bitcoin transaction?

Only if it was truly dropped from the mempool, which you verify by checking multiple block explorers and seeing no record of the txid anywhere. If any explorer still shows it pending, the transaction is live and rebroadcasting does nothing useful. If it is genuinely absent and the original fee remains below the clearing price, rebroadcasting just drops it again; raise the fee first. Rebroadcasting with a higher fee is essentially a manual RBF bump and follows the same BIP-125 rules.

Researched and written by the BloFin Academy editorial team with AI-assisted drafting. All facts independently verified.

Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.