Unconfirmed Transaction

An unconfirmed transaction is one that nodes have validated and accepted into their mempools but that no miner has yet placed into a block. It is fully signed, structurally valid, and ready to be mined — it simply has not been selected. Until a block includes it, the transaction has zero confirmations and is not settled in any meaningful sense: it exists only as a promise circulating through node memory, and promises in the mempool can be replaced, evicted, or double-spent.

Why a transaction stays unconfirmed

The overwhelmingly common cause is an insufficient fee rate. Miners assemble blocks from the highest-paying transactions available, measured in fee per unit of transaction weight, so a transaction paying below the going rate waits until congestion eases or someone bumps its fee. Congestion itself is spiky — an inscription wave or a market move can multiply the going fee rate within an hour, stranding transactions that looked adequately paid when broadcast. A second cause is dependency: a transaction spending an output of another unconfirmed transaction cannot confirm until its parent does, so a cheap parent holds the whole chain back. Finally, a transaction can violate a node's relay rules — too low a fee to even enter the mempool, or exceeding chained-transaction limits — in which case it never propagates at all, which is a mempool policy problem rather than a mining one.

What zero confirmations actually means

Treat an unconfirmed inbound payment as informational, not final. The sender may be able to replace it with a version paying themselves; a conflicting transaction may already exist in other mempools; and there is no single authoritative mempool — every node holds its own view, so "the mempool" is really thousands of slightly different ones. This is why merchants and exchanges wait for confirmations before crediting funds, and why accepting zero-conf payments from strangers is a calculated risk, not a technicality. One block makes reversal expensive; the traditional six make it economically absurd for all but nation-state adversaries.

Getting unstuck

An unconfirmed transaction is never lost — the coins have not moved, and there are three exits. If the sender flagged it replaceable, they can rebroadcast with a higher fee via Replace-by-Fee. If it has a spendable output, the recipient (or the sender, via change) can attach a high-fee child through Child-Pays-for-Parent, letting the child's fee pull the parent into a block. And if neither applies, patience works: default node policy expires transactions from the mempool after roughly two weeks, after which the inputs are simply spendable again, as though the transaction had never been sent. Wallets sometimes keep showing the ghost transaction after eviction — rescanning or manually abandoning it clears the display.

For home miners this is routine operational knowledge: pool payouts arrive on-chain, hardware gets bought and sold on-chain, and sooner or later one of those transactions will sit longer than you would like. Check it in a public explorer or, better, against your own node's mempool; read the current fee market before you broadcast; and prefer wallets that support RBF and CPFP so you are never at the mercy of a queue you cannot influence. See transaction accelerator for the full menu of resolution paths and fee estimation for avoiding the problem in the first place.

A note on watching the wait: confirmation is not a countdown but a lottery. Blocks arrive on average every ten minutes, yet gaps of an hour occur regularly, and your transaction's position in the queue shifts as better-paying traffic arrives behind it. Explorers that visualize the mempool in fee-rate bands show exactly where you stand — if your fee rate sits below the band currently clearing into blocks, waiting will not fix it, and a bump will. Reading that picture once turns the anxious refresh-loop into a two-minute diagnosis, which is precisely the kind of literacy that makes self-custody calm instead of stressful.