History, Speed Up & Cancel (RBF)

What this tool does

History is the shared local log of every transaction broadcast through the tools (txid, tool used, fee, status). While a tx is still pending in the mempool, two RBF (BIP-125) actions are available on it: Speed Up rebuilds the same tx with a higher fee by trimming its change output, and Cancel replaces it with a minimal 1-in / 1-out tx that sends the funds back to your payment address so the original recipient receives nothing.

Two RBF actions at a glance

Both actions are fee replacements (replace-by-fee) and can only be used while the original tx is still unconfirmed. Relay and mining of a replacement depend on the policy of each node and miner (BIP-125 signalling, or full-RBF where enabled): acceptance is never universal or guaranteed. They differ in intent and in what happens to the recipient:

• Speed Up — keeps the same recipient outputs; the fee bump is funded by shrinking the change output, or, when the change is not enough, by adding verified-clean Payment UTXOs as extra inputs. The recipient still gets paid, just faster.
• Cancel — replaces the pending tx with a 1-in / 1-out tx that returns funds to your payment address. The recipient gets nothing. Use it when you want to abort a transfer (wrong address, wrong amount, changed your mind) before it confirms.

The rest of this page is split into two parts: Part 1 documents Speed Up; Part 2 documents Cancel (including how extra payment UTXOs are pulled in when the reused input alone doesn't cover the new fee).

Part 1 — Speed Up (bump the fee, keep the tx)

Speed Up rebroadcasts the same transaction with a higher fee rate. Recipient outputs stay identical. The fee bump is funded first by shrinking the Payment change output; if that is not enough, verified-clean Payment UTXOs can be added as extra inputs (a new CHANGE output may then appear).

When to Speed Up

• Tx stuck for several hours because of an insufficient fee.
• Confirmation urgency (sale, deadline).
• After-the-fact audit of a past operation.

Speed Up prerequisites

• Xverse wallet connected (Speed Up only).
• Tx tracked in tx_history (every tx broadcast via Bitcoin Tools is, automatically).
• Enough value to fund the fee bump: either the change output can be shrunk, or additional verified-clean Payment UTXOs are available to be added as inputs.

Speed Up step-by-step

1. Open History or the Wallet Dashboard (Pending tab).
2. Click a pending tx → Speed Up.
3. The tool loads inputs from mempool.space.
4. Pick the new fee rate. The dialog shows two distinct numbers: the minimum valid replacement — the planner computes the stricter of Bitcoin Core's incremental-relay requirement and a fee strictly exceeding the original feerate, using the actual replacement size and the selected input/output layout — and the mempool recommendation for a likely next-block confirmation. Neither guarantees relay, mining or next-block confirmation.
5. The payment change output is reduced automatically.
6. Sign via Xverse; the new tx replaces the original.

Speed Up edge cases

• Inputs outside the wallet: refused (impossible to RBF someone else's tx).
• Change below the 546-sat threshold after reduction: blocked.
• Tx already confirmed in the meantime: Speed Up disabled.

Speed Up safeguards

• Ownership validation on every input.
• Anti-dust on the reduced change.
• The planner is the single validator of the fee: a rate below the computed minimum replacement is refused, and any Payment UTXO added as a new input must be verified clean (fail-closed: unknown or incompletely verified UTXOs are never added).

Sources & server (both actions)

mempool.space (fetch tx, broadcast). Updates tx_history with the new txid.

Need to abort the transfer instead of accelerating it? Jump to Part 2 — Cancel (RBF) below.

Part 2 — Cancel (RBF) — abort a pending transaction

Cancel replaces a pending transaction with a minimal 1-in / 1-out RBF transaction that sends the funds back to your own payment address. The original recipient receives nothing. It works as long as the original tx has not been mined.

Only want to speed the tx up without changing its outputs? See Part 1 — Speed Up above.

Why this is safe for your assets

BIP-125 only requires at least one common input between the original and its replacement — not all of them. Cancel keeps a single payment input and omits every ordinals input the original was spending.

Because ordinals inputs are never referenced by the cancel tx, they are never signed and never spent on-chain. Once the original is evicted from the mempool, those UTXOs stay in the wallet exactly as before — same rule for inscriptions, runes, BRC-20, rare sats and alkanes.

Fee rules (BIP-125, cumulative)

For nodes to relay the replacement and for miners to prefer it, both rules must hold:

1. newFeeRate > oldFeeRate — the new tx must beat the original on sat/vB.
2. newFee > oldFee and newFee − oldFee ≥ minRelay × newVsize (~110 sats minimum for a cancel tx) — covers the relay bandwidth of the extra tx.

The cancel tx is smaller than the original (~110 vB for 1-in / 1-out P2WPKH), so at an equal fee rate its absolute fee would be lower and rule #2 would fail. The dialog therefore pre-fills the minimum viable fee rate; you can only raise it, never lower it below that floor.

Funding the cancel — extra payment inputs

A 1-in / 1-out cancel tx is only valid if the reused payment input covers newFee + 546 sats (the P2WPKH dust threshold on the recovered output). When it doesn't, the dialog automatically pulls extra P2WPKH UTXOs from your payment wallet as additional funding inputs.

• Confirmed first, largest-first: confirmed payment UTXOs are picked in descending value order until the required total is reached.
• Vsize and fee are recomputed at each step: every extra P2WPKH input adds ~68 vB, so the target fee rate is applied to the new vsize.
• Strict exclusions: never the outpoint already reused, never an outpoint already spent by another pending tx, never a UTXO from the ordinals address, never a UTXO carrying an inscription, rune, BRC-20 or rare sat.
• Recap rows in the dialog: Required input total (cancel fee + 546 dust), Available input total, and Missing X sats when funds are insufficient.

Last resort — using unconfirmed payment UTXOs

When confirmed UTXOs alone don't cover the required total, an opt-in switch appears: "Use unconfirmed payment UTXOs". It lets the cancel consume UTXOs from your payment wallet that are still sitting in the mempool.

• Toggle visibility: shown only when confirmed funds are insufficient AND at least one eligible unconfirmed UTXO exists. Default is off.
• Selection order: confirmed UTXOs are still consumed first (largest-first), unconfirmed ones are added only if still short — again largest-first.
• Same filters: only UTXOs whose scriptpubkey_address === paymentAddress are eligible. Ordinals-address UTXOs and asset-bearing outpoints stay excluded.
• Amber warning banner: displayed only when the final selection actually consumes ≥1 unconfirmed input — the cancel will only confirm after its parent transactions do.

When to Cancel

• You realise the destination address or the amount is wrong, before the tx is mined.
• You changed your mind about the transfer while it is still pending.
• A pending tx would spend an ordinal / rune UTXO you no longer want to move.

Cancel prerequisites

• Wallet connected and the original tx still pending in the mempool.
• The original tx must contain at least one input owned by your payment address.
• The reused payment input must be large enough that the recovered amount stays above the 546-sat dust threshold.
• Enough payment sats available — confirmed, or confirmed + unconfirmed as a last resort — to cover newFee + 546 sats.

Cancel step-by-step

1. Open the Wallet Dashboard → Pending TXs tab (or the History page).
2. Click a pending tx → Cancel (next to Speed Up).
3. Read the red warning banner and confirm you want to abort the transfer.
4. The slider is pre-filled with the minimum valid replacement rate for the cancel transaction: the planner takes the stricter of the incremental-relay requirement and a fee strictly exceeding the original feerate, at the actual replacement size. Raise it if you want extra priority — the minimum guarantees neither relay nor mining.
5. Review the recap: original fee, new fee, extra cost, amount recovered to your wallet.
6. Sign; the cancel tx broadcasts and the original is evicted once relays converge.

Cancel edge cases

• No payment input in the original (fee entirely paid from an ordinals input): Cancel is blocked with a clear message — there is no fee-paying input to reuse.
• Recovered amount below 546 sats: blocked as dust.
• Fee rate lowered below the calculated floor: refused with the BIP-125 minimum shown.
• Cancel evicted, original mined: the history shows replaced-original-confirmed — the transfer went through despite the attempt.
• Not enough funds: even with unconfirmed opt-in enabled, if the available total is below the required total the button stays disabled and the dialog shows Missing X sats.
• Parent tx evicted: a cancel that spends an unconfirmed input becomes invalid if its parent is dropped from the mempool — rebroadcast is required.

Cancel safeguards

• Zero reference to ordinals inputs — they are never signed by the cancel tx.
• Both BIP-125 fee rules enforced at build time (rate + absolute).
• Ownership check on the reused input; dust check on the recovered output.
• When several payment inputs exist, the largest one is picked to maximise the recovered amount.