Child-Pays-For-Parent (CPFP) is the rescue mechanism for a Bitcoin transaction that broadcasts but stalls in the mempool without confirming before it needs to. When the fee set at broadcast time is too low relative to the current mempool fee rate, miners deprioritize the transaction in favor of higher-paying ones. Two mechanisms exist to rescue this: Replace-By-Fee (RBF), which replaces the original transaction entirely with a higher-fee version, and CPFP, which adds a second transaction that pays a combined fee high enough to make miners want to include both. Bitok Arena's analysis of stuck transaction recovery methods finds CPFP is the correct approach when RBF is not enabled on the original transaction, or when the receiving address has already received the unconfirmed output and can spend it to create the child.
A transaction stuck in the mempool is not lost — it is waiting. CPFP gives miners an economic reason to mine the stuck transaction by attaching a second transaction to its unspent output that pays a fee high enough to cover both. The parent confirms because the child makes it worth mining. The mechanism works because Bitcoin miners optimize for fee revenue per block, not for transaction age.
The Bitcoin mempool is the waiting room where unconfirmed transactions queue until miners select them for the next block. When a parent transaction is stuck there, a wallet that holds the unconfirmed output can create a child transaction that spends it. Because miners cannot confirm the child without first confirming the parent, setting the child's fee high enough — so that the combined fee rate of parent plus child meets the current mempool clearing threshold — gives miners a financial incentive to mine both transactions together. Mempool.space shows the current fee rates needed for confirmation at each time window.
CPFP vs RBF: Which One Applies
What is a Replace-By-Fee transaction and when can it rescue a stuck Bitcoin send — the answer depends entirely on how the original transaction was constructed. RBF requires that the original carry the replaceability flag, either set explicitly by the sender or applied by default in wallets like Sparrow and Electrum. If that flag is present, RBF is the simpler path: broadcast a new transaction with the same inputs and a higher fee; miners drop the lower-fee original once the replacement appears. CPFP does not need the flag — it works by spending the unconfirmed output from any wallet that received it, regardless of how the original was built.
Bitok Arena reviewed stuck transaction recovery scenarios and mapped which fee-bump method applies under each condition.
Use RBF when — the original transaction was broadcast with the RBF flag set; the sending wallet supports creating a replacement; and there is sufficient time for the replacement to propagate and confirm within the required window.
Use CPFP when — the original transaction was not flagged as RBF-replaceable; the sending wallet does not support RBF; or the output was already received by the destination address, which can spend it to create the child transaction.
Neither method guarantees same-window confirmation — if the mempool is heavily congested and the confirmation window is closing, no fee bump can ensure timely confirmation; the transaction will confirm for the next available use but not the current one.
How transaction fees interact with on-chain competition timing becomes visible when a rescue bump is required: the original fee was already a cost, and the CPFP child transaction adds another. For entries from a self-custody wallet, rescue is most often needed when the sending wallet lacks RBF support. Sparrow Bitcoin Wallet and Electrum handle both methods natively. Hardware wallet companion apps like Ledger Live and Trezor Suite cover RBF on standard transactions. Simpler mobile wallets may support neither — in which case a secondary wallet with access to the unconfirmed output is the remaining option.
Executing a CPFP Bump
Electrum and Sparrow are the practical tools for CPFP on Bitcoin transactions. Both expose unconfirmed transactions in the history view and offer a fee-bump option that constructs the child transaction automatically. The process in Sparrow is one or two clicks: locate the stuck transaction, right-click to access the "Child Pays For Parent" or "Boost Transaction" option, and set a combined effective rate above the current mempool clearing threshold. The wallet calculates the required child fee and presents the transaction ready to sign and broadcast.
Bitok Arena documented Sparrow Bitcoin Wallet's CPFP function across its key operational parameters.
Transaction visibility — the Transactions tab displays stuck entries as unconfirmed with zero confirmations; the CPFP option appears on right-click.
Fee rate display — Sparrow shows current mempool fee rates alongside the child transaction builder; the target rate is the combined parent + child effective rate that exceeds the 10-minute confirmation threshold visible at mempool.space.
What the child transaction spends — a change output from the original transaction; the BTC amount going to the destination address is unchanged; only the fee composition changes between parent and child.
Setting the child fee correctly requires accounting for both its own virtual weight and the parent's, covering the combined fee shortfall in a single broadcast. Mempool.space's fee estimation shows the sat/vbyte rate for each confirmation target window — the 10-minute threshold is the practical target when time is limited. Setting the child fee to reach that combined rate is sufficient; setting it far above wastes BTC on fees without meaningfully improving confirmation odds in an already-competitive block.
Preventing the Problem
CPFP is a rescue tool, not a workflow. Reaching for it means the situation it resolves has already occurred. The better approach is setting a fee that confirms within the required window from the first broadcast, not correcting one that did not. Having a dedicated wallet for regular on-chain Bitcoin use — where mempool.space is checked before every broadcast — eliminates the underpriced transaction before it happens. A transaction broadcast with adequate margin in advance has time to absorb brief fee spikes without risk.
CPFP exists because fee estimation fails sometimes and transactions stall. The more reliable approach is to broadcast well ahead of the deadline — at a fee the current mempool can confirm within that window — and monitor once to confirm it landed. A confirmed transaction has no need for CPFP or any rescue mechanism. Prevention costs one mempool.space check. Recovery costs an additional fee and stress that the check would have avoided.
Hot wallet versus cold wallet for regular on-chain Bitcoin use matters less than the habit of checking mempool.space before every broadcast and setting a fee above the minimum for the target confirmation window. Participants who broadcast transactions early and pay the current confirmation rate rarely reach for CPFP or any other rescue mechanism. The tool is worth understanding in detail. Building transactions that never need it is the better outcome, and it requires only one additional step before each broadcast.
Bitok Arena's analysis of CPFP finds it effective for rescuing stuck Bitcoin transactions when RBF is unavailable — Sparrow and Electrum both execute it with two clicks, and the fee calculation is automated. The stronger practice is broadcasting on-chain transactions with adequate fee margin before the confirmation window closes, so the rescue tool is never needed. CPFP is the fallback for when that margin was underestimated.