Stuck transactions: why they happen, and how replace-by-fee gets you out
You sent a payment. The wallet says pending. An hour goes by. Then three. The block explorer shows your transaction sitting in the mempool, unconfirmed, apparently forever.
Nothing is broken and nothing is lost. You just underbid an auction, and the auction is still running.
Fees are an auction, not a price
Block space is scarce and permanently so. Each block holds a limited amount of transaction data, and miners choose which transactions to include. They pick by fee rate — satoshis per virtual byte — because that is what maximises their revenue.
This means the fee you attach is not a price for a service. It's a bid in a continuous auction against everyone else trying to get into the next block.
Two consequences follow, and both are counterintuitive:
Your fee is only meaningful relative to everyone else's. The same fee that confirmed in ten minutes last Tuesday can sit for two days during a busy weekend. Nothing about your transaction changed; the competition did.
There is no timeout. An underbid transaction doesn't expire and doesn't fail. It waits in the mempool while higher bidders go past it, and it can wait indefinitely. Nodes eventually drop very old transactions from their memory pools — commonly after around two weeks — but that is a local housekeeping default, not a protocol rule, and you cannot rely on it as an escape hatch.
That second point is what makes stuck transactions feel so bad. There is no error message, no refund, no obvious action. Just a spinner that never resolves.
Why yours got stuck
The fee estimate was stale. Fee estimators read recent conditions. If the mempool fills between your estimate and your broadcast — a large exchange consolidating, an NFT mint, an ordinals wave — your bid is instantly below market.
You chose the economy tier and got what you asked for. Low-priority tiers are explicitly a bet that congestion will ease. Usually it does. Sometimes it doesn't.
Your transaction is physically large. Fee rate is per byte, so a transaction spending many small inputs costs more to confirm than a simple one for the same amount of money. Wallets holding lots of dust hit this constantly.
You're spending an unconfirmed input. If you spend change from a transaction that hasn't confirmed, your new transaction cannot confirm until the parent does. One stuck payment can silently strand everything that follows it.
Replace-by-fee: the actual fix
Replace-by-fee, specified in BIP 125, lets you broadcast a replacement for an unconfirmed transaction that pays a higher fee. Nodes drop the original and relay the new one; miners take the better bid. Only one of the two can ever confirm — they spend the same inputs, so they're mutually exclusive by construction.
This is not a second payment. It's the same payment, re-bid.
Two details matter in practice.
A transaction has to be marked replaceable in advance. RBF is opt-in: it's signalled by setting an input's sequence number below 0xfffffffe. Bitcoin Core's convention is 0xfffffffd, and that is what SSP sets — literally 0xffffffff - 2 in the transaction builder. If a transaction wasn't marked replaceable when it was created, most nodes will refuse the replacement, and your options narrow considerably.
The replacement must clear a floor, and the obvious floor is wrong. BIP 125's fourth rule requires the replacement to pay at least the original fee plus the replacement's own size at the minimum relay rate. This trips people up: bumping from "economy" to "normal" can raise the fee rate while the size barely changes, and if the arithmetic lands short, the node rejects the replacement and you've achieved nothing. SSP computes this floor explicitly before building the replacement, so the new fee is guaranteed to clear rule 4 rather than being silently refused by the network.
In SSP, an unconfirmed replaceable transaction shows a Replace by fee action in the transaction list. It pre-fills the same recipient and amount and carries the replaced transaction's fee through so the floor can be computed, then walks you through signing the replacement on both devices exactly like any other payment. The second signature is still required — a replacement is a new transaction, and nothing signs with one device.
Not every chain allows it
RBF is a policy choice, not a universal feature, and the chains SSP supports genuinely differ:
| Chain | Replaceable in SSP |
|---|---|
| Bitcoin | Yes |
| Litecoin | Yes |
| Dogecoin | Yes |
| Ravencoin | Yes |
| Bitcoin Cash | No |
| Zcash | No |
| Flux | No |
Bitcoin Cash's exclusion is deliberate on the chain's part: BCH removed RBF to make zero-confirmation payments more dependable for point-of-sale use. It's a real trade-off rather than an oversight — you gain confidence in unconfirmed payments and lose the ability to correct an underbid one. Zcash and Flux likewise don't relay replacements.
On those chains, an underpriced transaction has to be waited out. Which is the strongest argument for not underbidding in the first place on a chain that won't let you take it back.
What to do when it happens
First, wait a little. Mempool congestion is spiky. A transaction that looks doomed at 9pm often confirms overnight when the backlog drains. Check a mempool visualiser before spending money on a fix.
If it's replaceable and you're in a hurry, replace it. Pick a fee rate above the current bottom-of-the-next-block rate, not merely above your original. Bidding slightly higher than a losing bid is how you end up doing this twice.
Don't broadcast a second payment. If the first one eventually confirms, you've paid twice. Replacement is safe precisely because it's mutually exclusive with the original; a separate transaction is not.
Don't spend the change from a stuck transaction. You'll chain a second stuck transaction onto the first.
If you can't replace it, wait. On non-RBF chains, the transaction either confirms when congestion clears or is eventually dropped from mempools, after which the coins are spendable again. Do not attempt "cancel" services; there is no such thing.
Avoiding it next time
Look at the fee, not just the tier label. "Economy" means something different on a quiet Sunday than during a fee spike. Most wallets, SSP included, show you the actual rate.
Match urgency to fee honestly. A payment that genuinely doesn't matter for a day should use a low fee — that's the whole point of the tier. A payment you'll refresh anxiously should not.
Keep your UTXO set tidy. Consolidating small inputs when fees are low makes every future transaction smaller and cheaper. It is the single most effective thing a long-term holder can do about fees, and the best time to do it is when nobody else wants block space.
Prefer chains and moments deliberately. Fee strategy is a real skill, and most of it is just noticing that block space is cheaper at some times than others.
A stuck transaction is one of the few crypto problems that is genuinely benign. Your coins never left your control, no attacker is involved, and the fix is a well-specified protocol feature. It only feels like an emergency because the interface offers no reassurance — which is itself a reason to understand what's happening underneath.
