Transaction Acceleration

What Is Transaction Acceleration?

Transaction acceleration is the process of increasing the priority of an unconfirmed Bitcoin transaction so that miners include it in a block more quickly. When a transaction sits in the mempool with a fee rate below what miners currently require, it can remain unconfirmed for hours or even days. Acceleration techniques solve this by raising the transaction's effective fee rate or by arranging for specific mining pools to prioritize it.

Bitcoin's fee market is a competitive auction for limited block space. Each block can hold roughly 4 million weight units of transaction data, and miners select transactions with the highest fee rates first. When network activity surges (from events like Ordinals minting or post-halving demand spikes), the minimum fee rate for timely confirmation can jump dramatically, leaving previously broadcast transactions stranded.

How It Works

There are three primary approaches to accelerating a stuck transaction, each with different requirements, costs, and trust assumptions.

Replace-By-Fee (RBF)

RBF allows the sender to create a replacement transaction that spends the same inputs but pays a higher fee. The replacement completely supersedes the original in the mempool. Since it replaces rather than supplements the original transaction, RBF adds no extra block weight, making it 30 to 90 percent more fee-efficient than CPFP.

Historically, RBF required opt-in signaling via BIP 125: the original transaction had to set at least one input's nSequence value below 0xfffffffe. Bitcoin Core 28.0 (October 2024) changed the default to enable full RBF, and Bitcoin Core 29.0 (April 2025) removed the configuration option entirely. Full RBF is now mandatory: any unconfirmed transaction can be replaced regardless of its nSequence signaling.

A valid replacement must satisfy several rules defined in BIP 125:

1. The replacement must not introduce new unconfirmed inputs beyond those the original already used
2. It must pay an absolute fee at least equal to the sum of fees paid by all transactions it replaces
3. It must pay an additional fee to cover its own relay bandwidth at or above the node's minimum relay fee
4. The total number of original transactions plus descendants being evicted must not exceed 100

# Bump fee on a stuck transaction using Bitcoin Core
bitcoin-cli bumpfee <txid>

# Or manually create a replacement with higher fee
bitcoin-cli createrawtransaction '[{"txid":"<txid>","vout":0}]' '{"<address>":0.01}'
bitcoin-cli fundrawtransaction <hex> '{"fee_rate": 25}'

Child-Pays-For-Parent (CPFP)

CPFP works by creating a new "child" transaction that spends an unconfirmed output from the stuck "parent." The child carries a fee high enough that the combined fee rate of both transactions (total fees divided by total virtual size) exceeds the threshold for block inclusion.

Miners cannot confirm the child without first confirming the parent, because the child spends an output that does not exist on-chain yet. This dependency creates an economic incentive: to capture the child's high fee, miners must include both transactions as a package.

CPFP is particularly useful when the recipient of a stuck transaction needs to accelerate it. Unlike RBF, which requires control of the original transaction's inputs (limiting it to the sender), CPFP can be performed by anyone who holds a spendable output from the stuck transaction.

Bitcoin Core 28.0 introduced 1-parent-1-child (1P1C) package relay, allowing a parent transaction below the dynamic mempool minimum fee rate to enter the mempool when accompanied by a qualifying child. This significantly improved CPFP reliability for transactions that would previously have been rejected outright.

# Create a CPFP transaction spending the stuck parent's output
bitcoin-cli createrawtransaction \
  '[{"txid":"<parent_txid>","vout":<output_index>}]' \
  '{"<destination_address>": <amount>}'

# Sign and broadcast the child with a high fee rate
bitcoin-cli signrawtransactionwithwallet <hex>
bitcoin-cli sendrawtransaction <signed_hex>

Out-of-Band Acceleration Services

Out-of-band accelerators let users submit a transaction ID to a service that partners with mining pools. The partner pools add the transaction to a priority list and include it in their next block template, even if its on-chain fee rate would normally be too low. The acceleration fee is paid off-chain (via Lightning, credit card, or other methods) rather than through the transaction itself.

Major providers include mempool.space's Accelerator (partnering with pools covering approximately 40 percent of global hashrate, including Foundry USA Pool and MARA Pool), ViaBTC's Transaction Accelerator, and F2Pool's accelerator service. Because block discovery is probabilistic, acceleration time depends on whether a partner pool finds the next block.

When Transactions Get Stuck

A transaction becomes stuck when its fee rate falls below the threshold that miners require for inclusion. Several factors contribute:

• Network congestion: during demand surges, the mempool can grow to hundreds of megabytes, pushing minimum confirmation fee rates sharply higher
• Stale fee estimates: wallet software may calculate fees based on conditions that change between estimation and broadcast
• Mempool eviction: Bitcoin Core caps the mempool at 300 MB by default and evicts the lowest-feerate transactions first when full
• Dynamic minimum fee: when the mempool is full, nodes raise their minimum relay fee to the feerate of the last evicted transaction, rejecting any incoming transaction below this floor

Unconfirmed transactions expire after 336 hours (14 days) by default if they remain in the mempool without confirmation. After expiration, the sender's funds become spendable again, but any time-sensitive payment has effectively failed.

Comparing Acceleration Methods

Use Cases

Time-Sensitive Payments

When a payment must confirm within a specific window (exchange deposits before a trading deadline, invoice payments before expiry), acceleration prevents the transaction from missing its deadline. RBF is the preferred method because most modern wallets support it natively and it is the most cost-effective approach.

Lightning Channel Operations

Force-close transactions and anchor output spends on the Lightning Network often require fee bumping to confirm before timelocks expire. Lightning implementations use both RBF and CPFP extensively. The introduction of TRUC transactions (BIP 431) in Bitcoin Core 28.0 provides tighter topology constraints specifically designed for reliable fee bumping in protocol contexts.

Consolidation During Low-Fee Periods

Users performing UTXO consolidation at minimal fee rates may find their transactions stuck if fees rise unexpectedly. RBF allows them to bump the fee incrementally rather than abandoning the consolidation entirely.

Avoiding Acceleration Entirely

Transaction acceleration is fundamentally a workaround for Bitcoin's base-layer throughput constraints. Layer 2 solutions take a different approach by moving transactions off-chain, where they are not subject to block space competition.

Spark, for example, provides instant finality for Bitcoin and stablecoin transfers without requiring users to interact with the mempool at all. Transactions settle immediately between participants, eliminating the fee estimation guesswork and congestion delays that make acceleration necessary. For users who regularly encounter stuck transactions, moving routine payments to a layer 2 protocol can be more practical than repeatedly accelerating on-chain transactions.

Risks and Considerations

Overpaying Fees

When accelerating under pressure, users often overshoot by setting fees far above what is necessary. Fee estimation tools can help, but during volatile fee markets their predictions become less reliable. RBF allows incremental bumps (increasing the fee rate step by step), which is more economical than a single large jump.

Double-Spend Perception

RBF replaces the original transaction entirely, which means the original TXID becomes invalid. Recipients tracking the original TXID may incorrectly interpret this as a failed payment. Wallets and payment processors must handle RBF replacements properly to avoid confusion.

Centralization Risk with Accelerators

Out-of-band acceleration services introduce a trust dependency on specific mining pools. If users increasingly rely on these services rather than protocol-native mechanisms, it could create an off-chain fee market that benefits large pools at the expense of network decentralization. The pricing of these services is also opaque compared to on-chain fee markets.

CPFP Output Requirements

CPFP requires a spendable unconfirmed output from the stuck transaction. If the transaction sends its entire value to the recipient with no change output, the sender cannot perform CPFP. In this scenario, only the recipient (or the sender via RBF) can accelerate the transaction.

Related Resources

• Fee Bumping Guide: RBF and CPFP for a detailed walkthrough of both protocol-native acceleration methods
• Bitcoin Fee Market Dynamics for understanding how fee competition drives transaction delays
• Mempool Congestion Economics for analysis of what causes mempool backlogs

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.