Bitcoin Tools logo
Security & data

Safeguards & security

Bitcoin Tools layers multiple protections so that a bad move can't destroy an asset. Here is the full inventory.

Demo mode: signing impossible by design

The demo wallet adapter (demoAdapter.signPsbt) throws an exception unconditionally. No demo PSBT can ever reach the mempool, even if someone tried to bypass the UI.

Automatic exclusions per asset type

  • BRC-20 transferable “locked”: any UTXO holding a BRC-20 “transfer” inscription ready to send is locked. Every builder excludes it and displays a dedicated banner.
  • Runes: excluded from the Inscriber, Splitter and Padding Recovery (burn risk if not handled via a runestone).
  • Alkanes: any UTXO positively detected as Alkanes-bearing is excluded everywhere except in the Wallet Dashboard (read-only), because the current stack cannot build alkane-safe PSBTs. Alkanes detection depends on an external provider: when that provider is unavailable, detection is reported as incomplete in the interface and is not treated as proof that a UTXO is Alkanes-free.

FIFO 1:1 for ordinals

The UTXO Mover and Padding Recovery build transactions where each source UTXO produces exactly one destination UTXO, in the same order. This FIFO rule guarantees that a numbered sat stays identifiable and will never be accidentally swapped with another.

Decoded / re-encoded edicts

The Runes Mover validates edicts via roundtrip: the built runestone is decoded and compared to the original specification. Any divergence or cenotaph blocks signing.

Minimum output thresholds used by Bitcoin Tools

These are conservative thresholds enforced by the application to avoid creating tiny or poorly relayed outputs. They are not necessarily the exact protocol or relay-policy dust threshold for every script type.

  • P2TR (ordinals): 330 sats minimum per output.
  • P2WPKH (payment): 546 sats minimum per output.
  • Padding Recovery: if the recovered surplus is below 546 sats, an automatic top-up from the payment address (target: 600 sats) prevents the loss.

Network and address validation

  • The destination address is checked against the active network (mainnet).
  • For Speed Up and Cancel (RBF), every reused input must belong to your connected wallet — impossible to RBF someone else's tx. Cancel additionally never references the ordinals inputs of the original tx, so inscriptions, runes, BRC-20, rare sats and alkanes cannot be spent by the replacement.
  • UTXOs are re-checked in the background against mempool.space before PSBT construction, to avoid spending outpoints that are already spent.

Bitcoin limits (ancestor cap)

The Splitter and the Runes Minter are bound by Bitcoin's limit of 25 unconfirmed ancestor transactions. Chains are automatically split into batches that respect this cap.

Inscriptions always at offset 0

The Inscriber always places the inscription at offset 0 of the destination UTXO, which makes it compatible with every ordinals marketplace and wallet.

The three Payment scan states

Before any payment UTXO is used to pay fees, it goes through the shared payment scan. It always ends in one of three states, and the wording used in the tools follows it exactly:

  • Clean — the scan finished and found nothing valuable: the UTXO can fund fees and change.
  • Risk detected — the scan found a rare sat, a satribute, an inscription or a rune on that UTXO: it is blocked and can never fund fees.
  • Incomplete / unverified — the scan could not finish (source unavailable, quota, network). Nothing is assumed: the UTXO stays out of new fee pools until you explicitly accept the reduced-coverage fallback, and a retry is offered.

Three different notions are often confused. A blocked UTXO carries positive evidence of value and is refused on purpose. A neutral / unknown UTXO carries no proven identity or no completed scan: it is displayed without colour and is not treated as safe. A UTXO that is merely not selectable is perfectly ordinary — it just does not fit the current tool (wrong wallet, unconfirmed, already planned, below the required size).

Anti-burn for rare sats

The Splitter verifies that the chain never lets a rare sat transit through the payment address (where it could be spent as fee). Rare singletons (isolated palindromes, alpha, omega…) are redirected to the Rescuer.

Fail-closed rare-sat check before spending

Any tool that could spend a supposedly ordinary UTXO (Consolidator Rescue in particular) uses one shared safety check. A UTXO is only treated as ordinary when the rare-sat check completed successfully and found nothing.

  • Positive evidence at any level — an exact sat, a range-level category or counter, or an outpoint-level aggregate — blocks the UTXO.
  • Pending, unavailable, rate-limited, misconfigured or invalid results also block it: uncertainty is never treated as safety.
  • A manual “verified common” flag cannot override positive evidence.
  • The check is repeated immediately before signing, and the transaction is aborted if a selected UTXO no longer qualifies.
  • When the WecSats integration is globally switched off, the previous flow applies: Ordiscan plus your explicit manual verification.

Ordiscan key encryption

Your Ordiscan key is validated live, then encrypted with AES-256-GCM (random 12-byte IV) using a server key. It is never sent back to the client nor logged. Only the last4 is displayed for identification.

Maintenance & read-only modes

The team can, from the admin panel, switch the platform to maintenance mode (full-screen page for everyone except admins) or mark a tool as read-only (broadcasts are blocked client-side and server-side — defense in depth).

PSBT Inspector security score

Before signing an external PSBT, the PSBT Inspector computes a score based on: presence of inscriptions/runes/rare sats, output types, balance, fee rate, signatures already present. See PSBT Inspector.

The last line of defense is you
No software protection replaces a careful read of the summary inside Xverse before signing. Always check addresses, amounts and fee.
BTC —