A zero-confirmation (0-conf) Bitcoin transaction has been broadcast and may be accepted by one or more nodes, but it is not included in a block. It is an unconfirmed payment, not settlement.
For merchants, 0-conf acceptance is a risk decision: a conflicting transaction can win the race to a miner or replace the first transaction under applicable relay policy. For miners, an ASIC supplies proof-of-work hashing; a pool or mining node usually chooses the candidate block template.
This guide separates Bitcoin consensus from local mempool policy, explains RBF, CPFP and package relay, and gives a practical confirmation policy for 2026. Protocol behavior changes over time, so current release and policy notes are linked below.
What Is a Zero-Confirmation Transaction?
A zero-confirmation transaction is a signed transaction that has not yet been included in a block. A node may validate it against consensus rules and accept it into that node’s local mempool, then relay it according to local policy. There is no single global mempool, and not every node has seen or accepted the transaction.
Confirmation begins when a valid block containing the transaction becomes part of the node’s best chain. A reorganization can temporarily remove a recent block, so one confirmation is increased confidence rather than an absolute guarantee. Additional blocks add cumulative proof of work and make replacement progressively harder.
Bitcoin’s roughly ten-minute block interval is an average, not a timer. A fee rate, transaction ancestry, package relationships, local policy and block-template policy all affect when a transaction may confirm.
How Zero-Confirmation Transactions Work — From Broadcast to Block
The lifecycle is easiest to understand when consensus validity and relay policy are kept separate.
Step 1: Construction and signing
The wallet selects UTXOs, creates outputs and change, chooses a fee, and signs the transaction. A valid signature proves authorization to spend the inputs; it does not prove that the transaction will be relayed or mined.
Step 2: Broadcast and relay
The transaction is sent to one or more peers. Each node independently checks consensus validity and applies its own standardness, fee, replacement and mempool rules. A consensus-valid transaction can therefore be absent from a particular node’s mempool. Propagation is variable, and private or direct broadcast can create further differences between nodes.
Step 3: Local mempool residency
A transaction in a node’s mempool is publicly observable only to peers or services that have received it. Explorers are useful indicators, but their view does not prove that the transaction has reached miners or the whole network. Conflicting transactions may coexist in different mempools.
Step 4: Candidate block selection
Pools and miners construct candidate blocks using their own policies. Fee rate and package fee rate are important incentives, but neither consensus nor the Bitcoin peer-to-peer protocol mandates a single transaction ordering. CPFP packages, transactions received privately, and operational preferences can affect selection.
Step 5: Confirmation
When a block containing the transaction is accepted on the best chain, it has one confirmation. Each block added afterward increases confidence, subject to the attacker’s hash rate, chain conditions, transaction value and the business’s risk model.
Why Zero-Confirmation Transactions Exist
Waiting for a block is inconvenient for point-of-sale and other time-sensitive payments. Accepting 0-conf trades settlement assurance for speed; the acceptable trade-off depends on the value and reversibility of what is delivered.
| Use case | Prudent default | Reason |
|---|---|---|
| Low-value, in-person item | 0-conf only within a defined loss limit | Speed may be worth bounded, explicit risk, but no heuristic eliminates double-spend risk. |
| Online order or shipped hardware | Wait for confirmation before irreversible fulfillment | The counterparty and delivery window make recovery difficult. |
| High-value transfer or irreversible service | Set a confirmation threshold based on value and threat model | Deeper burial provides stronger probabilistic protection. |
The Double-Spend Problem
Two transactions that spend the same input are conflicting transactions. Before confirmation, no recipient can know with certainty which conflict, if any, will be included in a block.
Race attack
An attacker broadcasts one transaction paying the merchant and another paying an address they control, attempting to make the self-paying transaction reach a miner first. Propagation observations can reduce uncertainty but cannot make the payment final.
Finney attack
A miner can privately mine a block spending the coins back to themselves, make a separate unconfirmed payment to a merchant, and then publish the privately mined block. This requires mining capability and timing; a confirmation changes the conditions, but deeper confirmation gives more protection.
Vector76 and related attacks
More elaborate attacks combine private blocks, network timing and merchant or exchange behavior. The lesson is not that every attack is practical, but that 0-conf acceptance depends on assumptions outside consensus.
Mitigation Strategies and Protocols
These techniques can improve operational handling or confirmation speed. None turns an unconfirmed on-chain payment into confirmed settlement.
Replace-by-Fee (RBF)
BIP125 defines opt-in replacement signaling through input sequence numbers. Full-RBF was configurable in Bitcoin Core 24.0 and became the default policy in v28.0; Bitcoin Core v31 documents current replacement rules. Full-RBF is relay and mempool policy, not a consensus change, and replacement still has to satisfy the receiving node’s fee, conflict, cluster and relay rules.
Therefore, a transaction without BIP125 signaling is not a 0-conf guarantee. Signaling is a useful warning, but its absence is not proof that the transaction cannot be replaced or that a conflicting transaction cannot be mined.
Child Pays for Parent (CPFP) and package relay
When a recipient controls a spendable output, a high-fee child can improve the combined package’s incentive to confirm. CPFP does not prevent a conflicting spend of the parent’s inputs. Current Bitcoin Core supports limited one-parent/one-child package relay and package-RBF behavior, while broader package behavior remains policy-dependent and not every node or pool follows the same rules.
Mempool and conflict monitoring
A merchant can run its own full node with multiple peers, inspect the transaction and its inputs, and watch for conflicts. This is best-effort evidence from a local view: a missing conflict does not prove that no private, delayed or differently relayed conflict exists.
Lightning payments
Lightning can provide rapid off-chain settlement when the route, liquidity and counterparties support it. Payments can fail, routing has operational trade-offs, and channel opening or closing still uses the blockchain. It is an alternative payment path, not a reason to describe every Lightning payment as universally instant, final or fee-free.
Zero-Confirmation Transactions and Mining in 2026
In 2026, the important update is policy nuance rather than a single network-size number. Bitcoin Core v28 made Full-RBF the default policy, and v31 introduced cluster-mempool ordering and additional one-parent/one-child package-relay behavior. Nodes, pools and miners can still run different software or settings.
The block subsidy remains 3.125 BTC after the April 2024 halving. Hashrate and difficulty are estimates or changing chain parameters, not permanent article facts; this guide intentionally avoids an undated EH/s or trillion-difficulty snapshot.
What this means for miners
An ASIC performs hashing and does not itself enforce first-seen relay policy. A pool, mining node or template service selects transactions, and a successful block contributes proof of work to the chain. Home mining can contribute hash rate, but it does not provide a special guarantee for any particular 0-conf payment.
For people operating Bitcoin space-heater hardware, an open-source Bitaxe, or an S21-class miner, the operational lesson is to distinguish hashing, template construction and node relay. Hardware maintenance can be useful; it should not be described as directly settling unconfirmed payments. See ASIC repair services for hardware support and mining hosting for facility operations.
Should You Accept Zero-Confirmation Transactions?
Use a written risk policy rather than a universal dollar cutoff.
For merchants
- Do not release high-value goods, shipped hardware or irreversible services solely because a transaction appears in an explorer or local mempool.
- If accepting a low-value in-person payment at 0-conf, define the maximum loss, keep fulfillment reversible where possible, and understand that presence, propagation and no-RBF signaling are only heuristics.
- Use an independently controlled full node with multiple peers, inspect input conflicts and record the transaction ID; treat monitoring as evidence, not settlement.
- Require one or more confirmations according to value, fraud exposure, delivery irreversibility and operational policy. Six confirmations is a conventional high-value threshold, not an absolute finality rule.
- Consider a Lightning payment when the business can support its liquidity, routing, custody and channel requirements.
For current hardware shopping, the relevant internal paths remain available through the ASIC miner catalog and the D-Central shop; a payment is not settled merely because an order system has seen its transaction.
The Broader Context: Decentralization and Transaction Policy
Bitcoin consensus rules determine which blocks and transactions are valid in the chain. Relay and mempool policy determines which unconfirmed transactions a particular node accepts, stores and announces. Policy is local and configurable; it is not applied in the same way to transactions already included in blocks.
Decentralization gives users multiple paths to broadcast and verify transactions, but it does not promise universal propagation or inclusion. Mining distribution, peer diversity, miner incentives and network connectivity all affect confidence; none creates an enforceable first-seen rule for 0-conf payments.
Technical Deep Dive: What Happens in the Mempool
Consensus and policy checks
A node checks transaction structure, scripts and signatures, input availability, value conservation and consensus limits. Before admitting an unconfirmed transaction, it may additionally apply standardness, minimum-fee, replacement, ancestry and package policies. A conflicting-input check is a fact about that node’s current mempool, not a global first-seen rule.
Mempool limits and expiry
Bitcoin Core’s default mempool memory limit is commonly 300 MB and its default expiry is commonly 336 hours, but operators can configure both. Full mempools use package or cluster economics and local limits; an evicted transaction can be rebroadcast later and may still be valid.
Propagation and private broadcast
Propagation timing varies with peers, topology, policy, bandwidth and transaction origin. Do not treat a fixed percentage or number of seconds as a protocol guarantee. Bitcoin Core also supports private broadcast paths, reinforcing that public explorer visibility is not a complete network view.
What ASIC Miners Actually Contribute
An ASIC contributes hash attempts toward finding a valid proof-of-work block. It does not validate every transaction, decide which conflicting transaction wins, or make a 0-conf payment immutable. Those functions involve full-node validation, pool or miner template policy and eventual chain confirmation.
Keeping hardware operational can contribute to available network hash rate, but the effect of any individual machine is fractional and does not justify a claim that repair directly secures every unconfirmed transaction. For equipment support, see ASIC repair services.
Frequently Asked Questions
What exactly is a zero-confirmation transaction in Bitcoin?
It is a signed transaction that has not yet been included in a block. It may be accepted by some nodes and absent from others, and it has no confirmation-based settlement assurance.
Is it safe to accept a zero-confirmation Bitcoin transaction?
Not by default for high-value or irreversible fulfillment. A business that accepts 0-conf should use an explicit loss limit, its own node and peer monitoring, while recognizing that these measures are heuristics rather than guarantees.
How does Replace-by-Fee (RBF) affect zero-confirmation transactions?
BIP125 signaling warns that replacement is intended. Full-RBF became configurable in Bitcoin Core 24.0 and the default policy in v28.0, so no-RBF signaling is not proof that an unconfirmed payment cannot be replaced or conflicted.
How do CPFP and package relay affect zero-confirmation transactions?
CPFP can improve the fee incentive for a parent and child package when the recipient controls a spendable output. It does not prevent a conflicting spend, and package relay behavior is local policy rather than consensus.
How does Lightning relate to zero-confirmation on-chain payments?
Lightning can provide rapid off-chain settlement when routing and liquidity work, but payments can fail and channel operations still touch the blockchain. It should be described as an alternative payment path, not universally instant, final or fee-free.
What role do miners and ASICs play in 0-conf security?
ASICs perform hashing; pools or mining nodes select candidate transactions. A block confirmation adds proof-of-work-backed confidence, but miners and nodes are not bound by a universal first-seen policy.
Can a zero-confirmation transaction be reversed or cancelled?
Before confirmation, a conflicting transaction may be accepted or mined, depending on propagation, policy and miner selection. After confirmation, replacement requires reorganizing chain history and becomes harder with additional blocks, but finality remains probabilistic.
Sources and policy notes
Technical claims were checked against the BIP125 specification, Bitcoin Core transaction relay policy, current Core mempool replacement policy, the Core v28 release notes, the Core v31 release notes, and the Bitcoin Developer Guide payment-processing notes. Policy and network behavior are implementation-dependent and should be rechecked when software or operating conditions change.
Reviewed: August 29, 2026.
