You wrote down your 12 words. You stored them somewhere safe. Most wallet guides stop there — but that advice glosses over a surprising amount of complexity. What those words actually encode, how they become keys for dozens of blockchains, and what they cannot recover is worth understanding before the moment you need to restore your wallet.
If you haven't read the Seed Phrases primer, start there. This article picks up where it leaves off.
From Entropy to Mnemonic: The BIP-39 Encoding
A seed phrase is not a collection of memorable words chosen for convenience. It is a precise encoding of a cryptographically random number — called entropy — using a standardized 2,048-word list defined by BIP-39 (Bitcoin Improvement Proposal 39).
The process works like this. A wallet generates a random number: 128 bits for a 12-word phrase, up to 256 bits for a 24-word phrase. Five lengths are specified: 128 bits to 12 words, 160 to 15, 192 to 18, 224 to 21, and 256 to 24 words.
Before mapping to words, a checksum is appended. The wallet hashes the raw entropy with SHA-256 and takes the first ENT/32 bits of the result — that is 4 bits for a 128-bit entropy, 8 bits for 256-bit. Those checksum bits are concatenated to the entropy, and the combined string is split into 11-bit groups. Each 11-bit value (0–2047) maps to one word in the BIP-39 wordlist.
Two things follow from this design. First, every word in the list was chosen so that the first four letters are unique — abbreviated entry is supported without ambiguity. Second, the checksum makes invalid or mistyped phrases detectable. A wallet app that rejects your phrase on import is telling you the checksum doesn't match, not that the phrase is wrong.
12-word phrases provide 128 bits of effective security — the same security level as a Bitcoin private key. 24-word phrases provide 256 bits. Both are computationally infeasible to brute-force with current or foreseeable hardware.
From Mnemonic to Master Seed: PBKDF2 and the Passphrase Layer
The mnemonic itself is not used directly as a cryptographic key. It is an input to a key-stretching function.
PBKDF2 (Password-Based Key Derivation Function 2) takes the mnemonic words as a string and runs HMAC-SHA512 against them for 2,048 iterations. The salt is the string "mnemonic" concatenated with an optional passphrase (sometimes called the 25th word). The output is a 512-bit (64-byte) value called the master seed.
This design has an important consequence: the passphrase is not stored anywhere. Not on the device, not in the backup. It exists only in the user's memory or a separate written record. A different passphrase — including an empty one — produces a completely different master seed, and therefore a completely different wallet. Two wallets derived from the same mnemonic with two different passphrases are cryptographically unrelated.
A blank passphrase is valid and produces the standard wallet. This means the mnemonic alone, with no passphrase, fully derives the default account most users interact with.
The security model here is two-factor: an attacker who obtains the mnemonic but not the passphrase cannot access the passphrase-protected wallet. The trade-off is severe — forgetting the passphrase is irreversible. There is no reset, no recovery path, no customer support. The passphrase-protected funds are gone.
The Derivation Tree: BIP-32 and BIP-44 Paths
The 512-bit master seed is fed into HMAC-SHA512 with the fixed key string "Bitcoin seed". The output is split: the left 256 bits become the master private key, and the right 256 bits become the chain code. Together, these form the root of a hierarchical deterministic (HD) wallet as defined by BIP-32.
From this root, the wallet can derive an effectively unlimited number of child keys. Each child derivation mixes the parent key, the chain code, and an index number through another HMAC-SHA512 operation.
Two derivation modes exist:
- Hardened derivation (index ≥ 2³¹): uses the parent private key in the HMAC. Child keys derived this way cannot be computed even if someone obtains the parent's extended public key (xpub). This protects against a leaked xpub cascading into private key exposure.
- Normal (non-hardened) derivation: uses the parent public key. This allows deriving child public keys without ever exposing private keys — useful for watch-only wallets and exchanges generating deposit addresses.
BIP-44 standardizes the path structure across coins:
m / 44' / coin_type' / account' / change / address_index
The coin_type value is different for each blockchain: Bitcoin uses 0, Ethereum uses 60, and so on across hundreds of registered coins. This is why one seed phrase backs up an entire multi-coin crypto wallet — each chain lives at a different path under the same master seed.
The hardened apostrophes on the first three levels mean those derivations use hardened mode, protecting the account-level keys even if an address-level xpub leaks.
What Survives a Device Reset — and What Doesn't
Understanding what the seed phrase actually encodes clarifies what is and is not recoverable.
Recoverable from seed alone:
- On-chain balances and transaction history for any BIP-44 standard account
- All derived addresses across all supported chains
- The wallet's spending capability
Not recoverable from seed:
- Hardware wallet PINs, custom account labels, and address book entries — these are device-local metadata
- Lightning Network channel state — Lightning is off-chain; open channel balances require a static channel backup (SCB) file in addition to the seed
- Watch-only wallet configurations using non-standard derivation paths
- Software wallet app-specific data: portfolio tags, price alerts, custom RPC endpoints
"I have my seed phrase, so I'm fine" is true for standard BIP-44 accounts. It is not true for Lightning channels or any wallet that used non-standard paths.
A hardware wallet reset is recoverable if the seed phrase is intact and the device's PIN was the only thing forgotten. But if the seed is gone too, the hardware wallet becomes a useless brick.
Backup Trade-offs: Paper, Metal, and the Threat Model You're Solving
The question is not "what backup method is best" but "what are you actually defending against."
Paper is low cost and immediately readable. It degrades over years and does not survive fire or flooding. Most home fires reach temperatures that reduce paper to ash.
Metal (steel plate stamping or engraving) survives typical house fire temperatures and flooding. It requires physical security, costs more, and is slower to create. For holdings that would be painful to lose, metal is the practical choice.
Digital backups — photos, cloud storage, password manager notes — are convenient but expose the seed to network-connected systems. A single breach of the cloud account or device compromises the wallet. This is generally not recommended for the seed phrase itself.
Splitting a seed across two locations is widely practiced but poorly understood. Discovering half of a 12-word phrase dramatically reduces the brute-force search space. Split storage weakens security rather than strengthening it.
SLIP-39 (Shamir Secret Sharing) is the mathematically sound alternative. It splits the secret into N shares, any M of which can reconstruct it, without weakening the security of any individual share. Trezor supports SLIP-39; support is not yet universal across wallet software.
The realistic threat model for most users is not a targeted attack but: house fire, flood, physical theft, and the owner forgetting where the backup is stored. Choose a medium and storage location with those risks in mind.
Recovery Failure Modes Nobody Warns You About
These are the failures that appear only at restoration time — usually when stakes are highest.
Passphrase forgotten. The mnemonic is entered correctly. The wallet derives addresses that have no balance. No error message appears. The funds are in the passphrase-protected wallet, which is unreachable. This is the most common irrecoverable failure for users who enabled a passphrase and stored it only in memory.
Wrong derivation path. A wallet that used BIP-49 (SegWit wrapped) addresses restored into an app that defaults to BIP-44 (legacy) produces a different address set from the same seed. Balances appear missing. Switching the derivation path in the new app's advanced settings resolves this — if the user knows to look.
Wallet app incompatibility. Not all wallet software implements all BIP-39 languages or all coin_type values. Restoring into software that does not support the original coin's derivation path silently shows nothing. The funds are not gone, but they are invisible until the correct app is used.
Lightning channel loss without SCB. The seed restores the on-chain balance. Open Lightning channels, however, require the SCB file to close cooperatively. Without it, channels may be force-closed; if the backup state is stale, the counterparty can claim a penalty transaction.
Camera-readable seed storage. A QR code encoding the seed phrase, or a photo stored in a cloud-synced gallery, is a single account breach away from total loss. The seed should never be in a form that a camera or screen capture can transmit to a server.
What to Do Next
- Verify your backup today. Locate your seed phrase and confirm you can read every word clearly. Do not wait for a hardware failure to find out the paper is illegible.
- Record your derivation path. If your wallet uses any non-standard path, write it down alongside the seed. Standard BIP-44 is fine to leave implicit, but anything custom must be documented.
- Keep the passphrase separate and tested. If you use a passphrase, store it separately from the seed and verify at least once that you can restore the wallet correctly using both.
- Get a static channel backup for Lightning. If you run Lightning channels, store the SCB file in a separate location from the seed and update it after opening or closing channels.
- Match your backup medium to your threat model. Paper is acceptable for small amounts in low-risk environments. Metal is worth the cost once holdings become significant.
