Bitcoin replace-by-fee, shortened to RBF, is a mechanism that lets you replace an unconfirmed transaction in the mempool with a new version that pays a higher fee. If you've ever sent Bitcoin and watched it sit unconfirmed for hours while the network was busy, RBF is the escape hatch you wish you'd known about.
Why transactions get stuck in the first place
Every Bitcoin transaction waits in a queue called the mempool before a miner picks it up and includes it in a block. Miners aren't charitably processing transactions in arrival order. They prioritise whichever transactions offer the highest fees per unit of data (measured in satoshis per virtual byte, or sat/vB).
When network demand spikes, the mempool fills up fast. A transaction that carries a fee matching yesterday's quiet-market rate can slide to the back of the queue. It waits. And waits. Sometimes for days.
RBF exists to solve exactly this problem.
How replace-by-fee actually works
When you send a Bitcoin transaction, you can signal to the network that you're willing to replace it later. This is called opting in to RBF. The signal is set in the transaction's sequence field. Any transaction with a sequence number below 0xFFFFFFFE is treated as RBF-enabled by default on most modern wallets.
Once that signal is set, you can broadcast a second version of the same transaction, spending the same inputs, but with a higher fee attached. Miners will see the new version, prefer it over the original because it pays more, and the original gets evicted from the mempool. Only one version can confirm on the blockchain.
There are two key rules the replacement must satisfy:
- The new fee must be high enough to cover the original fee plus at least 1 sat/vB extra for the replacement's own size.
- The replacement can't add more than 100 new unconfirmed ancestor transactions.
Most wallet software handles the maths automatically. You just tap "bump fee" and the wallet constructs the replacement transaction for you.
Full RBF vs opt-in RBF
There are two versions of the policy, and it's worth knowing the difference.
Opt-in RBF (formalised in BIP 125) only allows replacement when the original transaction explicitly set the RBF signal. A transaction without the signal was theoretically safe from replacement. This gave merchants some confidence that an unconfirmed payment without the flag was less likely to be reversed.
Full RBF is a more aggressive policy where any unconfirmed transaction can be replaced, regardless of signalling. Bitcoin Core added full RBF as a configurable option in late 2022. Adoption among miners has grown gradually since then. In practice, this means zero-confirmation payments are now treated as provisional by most professional participants.
For everyday buyers and sellers, the takeaway is simple: treat any unconfirmed Bitcoin transaction as not-yet-final, regardless of the RBF flag.
When you'd actually use RBF
The most common use case is a stuck payment. You send Bitcoin, the network fee estimate turns out to be too low, and your transaction has been sitting unconfirmed for an hour. You open your wallet, find the pending transaction, and hit "bump fee" or "replace transaction." The wallet constructs a new version with a higher fee, you confirm, and the replacement typically gets picked up within the next block or two.
RBF is also used to cancel a transaction before it confirms. Because the replacement must spend the same inputs, you can redirect those funds back to yourself. Send a replacement transaction to your own address with a high enough fee, and the original payment effectively never happens. This only works if the original transaction hasn't confirmed yet.
Traders using time-sensitive payments find RBF useful too. If you're paying for something with a deadline, being able to increase your fee on the fly removes the anxiety of watching a stuck transaction slowly lose relevance.
What RBF is not
RBF is not a way to reverse a confirmed transaction. Once a transaction has been included in a block and received sufficient confirmations, it is permanent. The blockchain is immutable at that point. RBF only operates in the mempool, on unconfirmed transactions. This distinction matters enormously.
RBF is also not unique to any one wallet. Support varies, but most reputable wallets either enable it by default or give you the option. Check your wallet's documentation to confirm its stance.
Is RBF a security risk?
RBF was controversial when it was first proposed because some merchants accepted zero-confirmation transactions as final. The concern was that a buyer could pay, receive goods, then replace the transaction with one sending the funds back to themselves.
The practical consensus today is that accepting zero-confirmation Bitcoin payments for physical goods without additional safeguards was never secure to begin with. RBF didn't create that vulnerability. It just made it more visible. Merchants who need payment certainty should wait for at least one confirmation before releasing goods or services. Understanding how Bitcoin network fees are calculated helps you set an appropriate fee from the start, reducing the need for replacements altogether.
Checking whether your wallet supports RBF
Most modern Bitcoin wallets support RBF in one form or another. Bitcoin Core enables RBF by default for all outgoing transactions. Mobile wallets like BlueWallet and Muun also support fee bumping. Some simpler or custodial wallets don't expose fee bumping controls, in which case your only option is to wait.
If your wallet doesn't support RBF, the alternative is CPFP: child-pays-for-parent. You create a new transaction that spends an unconfirmed output from the stuck transaction, attaching a high enough fee to compensate for both. Miners see the combined fee, treat both transactions as a package, and include them together.
Knowing both options means you're never completely stuck, regardless of which wallet you're using.