What you will do
A Bitcoin payment can remain pending when its fee rate is too low for current demand. If the payment was built for replacement, the sender can create a new version that spends the same inputs and pays a higher fee. This is called Replace by Fee, or RBF.
This guide uses Sparrow Wallet 2.5.5, the latest published release when checked on 21 October 2026. The official release record dates it to 17 September 2026. Sparrow's fee-increase instructions describe the same flow used here: find an unconfirmed transaction, choose Increase Fee, set a higher fee rate, review the replacement, then sign and broadcast it.
You will stop before signing while practising. No wallet, keys, address, server connection, transaction broadcast or funds were used to verify this guide.
Before you start
You need:
- Sparrow Wallet 2.5.5 opened to the wallet that sent the original payment
- the pending transaction visible on the Transactions screen
- the signing device or signing process normally used by that wallet
- enough wallet value to pay the larger fee
- the original recipient, amount and transaction ID written down for comparison
The Sparrow FAQ lists three conditions for its RBF action: the transaction is still in the mempool, all inputs permit the wallet's replacement flow, and all inputs belong to the wallet. Sparrow enables RBF by default for payments it sends, but a transaction created elsewhere may not meet these conditions.
Do not restore a seed phrase, import private keys or move funds merely to expose the button. If the wallet that created the transaction is unavailable, stop and recover that wallet through its normal documented process first.
1. Confirm that the payment is still pending
Open Transactions and find the payment. It must show as unconfirmed. If it already has a block confirmation, it cannot be replaced through the mempool. A confirmed payment is part of the blockchain history.
Compare the transaction ID, recipient amount and time with the record made before starting. A wallet may show several pending payments. Raising the wrong fee creates a real replacement for the wrong transaction.
Do not judge confirmation only from a message sent by the recipient. Let Sparrow finish syncing with its configured server. If the wallet is offline or still loading, its status may be stale.
An unconfirmed transaction is not a promise that its first version will confirm. The deployed BIP 125 specification explains that nodes may accept a replacement that spends the same inputs and pays enough additional fee. Current Bitcoin Core policy also allows full replacement by default. Different nodes can briefly hold different versions, so wait for a block confirmation before treating the result as final.
2. Open the fee-increase action
Right-click the pending transaction and choose Increase Fee. Sparrow may also show a fee-increase icon beside an eligible transaction.
The released 2.5.5 source only exposes that action when the transaction is unconfirmed, Sparrow can construct the replacement from wallet inputs, and mempool outputs are available. The source is visible in Sparrow's transaction entry implementation.
Sparrow should open the Send screen with a replacement transaction loaded. Do not change the recipient or payment amount. RBF is a new transaction, not an edit to a confirmed record, so every field needs another review.
If Increase Fee is absent, skip to troubleshooting. Do not choose Cancel Transaction as a substitute. Cancellation is itself a replacement that redirects value back to the wallet, which is a different operation from paying the original recipient faster.
3. Choose a higher rate and understand the cost
The new fee rate must be higher than the old one and high enough for the replacement to be accepted. Sparrow presents current estimates, but an estimate is not a guarantee of the next block.
Write down four figures before continuing:
- the original fee rate
- the original total fee
- the proposed fee rate
- the proposed total fee
Fee rate is measured in satoshis per virtual byte, written sat/vB. Total fee is measured in satoshis. They are different numbers.
Consider a synthetic 160 vB transaction:
| Version | Fee rate | Total fee |
|---|---|---|
| Original | 3 sat/vB | 480 sats |
| Replacement | 12 sat/vB | 1,920 sats |
The replacement pays 1,440 sats more. If the original transaction had a 20,000-sat change output and its size did not change, that change could fall to 18,560 sats. These are teaching figures, not a recommended fee.
Bitcoin Core 31.1 documents the current mempool replacement policy. The replacement must pay at least the fees of the transactions it removes, pay an additional relay cost, and improve the mempool's fee-rate position. This is why a tiny increase can still be rejected.
If the change output cannot cover the increase, Sparrow may add another wallet output. That can make the transaction larger, raise the fee again and link another part of the wallet's history. Return to the input and output review instead of approving the new input automatically.
4. Compare the replacement with the original
Review the transaction diagram and output list. Confirm all of the following:
- the recipient address is unchanged
- the recipient amount is unchanged
- the fee and fee rate are the figures just reviewed
- the change returns to the expected wallet
- any extra input is understood and acceptable
- the transaction does not add an unfamiliar output
The new transaction ID will be different. That is expected because the serialized transaction changed. The recipient should track the replacement ID once it propagates.
If a hardware signing device displays the outputs, compare its screen with Sparrow. Reject the signature if the device shows a different recipient, amount or unexpected output. Reopening Sparrow is safer than approving a mismatch to see what happens.
Changing the fee can reduce change or add an input. It should not silently reduce what the recipient receives. If the recipient amount changed, go back and rebuild the replacement.
5. Sign, broadcast and keep both IDs
Only sign after the replacement matches the intended payment. Use the wallet's normal signing process. A watch-only wallet may export a PSBT to a signing device. A software wallet may sign locally.
After broadcast, record both transaction IDs. Sparrow should mark the old version as replaced and show the new one as pending. The recipient may need the new ID if their wallet or invoice system cached the first version.
Do not broadcast several replacements in quick succession. Give the wallet time to sync and show whether the latest version reached its server. Another fee increase may be possible later, but every replacement costs more and creates another version to track.
Wait for confirmation according to the payment's real context. RBF improves the transaction's offer to miners. It does not reserve space in a block or guarantee a deadline.
When not to raise the fee
Leave the transaction alone if the delay is acceptable and its fee rate still matches that patience. A pending payment is not broken merely because it missed the next block.
Stop if Sparrow adds an input whose privacy cost is not understood, the fee exceeds the maximum amount worth paying, or the signing device shows different outputs. A payment can wait while those questions are resolved.
Do not use RBF after the transaction confirms. Do not use it to change a merchant's amount without agreement. Do not treat it as a cancellation guarantee: miners may confirm a version already in their mempool before another version reaches them.
If something goes wrong
Increase Fee is missing: confirm that the transaction is unconfirmed, belongs to this wallet and has no input Sparrow cannot replace. Let the wallet sync. A payment created in another wallet may need that wallet's recovery path.
Sparrow says the replacement fee is insufficient: choose a clearly higher rate and review the new total. The replacement must cover more than the original absolute fee plus the network's incremental relay requirement.
Sparrow adds another input: inspect its label and history. Adding it can link previously separate activity. Cancel the draft if that tradeoff is not acceptable.
The replacement is broadcast but the old version still appears: different servers and mempools may update at different times. Keep both transaction IDs and wait for Sparrow to sync. Do not assume that seeing both means both can confirm, because they spend the same input.
The recipient sees the old ID: send the replacement ID through the same trusted channel used for the payment details. Ask them to wait for confirmation rather than treating the first pending version as final.
The signing device shows different outputs: reject the signature. Reopen the intended wallet, verify the original payment and prepare a fresh replacement.
The fee is now too expensive: cancel the unsigned draft and wait. A wallet estimate is a choice offered to the sender, not a command to spend.
What was and was not verified
The Sparrow 2.5.5 release, current official FAQ, released 2.5.5 RBF action source, deployed BIP 125 and Bitcoin Core 31.1 replacement policy were checked on 21 October 2026.
A disposable Node.js fixture checked the synthetic arithmetic above. It confirmed 480 sats at 3 sat/vB for 160 vB, 1,920 sats at 12 sat/vB, a 1,440-sat increase and 18,560 sats of remaining change from a 20,000-sat starting change output. Negative controls rejected a non-increasing rate, insufficient change, zero size and non-integer satoshi values.
No Sparrow interface, wallet file, signing device, PSBT, server, mempool or broadcast was exercised. No real address, transaction, private key, recovery phrase or funds were used. Button placement and fee estimates can change after version 2.5.5.
The useful boundary is simple: RBF creates a second transaction that competes with the first. Check the same recipient and amount, understand the larger fee and any new input, then sign only the version intended to confirm.