A seed backup may recover keys and still miss the wallet

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

A recovery phrase can reproduce a tree of keys. It does not necessarily tell replacement software which branches were used, which script type wrapped those keys, which account was receiving, or where change went. That gap is why a wallet can be cryptographically recoverable yet appear empty. After using the recovery rehearsal to check the secret backup, use an output descriptor to describe the scripts a wallet should recognize. Treating it as part of a portability packet makes recovery less dependent on one application's defaults.

Inventory what the wallet actually uses

For each account, record the network, script family, master fingerprint, key origin path, receiving branch, change branch and descriptor checksum. Bitcoin Core's descriptor reference defines these fields and notes that checksums catch many transcription errors. The checksum validates the string's integrity; it does not certify that the descriptor belongs to your intended seed.

Keep public and private forms distinct. A descriptor containing only public keys may reveal every derived address and balance in its range but cannot spend. A descriptor containing private material is a spending secret and belongs under the same controls as a seed. Never assume a file is safe because its name says “descriptor.” Inspect whether it contains xpub or xprv material before deciding how to store it.

Build a two-part portability packet

The non-secret operational packet can contain wallet name, software and version, device model, script type, public descriptors, account labels, creation or birthday estimate, and instructions for deriving a few known addresses. Store it with access controls because it exposes financial privacy. Keep the seed, any passphrase and private descriptors in the separate secret layer. This same separation is useful in the inheritance handoff workflow.

Wallet metadata deserves its own note. Bitcoin Core's wallet-management documentation explains that labels are not recovered by a blockchain rescan. A fresh wallet file backup can therefore preserve useful context that neither a seed nor a public descriptor contains.

Test portability without moving funds

1. Create a fresh, isolated watch-only profile in the target software.
2. Import the public descriptor with the correct earliest timestamp or block-height hint. Bitcoin Core's importdescriptors documentation warns that an early timestamp can make rescanning lengthy, while “now” skips history.
3. Let the rescan finish; an incomplete scan can look like a failed recovery.
4. Compare at least three receive and three change addresses at non-adjacent indexes with the original wallet.
5. Confirm known historical transactions and balances from your own node or chosen backend.

Do not import private descriptors merely to test viewing. Do not send a “test” payment until the address derivation agrees. A successful watch-only reconstruction proves script discovery; it does not prove that the signer can authorize a transaction. That is a separate, carefully controlled recovery or signing rehearsal.

Know the portability boundary

Descriptor support is not uniform. One wallet may reject a function another accepts, omit labels, impose a limited range, or handle account discovery differently. Lightning channels, custodial balances and application-specific state are not restored by a base-layer descriptor. Keep the original wallet backup as well as the descriptor packet, and re-run the test after changing script type, account structure or software. Portability is evidence produced by an import test—not a promise inferred from the word “standard.”