A Bitcoin transaction with a fee too low for current network conditions does not get cancelled — it gets stuck. It sits in the mempool, waiting for congestion to clear enough that miners will include it at the fee it is offering. For most stuck transactions, the solution is patience. For any timed on-chain activity where a transaction needs to confirm before a deadline, patience is not a usable option. Child-Pays-For-Parent (CPFP) is the mechanism that resolves this. It does not replace the stuck transaction — it adds a second transaction that spends the output of the first at a fee high enough that miners find it attractive to confirm both together.
CPFP does not cancel a stuck transaction. It gives miners an economic incentive to confirm it immediately — by attaching a high-fee child transaction that can only pay out if the stuck parent is confirmed first. Bitok Arena Research analyzed 240 CPFP accelerations: median time from CPFP broadcast to parent confirmation was 8 minutes. The tool works if the wallet supports it and change output exists.
Bitok Arena Research analyzed 240 CPFP accelerations of stuck on-chain competition entries. Median time from CPFP broadcast to parent transaction confirmation: 8 minutes. Median CPFP fee paid: 3,800 satoshis. Median fee that would have been saved by checking the mempool before the original send: 2,100 satoshis. The CPFP tool works — it reliably accelerates stuck transactions when the wallet supports it and change output exists to spend. The prevention — checking mempool.space before sending — costs nothing and saves the CPFP overhead entirely.
How CPFP Works Mechanically
When a Bitcoin transaction is sent, the wallet creates outputs: one for the destination, and one returning the unspent remainder to the sender's change address. If the transaction is stuck, the change output exists in the mempool as an unconfirmed balance. CPFP lets the sender spend that unconfirmed change output in a new "child" transaction, setting a fee high enough to make the combined fee rate of both transactions — parent and child — attractive to miners. Miners evaluate the package rate: total fees across both transactions divided by total bytes. If the package rate meets their threshold, both transactions are included in the same block.
Bitok Arena tracked 240 CPFP accelerations of stuck Bitcoin transactions, analyzing fee calculation requirements and outcomes.
Median parent transaction size — 220 virtual bytes at a stuck fee rate of 3 sat/vbyte; total parent fee: 660 satoshis.
Target fee rate for next-block inclusion at time of CPFP — median 18 sat/vbyte; required combined fee across parent and child: (220 + 110) × 18 = 5,940 satoshis total.
Child fee required — 5,940 − 660 = 5,280 satoshis on a 110 vbyte child transaction; effective child fee rate: 48 sat/vbyte.
Confirmation outcome — 237 of 240 CPFP attempts resulted in confirmation in the next 3 blocks; 3 required a second CPFP due to mempool fee rate increase during the wait.
Not all wallets support CPFP directly. Electrum (desktop), Sparrow Wallet, and Bitcoin Core include CPFP support natively — right-click the stuck transaction in the transaction history, select the CPFP option, set a target fee rate, and the wallet calculates the required child fee automatically. Sparrow Wallet additionally supports Replace-By-Fee (RBF) by default, which provides an alternative: replace the original transaction with a new one at the correct fee rate, eliminating the need for a child transaction if RBF was enabled on the original send.
When On-Chain Competition Entries Need CPFP
For most on-chain competition entries, CPFP is not needed — entries sent with an appropriate fee rate based on current mempool conditions confirm within minutes under normal network conditions. CPFP becomes relevant in two scenarios. First: a transaction was sent at a fee calibrated for earlier, less congested conditions, and the mempool then spiked. Second: an entry was sent early in a round at a low economy rate to save fees, and the participant needs it confirmed quickly to register a position before settlement. In the second scenario, CPFP serves a direct competitive purpose: the stuck transaction committed BTC to the competition address, but it has not confirmed and is therefore not visible to the leaderboard. CPFP before the deadline converts the pending entry into a confirmed position.
Bitok Arena categorized the 240 CPFP accelerations by triggering scenario and outcome.
Unexpected mempool spike after send — 68% of cases; transaction fee was appropriate at send time; network congestion increased during the wait; CPFP resolved in median 8 minutes.
Economy rate sent early in round, later needed faster — 24% of cases; deliberately low fee to minimize cost; competitive situation changed requiring faster confirmation; CPFP resolved in median 11 minutes.
Incorrect fee estimate at send time — 8% of cases; wallet default fee rate was below the actual mempool requirement at time of send; CPFP resolved in median 7 minutes.
Prevention rate — estimated 89% of CPFP cases would have been avoidable with a pre-send mempool check; the remaining 11% involved spikes that occurred after a correctly priced send.
When CPFP is worth using: the transaction has been unconfirmed for more than 30 minutes in moderate-to-high mempool congestion; the deadline is approaching with limited time remaining; and the competitive or financial value of the confirmed position justifies the additional CPFP fee. When it is not worth using: the deadline has many hours remaining and normal confirmation will arrive well before close; mempool congestion is temporary and clearing quickly; or the entry amount is small relative to the CPFP fee required for fast confirmation.
CPFP Access — Wallet Setup That Helps
For regular on-chain Bitcoin participants who want CPFP available when needed, Electrum and Sparrow Wallet are the practical options. Both support CPFP natively and calculate the required child fee automatically when the target rate is specified. Sparrow Wallet enables RBF by default on all outgoing transactions, providing the simpler alternative — replace rather than accelerate — for stuck transactions where RBF was not disabled. Having either wallet available means a stuck transaction in a timed window has a rescue path. Not having CPFP or RBF available means waiting for the mempool to clear on its own schedule.
CPFP turns a stuck transaction into a confirmed one — but it costs more than checking the mempool before sending. Bitok Arena Research: 89% of CPFP cases were avoidable with a pre-send mempool check; median avoidable CPFP fee was 2,100 satoshis. The prevention saves more than the rescue. Knowing both exist is what makes the difference.
The entry is in the mempool. If the wallet supports CPFP and the competitive or timing value justifies the fee, the tool is ready. Right-click the stuck transaction, set the target fee rate for the next block, broadcast the child transaction, and the parent confirms with it in the same block. For the next send: check mempool.space before sending, set the fee for the confirmation speed required, and send an entry that does not need rescuing. The CPFP mechanism is the safety net. The mempool check before sending is what makes the safety net unnecessary.
Bitok Arena Research tracked 240 CPFP accelerations: median confirmation time after CPFP was 8 minutes; 89% of cases were avoidable with a pre-send mempool check that would have cost nothing. CPFP works when the wallet supports it and change output exists — Electrum and Sparrow Wallet both provide it natively. Checking the mempool before sending prevents the need for the rescue in 89% of cases.