How to cancel a pending transaction in UniSat? (RBF Tutorial)

Understanding Transaction Mempool Dynamics

1. Bitcoin transactions enter a public pool known as the mempool before confirmation.

2. UniSat wallet relies on the Bitcoin network’s native transaction propagation mechanism, meaning it does not host its own mempool or override consensus rules.

3. Once broadcast, a transaction remains pending until mined or evicted due to low fee pressure or timeout.

4. The mempool is volatile—transactions with higher feerates tend to displace lower-fee ones over time.

5. No centralized authority controls which transaction gets confirmed first; miners decide based on economic incentives.

Requirements for RBF Activation

1. The original transaction must signal Replace-by-Fee (RBF) by setting the nSequence field to a value less than 0xFFFFFFFE.

2. UniSat wallet enables RBF by default for all standard send operations unless manually disabled during transaction construction.

3. Users must retain full control of the private keys associated with the inputs used in the original transaction.

4. The replacement transaction must spend at least one of the same inputs and cannot reduce the total output value.

5. Fee bumping requires calculating a new feerate that exceeds the original by a sufficient margin to attract miner attention.

Step-by-Step RBF Execution in UniSat

1. Open UniSat wallet and navigate to the Transaction History tab.

2. Locate the pending transaction and tap the three-dot menu icon next to it.

3. Select 'Speed Up' — this triggers an RBF-aware transaction builder.

4. Adjust the feerate slider upward until the estimated confirmation time drops below your target threshold.

5. Confirm the new signature using your wallet passphrase or hardware device prompt.

Common Pitfalls and Limitations

1. If the original transaction was sent without RBF signaling, no replacement is possible through UniSat or any other tool compliant with Bitcoin Core policies.

2. Attempting multiple RBF replacements too quickly may result in mempool rejection due to ancestor fee constraints.

3. Some block explorers do not immediately reflect RBF status changes, causing confusion about whether the replacement succeeded.

4. Hardware wallets like Ledger or Coldcard require explicit RBF support activation in their firmware settings prior to signing.

5. Transactions stuck for more than 72 hours often get dropped from most node mempools, making RBF irrelevant after that point.

Frequently Asked Questions

Q: Can I cancel a UniSat transaction if it has zero confirmations but wasn’t created with RBF?A: No. Without RBF signaling, the transaction cannot be replaced under Bitcoin’s current consensus rules. You must wait for natural mempool expiry or attempt CPFP via a child transaction—if you control the change output.

Q: Does UniSat support CPFP as an alternative to RBF?A: Yes. If you received change from the original transaction and hold its private key, you can create a new transaction spending that change with a high feerate, indirectly incentivizing miners to confirm both.

Q: Why does the 'Speed Up' option sometimes appear grayed out?A: This occurs when UniSat detects that the pending transaction lacks RBF signaling, originates from a watch-only address, or involves inputs controlled outside the current wallet session.

Q: Will my original transaction reappear after sending a replacement?A: No. A valid RBF replacement invalidates the original in the eyes of compliant nodes. However, some outdated block explorers may temporarily display both until full network propagation completes.