Why is my transaction still unconfirmed?

First question: can anyone see it?

Before anything else, establish whether the transaction reached the network at all. Look it up on two different explorers — for Bitcoin, try mempool.space and Blockstream.info.

If both show it as unconfirmed, it is in the mempool and the problem is a fee problem. Skip to the next section.

If neither shows it, the transaction never propagated, and this is a different situation entirely with a different fix. The usual cause is a fee below the network's relay minimum: nodes will not pass along a transaction that pays too little, so it exists on your device and nowhere else.

The good news is that this is the most recoverable case. Because no other node has it, there is nothing to conflict with. Most wallets have an option to clear unconfirmed transactions or to rebuild the wallet from the chain, after which the funds are simply available again and you can resend with a sensible fee.

The wrinkle is that your own wallet still considers those outputs spent, which is why the balance looks wrong until you clear it. If your wallet has no such option, moving the seed phrase into one that does resolves it.

The common case: the fee rate was too low

If explorers can see your transaction and it is not confirming, this is nearly always why.

Miners select transactions by fee rate — satoshis per virtual byte — because block space is the scarce resource. If your rate is below what is currently clearing, your transaction waits until either demand falls or someone raises it.

Open the transaction on mempool.space. The page shows your fee rate and the projected blocks, each labelled with the range it will likely contain. If your rate falls inside the first projected block you are minutes away and nothing needs doing. If you are several blocks down, the projection is genuine and based on what is queued ahead of you.

What makes this frustrating is that demand is not predictable. A transaction that looked adequately priced can be left behind by a surge an hour later, and there is no mechanism that automatically raises it.

The fixes are covered below. The thing not to do is rebroadcast the same transaction through a different service — it will not help, because the network already has it and rebroadcasting an identical transaction changes nothing about its attractiveness to miners.

The two fixes, and when each applies

Replace-by-fee is the clean option. If your transaction signalled RBF — most modern wallets do this by default — you can rebroadcast it with a higher fee and the new version replaces the old. Your wallet will have this as "bump fee", "speed up" or similar. The explorer shows whether RBF was signalled, usually near the top of the transaction page, and if it was not then this route is closed.

Child-pays-for-parent works when RBF is unavailable. You create a new transaction spending one of the stuck transaction's outputs, paying a fee high enough that a miner including both together earns a good rate on the pair. Since the child cannot be confirmed without the parent, the miner has to take both.

CPFP requires that you control one of the outputs — usually your change — and that your wallet supports it. Some do this automatically when you try to spend an unconfirmed output; others expose it explicitly. If you are the recipient rather than the sender, you can use CPFP on the output paid to you, which is a genuinely useful thing to know when someone has underpaid a payment to you.

If neither is available, the remaining option is waiting. Mempools clear, usually within days, and transactions are eventually either confirmed or dropped by nodes after a timeout — commonly around two weeks — at which point the funds return to being spendable.

The three less common causes

Wrong chain. The transaction confirmed perfectly well on a network you are not looking at. This happens constantly with assets that exist on several chains — USDT exists on Ethereum, Tron and others, and an exchange withdrawal specifies which. If a hash does not resolve, confirming the network before concluding anything is worth thirty seconds.

Explorer indexing lag. The transaction is confirmed and the explorer has not caught up. Compare the explorer's reported latest block height against a second one; a gap of thousands of blocks means that deployment is behind and everything it tells you about recent activity is stale. This is most common on self-hosted Blockscout instances and on multi-chain explorers covering long-tail networks.

Locktime set in the future. Rare, but real. A transaction can specify the earliest block at which it may be included, and until then it will not confirm no matter what it pays. The field is visible on the transaction page and most explorers will tell you plainly if it is set ahead.

On Ethereum there is a further cause with no Bitcoin equivalent: a nonce gap. Ethereum transactions from one address must be processed in strict sequence, so if transaction number 47 is stuck, 48 and 49 cannot proceed regardless of what they pay. Fixing the earliest stuck one releases the rest.

The Ethereum version of the problem

Ethereum's fee market behaves differently enough that the advice diverges.

Since EIP-1559, each block has a base fee that adjusts algorithmically with demand and is burned rather than paid to anyone. You additionally set a priority fee, which is what the proposer actually receives. A transaction is includable when the base fee falls to or below your maximum, and competitive when your priority fee is reasonable.

A stuck Ethereum transaction is therefore usually one of two things: a max fee below the current base fee, or a nonce gap caused by an earlier stuck transaction from the same address.

The fix for both is the same mechanism — resubmit with the same nonce and a higher fee, which replaces the pending transaction. Wallets expose this as speed up or cancel. Cancelling is the same operation sending zero value to yourself, which occupies the nonce and clears the blockage.

The one thing to avoid is submitting a new transaction with a higher nonce hoping it will jump the queue. It cannot. The sequence is strict, and the new transaction will sit behind the stuck one indefinitely.

Avoiding it next time

Three habits prevent most of this.

Let your wallet set the fee unless you have a specific reason not to. Modern wallets query a fee estimation service and get it approximately right. Manual fee entry is where most stuck transactions originate, usually from someone trying to save a few pence.

Check that RBF is enabled. It costs nothing, it is the default in most wallets, and it is the difference between a two-minute fix and a two-week wait. There is no real downside for an ordinary user.

Consolidate small outputs during quiet periods. A wallet that has accumulated many small payments produces large, expensive transactions, because fees scale with size rather than value. Merging them when fees are low turns a future expensive transaction into a cheap one now — and the live rates on our Bitcoin fee tracker make it easy to pick a moment.

And if you are about to move a meaningful amount, send a small test transaction first. It costs a few pence and it catches wrong-chain errors, wrong-address errors and fee misjudgements before they matter.