A Bitcoin payment can show as “pending” even after your wallet says it was sent. Usually the transaction has been broadcast but has not yet been included in a block. Before changing anything, check its status, fee rate, and urgency. Then decide whether to replace the transaction with a higher-fee version, attach a fee-paying child transaction, or wait.
The terms can sound technical, but the decision is practical: RBF is usually the first option for a sender whose wallet supports it; CPFP can help when you control an unconfirmed output and the wallet can construct the required child transaction; waiting can be sensible when timing is flexible and the fee bump would cost more than the delay is worth.
The interface images in this guide are simplified concepts, not screenshots of a particular wallet. Wallet menus and capabilities differ.
A mempool is a node’s local collection of valid transactions that it has received but that are not yet confirmed in a block. There is no single, perfectly synchronized global queue: different nodes can hold different transactions and apply different relay policies. A transaction can be visible in one wallet or explorer and absent from another.
The fee is the total amount paid for a transaction. The fee rate is the fee relative to transaction size, commonly shown as sat/vB: satoshis per virtual byte. Miners generally have an incentive to choose transactions that pay well for the block space they use, so fee rate is more useful than comparing total fees alone. It still cannot promise a particular confirmation time. Demand changes, blocks have limited space, and fee estimates are estimates.
When a transaction remains unconfirmed, open it in the wallet that sent it. Check that it is still pending, whether the wallet shows an RBF or fee-bump option, and whether it identifies an unconfirmed output you can spend. If you use a block explorer, remember that transaction details are public; avoid giving a site your recovery phrase or private keys.
| Choice | Best fit | What it changes | Main limitation |
|---|---|---|---|
| RBF | You sent the transaction, control the wallet, and want to pay more for faster inclusion. | Broadcasts a replacement that conflicts with the original and offers a higher fee. | Your wallet must support it, and replacement acceptance depends on node and miner policies. |
| CPFP | You control a spendable output from the unconfirmed transaction and RBF is unavailable or unsuitable. | Creates a child transaction that spends the parent’s output and adds a fee incentive for miners to confirm both. | You need a usable output and wallet support; the child adds cost, and package relay is not universal. |
| Wait | The payment is not time-sensitive, the fee increase is not worthwhile, or the current estimate suggests conditions may improve. | Nothing new is broadcast; you monitor the original transaction. | Confirmation time is uncertain, and a transaction can eventually leave some mempools. |
Replace-by-fee (RBF) lets a sender replace an unconfirmed transaction with a conflicting version that pays a higher fee. The replacement normally spends the same inputs, and the wallet may cover the added fee by reducing change or using additional inputs. That can alter the amount returned to you as change, so review the replacement’s recipients and total fee before approving it.
In your wallet, select the pending transaction and look for an option such as “Increase fee,” “Bump fee,” or “Replace.” Names vary by wallet. Choose a fee rate based on the wallet’s current estimate and your own time target, check the total fee in bitcoin or satoshis, then review and authorize the replacement. Watch for the replacement transaction ID and confirm that the wallet now tracks the new version.
Older explanations often say a transaction must have opted in to RBF. BIP 125 describes opt-in signaling, but relay policy has evolved: Bitcoin Core 28.0 changed its default to full-RBF, and Bitcoin Core 29.0 removed the configuration option after describing full-RBF as standard behavior for that software. This does not mean every wallet, node, or miner follows identical policy. RBF remains a policy and wallet-capability question, not a guarantee. Bitcoin Core’s version 31.0 bumpfee documentation describes how its wallet creates a replacement and the conditions that can prevent it.
Child-pays-for-parent (CPFP) means creating a new transaction—the child—that spends an output from the unconfirmed parent. The child pays a sufficiently high fee so miners have an incentive to include the parent and child together. The relevant incentive is the package’s combined fee relative to its combined size, not just the child’s fee rate viewed in isolation.
CPFP can be useful if you are the sender but cannot replace the original, or if you are the recipient and control an output from the incoming payment. It will not work if you have no spendable output from the parent, if the wallet will not spend unconfirmed funds, or if the transaction package does not meet the receiving node’s policy. Check the child’s amount, change, and total combined cost before signing.
Some wallets offer an “accelerate” or CPFP action; others do not. Advanced users may encounter package-submission tools, but those are implementation-specific. Bitcoin Core’s submitpackage reference says the package is checked against consensus and mempool policy and warns that a successful submission to one node does not guarantee propagation across the network. BIP 331 describes proposed ancestor package relay; it is a draft specification, not proof that every peer supports package relay.
Wait when a confirmation is not urgent, the original fee rate is not far from current wallet estimates, and paying a higher fee would not solve a meaningful problem. Check again later rather than repeatedly rebroadcasting or creating a second ordinary payment. A transaction may confirm as block space opens, but no wallet can promise when.
Waiting has limits. Nodes can remove transactions from their mempools, including when local policies or capacity rules change. If your wallet still shows “pending” but independent transaction lookups no longer find it, the wallet’s display alone may not tell you whether the transaction is still widely available. Follow the wallet provider’s recovery guidance before trying to resend. Bitcoin Core’s getmempoolinfo documentation illustrates that even a node’s mempool and minimum fee are local, changing state.
For technical reference, this guide was checked against Bitcoin Core 31.0 RPC documentation and Bitcoin Core release notes available September 29, 2026. The basic choice is straightforward: use RBF when your sender wallet can safely replace the transaction, consider CPFP when you control an eligible output and understand the combined fee, and wait when the delay is acceptable. In every case, verify the proposed transaction in your wallet and treat confirmation estimates as uncertain.
A successful blockchain transaction does not always mean a wallet will display the tokens. Learn how to verify the network, recipient, token contract, explorer balance, bridge status, and exchange deposit details safely.
Why liquid staking tokens can trade below redemption value, how withdrawal queues, liquidity, risk and time affect the discount, and when swapping or redeeming may make more sense.
Use this practical airdrop safety checklist to verify official claim contracts, inspect wallet permissions, spot malicious signatures, and respond to suspicious approvals.
Learn how to monitor validator performance and commission changes from primary blockchain data, compare the trade-offs, and build a reliable delegator check routine.
Learn how to match crypto transfers across exchange and wallet exports, preserve cost basis, separate fees, and review Form 1099-DA before calculating gains.
Learn how MEV protection works for retail DEX swaps, how private transactions reduce sandwich risk, how slippage affects exposure, and what trade-offs to check before you trade.
Understand how account abstraction wallets use session keys, paymasters, and recovery rules, plus the permissions and risks to check before signing.
Avoid crypto withdrawal mistakes by checking the receiving chain, token contract, address, and memo or destination tag before you send funds.
Before delegating restaked assets, verify an operator’s AVS exposure, slash conditions, loss limits, redistribution rules, and exit delays with this practical checklist.
Learn what crypto proof of reserves can verify, what liabilities it may omit, and how to check an exchange’s snapshot, customer balances, and audit scope.
