A backup that has not been tested is not a backup; it is a hope, and rehearsal is the most-emphasised single discipline across every serious self-custody practitioner — Lopp, Casa, Unchained, Nunchuk, Blockchain Commons. Recovery rehearsal converts backup-as-hope into backup-as-verified-fact by actually performing the recovery: wipe the hardware wallet, restore from the written backup, and verify the restored wallet sees the expected balance and addresses. The discipline applies at three time-scales — at setup (the canonical wipe-and-restore test before funding the wallet), periodically (annual or semi-annual verification as documentation drifts and firmware evolves), and at inheritance (the heir walks through the procedure with the holder present, the discipline that distinguishes inheritance plans that work from inheritance plans that don't). Lightweight rehearsals — signed challenge messages, descriptor-import verification — provide partial assurance without the overhead of full restoration; full rehearsals are heavier but uniquely thorough, and both have a place. The principle: trust nothing you have not tested.
Why this note matters
Recovery rehearsal is the discipline that most distinguishes setups that survive their intended events from setups that fail at the moment of need. The note matters because:
- It establishes the single most-emphasised discipline across every practitioner the synthesis reviews. The unanimity is striking — Lopp, Casa, Unchained, Nunchuk, Blockchain Commons all treat this as load-bearing.
- It surfaces the inheritance-rehearsal practice (the heir-walks-through pattern) that is the synthesis’s strongest specific recommendation for converting inheritance plans into working procedures.
- It distinguishes lightweight rehearsals (signed-challenge-message verification) from full rehearsals (wipe-and-restore) — each has its place; the operational cost differs.
The defensible position: a self-custody setup that has not been rehearsed end-to-end at least once is not a setup; it is a hope. The wipe-and-restore test at setup is non-negotiable. Periodic rehearsals are the discipline that catches drift before drift becomes loss.
What this is
Recovery rehearsal is the practice of performing the steps a holder (or heir) would actually need to perform if the setup had to be recovered from backup alone. The minimum form:
- Wipe the hardware wallet (return it to factory state)
- Restore from the written seed phrase (and passphrase, if any; and descriptor, for multisig)
- Verify the restored wallet shows the same addresses and balances as before the wipe
This is the canonical end-to-end recovery. It catches:
- Backup transcription errors (a word recorded incorrectly)
- Backup completeness errors (missing words; missing passphrase)
- Documentation errors (the holder thought the setup was X; it was actually Y)
- Hardware-wallet compatibility issues (the device firmware doesn’t restore the way the holder expected)
- Coordinator-software state issues (for multisig: the descriptor doesn’t reconstruct the wallet)
A backup that survives this test is verified. A backup that does not survive is a hope; the holder learns this with a small test balance rather than at the moment of need.
Three time-scales
Setup-time rehearsal — performed once, after setup, before substantial funds are placed in the wallet. The canonical “trust nothing you have not tested” discipline.
Periodic rehearsal — performed annually or semi-annually. Catches drift in documentation, firmware-update incompatibilities, location instability, holder memory fade, multisig coordinator changes.
Inheritance rehearsal — the heir walks through the recovery procedure with the holder present. The discipline that distinguishes inheritance plans that work from inheritance plans that don’t.
Each scale serves a different purpose. All three are part of a mature operational practice.
Lightweight vs full rehearsals
Full rehearsal — actual wipe-and-restore, with a test transaction to verify the restored wallet can sign. Most thorough; most operationally heavy. Appropriate at setup and at major changes (firmware upgrades, location changes, configuration evolution).
Lightweight rehearsal — signed challenge message. The holder uses the wallet’s signing capability to sign a specific challenge message; the resulting signature mathematically proves the holder has signing access to the wallet’s keys. No funds need to move; no wipe-and-restore is required. Appropriate for periodic checks; takes minutes rather than hours.
Descriptor-import rehearsal — for multisig specifically, the holder imports the descriptor into an alternative coordinator (e.g., from Sparrow into Specter) and verifies the same wallet appears. Catches coordinator-lock-in issues.
The discipline: full rehearsal at setup; lightweight rehearsals periodically; full rehearsal at major changes.
When to use this
Recovery rehearsal applies at every stage of a self-custody setup’s lifecycle:
- At wallet setup — the canonical wipe-and-restore test before funding
- At major changes — firmware updates, configuration changes, device replacements
- At annual review — the standing discipline that catches drift
- At inheritance planning — the heir-walks-through pattern
- After any event affecting the setup — moves, family changes, device repairs, security incidents
The principle: any time the setup has changed in a way that could affect recovery, the recovery should be re-verified.
How rehearsal works in practice
The setup-time full rehearsal
- Hardware wallet is initialized; seed is generated and recorded on durable media
- Wallet receives a small test transaction — typically 100 worth of Bitcoin
- The holder wipes the hardware wallet — factory reset; the device’s internal storage no longer contains the seed
- The holder restores from the written backup — enters the seed (and passphrase, if any) into the device’s restoration flow
- The wallet is reconstructed — same addresses appear; the test transaction’s balance is visible
- The holder verifies by signing a small spend — moves the test funds to a different address and back; this confirms the restored wallet can sign
If any step fails, the setup is wrong, the backup is wrong, or the documentation is wrong. Better to discover this with a test balance than with the actual holding.
For multisig: the same process for each key independently, plus a verification that the coordinator can reconstruct the wallet from the restored keys (typically by importing the descriptor into a fresh coordinator instance).
Periodic lightweight rehearsals
The signed-challenge-message pattern:
- The holder generates a challenge message — typically the current date or a specific phrase
- The holder uses the wallet to sign the message — using the hardware wallet’s “sign message” function
- The signature is verified — proves the holder has signing access to the wallet’s keys
This takes 5-10 minutes per wallet. It doesn’t move funds; it doesn’t expose the keys; it proves operational integrity. Most hardware wallets support this; some coordinator software automates the workflow.
Casa, LegacyCipher, and several other services have built signed-challenge-message workflows into their standard customer experience. The discipline is portable to DIY setups.
The descriptor-import verification:
- The holder exports the wallet descriptor from the current coordinator
- Imports it into a fresh coordinator (e.g., Specter when normally using Sparrow)
- Confirms the wallet reconstructs cleanly — same addresses, same balance
This catches coordinator-lock-in. Takes 15-20 minutes for a 2-of-3 multisig.
Periodic full rehearsals
Every 12-24 months, the discipline recommends a full rehearsal:
- Wipe one of the hardware wallets
- Restore from its seed backup
- Verify the wallet reconstructs
For multisig, rotate which key is rehearsed (rehearsing all keys simultaneously would risk co-location if one were compromised at the moment of test). For single-sig, perform the rehearsal with appropriate caution.
The full rehearsal catches:
- Hardware-wallet aging (does the device still work?)
- Battery degradation (especially for devices with non-removable batteries)
- Firmware-update incompatibilities
- Documentation drift (does what’s written actually match what the setup is?)
- Holder memory fade
Inheritance rehearsal
The heir walks through the recovery procedure with the holder present. The structure:
- The holder provides the inheritance documentation
- The heir, using only the documentation, locates the backups
- The heir, using only the documentation and the backups, performs the recovery (or as much of it as is operationally feasible — for multisig, this may involve sweeping a test amount with the heir performing the signing)
- The holder observes and answers questions
- Where the procedure fails or stalls, the documentation is updated
This is the discipline Casa, Unchained, and The Bitcoin Adviser all explicitly recommend. It is the single most reliable test of whether an inheritance plan actually works.
The cadence: at inheritance-plan creation; on major life events (births of heirs, changes in family structure); every 3-5 years thereafter to catch drift.
Tradeoffs and considerations
Setup-time rehearsal is non-negotiable
The synthesis is unanimous: a setup that has not been wipe-and-restore tested before funding is structurally fragile. The cost is small (a few hours, a small test balance); the benefit is the entire setup’s credibility.
Holders who skip this step typically discover backup errors at the worst possible moment — during an actual recovery, often under stress. The pattern is the dominant cause of “I thought I had this” loss events.
Periodic rehearsal cadence
The synthesis’s recommendation: annual at minimum; semi-annual for substantial holdings.
The argument for annual: catches drift over the timescale on which drift becomes meaningful (firmware updates, location changes, documentation fade).
The argument for semi-annual: for Tier 2+ holdings, the cost of drift compounds; more-frequent verification is cheap insurance.
The argument against more-frequent: rehearsal itself is operationally costly; over-rehearsing diverts time from other operational discipline.
The right cadence depends on the holder’s risk tolerance and operational capacity. For most holders, annual is appropriate.
The exposure window during rehearsal
Rehearsing involves bringing backups out of their secure storage. This creates an exposure window — the backup is temporarily accessible to whatever can compromise the rehearsal environment.
Mitigations:
- Rehearse in a clean environment (no observation, no compromised devices)
- Return backups to secure storage immediately after rehearsal
- For multisig, rehearse one key at a time rather than all keys simultaneously
- For paranoia-level holders, use a dedicated air-gapped device for rehearsal
The exposure window is a real cost; it must be weighed against the benefit. For most holders, the benefit clearly dominates.
Lightweight vs full at periodic scale
For periodic rehearsals, the right choice depends on what the holder is checking:
Full rehearsal catches:
- Hardware aging
- Battery degradation
- Complete-restoration validity
Lightweight rehearsal catches:
- Wallet operational state
- Basic signing capability
- That the keys are still accessible
For most periodic checks, lightweight rehearsals are sufficient. Full rehearsals at major changes (every 2-3 years; firmware-update events; major life changes) catch what lightweight rehearsals miss.
Inheritance rehearsal: who participates?
The synthesis’s recommendation: the primary heir (or executor) should participate. For multisig with multiple heirs, having multiple heirs participate in separate rehearsals is appropriate.
Considerations:
- The heir must be trustworthy enough to know the setup details
- The heir must be technically capable enough to understand the procedure (or willing to learn)
- The heir should not become the holder’s single point of failure (don’t disclose to the heir what should remain compartmentalized from them)
The pattern: the inheritance documentation is shared with the heir during the rehearsal (sealed/encrypted in normal circumstances; opened during the rehearsal); the heir’s actual access to the backups is mediated by the documentation (knowing the locations) plus the holder’s instructions (knowing the procedure).
What to do if rehearsal fails
Rehearsal failures are common at first attempts. The right response:
- Identify the failure mode — what specifically didn’t work
- Diagnose — backup transcription error? documentation drift? firmware incompatibility?
- Fix the root cause — update the documentation, re-stamp the backup, update firmware
- Re-rehearse — verify the fix works
Don’t ignore failure. Don’t proceed to fund the wallet (for setup-time rehearsals) or assume the setup is fine (for periodic rehearsals) until the failure is resolved.
Common failure modes:
- One word in the backup is wrong (transcription error at setup; not catchable by the BIP-39 checksum if the alternative word also produces a valid checksum)
- The passphrase the holder remembers is different from what was used at setup
- The descriptor in the documentation doesn’t match the wallet
- The coordinator-saved-state has subtly drifted from what the descriptor reconstructs
- The hardware wallet’s firmware no longer supports the seed format (rare but real)
Each failure mode has a remediation. The remediation is the point of the rehearsal — fixing the issue before it becomes a loss event.
Comparison with alternatives
| Approach | Catches | Operational cost | Frequency | Best for |
|---|---|---|---|---|
| No rehearsal | Nothing | None | N/A | Not appropriate at any tier |
| Setup-time wipe-and-restore | Setup-time errors | Hours, small test balance | Once, before funding | Universal — non-negotiable |
| Signed challenge message | Operational signing | Minutes | Annual or semi-annual | Most periodic checks |
| Full periodic rehearsal | Drift, hardware aging | Hours | Every 2-3 years | Tier 2+ |
| Inheritance rehearsal | Heir-execution viability | Half day | Every 3-5 years | Any holder with inheritance concerns |
| Descriptor-import verification | Coordinator lock-in | 15-20 minutes | Annual for multisig | Multisig holders specifically |
The pattern most holders should adopt: setup-time full rehearsal + annual signed-challenge-message + biannual full rehearsal + inheritance rehearsal every 3-5 years.
Tiered application
Tier 0: Setup-time rehearsal is appropriate but the cost-benefit is lower. The pattern: at least one wipe-and-restore before placing significant funds.
Tier 1: Setup-time full rehearsal; annual signed-challenge-message verification; biannual full rehearsal; inheritance rehearsal at plan creation and every 5 years thereafter.
Tier 2: Same as Tier 1 with more frequent cadence — semi-annual signed-challenge-message; annual full rehearsal for one rotating key; inheritance rehearsal every 3 years; rehearsals integrated with broader estate-planning reviews.
Tier 3: Continuous operational practice. Possibly outsourced to a service or partner that schedules and verifies rehearsals. Multiple inheritance rehearsals over time as the family structure evolves.
In all tiers, the principle: the setup is only as good as the most recent rehearsal. Setups that have not been rehearsed are setups that may not work when needed.
Common pitfalls
Skipping the setup-time rehearsal. The dominant cause of “I thought I had this” loss events. Test before funding.
Treating a successful first rehearsal as sufficient for the holding horizon. Setups drift; firmware evolves; documentation fades. One rehearsal at setup is not enough for a 20-year holding horizon.
Rehearsing without a real backup. Some holders “rehearse” by entering the seed they have memorized, without actually testing the written backup. This catches some issues but not the load-bearing one — that the written backup is correct.
The “this is too much trouble” pattern. Rehearsals take time. The cost is real. The cost of skipping rehearsals is the entire holding. Budget the time.
Skipping rehearsal because “it worked last time.” Drift is the failure mode rehearsal catches. The whole point is that “it worked last time” doesn’t mean “it will work this time.”
Treating signed-challenge-message verification as full rehearsal. It catches operational signing but not hardware aging, backup correctness, or restoration capability. It is a useful lightweight discipline; not a substitute for periodic full rehearsals.
Inheritance rehearsal that the heir cannot actually perform. A rehearsal where the holder guides the heir through every step doesn’t test the heir’s actual capability. The right form: the heir performs the procedure using only the documentation; the holder observes and notes failures.
Catching a failure and not fixing it. Rehearsal failures should trigger root-cause investigation and remediation, not “I’ll fix that later” deferral. The whole purpose is to catch failures early; deferring the fix recreates the original problem.
Not documenting the rehearsal. Some holders run rehearsals informally and don’t document what was tested, when, by whom, and with what result. Documentation creates accountability and surfaces drift over time.
Sequence assumptions. Some setups depend on specific steps in specific order (e.g., restore with passphrase before importing descriptor). Rehearsals catch order-dependence issues that the holder didn’t realize were load-bearing.
Tooling and resources
Rehearsal-supporting tools:
- Sparrow Wallet — supports wipe-and-restore workflows, descriptor import/export, message signing
- Specter Desktop — same suite of features; descriptor verification across coordinators
- Nunchuk — desktop and mobile; supports rehearsal workflows
- Hardware-wallet vendor tools — Coldcard, Trezor, BitBox, Foundation Passport all support message signing for lightweight rehearsals
- Casa’s challenge-message workflow — used in their collaborative-custody product as a periodic verification
The synthesis document: Bitcoin Self-Custody & Security (LegacyCipher, April 2026) — recovery rehearsal treated as the single most-emphasised operational discipline across all practitioner sources.
Primary practitioner sources:
- Lopp — 21 tips for securing your bitcoin includes the wipe-and-restore discipline as a core recommendation. See Jameson Lopp.
- Casa — explicit signed-challenge-message workflow in their product; the canonical example
- Unchained — inheritance-rehearsal advocacy; the heir-walks-through pattern
- The Bitcoin Adviser — periodic inheritance rehearsals as standard practice
- Blockchain Commons — Smart Custody Book includes a structured verification framework
As of 2026-05-14: the discipline is widely codified; the tooling is mature. The remaining variable is operational — the holder’s commitment to actually performing the rehearsals on the cadence the framework recommends.
Open questions for further development
- The right cadence for periodic rehearsals is not strongly settled. Synthesis defaults to annual; some practitioners argue semi-annual; some argue triennial is sufficient. What is the empirical basis?
- Inheritance rehearsals are operationally heavy and emotionally complex (asking heirs to engage with the holder’s eventual unavailability). What is the right framing to make them tractable without trivializing the seriousness?
- Lightweight rehearsals (signed-challenge-message) are emerging as a useful intermediate practice. Should they become the default for periodic checks, with full rehearsals reserved for major changes?
- For very-long-horizon holders (multi-decade cold storage with deliberate non-touch), is there a rehearsal pattern that minimizes the exposure window while still providing meaningful verification?
Related notes
The framing context:
- Loss vs exposure failure modes — rehearsal catches loss-side errors before they become loss events
- Threat modeling for self-custody — rehearsal specifically defends against “yourself” category failures
- Self-custody configuration ladder — rehearsal discipline scales with configuration complexity
Adjacent discipline notes:
- Backup strategies for seeds — rehearsal is what converts backup-as-hope into backup-as-fact
- Steel seed storage — metal backup is verified by rehearsal
Storage and key concepts:
- Seed phrases and BIP-39
- Passphrases and the 25th word — passphrase backup is rehearsed alongside the seed
- BIP-85 child seeds — rehearsal applies to BIP-85 children as well
- SLIP-39 and Shamir Secret Sharing — reconstruction-time exposure is itself a kind of rehearsal
- PSBT and wallet descriptors — descriptor-import verification
Hardware wallets:
- Hardware wallets overview — all major devices support the rehearsal workflows
- Per-device notes provide the specific procedures
Custody configurations:
- Multisig setups — multisig rehearsal is more complex; rotate keys
- Collaborative custody services — providers often include rehearsal workflows
Operational security (remaining):
- Common attack vectors — rehearsal exposure window
- Operational security practices
- Common failure modes in self-custody — untested-backup as a catalogued failure mode
Inheritance:
- Inheritance planning for bitcoin — inheritance rehearsal is the central practice here
The principal practitioner:
- Jameson Lopp — the “trust nothing you have not tested” framing
The sub-MOC home: