Definition
A 0-confirmation transaction (also called 0-conf or zero-conf) is a cryptocurrency transaction that has been broadcast to the network and is visible in the mempool but has not yet been included in any mined block. In Bitcoin and similar proof-of-work blockchains, transactions achieve finality only after miners include them in a block and subsequent blocks are added on top.
A 0-conf transaction represents the earliest possible state — the sender has signed and broadcast the transaction, but no miner has yet confirmed it.
Merchants who accept 0-conf transactions trust the network’s mempool rules and the sender’s good faith, accepting the payment before cryptographic finality is achieved. This practice speeds up user experience but introduces a small risk of double-spending.
Origin & History
| Date | Event |
| 2008 | Bitcoin whitepaper published by Satoshi Nakamoto; block confirmation model introduced |
| 2010 | Early Bitcoin merchants begin accepting 0-conf for small purchases (pizza, coffee) |
| 2013 | Peter Todd publishes research demonstrating practical double-spend attacks on 0-conf |
| 2014 | BitPay and other payment processors develop risk-scoring systems for 0-conf transactions |
| 2017 | Bitcoin Cash community prioritizes 0-conf viability as a core design goal |
| 2018 | Bitcoin Cash introduces “canonical transaction ordering” to improve 0-conf reliability |
| 2021 | Lightning Network growth reduces need for 0-conf by offering instant finalized payments |
| 2024 | Bitcoin Core introduces full RBF (Replace-By-Fee) by default, further reducing 0-conf safety |
“The network is robust in its unstructured simplicity.” — Satoshi Nakamoto, Bitcoin whitepaper
How It Works
“` Sender signs TX
| v TX broadcast to mempool
| v [0-CONF STATE] — visible, unconfirmed
| v Miner selects TX from mempool
| v TX included in block → 1 confirmation
| v Additional blocks added → 6 confirmations = finality “`
| Confirmation Level | Security | Wait Time | Use Case |
| 0-conf | Very low | Instant | Small in-person purchases |
| 1 confirmation | Low | ~10 min (BTC) | Small online payments |
| 3 confirmations | Medium | ~30 min | Mid-value transactions |
| 6 confirmations | High | ~60 min | Large value transfers |
In Simple Terms
- When you send crypto, it first appears in a waiting area called the mempool — this is the 0-conf state.
- No miner has processed it yet, so technically it could still be reversed by a double-spend.
- Merchants accepting 0-conf are betting you won’t cheat — and for small amounts, that risk is usually acceptable.
- Bitcoin Cash and some other chains have optimized their protocols to make 0-conf safer.
- Lightning Network solves the problem entirely by providing instant, truly final payments off-chain.
Real-World Examples
| Scenario | Implementation | Outcome |
| Coffee shop Bitcoin payment | Merchant accepts 0-conf for purchases under $20 | Fast checkout; occasional double-spend risk absorbed as cost of doing business |
| Bitcoin Cash point-of-sale | BCH-optimized POS systems use first-seen policy + double-spend proofs | Near-instant acceptance with low fraud risk |
| Online merchant with risk scoring | BitPay scores transaction fee, sender history, and RBF flag | Higher-risk 0-conf transactions flagged for manual review |
| Lightning Network channel open | Requires 1 confirmed on-chain TX to open; all channel payments instant | Eliminates 0-conf risk for day-to-day payments |
Advantages
| Advantage | Description |
| Instant UX | Payment visible immediately; no waiting for block confirmation |
| Viable for small purchases | Risk of double-spend is low relative to value for micro-transactions |
| Enables point-of-sale crypto | Makes crypto practical for retail environments |
| Network propagation speed | Transactions spread across nodes in seconds, making double-spends difficult in practice |
Disadvantages & Risks
| Disadvantage | Description |
| Double-spend risk | Attacker can broadcast conflicting TX with higher fee before merchant accepts |
| RBF vulnerability | Full Replace-By-Fee allows senders to replace 0-conf TX with different recipient |
| No cryptographic finality | Trust is social, not mathematical, at 0-conf stage |
| Merchant dependent | Safety entirely depends on merchant’s risk tolerance and detection systems |
Risk Management Tips:
- Only accept 0-conf for small, low-value transactions
- Check whether the transaction has opted into RBF (a signal of potential replacement intent)
- Use Lightning Network for instant payments requiring true finality
- Monitor mempool for conflicting transactions before handing over goods
FAQ
Q: Is a 0-conf transaction the same as an unconfirmed transaction?
A: Yes — both terms describe a transaction that is in the mempool but not yet in a block.
Q: Can a 0-conf transaction fail?
A: Yes. It can be replaced (via RBF), dropped from the mempool if fees are too low, or double-spent by the sender before mining.
Q: Is Bitcoin Cash safer for 0-conf than Bitcoin?
A: Generally yes — BCH has implemented double-spend proof propagation and its community prioritizes 0-conf reliability as a feature.
Q: Does Lightning Network use 0-conf?
A: Lightning channel opens require one confirmed on-chain transaction. Payments within an established channel are instant and final without any confirmation waiting period.
Q: How do merchants protect against 0-conf fraud?
A: By checking RBF flags, setting transaction value limits, using payment processors with fraud scoring, and monitoring for double-spend attempts.
UPay Tip: For everyday crypto payments, consider using Lightning Network or similar Layer 2 solutions to get the instant experience of 0-conf with the security of confirmed transactions. UPay supports instant transfers designed for real-world usability.
Disclaimer: This content is for educational purposes only and does not constitute financial, legal, or investment advice. Always conduct your own research before making financial decisions.
UPay — Making Crypto Encyclopedic
