Note

A Backup Is Not a Recovery: Seed Phrases, Passphrases, and the Restore You Haven't Tested

A seed backup is not a recovery plan. A backup is a copy of a secret. Recovery is a procedure that turns that copy back into usable keys, on a new device, under stress, possibly done by someone other than you.

2026-10-16 · self-custody, seed-phrase, bip-39, bip-32, passphrase, slip-39, backups, recovery, monero, sovereign-starter, module-1

Sovereign Starter · Module 1 of 5 · Seed backup and recovery

Dark CryptoDecentral hex mesh — a bronze source cell on the left fans out to three small bronze backup cells, whose lines converge into a path of teal steps ending in a larger restored teal cell on the right; no text.

The Sovereign Starter guide ends with a promise: that you can "lose a laptop and still reason about recovery." That promise depends on a backup, and most people think the backup is finished the moment the words are written down.

Thesis, stated once: a seed backup is not a recovery plan. A backup is a copy of a secret. Recovery is a procedure that turns that copy back into usable keys, on a new device, under stress, possibly done by someone other than you. The gap between the two is where most self-custody losses happen.

This note sits before our PSBT note in the path, and it pairs with the one-page threat model: your threat model decides how many copies you keep and where.

What the words actually are

Most Bitcoin wallets use BIP 39. The mechanism is simple:

The wallet generates random entropy (128 to 256 bits).
A checksum, the first ENT / 32 bits of its SHA-256 hash, is appended.
The result is split into 11-bit chunks, each mapped to one word from a 2,048-word list. That gives 12 to 24 words.
To get the binary seed, the words are fed into PBKDF2 with HMAC-SHA512 and 2,048 iterations, using "mnemonic" + passphrase as the salt.

That seed then becomes the root of a BIP 32 key tree, from which every address is derived. One root, many keys: that's why a single backup can cover a wallet for its whole life.

Monero is different. Per Moneropedia, the official wallet's 25-word seed "correspond[s] to a 256-bit integer, which is the account's private spend key," with the last word as a checksum, and the view key derived from it. Some wallets use a 16-word form that, unlike the 25-word form, embeds the wallet's restore height. The two families are not interchangeable, so write down which one you have.

Three things the words don't carry

1. The passphrase. BIP 39 lets you add an optional passphrase. Because it goes into the salt, a different passphrase silently produces a different, valid wallet. The spec notes that "every passphrase generates a valid seed," which is useful for plausible deniability. It also means there is no error message if you mistype it at restore: you just see an empty wallet. A passphrase is a second secret that needs its own backup plan, and it should never be stored right next to the words it protects.

2. The wallet definition. The words recreate keys. They don't record which script types or derivation paths your wallet used, or whether it was one key among several in a multisig. Our descriptors note covers this in depth. The short version: back up the output descriptor (or at least write down the script type and path) next to the seed.

3. Metadata. Bitcoin Core's wallet guide says that since HD wallets arrived in version 0.13, "a single backup is enough to recover the coins at any time," but labels are a different story: "Metadata cannot be retrieved from a blockchain rescan." If labels matter for your records, they need their own, more frequent backup.

The checksum is not a safety net

BIP 39's checksum is short, and the spec now says so directly: it "only gives modest odds of catching random errors (1-in-256 errors will be missed)" and "is also not able to provide any assistance in correcting errors." Monero's single checksum word also detects errors rather than fixing them. Write clearly, spell each word in full, and double-check against the wordlist. Never rely on the software to rescue a sloppy copy.

Copies, splits, and the loss–theft trade-off

Every extra copy lowers the chance of losing access and raises the chance of someone else gaining it. There are three common structures, each with a different failure profile:

One copy, one place. Simple, and one fire or flood away from total loss.
Several identical copies in different places. Survives a single disaster. Any one copy found is a full compromise (unless a passphrase also protects it).
Split secrets. SLIP-39 applies Shamir's secret sharing to mnemonics: a threshold of shares rebuilds the secret, and "knowledge of fewer than the required number of parts does not leak information about the master secret." The catch: the same document notes SLIP-39 and BIP 39 are, "for the most part," not compatible, so the scheme your wallet supports decides what you can use.

Bitcoin Core's own advice about wallet-file backups generalises well: store them on media "reliable enough to work in an emergency," keep them off online devices where possible, and test them regularly.

Its warning about encryption generalises too. After you encrypt a Bitcoin Core wallet or change its passphrase, the guide says, "a new backup needs to be created immediately," because a new HD seed is generated. A backup can quietly go stale.

Recovery is a drill, not a hope

A backup you have never restored is a hypothesis. A simple, low-risk drill:

On a clean or offline device, restore from your written words, the passphrase if any, and the script type or descriptor.
Compare the first receive address (or the public key fingerprint, if your wallet shows it) with the original wallet's. They should match exactly.
Note how long it took and what you had to look up. Anything you had to look up belongs in the backup.
Wipe the test device.

Then write down the recovery line from your threat model: who would do this if you couldn't, where they'd find each piece, and what they need to know that isn't written anywhere. Inheritance and incapacity are recovery scenarios too. A plan only you understand doesn't cover them.

A note on Nostr

NIP-06 defines deriving a Nostr key from a BIP 39 mnemonic via the path m/44'/1237'/<account>'/0/0. It is currently marked "unrecommended", with the note "prefer a single nsec". Don't assume your Bitcoin seed habits carry over to your Nostr identity. Module 3 covers Nostr keys separately.

What this is not

This is not a ranking of wallets, metal plates or storage services, and not custody advice: it doesn't tell you where to keep anything or with whom. It doesn't cover multisig design or inheritance law in any jurisdiction. It contains no prices or trading content. Never type real seed words into a website, chat or "validator" tool, including anything that claims to check them for you.

The practical takeaway fits on one line: a backup is finished when you have restored from it, compared addresses, and written down everything you had to remember along the way.