Bitcoin Transaction Stuck: What to Do

The payment went out, the wallet shows zero confirmations, and it has been three hours. Usually nothing is broken: a bitcoin transaction is not "sent" the way a message is sent. It joins a queue and waits for a miner to pick it up. Here is why a transaction gets stuck, how long a wait is normal, what genuinely moves it along — and, separately, the case where the confirmations are there but the coins are not.

Why a transaction sits there

A block holds a limited amount of data, and more people want in than there is room for. A broadcast transaction lands in the mempool — the waiting room every node keeps — and miners take from it whatever is most profitable to include.

Profitability is measured per unit of size, in satoshis per virtual byte, not by the amount being moved. That catches people out: sending 0.5 BTC and sending 0.005 BTC cost the same if the transactions are built the same way. The fee buys space in a block, not permission to move money.

The rest follows. Your wallet proposed a rate based on demand at the moment you signed. If demand has risen since, your rate now sits below what blocks are clearing at, and the transaction waits for the queue to drain. Nothing has failed, and re-sending will not help — those coins are already committed to the pending transaction.

How long is normal

Blocks arrive every ten minutes on average, but the interval is random. Three blocks in four minutes followed by a forty-minute gap is ordinary network behaviour, not a fault.

There is only one useful measure: compare your rate against what blocks are clearing at right now. mempool.space shows both, along with how much is queued and at what rates. Above the bottom edge of the next few blocks, and it is a matter of tens of minutes. Well below it, and you wait for demand to fall — which it does cyclically, cheapest at night and over weekends.

One thing worth knowing while you look: much of what appears to be an enormous transfer is change returning to the sender. How to read that is covered in the companion piece on checking a bitcoin wallet address.

Finding your transaction in the queue

You need the transaction ID — the 64-character hash your wallet shows immediately after sending. Paste it into the search on mempool.space and you get the fee rate in sat/vB, the size, and roughly where it stands.

A small trap when comparing numbers: wallets usually display the fee as a total — "0.00004 BTC" — while the queue is ranked by rate per byte. To convert, divide the fee in satoshis by the size in virtual bytes; the explorer shows both figures side by side.

If the ID finds nothing at all, the transaction never reached the network. That happens when a wallet signs offline and fails to broadcast — in which case what you want is the wallet's re-broadcast option, not a place in the queue.

What actually speeds it up: RBF and CPFP

There are exactly two methods, and both come down to somebody paying more.

Replace-by-Fee — replacing the transaction with a higher-fee version of itself. The sender does this, from their own wallet. The mechanism is described in BIP-125, and it used to require that the original transaction flag itself replaceable in advance. Since version 28.0, released in October 2024, Bitcoin Core nodes accept a replacement regardless of that flag — see the release notes. The limit now lives in wallet software, not in the protocol: either your wallet can build a replacement or it cannot.

Child Pays For Parent — a child transaction paying for its parent. This works where replacement is unavailable, and it has one property RBF does not: the recipient can do it. They spend the still-unconfirmed output with a generous fee, and a miner evaluates parent and child together, taking the stranded parent along for the profitable child. If you are waiting to receive and have no influence over the sender, CPFP is the only lever you hold.

Why accelerators rarely help

An accelerator does not push a transaction through the network. It hands the transaction to one particular mining pool, outside the normal relay, and asks that pool to include it.

Which tells you what to expect. That pool can only include it in its own block, and it finds blocks roughly in proportion to its share of total hashrate. A pool holding a tenth of the hashrate finds about one block in ten — so the acceleration works in about that proportion, while the other nine blocks are assembled by someone who never saw the request. It is not a shove; it is a lottery ticket with known odds.

The second limit matters more than the first: an accelerator cannot change the fee already signed into the transaction. Only RBF and CPFP change your transaction's economics. Everything else is asking somebody to give up revenue on your behalf.

It confirmed, but the coins are not there

This is a different problem with different causes. Work through them in order.

1. Check that you are looking at the right address. Wallets hand out a fresh receiving address for almost every incoming payment. Open the transaction by its ID and see which address the output actually paid — then confirm that address belongs to your wallet.
2. Separate change from payment. The large number in a transaction is often change going back to the sender, not the amount headed for you.
3. Check the recipient's policy. An exchange credits after its own confirmation count. "Confirmed on-chain" and "credited to your balance" are separate events, and the second happens on the service's rules, not the network's.
4. Check the network the address belongs to. Address formats overlap between chains: legacy Litecoin addresses begin with 3, exactly like bitcoin ones. Bitcoin sent to a Litecoin address does not come back — it has paid an output nobody can ever claim.
5. Let the wallet finish syncing. After a restore from seed, a light wallet takes time to see the full history, and with the wrong derivation path it will never see it, even though the coins are exactly where they should be.

The general rule: if the explorer shows an output paying an address you control and the confirmations are in, the coins are yours. The problem then lies in how the wallet is displaying the chain, not in the chain.

When a stuck transaction disappears

Nodes do not hold an unconfirmed transaction forever. Bitcoin Core drops one from the mempool after two weeks, and sooner than that when the mempool fills — space is reclaimed by evicting the cheapest.

Nothing is "returned" when this happens. The coins never moved in the first place; the transaction only proposed spending them. Once it is dropped, those inputs count as available again and the wallet shows the old balance.

One caution, and it is a real one: being dropped does not cancel a transaction permanently. As long as the same inputs remain unspent, anyone still holding a copy can re-broadcast it. Treat the payment as cancelled only after you have spent those inputs yourself in a different transaction.

When the stuck payment is a deposit to an exchange

Here the stuck transaction acquires a deadline, and it is shorter than most people assume.

Every exchange issues a deposit address together with a window during which the rate is held. Ours is set per chain: an hour for slow networks — bitcoin, litecoin, dogecoin, Monero — less for fast ones, with roughly twenty minutes of reserve beyond the countdown shown on the page. The timer on your order page is the authoritative one; treat the figure here as background.

An hour is generous for a transaction with a sensible fee and short for a stuck one. That is where the practical risk sits — not in a service "losing" the money. If the deposit has not reached the required confirmations by the end of the window, the rail begins refunding to the sending address. Nor can we return it sooner: the deposit sits at the address issued for that quote, and we do not hold its keys.

What follows in practice. Payments to the same deposit address add up, so topping up before the deadline works and starts the swap automatically. Do not economise on the fee for a payment that has to execute at a quoted rate — the saved cents cost you the rate. And check the network before you send: we validate the payout address against the format of the chosen chain, which catches a typo or an address pasted from another chain, but no check can tell a well-formed wrong address from the right one.

In short

• A transaction waits because the fee it offered is below the current price of block space; the amount being sent has no bearing on the queue.
• Ten minutes is an average, not a schedule — half-hour gaps are normal. Compare your sat/vB against the current rate on mempool.space.
• Only RBF (done by the sender) and CPFP (which the recipient can do) actually speed a transaction up.
• An accelerator asks one pool to include the transaction and works roughly in proportion to that pool's hashrate; it does not change the fee.
• "Confirmed" and "credited" are separate events, and the second runs on the recipient's rules.
• After two weeks a transaction leaves the mempool, but count it cancelled only once the same inputs have been spent again.
• A deposit to an exchange has a window of its own — an hour for slow chains — and a stuck payment outlives it easily.

Reading the transaction itself — balances, outputs, confirmations — is covered in how to check a bitcoin wallet address. Current rates for the pairs we support are on the rates page.