What should you do when your Bitcoin transaction is stuck?
Check status on a block explorer using your TXID. If you send from your own wallet with RBF enabled, broadcast a replacement at a higher fee rate. If you are the receiver, use CPFP to pull the parent through. If you sent from an exchange, contact support. Most stuck transactions stem from a fee rate too low for current mempool demand.
Confirming your transaction status
A stuck Bitcoin transaction is unconfirmed, not failed. It has been broadcast to the network and sits in the mempool waiting for a miner to include it in a block. The distinction matters because each status requires a different response.
Your transaction ID is a 64-character hexadecimal string visible in your wallet's transaction history. Copy it exactly and paste it into a block explorer such as mempool.space or blockstream.info. The explorer will show one of several states:
Unconfirmed (in mempool): Broadcast and waiting. Fee rate visible. This is the most common "stuck" state.
Not found: The transaction was never broadcast or has been dropped from most mempools after exceeding the default 336-hour (14-day) expiry window (source: GitHub).
Confirmed: The transaction has already been settled. Your wallet may have sync lag.
Replaced / Conflicted: Another transaction spent the same inputs, typically via RBF.
If your wallet shows "pending" but no explorer recognizes the TXID, the transaction likely never left your device. Check connectivity and attempt to rebroadcast.
Why fee rate determines confirmation speed
Block space is limited. Each block holds roughly 1 to 4 megabytes of transaction data, produced approximately every 10 minutes. When more transactions enter the mempool than fit in the next block, miners select those paying the highest fee rate measured in satoshis per virtual byte (sat/vB).
Fee rate and total fee are different. A transaction with many inputs might pay 5,000 satoshis total but only 3 sat/vB. A smaller transaction paying 1,000 satoshis total at 20 sat/vB confirms faster. Miners sell block space, so they optimize for fee density.
Wallet fee estimates rely on recent data and can become stale within minutes if a surge of high-fee transactions enters the mempool. Ordinal inscription batches, exchange consolidation sweeps, and price-driven activity spikes can all shift the competitive threshold upward after you have already broadcast.
Common misunderstandings:
"I paid a high fee" does not guarantee fast confirmation if the fee rate per byte is low
Wallet estimates are predictions based on recent conditions, not guarantees
A fee rate that confirmed quickly last week may sit for hours today
Checking real-time fee conditions before sending prevents most stuck transactions. Tools like mempool.space display current fee brackets and estimated confirmation times (source: Mempool.space).
Other causes beyond low fees
Not every unconfirmed transaction is a fee problem.
Never broadcast: Your wallet was offline, behind a firewall, or experienced an API failure. The transaction exists locally but no node received it. Solution: verify connectivity and rebroadcast.
Dropped from mempool: Nodes enforce memory limits. The lowest-fee transactions get evicted during congestion. Bitcoin Core's default expiry is 336 hours (source: GitHub). If explorers show "not found," the transaction was likely purged. You can rebroadcast (same TXID, no double-payment risk) or create a replacement.
Unconfirmed parent: Your transaction spends an output from another unconfirmed transaction. Both must confirm together. If the parent has a low fee rate, the child is also held back regardless of its own fee. CPFP on the child can pull both through.
Non-standard transaction: Nodes reject transactions with unusual scripts, dust outputs below relay minimum, or deprecated formats. This is typically a wallet configuration issue rather than user error.
Decision tree: Choosing the right fix
Before acting, answer two questions. Do you control the sending wallet? Is the transaction RBF-signaled?
You control the wallet and RBF is enabled: Use Replace-By-Fee (fastest, lowest complexity).
You control an output from the stuck transaction: Use Child-Pays-For-Parent (works for receivers).
Transaction was never broadcast or was dropped: Rebroadcast it.
You sent from an exchange or custodial app: Contact support with your TXID.
None of the above apply: Wait. If the fee rate exceeds minimum relay (typically 1 sat/vB), the transaction will eventually confirm as congestion decreases.
Replace-By-Fee: How it works
RBF lets you broadcast a replacement transaction spending the same inputs with a higher fee rate. Miners include the replacement and discard the original. Only one version can ever confirm.
Since Bitcoin Core v28.0, full RBF is enabled by default across the network (source: GitHub). Previously, BIP 125 required opt-in signaling: at least one input with nSequence less than 0xFFFFFFFE (source: GitHub). With full RBF now standard, any unconfirmed transaction can be replaced regardless of signaling, though wallets still commonly set the flag for compatibility (source: Bitcoin Optech).
Requirements:
Original transaction is still unconfirmed
You control the sending wallet's private keys
Your wallet supports creating replacement transactions
New fee rate is meaningfully higher than the original
Replacement must pay higher absolute fee than original (BIP 125 rule 3)
In practice, most modern wallets (Electrum, Sparrow, Bitcoin Core) expose a "bump fee" or "replace" button. Select the stuck transaction, choose a new fee rate based on current mempool conditions, and broadcast.
Common mistakes:
Setting the replacement fee only slightly higher (may still not compete)
Attempting RBF after confirmation (impossible once in a block)
Confusing "cancel" with "replace" (both use RBF; cancel simply redirects funds back to yourself)
Child-Pays-For-Parent: Pulling a stuck parent through
CPFP works when you control an output from the stuck transaction. The receiver typically uses this method because they hold the unconfirmed output in their address.
You create a child transaction spending that unconfirmed output with a fee rate high enough to make the combined package attractive to miners. Miners evaluate parent and child together:
Package fee rate = (parent fee + child fee) / (parent size + child size)
Example: parent is 200 vB paying 2 sat/vB (400 sat total). You create a child of 150 vB paying 40 sat/vB (6,000 sat). Package rate becomes (400 + 6,000) / (200 + 150) = 18.3 sat/vB. If 18 sat/vB clears the current mempool threshold, both confirm together.
Requirements:
You control a spendable output from the stuck transaction
Your wallet supports spending unconfirmed outputs (not all do by default)
You have sufficient funds to cover the child transaction fee
No timelock or script restriction prevents immediate spending
Limitations: some wallets block spending unconfirmed inputs; long ancestor chains (more than 25 unconfirmed ancestors) may exceed node relay policy limits; and you need enough separate UTXOs to fund the child fee.
Exchange and custodial withdrawals
When you withdraw from an exchange, you do not control private keys. The exchange batches withdrawals, applies internal security reviews, and broadcasts on their schedule. Your "pending" status may reflect their internal queue rather than an on-chain delay.
Before contacting support, check whether the exchange has provided a TXID. If yes, look it up on an explorer. If the TXID shows unconfirmed on-chain, the exchange's transaction is genuinely waiting for block inclusion. If no TXID exists, the withdrawal has not been broadcast yet.
What to provide support:
TXID (if available)
Withdrawal amount and recipient address
Timestamp of the withdrawal request
Screenshot of the pending status in your account
Do not submit duplicate withdrawal requests. If both the original and duplicate eventually process, you receive funds twice and must arrange a return, which creates complications.
What not to do
Do not send a second transaction to the same address. This creates a new transaction spending different inputs. If both eventually confirm, you have made a double payment. Rebroadcasting the same TXID is safe; creating a new send is not.
Do not trust unsolicited "help" offers. Anyone contacting you via DM or social media claiming to fix your stuck transaction is attempting to steal funds. Legitimate support never asks for private keys, seed phrases, or remote access to your wallet. Verify support channels directly through official exchange or wallet websites.
Do not pay unverified accelerator services. While some legitimate accelerators exist (typically operated by mining pools like ViaBTC's free accelerator), many services simply collect payment and do nothing. Standard methods like RBF and CPFP are built into the protocol and require no third-party trust.
Do not panic during congestion. The mempool clears cyclically. A transaction that seems stuck during peak hours may confirm overnight or over a weekend when activity drops. Check current fee estimates before deciding whether intervention is necessary.
Prevention checklist
Enable RBF by default. Verify your wallet settings signal replaceability. This costs nothing and provides a safety valve for every future transaction.
Check mempool conditions before sending. Real-time fee dashboards show the sat/vB threshold for next-block inclusion. Match your fee to your urgency rather than relying on stale wallet estimates.
Use SegWit or Taproot addresses. Legacy vs SegWit vs Taproot addresses differ in weight efficiency. SegWit and Taproot transactions use less virtual block space, reducing your effective fee for the same confirmation priority.
Consolidate UTXOs during low-fee periods. Many small UTXO management create larger transactions with higher total fees. Consolidate when the mempool is nearly empty.
Record transaction details. Keep the TXID, fee rate, recipient address, and wallet used. Troubleshooting is faster with complete information. Having your security checklist habits in place prevents panic during delays.
Avoid sending during network surges. Ordinal inscription batches, halving-event speculation, and exchange consolidation rounds create temporary fee spikes. If your transfer is not time-sensitive, wait for the surge to pass.
From the operations side, the majority of "stuck transaction" support tickets we process trace back to users who broadcast during a fee spike without checking mempool conditions first. On the platform side, exchange-initiated withdrawals use dynamic fee estimation to avoid this, but user-controlled wallet sends do not have that safety net.
From running fee-bump operations on mainnet during the 2023 ordinals congestion and the early-2024 fee spikes, the pattern is consistent: users who enabled RBF by default never had to sweat a stuck transaction. Those who skipped it learned the hard way that CPFP requires controlling an output and having spare UTXOs available. The five minutes spent verifying wallet settings before your first send saves hours of anxiety later.
Frequently asked questions
Does "stuck" mean my Bitcoin transaction failed?
No. A stuck transaction is unconfirmed, meaning it has been broadcast to the network and waits in the mempool for a miner to include it in a block. It remains valid and will eventually confirm if the fee rate exceeds minimum relay thresholds and mempool demand decreases. Failure would mean the transaction was rejected entirely, which only happens with invalid signatures or double-spend conflicts. Check your TXID on a block explorer to see its real status rather than relying solely on wallet labels.
Can I cancel a Bitcoin transaction after sending it?
You cannot cancel in the bank-transfer sense, but you can effectively redirect funds using RBF. Create a replacement transaction that sends the same inputs back to your own address with a higher fee rate. The network treats this as a valid replacement and the original payment never confirms. This only works while the transaction is unconfirmed. Once included in a block, the payment is irreversible and refunds require the recipient's voluntary cooperation.
How long can a Bitcoin transaction stay unconfirmed?
Bitcoin Core nodes drop transactions from the mempool after 336 hours (14 days) by default. During that window, the transaction may confirm at any time if congestion decreases. If it is dropped, you can rebroadcast or create a new transaction. There is no guaranteed timeframe because confirmation depends on fee-market competition that fluctuates constantly with network activity and demand for block space.
What is the difference between RBF and CPFP?
RBF replaces the original transaction entirely with a higher-fee version spending the same inputs. Only the sender can use it. CPFP creates a new child transaction that spends an output from the stuck parent, with a fee high enough to incentivize miners to include both. Either the sender or receiver can use CPFP if they control a spendable output. RBF is simpler when available; CPFP is the fallback when RBF was not signaled or when the receiver needs to accelerate an incoming payment.
Will rebroadcasting my transaction create a duplicate payment?
No. Rebroadcasting pushes the same transaction with the same TXID back to network nodes. The Bitcoin network only accepts one transaction per set of inputs, so the same TXID cannot be confirmed twice. However, using your wallet's "send" function to create a new transaction to the same address does create a separate payment with a different TXID. If both eventually confirm, you have paid twice. Always rebroadcast the original rather than creating a fresh send.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include BIP 125 (opt-in RBF signaling specification), Bitcoin Core v28.0 full-RBF default policy (PR #30493), Bitcoin Core mempool expiry documentation (src/kernel/mempool_options.h), and real-time mempool data from mempool.space. 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.