Full RBF in Practice: How Bitcoin's Mempool Policy Shift Affects Zero-Conf Merchants

For years, Bitcoin merchants accepting unconfirmed transactions relied on a fragile social contract: senders who did not signal replace-by-fee were unlikely to double-spend. That contract is now void. As of Bitcoin Core 29.0, released in April 2025, full RBF is unconditional: any unconfirmed transaction can be replaced by a conflicting one that pays a higher fee. The configuration option to disable it has been removed entirely.

This shift has been over a decade in the making, and its impact on merchants who previously accepted zero-conf payments is both practical and philosophical. Understanding the technical mechanics, the actual risk data, and the available mitigation strategies is essential for anyone building or operating Bitcoin payment infrastructure.

What Is Replace-By-Fee?

Replace-by-fee is a mempool policy that allows a sender to replace an unconfirmed transaction with a new version paying a higher fee. When a node receives a conflicting transaction that meets the replacement criteria, it drops the original from its mempool and accepts the replacement. The replacement must pay strictly higher absolute fees and cover the additional bandwidth cost of relaying the new transaction.

RBF exists because Bitcoin transactions are not final until they are included in a confirmed block. Between broadcast and confirmation, a transaction sits in the mempool as a candidate. Nothing in the Bitcoin protocol prevents a sender from broadcasting a conflicting transaction during this window. RBF formalizes the rules under which nodes accept such replacements rather than ignoring them.

From Opt-In to Full: The Policy Evolution

The path from opt-in RBF to unconditional full RBF spans nearly a decade of development, debate, and gradual network adoption. Understanding this timeline is critical context for evaluating the merchant impact.

BIP 125 and Opt-In RBF (2016)

BIP 125, authored by David A. Harding and Peter Todd, was deployed in Bitcoin Core 0.12.0 on February 23, 2016. It introduced an opt-in mechanism: a transaction could signal replaceability by setting its nSequence field to a value less than 0xfffffffe. Only transactions carrying this signal would be eligible for replacement under standard mempool policy.

The opt-in design was a compromise. Merchants could treat non-signaling transactions as lower-risk for zero-conf acceptance, while senders who needed fee bumping could explicitly enable it. This created a two-tier system: signaled transactions were replaceable, non-signaled ones were treated as first-seen-safe by compliant nodes.

The mempoolfullrbf Option (2022)

In June 2021, Antoine Riard proposed adding a -mempoolfullrbf configuration option to Bitcoin Core. PR #25353 was merged on July 12, 2022, and shipped in Bitcoin Core 24.0.1 (December 12, 2022). When enabled, this option told the node to accept replacements for any unconfirmed transaction, regardless of whether it signaled BIP 125 replaceability.

The option defaulted to off (mempoolfullrbf=0), so operators had to consciously enable it. Even so, its mere existence triggered immediate pushback. Dario Sneidermanis of Muun Wallet posted to the bitcoin-dev mailing list in October 2022, warning that zero-conf applications would need to instantly disable their features and that Muun would have to turn off outbound Lightning payments for over 100,000 users.

Full RBF as Default and Unconditional (2024-2025)

Bitcoin Core 28.0, released on October 2, 2024, flipped the default: mempoolfullrbf=1. Every node running default settings now accepted replacements for all unconfirmed transactions. The release also introduced limited package RBF, TRUC (Topologically Restricted Until Confirmation) transactions, and pay-to-anchor outputs, reflecting a broader modernization of mempool policy.

Bitcoin Core 29.0, released on April 14, 2025, removed the mempoolfullrbf option entirely via PR #30592. Full RBF is now unconditional and cannot be disabled. The justification was straightforward: with effectively all mining hash power already applying full RBF, the toggle provided no meaningful protection.

How Full RBF Changes Mempool Replacement Rules

Under opt-in RBF, a node receiving a conflicting transaction would first check the original's nSequence values. If none signaled replaceability, the conflict was rejected. Under full RBF, the nSequence check is skipped entirely. Any unconfirmed transaction is eligible for replacement, provided the replacement meets the fee requirements defined in BIP 125's replacement rules.

The replacement must pay a higher absolute fee than the sum of all transactions it displaces. It must also pay a fee rate high enough to cover the incremental relay cost (the minimum relay fee multiplied by the replacement's size). The replacement cannot introduce new unconfirmed inputs that the original did not already spend. These rules prevent denial-of-service attacks where an attacker could flood the network with free replacements.

Technical detail: Full RBF does not change the replacement fee rules themselves. It only removes the gating check on nSequence signaling. A transaction that was non-replaceable under opt-in policy is now replaceable under the exact same fee-based criteria that always applied to signaled transactions.

Zero-Conf Merchants: The Risk Before and After

The practical impact of full RBF depends on understanding what zero-conf acceptance actually looked like before the policy change, and how the risk profile has shifted.

The Pre-Full-RBF Landscape

Merchants accepting zero-conf payments relied on two layers of protection. First, non-signaling transactions would not be replaced by compliant nodes, so an attacker needed to find a miner willing to include a conflicting transaction directly. Second, the first-seen rule meant that well-connected nodes would reject the double-spend attempt if it arrived after the original. Merchants with good node connectivity and mempool monitoring could detect most attack attempts within seconds.

Sergej Kotliar, CEO of Bitrefill (one of the largest Bitcoin-accepting merchants), reported that fewer than one in a million double-spend attempts succeeded against their systems. This figure reflected Bitrefill's specific setup: monitoring multiple mempools, enforcing fee-rate thresholds, and maintaining strong network connectivity. It was not generalizable to all merchants, but it demonstrated that zero-conf could be made practically safe with sufficient infrastructure.

What Changed With Full RBF

Full RBF removes the first layer of protection entirely. An attacker no longer needs to find a non-compliant miner: every miner running default Bitcoin Core settings will now accept the higher-fee replacement. The attack surface changes from "find a willing miner" to "broadcast a higher-fee transaction before the original confirms."

The second layer (first-seen propagation advantage) still provides some protection. A legitimate transaction broadcast to the network will propagate to most nodes within seconds. An attacker attempting a replacement must ensure their conflicting transaction reaches miners before the original is included in a block. For physical point-of-sale transactions where the merchant waits a few seconds and monitors the mempool, the window for attack remains small.

Measuring the Actual Double-Spend Risk

Academic research on double-spend attacks against zero-conf transactions has produced a range of findings, depending on the attack model and merchant countermeasures.

Karame, Androulaki, and others published "Misbehavior in Bitcoin" in ACM Transactions on Information and System Security (2015), finding that double-spending attacks on fast payments "succeed with considerable probability and can be mounted at low cost" unless detection techniques are integrated. Bamert et al. (2013) showed that merchants connecting to a large random sample of Bitcoin nodes could reduce double-spend success rates to less than 0.09%.

The gap between theoretical vulnerability and practical risk was wide. Bitrefill's operational data suggested that well-equipped merchants faced negligible actual losses. But this data came from a specific, well-funded operation. Smaller merchants without dedicated mempool monitoring infrastructure faced higher risk, and full RBF raises the baseline threat for everyone.

Miner incentive alignment: The core argument for full RBF is that miners are economically rational. They will always prefer a transaction paying a higher fee, regardless of nSequence signaling. Opt-in RBF relied on what Peter Todd called a "security assumption of miners being nice" rather than following their economic incentives. By August 2023, Todd's network measurements confirmed that at least 31% of hash power across four mining pools was already mining full RBF transactions, even before it became the default.

The Community Debate: Miners vs. Merchants

The full RBF debate exposed a fundamental tension in Bitcoin's design: should mempool policy optimize for miner revenue and protocol honesty, or for merchant usability and payment acceptance?

The Case for Full RBF

• Miners are incentive-driven actors who will always prefer higher-fee transactions, making opt-in signaling a fiction
• Full RBF prevents transaction pinning attacks that affect Lightning Network and other multi-party protocols
• The opt-in flag gave merchants a false sense of security by implying non-signaled transactions were safe
• Bitcoin's long-term scaling depends on Layer 2 solutions, not on-chain zero-conf payments

The Case Against Full RBF

• Zero-conf was "unsafe in theory, but currently quite safe in practice" according to merchant operators
• Kotliar noted that 85% of Bitrefill's Bitcoin payments were on-chain, and removing zero-conf acceptance would drive most users away
• Lightning Network adoption was too low to replace on-chain zero-conf at the time of the initial debate
• Full RBF enables a "call option" attack where buyers cancel payments if exchange rates move against them after purchase
• Merchants argued they were not given adequate transition time to adapt their systems

The debate ultimately resolved through gradual adoption rather than sudden consensus. As hash power running full RBF grew from a minority in 2022 to effectively universal by 2025, the practical argument for maintaining the opt-in fiction became untenable.

Merchant Mitigation Strategies

With full RBF now unconditional, merchants accepting Bitcoin payments have several strategies to manage the double-spend risk on unconfirmed transactions.

Wait for Confirmations

The simplest approach is to require one or more block confirmations before releasing goods or services. Even a single confirmation provides strong finality guarantees for most transaction values. The tradeoff is time: Bitcoin blocks arrive approximately every ten minutes on average, and the variance can be significant. For physical retail, asking a customer to wait ten minutes is impractical for low-value purchases.

Some merchants use tiered policies: low-value transactions (under a threshold like $50) are accepted at zero-conf with the understanding that occasional fraud is a cost of doing business, while higher-value transactions require one or more confirmations.

Payment Processors With Instant Credit

Payment processors like BitPay and BTCPay Server can absorb the double-spend risk on behalf of merchants. The processor credits the merchant immediately while managing the confirmation risk internally. The processor's business model accounts for the expected loss rate from successful double-spends, pricing it into their fees. This is analogous to how credit card processors absorb chargeback risk.

After experiencing double-spend attacks in 2019, BitPay updated its guidance to recommend that merchants only fulfill orders after transactions reach "Confirmed" or "Complete" status, effectively moving away from zero-conf acceptance for their platform.

Layer 2 Payment Networks

The most robust mitigation is to move payment acceptance off the base layer entirely. Lightning Network payments settle in seconds with cryptographic finality: once a payment completes, it cannot be reversed without the recipient's cooperation. This eliminates the entire class of double-spend attacks that full RBF amplifies.

The challenge with Lightning for merchants has historically been operational complexity: channel management, liquidity planning, and the requirement that both parties be online. These barriers have slowed merchant adoption despite Lightning's security advantages.

How Layer 2 Solutions Eliminate Zero-Conf Risk

Full RBF makes the case for Layer 2 payment acceptance stronger than ever. When on-chain transactions can always be replaced before confirmation, merchants need settlement mechanisms that provide instant finality without relying on mempool behavior.

Spark addresses this gap directly. Transfers on Spark settle instantly with no confirmation delay and no possibility of replacement. The protocol uses a statechain-based architecture where ownership changes are cryptographically committed through FROST threshold signatures. Once a transfer completes, the sender's key material is destroyed: there is no mechanism for the sender to "replace" or reverse the payment, regardless of fee levels.

For merchants, this means the payment experience that zero-conf once approximated: instant acceptance with immediate certainty. Unlike zero-conf, which always carried a nonzero (if small) risk of double-spend, Spark transfers are final at the protocol level. The merchant does not need to monitor mempools, enforce fee-rate thresholds, or maintain connections to a large set of nodes. The payment is either complete or it is not.

Spark also integrates natively with Lightning Network, so merchants accepting Spark payments can also receive Lightning payments to the same wallet. This eliminates the need to choose between Layer 2 solutions and provides coverage for customers using either protocol.

The Path Forward for Bitcoin Payments

Full RBF represents a maturation of Bitcoin's base layer: the protocol now honestly reflects the economic reality that miners will always prefer higher-fee transactions. For the base layer to serve as a robust settlement network, this honesty is essential. Pretending that non-signaled transactions were safe created a false sense of security that served neither merchants nor the protocol's long-term credibility.

The practical consequence is clear: on-chain zero-conf acceptance is no longer a viable strategy for any merchant handling non-trivial transaction values. The mitigation options are well-established: confirmation waiting for high-value transactions, risk-absorbing payment processors for convenience, and Layer 2 networks for instant settlement.

For merchants evaluating their options, Layer 2 solutions offer the strongest combination of speed and security. Wallets built on Spark, such as General Bread, demonstrate what this looks like in practice: instant payments with self-custody and no double-spend risk. Developers building payment infrastructure can explore the Spark SDK documentation to integrate instant-finality Bitcoin payments into their applications. For a deeper comparison of merchant payment approaches, see our guide on Bitcoin merchant payment acceptance.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.