Zero-Confirmation Transaction (0-conf)

A zero-confirmation transaction, usually shortened to 0-conf, is a valid Bitcoin transaction that has been broadcast to the network and is visible in node mempools, but has not yet been mined into a block. Because no block has buried it, it carries zero confirmations and is therefore not settled — it is a promise in transit, not money received. Wallets typically show the funds as pending, and most explorers display the transaction within seconds of broadcast, which is exactly what makes 0-conf both tempting and dangerous.

It is worth being precise about what "valid but unconfirmed" means. A 0-conf transaction has typically passed every consensus check a node can apply — signatures verify, the inputs exist and are unspent, no rule is violated. What it lacks is not validity but ordering: Bitcoin's whole innovation is using proof-of-work to establish which of two conflicting valid transactions came "first," and until a block renders that verdict, the question genuinely has no answer. Two nodes can hold different, individually valid views of the same coins without either being wrong. Accepting 0-conf therefore means accepting payment while the double-spending problem — the exact problem Bitcoin exists to solve — is still momentarily unsolved for your specific coins.

Why 0-conf is convenient but not final

Accepting a payment at zero confirmations lets buyer and merchant transact instantly, which is attractive for point-of-sale, vending machines, and ATMs where waiting roughly ten minutes — sometimes much longer — for a block is impractical. The trade-off is fundamental: until a transaction is mined, nothing in Bitcoin's consensus rules prevents it from being replaced. A sender can broadcast a conflicting transaction spending the same coins — typically paying a higher fee, and possibly redirecting the funds back to themselves — and if that version confirms first, the original recipient receives nothing. The mempool is not a ledger; it is a waiting room with no security guarantees, and every node's copy of it can differ.

What changed with full-RBF

For years, merchants leaned on the convention that transactions not signaling Replace-by-Fee would not be replaced by most nodes, making non-signaling 0-conf payments somewhat safer in practice. That comfort has eroded: replacement behavior is mempool policy, not consensus, and as full-RBF relay — where nodes accept replacements regardless of signaling — spread across the network, the "unreplaceable" transaction effectively ceased to exist. The honest modern framing: any unconfirmed transaction should be treated as replaceable by a motivated sender, full stop.

Mitigating the risk

Merchants who still accept 0-conf manage it as fraud risk, not as security. Practical heuristics include connecting to many well-peered nodes and watching for conflicting spends in the seconds after broadcast, requiring a healthy fee rate so the transaction is attractive to miners immediately, capping the value accepted without a confirmation to an amount you can afford to lose, and factoring in the customer relationship — 0-conf from a regular is a different bet than from a stranger. None of these are consensus guarantees; they are actuarial judgment. For higher values, waiting for one or more confirmations remains the only cryptographic assurance, and for genuinely instant retail payments the Lightning Network is the tool actually designed for the job — final the moment it completes, no block required.

The miner's-eye view

From the mining side, 0-conf risk is simply the flip side of fee maximization. Miners assemble blocks from whatever paying transactions their mempool holds; when two conflicting versions exist, the higher-feerate one usually wins — whether directly or via CPFP-style packages. No miner is obligated to honor the version a merchant saw first, and that neutrality is a feature: Bitcoin's finality comes from proof-of-work, not from politeness. To understand how an unconfirmed transaction travels and finally settles, see transaction propagation and confirmation time.