Wallets, seed phrases and custody models · Lesson 2 of 5
Seed phrases, BIP-39 and passphrases
6 min read
Why recovery material exists
A deterministic wallet can produce many related signing keys from a common starting secret, allowing a compact recovery method. A seed phrase, also called a mnemonic phrase or recovery phrase, is a sequence of words representing or encoding recovery material under a particular scheme. The widespread BIP-39 scheme defines a way to turn random data into words and then derive a binary seed. The words are not a password selected for convenience, nor are they a universal standard understood identically by every blockchain wallet.
The term “seed” is often used casually for both the words and the derived binary value. In a careful technical discussion, distinguish the BIP-39 mnemonic from its resulting 512-bit seed and from the downstream wallet keys. This is not merely terminology: troubleshooting a failed recovery requires knowing which item a system expects and which conventions its implementation supports.
A standard is not universal compatibility
BIP-39 (Mnemonic code for generating deterministic keys) is widely implemented, but some wallets use different backup systems, derivation schemes, or account structures. BIP-32 (Hierarchical Deterministic Wallets) describes a tree of related keys derived from a root. BIP-44 (Multi-Account Hierarchy for Deterministic Wallets) proposes a common account organization for compatible implementations. A correct mnemonic alone does not always reproduce identical addresses in another wallet unless the passphrase, derivation path, network, and script or address conventions are also compatible.
How BIP-39 works, conceptually
BIP-39 starts with computer-generated randomness, also called entropy, then appends a short checksum derived from a cryptographic hash. It splits the combined bits into groups that index words from a fixed 2,048-word list. Permitted entropy lengths range from 128 to 256 bits in steps of 32, yielding phrases of 12, 15, 18, 21, or 24 words. Twelve and twenty-four words are familiar examples, but they are not the only valid lengths in the specification. The checksum helps catch some transcription errors; it is not a guarantee that a phrase was created securely or correctly.
The phrase is processed by a password-based key-derivation function, PBKDF2, with HMAC-SHA512, 2,048 iterations, and a specific salt construction defined by BIP-39, producing a 512-bit seed. PBKDF2 expands the mnemonic and optional passphrase into standardized binary material. The derived seed can then feed a deterministic key-generation system such as BIP-32. The algorithm’s details matter for interoperability, but a newcomer’s most important task is to understand the relationship among entropy, mnemonic, passphrase, seed, and derived wallet accounts.
| Entropy bits | Checksum bits | BIP-39 words |
|---|---|---|
| 128 | 4 | 12 |
| 160 | 5 | 15 |
| 192 | 6 | 18 |
| 224 | 7 | 21 |
| 256 | 8 | 24 |
The optional BIP-39 passphrase
BIP-39 permits an optional passphrase in addition to the mnemonic. It is incorporated into the derivation process; it is not simply an app-login PIN and should not be confused with the password used to unlock a particular device. An omitted passphrase means the empty string. The same mnemonic combined with different passphrases produces different derived seeds and therefore potentially different accounts and addresses. Importantly, BIP-39 does not generally provide a “wrong passphrase” warning: a different passphrase still produces a plausible seed.
This creates a serious recoverability tradeoff. A mnemonic backup without its required passphrase does not restore the intended accounts. Conversely, recording both components together may reduce the security benefit of separating them. The suitability of a passphrase depends on the threat model, human error risk, and recovery procedures, not on a claim that longer or more complicated setups are automatically safer. For institutions, the relevant issue is how authorized recovery personnel can use and verify protected information without creating unnecessary exposure.
Do not confuse three different secrets
A wallet PIN often controls access to a specific app or device. A BIP-39 mnemonic can enable reconstruction of signing material in compatible software. A BIP-39 passphrase changes the derived seed. Losing or changing one has different consequences. A resettable online account password is different again: a service may be able to reset login access, but that does not imply it can reconstruct an independent self-custodial seed.
Backup design and recovery assurance
Recovery is a process, not the existence of a handwritten sheet alone. A sound recovery plan considers whether a readable record exists; whether it is complete and accurate; whether authorized people know which wallet standard and network conventions apply; and whether recovery can be tested in a controlled way without exposing live secrets. The location, accessibility, and integrity of a backup matter just as much as the mnemonic’s mathematical properties. A perfect backup inaccessible after an emergency is not an effective recovery capability.
Typing recovery words into untrusted websites or sharing them with purported support personnel is a common route to compromise. A legitimate recovery process should occur only through appropriate, verified software and organizational procedures. For this course, illustrative diagrams intentionally do not contain a valid recovery phrase. Learners should not use example words from educational material as real security credentials.
Derivation paths and institutional inventories
A derivation path is a structured description of where a particular account or key sits within a deterministic key tree. Two systems can apply the same BIP-39 words but follow different path conventions or address representations. For an organization, this means that a recovery inventory should preserve the wallet family, supported networks, account conventions, and any other nonsecret configuration needed for authorized restoration. Such information is not a substitute for the actual protected secrets. It helps prevent an emergency in which staff possess the correct phrase but cannot identify the expected addresses.
Handling a suspected exposure
If recovery material may have been disclosed, the question is not whether the mnemonic checksum remains valid; it is whether someone else could reconstruct usable signing credentials. The consequences depend on all relevant ingredients, including any passphrase, additional account policy, and available transaction authority. Incident plans should focus on preserving evidence, confirming affected accounts, and having authorized personnel determine any necessary protective actions. Merely changing an app unlock code ordinarily does not invalidate a leaked recovery phrase. A recovery plan should be rehearsed before there is an emergency, using a controlled test environment and suitably authorized participants.
What recovery does not promise
A seed-based restore may recover control over matching keys but not the transaction labels, historical notes, contacts, local drafts, or third-party account settings stored only by the original application. It also does not guarantee that every network, token position, or contract-based account appears automatically. A restored wallet may need the appropriate account discovery, network configuration, or compatible account implementation before balances become visible. The ledger itself remains unchanged by the recovery process.
A checksum does not validate that the phrase belongs to the person attempting recovery. Nor does a valid phrase guarantee that the desired assets still exist at the derived addresses. Examiners and auditors should distinguish proof of a valid BIP-39 encoding, proof of a particular derived key, and evidence of control over a specified address. These are separate factual propositions.
Standards and professional context
BIP-39 specifies mnemonic creation and seed derivation; BIP-32 describes hierarchical deterministic keys; and BIP-44 describes one organizational convention for multiple accounts. NIST SP 800-57 Part 1 Revision 5 provides general guidance on cryptographic-key recovery and lifecycle protection. These technical documents are different in purpose: interoperability specifications address computation, while management guidance addresses protection and operational continuity.
Exam focus: Explain the sequence from random entropy through a BIP-39 mnemonic and optional passphrase to a derived seed and deterministic keys. Know that BIP-39 does not guarantee wallet compatibility or safe recovery, and distinguish recovery words from an app PIN or online account password.