Test a Bitcoin wallet recovery safely

A visual inspection of recovery words is not a recovery test. A useful test proves that an offline backup opens the intended wallet, derives the expected addresses, and can sign—without exposing the secret or risking the only funded device.

Never recover into software. Do not type recovery phrases or passphrases into a phone, computer, website, Sparrow or another coordinator, cloud form, chat, or support ticket. Enter them only directly on trusted hardware during a documented recovery flow.

Choose a safe test method

The lowest-risk options are a manufacturer's documented non-destructive hardware backup check, Jade's documented Temporary Signer fingerprint check, or a spare hardware device. A full reset can be useful on a reset, unfunded device but should not be performed on the only device controlling meaningful funds.

Use no funds or a small mainnet test balance. Testnet can teach interface steps, but it does not prove the exact mainnet network, script type, account, derivation paths, addresses, or policy used by the final wallet.

Before starting, record:

• wallet type and Bitcoin network;
• expected wallet fingerprint;
• one complete receiving address previously verified on hardware;
• whether a BIP39 passphrase exists;
• script/address type and relevant account or derivation settings;
• for multisig, the complete policy or descriptor and required threshold.

Fingerprints, addresses, xpubs, and descriptors are sensitive metadata even though they cannot sign by themselves.

Test a Jade Plus singlesig backup

1. Use an unfunded wallet, small test wallet, or spare/reset test Jade.
2. Follow Blockstream's current recovery or Temporary Signer instructions.
3. Enter the recovery phrase directly on Jade.
4. If required, enter the exact passphrase directly on Jade.
5. Compare the restored fingerprint with the recorded value.
6. Connect or transfer public wallet information through the documented flow.
7. Display and compare the complete known receiving address on Jade.
8. Create a small transaction and verify the destination, amount, fee, and network on Jade before signing.

A matching fingerprint is useful but not sufficient. A known address and successful small spend prove more of the configuration.

Test a passphrase wallet

Every exact passphrase creates a valid wallet. A typo can produce a valid but empty wallet with no warning. During the test, preserve capitalization, spaces, punctuation, and character order exactly.

After recovery, compare the expected fingerprint and known address. If they do not match, stop. Check the passphrase, recovery-word order, script type, account, and derivation settings. Do not send funds to “see whether it is right,” and do not ask support to inspect the secrets. See Use a BIP39 passphrase on Jade Plus.

Test a 2-of-3 multisig backup

A signer phrase alone cannot rebuild the wallet. Begin with the complete policy backup.

1. Import the output descriptor or policy into a clean Sparrow profile.
2. Confirm threshold, script/address type, fingerprints, xpubs, derivation paths, key order, and coordinator configuration.
3. Compare known receive addresses and discover the test history.
4. Restore two independent signers directly on spare/reset trusted hardware.
5. Register or review the policy on each signer through its tested flow.
6. Verify a known complete address on hardware.
7. Sign and broadcast a small transaction with that quorum.
8. Before meaningful funding, repeat the signing test with the other two pairs so A+B, A+C, and B+C all succeed.

For a 2-of-3 wallet, test A+B, A+C, and B+C before meaningful funding. One or two successful pairs do not fully validate the design.

Use a small-transfer rule

For a newly created or recovered wallet:

1. Verify a receive address on hardware.
2. Send a small amount.
3. Confirm it arrives.
4. Spend part through the intended signing process.
5. Rebuild from the documented backup.
6. Increase the balance only after all checks match.

When enough signing material to authorize a spend is confirmed exposed, urgency can outweigh this sequence: move to a fresh, hardware-verified wallet without delaying solely for a test when delay materially increases theft risk. If only one factor or one multisig signer may be exposed, treat it as untrusted and assess what additional material an attacker would need.

Record the test without recording secrets

Write the date, hardware model and firmware, software version, method, fingerprint match, address match, signing pair, and result. Never record test recovery words in screenshots, logs, transaction notes, or support messages.

Repeat after major firmware or coordinator changes, hardware replacement, backup damage, a move, or a change in the person responsible for recovery. Incorporate the result into your Bitcoin inheritance plan.

Software visual reference

Updated on: 04/08/2026