Bitcoin Zero-Conf vs RBF: Instant Acceptance vs Fee Bumping

Zero-Conf vs Replace-by-Fee Overview

Bitcoin merchants face a fundamental tradeoff: accept unconfirmed transactions instantly (zero-conf) or wait for block confirmations while giving senders the ability to bump fees via Replace-by-Fee (RBF). For most of Bitcoin's history, the "first-seen" mempool policy gave merchants some confidence that an unconfirmed transaction would eventually confirm. That changed in April 2025 when Bitcoin Core 29.0 made full RBF unconditional, meaning any unconfirmed transaction can now be replaced regardless of signaling.

This guide compares zero-conf acceptance and RBF from both the merchant and user perspective, examines double-spend risks, and explains why Layer 2 solutions have largely resolved the tension between instant payments and fee flexibility.

How Zero-Conf Acceptance Works

A zero-confirmation transaction is a payment that has been broadcast to the Bitcoin network and propagated to nodes but has not yet been included in a mined block. The transaction exists in the mempool but lacks the security of blockchain inclusion. Merchants who accept zero-conf deliver goods or services after seeing the transaction in their node's mempool, typically within seconds of broadcast.

Historically, most nodes followed a "first-seen" policy: accept the first valid transaction spending a given UTXO and reject later conflicting transactions. This convention gave merchants some assurance that the payment would confirm, but it was never a consensus rule. Miners were always free to include any valid transaction they chose, including a conflicting one that paid higher fees.

How Replace-by-Fee Works

Replace-by-Fee allows a sender to replace an unconfirmed transaction with a new version that pays a higher fee rate. Originally specified in BIP 125, opt-in RBF required transactions to signal replaceability by setting nSequence < 0xfffffffe. Replacement transactions must pay both a higher fee rate (sat/vB) and a higher absolute fee (total satoshis) than the original.

Satoshi Nakamoto's original Bitcoin code actually included transaction replacement via nSequence numbers, but this was disabled in version 0.3.12 (2010) due to denial-of-service concerns. The feature was reintroduced as opt-in RBF in Bitcoin Core 0.12.0 (February 2016) and progressively expanded until becoming unconditional in Bitcoin Core 29.0 (April 2025).

The Road to Full RBF

The transition from first-seen policy to unconditional full RBF took over a decade of debate. The timeline below captures the key milestones.

The developer consensus reflected in Core 29.0 is clear: Layer 2 solutions are the proper answer for instant payments, not reliance on unconfirmed on-chain transactions. For a deeper look at fee bumping mechanics, see the RBF vs CPFP comparison tool.

Double-Spend Risk Analysis

The core security concern with zero-conf is the double-spend attack: a sender broadcasts a payment to the merchant while simultaneously broadcasting a conflicting transaction (spending the same UTXOs to a different address) to miners. Research has estimated the success rate for such attacks against zero-conf at approximately 11%.

Attack Types Against Zero-Conf

• Race attack: broadcasting two conflicting transactions simultaneously, one to the merchant and one to well-connected mining nodes
• Finney attack: a miner pre-mines a block containing a conflicting transaction, spends those coins at a merchant, then releases the block
• Vector76 attack: combining race and Finney techniques to exploit a single-confirmation wait

With full RBF now unconditional, race attacks are trivial: the attacker simply broadcasts a replacement transaction with a higher fee, and nodes will relay and miners will prefer the higher-fee version. No special network position or mining power is required.

Merchant Risk Mitigation Strategies

Before full RBF became default, merchants employed several strategies to reduce zero-conf risk. Some of these remain relevant for merchants who still accept unconfirmed payments with calculated risk tolerance.

• Enforce value limits: only accept zero-conf for transactions under a threshold (commonly $20-50)
• Monitor the mempool for conflicting transactions that indicate a double-spend attempt in progress
• Verify the transaction fee is sufficient for likely next-block inclusion, using fee estimation data
• Require physical presence: zero-conf fraud is harder when the attacker must stand at a point-of-sale terminal
• Avoid irreversible goods: do not deliver digital goods, gift cards, or high-value items on zero-conf

Post-Core 29.0 reality: With full RBF unconditional, these mitigations reduce but do not eliminate risk. Merchants accepting zero-conf on-chain today are accepting a non-trivial probability of loss.

Payment Processor Approaches

Major Bitcoin payment processors have taken different stances on zero-conf acceptance. The table below summarizes current policies.

BTCPay Server's approach is instructive: even before full RBF became default, its "High" speed policy (zero-conf) was labeled with a warning against use. When a transaction is flagged as signaling RBF, BTCPay Server automatically overrides the speed setting and waits for at least one block confirmation.

Why Layer 2 Solutions Resolve the Debate

The zero-conf vs. RBF debate was fundamentally about whether on-chain unconfirmed transactions could serve as a payment mechanism. Layer 2 protocols provide a definitive answer by moving fast payments off-chain while retaining on-chain security guarantees.

The Lightning Network settles payments in under a second with fees measured in satoshis. At the Bitcoin 2025 conference, BTCPay Server processed over 4,100 Lightning transactions in a single 8-hour period, demonstrating real-world throughput at merchant scale. For a detailed comparison of on-chain versus Lightning payments, see the Lightning vs On-Chain tool.

Spark takes a different approach as a statechain-based Layer 2 protocol: it enables instant, self-custodial Bitcoin transfers without requiring payment channels or node management. Spark is natively interoperable with Lightning and supports stablecoins via Taproot Assets, allowing merchants to accept both BTC and dollar-denominated payments with instant finality. This eliminates the zero-conf problem entirely: merchants receive confirmed value in milliseconds instead of gambling on mempool policy.

For a deeper dive into the security model, read Zero-Conf Bitcoin Explained.

Risk Comparison by Payment Method

The following table compares double-spend risk, speed, and merchant suitability across on-chain and Layer 2 payment methods.

Frequently Asked Questions

Is it safe to accept zero-conf Bitcoin transactions in 2026?

No. Since Bitcoin Core 29.0 (April 2025), full RBF is unconditional and cannot be disabled. Any unconfirmed transaction can be replaced with a higher-fee version, making double-spend attacks trivial. Merchants should either wait for at least one block confirmation or use a Layer 2 protocol like Lightning or Spark for instant payments.

What is the difference between opt-in RBF and full RBF?

Opt-in RBF (BIP 125, introduced in Bitcoin Core 0.12.0) required transactions to signal replaceability by setting nSequence < 0xfffffffe. Merchants could check this flag and reject signaling transactions for zero-conf. Full RBF removes the signaling requirement: all unconfirmed transactions are replaceable regardless of their sequence number. Bitcoin Core 28.0 made full RBF default, and Core 29.0 made it unconditional.

Can merchants use CPFP instead of RBF to speed up stuck transactions?

Yes. Child-Pays-for-Parent allows the recipient (or sender) to create a child transaction spending an output of the unconfirmed parent, with a fee high enough to incentivize miners to include both. Unlike RBF, CPFP does not replace the original transaction, so the original payment destination remains intact. See the RBF vs CPFP comparison for a detailed breakdown.

How does Lightning Network eliminate the zero-conf problem?

Lightning payments settle atomically using HTLCs: the payment either completes in full or fails entirely, with no intermediate state where a double-spend is possible. Settlement happens in under a second, and the payment is final the moment the recipient receives the payment preimage. There is no mempool, no confirmation wait, and no replacement window.

Why did Bitcoin Core make full RBF unconditional?

The Bitcoin Core 29.0 release notes stated: "With widespread adoption of this policy, users no longer benefit from disabling it." The rationale was threefold: full RBF improves fee market efficiency by letting users correct underpaying transactions, it improves block reconstruction for compact block relay, and Layer 2 solutions now provide proper instant payment mechanisms without relying on mempool conventions.

Does Spark support zero-conf channels like the Lightning Network?

Spark does not use payment channels at all. As a statechain-based protocol, Spark enables instant, self-custodial transfers without requiring channel management, inbound liquidity, or watchtowers. This fundamentally different architecture avoids both the zero-conf on-chain problem and the channel-management complexity of Lightning. For a comparison of the two approaches, see Lightning vs Spark.

What happened to merchants who relied on zero-conf?

Merchants like Bitrefill, which sold gift cards on zero-conf, operated successfully for years by combining mempool monitoring, transaction value limits, and RBF flag checking. The introduction of full RBF forced these merchants to either add confirmation waits (degrading UX for on-chain payments) or migrate to Lightning for instant settlement. Most Bitcoin-native merchants now offer Lightning as the primary payment rail.

This tool is for informational purposes only and does not constitute financial advice. Data is approximate and based on publicly available information as of mid-2026. Bitcoin Core policies and payment processor terms may change. Always verify current data before making merchant acceptance decisions.