Zero-confirmation transaction
A zero-confirmation transaction (also called a 0-conf payment) is a Bitcoin payment that a receiver treats as settled before any block includes it. The receiver sees the transaction in the mempool or on the P2P network and may release goods or credit an account immediately. Settlement under that policy is provisional. A conflicting spend of the same inputs can still be mined instead, leaving the receiver unpaid.
Bitcoin's consensus finality is tied to block inclusion and subsequent work. Early merchant practice sometimes accepted unconfirmed payments for small face-to-face purchases under a first-seen heuristic. Replace by fee policies weakened those assumptions. BIP 125 defined opt-in signaling with nSequence and replacement fee rules focused on higher absolute fees and incremental payment for relay bandwidth. It did not prohibit replacing non-signaling transactions at consensus. Bitcoin Core later added full RBF settings that allow replacement regardless of signaling. As full RBF became widespread default policy, any unconfirmed payment could be displaced by a higher-paying conflict that honest miners prefer. The Lightning Network and other off-chain protocols exist in part because on-chain 0-conf cannot provide fast, high-assurance settlement for open-network commerce. After one confirmation, reversing the payment requires a chain reorganization.
Double-spend risks
Double-spend races can be finney attacks (a miner pre-mines a conflict), race attacks (two conflicting broadcasts), or fee-bump replacements under Full RBF. Receivers who accept 0-conf often limit face value, require the payment to hit their own node quickly, and watch for conflicts until the first confirmation. None of those heuristics matches the security of waiting for blocks.
Some services still accept 0-conf from known customers or over private payment channels where replacement is contractually constrained. On the open P2P network, policy diversity means a transaction may be replaceable on one relay path and sticky on another until miners choose. Lightning inbound receives that rely on unconfirmed funding (including some JIT opens) inherit related risks until the funding transaction confirms.
Relay and packages
Compact block relay and fee filters do not change the consensus rule that unconfirmed transactions remain reversible by a higher-work chain tip. They only affect how quickly a receiver might see a payment or a conflicting double spend. Explorers that mark a transaction as confirmed after one block are reporting chain inclusion, not merchant risk policy.
Under Cluster mempool and Package relay, a child can raise a parent's effective feerate without making the parent final. A receiver who credits on first sight of a low-fee parent can still lose to a replacement package that miners prefer. Policies that wait for the payment to clear the node's mempool minimum and to remain unconflicted for a short timer only reduce, not eliminate, that risk.