Seed phrase

In brief

A seed phrase, also called a recovery phrase or mnemonic, is a human-readable encoding of high-entropy random data. In the widely used BIP-39 construction, that entropy is turned into 12, 15, 18, 21 or 24 words from a fixed list, then stretched with PBKDF2 into a 512-bit cryptographic seed. Hierarchical-deterministic derivation (BIP-32, or SLIP-0010 on some other curves) turns that seed into a tree of private keys. One phrase can therefore restore many accounts and addresses, but only when the wallet uses the same derivation paths, optional passphrase and wordlist. BIP-39 is common, not universal: Electrum uses a versioned scheme of its own, and SLIP-0039 splits a secret across Shamir shares. The phrase is not a wallet app, and it is not the same object as any one private key.

What a seed phrase is

A seed phrase is a sequence of dictionary words that lets a person write down, read back and later re-enter the secret material a deterministic wallet needs. BIP-39 calls this a “mnemonic code or mnemonic sentence — a group of easy to remember words — for the generation of deterministic wallets.” The point is human handling: paper, metal, or spoken backup is easier than copying a long hex string.

The phrase is a transcription of computer-generated randomness. BIP-39 is explicit that it is not a method for turning a user-invented sentence (a so-called brainwallet) into a seed.

Wallets and educational sites also say “recovery phrase” or “secret recovery phrase.” Ethereum.org describes it as the list of words given when you create a wallet, and the usual way to recover that wallet if you lose the device or app. The words themselves are not an account, an address or a wallet application.

Why deterministic wallets use one phrase

Older Bitcoin software generated keys independently. Each new address meant new secret material, so a backup taken yesterday might not cover keys created today. BIP-32 was written to replace that pattern. A single seed can grow a tree of keys, so one backup covers current and future addresses in that tree.

A mnemonic sits in front of that design for a practical reason: people can copy words more reliably than raw bytes. The mnemonic is optional packaging around the seed. The seed is what key-derivation actually consumes.

Entropy, words and the cryptographic seed

These three things are related and must stay distinct.

Entropy is the high-quality random data chosen at generation time. In BIP-39 it must be a multiple of 32 bits, between 128 and 256 bits inclusive.

Mnemonic words encode that entropy, plus a checksum, as indices into a wordlist. The English BIP-39 list has 2,048 words, so each word carries 11 bits. The checksum is the first ENT / 32 bits of SHA-256(entropy). Concatenated bits are split into 11-bit groups and looked up in the list.

| Entropy (bits) | Checksum (bits) | Words | | --- | --- | --- | | 128 | 4 | 12 | | 160 | 5 | 15 | | 192 | 6 | 18 | | 224 | 7 | 21 | | 256 | 8 | 24 |

BIP-39 supports those specific mnemonic lengths from the defined entropy sizes. The checksum only catches some typing mistakes; BIP-39 itself notes that it is short and cannot correct errors.

The cryptographic seed is a different object. BIP-39 converts the mnemonic sentence (UTF-8, NFKD-normalized) into a 512-bit seed with PBKDF2-HMAC-SHA512, 2,048 iterations, using the salt "mnemonic" + passphrase. If the user did not set a passphrase, the passphrase is the empty string. That 64-byte seed is what BIP-32 (or an analogue) then uses.

The conversion is one-way from sentence to seed. You cannot represent an arbitrary BIP-32 seed as a BIP-39 sentence. Translating the same words into a different BIP-39 language wordlist also produces a different seed, because the seed is hashed from the words themselves, not from the original entropy.

How one phrase becomes many private keys

After the seed exists, hierarchical-deterministic derivation builds a tree.

BIP-32 starts from a seed of 128–512 bits (256 advised). It computes HMAC-SHA512(Key = "Bitcoin seed", Data = S) and splits the result into a master private key and a master chain code. Child keys are then derived with HMAC-SHA512, either hardened or non-hardened. Hardened children cannot be computed from a parent public key. Knowing an extended private key reconstructs the whole subtree beneath it.

SLIP-0010 generalizes that process to other curves, including Ed25519. For secp256k1 it uses the same HMAC key "Bitcoin seed" and is practically identical to BIP-32. For Ed25519 it uses "ed25519 seed" and supports only hardened children. A wallet that uses this Ed25519 scheme therefore does not simply replay the Bitcoin or Ethereum child keys; the actual path and derivation scheme remain wallet-specific.

None of this makes the mnemonic itself a private key. The phrase regenerates the seed; the seed regenerates a master key; derivation paths select individual private keys; those keys sign.

Derivation paths

Wallets do not use “the first key from the seed” in a single universal way. BIP-44 defines a five-level path:

m / purpose' / coin_type' / account' / change / address_index

Purpose 44' marks this layout. Coin type separates networks (Bitcoin is 0'). Account index splits user identities. Change 0 is the external/receiving chain; 1 is the internal/change chain. Address index counts keys on that chain. Apostrophes mean hardened derivation.

Example: the first Bitcoin receiving address of the first account is m/44'/0'/0'/0/0.

Later Bitcoin address types use other purpose values (for example native SegWit and Taproot wallets). Ethereum-oriented wallets typically follow a BIP-44-style path with Ethereum’s coin type, but implementations differ in whether they use the change level and how they scan accounts. Compatible restoration means the same seed, the same optional passphrase and the same path family.

BIP-44 also describes account discovery with an address gap limit of 20 unused external addresses. A wallet that stops scanning too early can hide funds that sit on a later index.

BIP-39 is common, not universal

Many popular hardware and software wallets generate BIP-39 phrases. That does not make BIP-39 a network rule, and it is not the only recovery format.

Electrum, from version 2.0, does not generate BIP-39 seeds. Its documentation argues that BIP-39 still needs a fixed wordlist for the checksum, has no version number, and therefore cannot tell future software which derivation or script type to use. Electrum instead hashes a UTF-8-normalized phrase with no wordlist dependency and embeds a version prefix that distinguishes standard, SegWit and two-factor wallets.

SLIP-0039 is another alternative: Shamir secret sharing for mnemonic codes. A secret is split into shares; a threshold of shares reconstructs it. SLIP-0039 states that it is “mainly intended as a replacement for BIP-0039” and that the two are, for the most part, not compatible. Share word counts and the wordlist differ from BIP-39.

Wallets can also store isolated private keys with no mnemonic at all, or use vendor-specific backups. A 12-word list that looks like English is not automatically a BIP-39 phrase.

Optional passphrases

BIP-39 allows an extra passphrase when turning the mnemonic into a seed. This is not another word from the 2,048-word list. It is an arbitrary string chosen by the user. Every passphrase, including a typo, yields a valid seed and therefore a different wallet. Only the intended passphrase opens the intended keys.

Trezor documents this as an optional advanced feature that creates additional wallets linked to the same backup. The device does not store the passphrase; it must be entered each time. Trezor states that passphrases cannot be changed, removed or recovered, and that losing the passphrase loses access to that passphrase wallet. Informal talk of a “25th word” refers to this extra secret on a 24-word backup; the specification does not require it to be a single dictionary word.

The passphrase is not a substitute for the mnemonic. Recovery needs both the words and the exact passphrase if one was used.

Compatibility caveats

Restoring “the same phrase” can still produce empty or different accounts when:

• the new wallet assumes BIP-39 and the old one used Electrum, SLIP-0039 or an isolated key;
• the derivation path, purpose field or coin type differs;
• a passphrase was used and is omitted, mistyped or applied when none existed;
• a non-English BIP-39 wordlist was used (BIP-39 strongly discourages this because most wallets only support English);
• account discovery stops before the indices that actually received funds;
• the network uses a different curve or derivation rule (secp256k1 BIP-32 versus ed25519 SLIP-0010).

A successful checksum check only means the words form a valid BIP-39 sentence. It does not prove that a given app will find the same addresses you used before.

Seed phrase versus private key versus wallet

A private key authorizes signatures for one keypair and can thereby satisfy key-based spending rules for particular UTXOs or an account. A seed phrase is backup material that can regenerate many such keys. Exporting one private key does not export the rest of the tree. Losing one private key while still having the phrase is usually recoverable; losing the phrase while holding only some derived keys is not a full backup.

A wallet is software or hardware that generates or stores keys, builds transactions and produces signatures. ethereum.org puts it directly: a wallet is a tool for interacting with an account, and you can change wallet providers. The phrase outlives any one app. The app is not the phrase.

Hardware devices aim to keep seed and key material off the general-purpose computer. They still depend on the same backup rules: the phrase (and passphrase, if any) is the recovery secret, not the plastic device.

Loss, compromise and support

If the phrase and every copy of the seed or derived keys are gone, assets controlled only by those keys and without a separate recovery policy are unreachable. Bitcoin.org states that no one — developers, miners, wallet providers or exchanges — can recover funds permanently lost from an ordinary self-custodied wallet. ethereum.org likewise cannot reset access to an ordinary key-controlled Ethereum account.

If the phrase is the wallet's only secret, someone who obtains it can restore the tree in compatible software and sign. If a BIP-39 passphrase was used, the attacker also needs that exact passphrase to reach the intended wallet. A multisignature policy or smart-account rule can likewise reduce what one phrase controls.

That is why a legitimate support agent, exchange employee, “recovery expert” or website should never need the phrase. ethereum.org is explicit: nobody from Ethereum or ethereum.org will ask for a seed phrase or private keys, and anyone who does is attempting a scam. Pasting the words into a chat, form, AI assistant or unsolicited “wallet connect” page hands control to whoever receives them.

Write the words on durable offline media. Do not photograph them into cloud-backed camera rolls. Follow the wallet's documented verification or recovery-check procedure before relying on a backup.