Seed phrase fundamentals

Before choosing how to store a secret, understand exactly what the secret is, what it controls, and what else you need to recover a wallet.

Last fact-checked 25 October 2026 (time-sensitive claims re-checked against the linked sources).

Private keys, seeds and wallets Beginner

A private key is a very large random number that authorises spending from an address. Modern wallets do not store one key; they store a single master secret from which millions of keys are derived. The seed phrase (also called recovery phrase, mnemonic or secret recovery phrase) is a human-friendly encoding of that master secret.

• Whoever has the seed (plus passphrase, if any) controls every coin in every account derived from it, on every compatible wallet, forever.
• Your hardware wallet is replaceable; the seed is not. Lose the device and you buy another. Lose the seed and the device and the funds are gone.
• Coins are not "in" the device — they are recorded on the blockchain. The device just holds the keys.

What each piece lets someone do Beginner

A wallet involves several pieces of information. Only some of them can move money; others "only" reveal your balance and history. This table follows the standards (BIP32 and BIP39) and is meant for deciding how carefully to store each one.

BIP39: words, wordlist and checksum Beginner

BIP39 (2013) is the near-universal standard. A random number (the entropy) is split into 11-bit chunks; each chunk picks one of 2,048 words (2¹¹ = 2,048). A few checksum bits taken from the SHA-256 hash of the entropy are appended so that typos are usually detected.

• The English wordlist is chosen so the first four letters identify each word uniquely, so you may store only four letters on metal.
• The last word partly encodes the checksum, which is why you cannot simply pick 24 words yourself (only some last words are valid) — and why "make your own" seeds are dangerous (see entropy).
• Wordlists exist in other languages, but English has the widest support. Stick to it unless you have a strong reason.
• Recovery uses PBKDF2-HMAC-SHA512 with 2,048 iterations and the salt "mnemonic" + passphrase, producing a 512-bit seed.

Why the wordlist and checksum matter Beginner Intermediate

BIP39 says an ideal wordlist has "smart selection of words" so that typing the first four letters is enough, avoids similar words such as "build" and "built" or "woman" and "women", and is sorted for quick lookup (BIP39). That is why many metal backups store only four letters per word.

• Languages. The BIP39 repository lists ten wordlists: English, Japanese, Korean, Spanish, Chinese (Simplified and Traditional), French, Italian, Czech and Portuguese (BIP39 wordlists). BIP39 "strongly" discourages non-English lists because most wallets support only English, and translating a phrase gives a different wallet (see misconceptions).
• What the checksum catches. A 12-word phrase has 4 checksum bits and a 24-word phrase 8 (see the table above). So, by simple arithmetic, a wrong word will still give a valid checksum roughly 1 time in 16 for 12 words and roughly 1 in 256 for 24 words. A valid checksum means "probably typed correctly", not "this is my wallet".
• What it cannot catch. The checksum says nothing about the passphrase, the derivation path or whether the words were generated randomly. For randomness, see Randomness & entropy.

Common misconceptions Beginner

Most losses we document start with a wrong belief rather than a technical failure. Each row below is checked against the standard or the wallet maker's documentation.

The BIP39 passphrase ("25th word") Intermediate

An optional extra secret mixed into the seed derivation. Any passphrase — including a typo — produces a different, valid, empty-looking wallet. There is no "wrong passphrase" error. Its strength comes from how randomly it was chosen: see passphrase entropy. Case, spaces, Unicode, device limits, decoy wallets and heirs are covered in passphrase pitfalls in depth.

Real-world: forums such as r/TREZOR and r/ledgerwallet regularly carry posts from users who cannot reproduce a passphrase. Recovery firms can sometimes brute-force a partially remembered passphrase, but only if you remember most of it.

Passphrase pitfalls in depth Intermediate Expert

The passphrase is where careful people most often lock themselves out, because a wallet cannot tell a wrong passphrase from a right one. These are the details that matter, each checked against the standard or the maker's documentation on 25 October 2026.

Every character counts: case, spaces and keyboards

• Case and spaces. Trezor states that passphrases are case-sensitive and that a blank space counts as a character, so "Hello World" and "Hello world" open different wallets (Trezor: using a passphrase wallet). COLDCARD gives the same warning and adds that there is "no validation performed on your passphrase" (COLDCARD: BIP-39 passphrase). A leading or trailing space you cannot see on paper is still part of the passphrase.
• Keyboard layout. If you type the passphrase on a computer, Trezor says to make sure the keyboard is set to the correct layout; a UK and a US keyboard put @, " and £/# in different places (Trezor: passphrase troubleshooting). Entering it on the hardware wallet's own screen, where the model allows, avoids both the layout problem and exposing it to the computer.
• Autocorrect and smart punctuation. Phones and word processors silently turn straight quotes into curly ones and two hyphens into a dash. If you keep a written copy, write it by hand and in block capitals where the case is ambiguous (for example, mark whether a character is a capital O or a zero).

Unicode, NFKD and why plain ASCII is safest Expert

BIP39 turns the words and passphrase into the seed with PBKDF2-HMAC-SHA512 (2,048 iterations), using the salt "mnemonic" + passphrase, and requires both strings to be normalised to Unicode NFKD first (BIP39). NFKD makes some differently typed characters identical: a pre-composed "é" and an "e" followed by a combining accent become the same bytes, and a full-width "Ａ" becomes a plain "A". It does not remove accents and it does not ignore case. Three practical consequences:

• Many devices accept ASCII only. COLDCARD allows ASCII characters 32–126 only, up to 100 characters (COLDCARD); Trezor accepts "the standard ASCII set", up to 128 characters on Model T, Safe 3, Safe 5 and Safe 7 and up to 50 on Model One (Trezor); Ledger allows up to 100 characters (Ledger: how to set up a passphrase). A passphrase with "é", "ß" or an emoji created in a software wallet may be impossible to type on the hardware wallet your heirs use.
• Length limits differ. A 60-character passphrase made on a newer Trezor cannot be typed on a Trezor Model One (50 maximum). Check the limit of every device you might restore on.
• SLIP-39 is stricter. A SLIP-39 passphrase must contain only printable ASCII (code points 32–126), and it works differently: it encrypts the shared master secret rather than feeding BIP39's PBKDF2 (SLIP-39). The same passphrase used with a BIP39 phrase and with SLIP-39 shares gives unrelated wallets.

How wallets handle the passphrase differently

Sources: Trezor: what is a passphrase · Trezor: using a passphrase wallet · Ledger: how to set up a passphrase · COLDCARD: BIP-39 passphrase

Decoy wallets: what plausible deniability can and cannot do

BIP39 and SLIP-39 both point out that every passphrase opens a valid wallet, so you can keep a small "decoy" balance behind one passphrase and the main funds behind another; SLIP-39's authors write that a coercer has "no way ... to prove that the decoy wallet is not the real one" (SLIP-39 rationale, BIP39). Ledger describes its secondary PIN as making it "highly unlikely for an unsuspecting sophisticated attacker" to guess a second PIN exists (Ledger firmware 1.3 guide). Our assessment of the limits, which is reasoning rather than a cited finding:

• The feature is well known. An attacker who knows passphrases exist can keep demanding "the other one". Deniability protects the secret, not your safety; a wrench attack is about people, not cryptography.
• A decoy must be believable. An untouched wallet with a token balance is less convincing than one with a plausible history.
• The blockchain remembers. Moving coins directly between the decoy and the hidden wallet links them publicly; so can exchange withdrawal records.
• Your paperwork can give it away. A letter of instruction, a fingerprint list or a labelled metal plate that mentions two wallets defeats the purpose if it is found with the seed.

How heirs recover a passphrase wallet

1. Know that a passphrase exists. Without that fact, an heir who restores the words sees an empty wallet and may conclude the coins are gone (see when a restore shows zero). Your letter of instruction can say "a passphrase is used and is stored at location X" without revealing it.
2. Find the exact passphrase. Trezor warns that if you keep only a hint, it must account for case, spaces and punctuation, and that funds are lost if beneficiaries have to guess (Trezor: passphrase troubleshooting). A written copy, stored apart from the words, is more reliable than a hint.
3. Use the right kind of wallet. Record which standard (BIP39 or SLIP-39), which device or app, and any non-default address type, so the passphrase is applied in the right place.
4. Check the result. Compare the passphrase wallet's fingerprint or first receive address with the value you recorded (COLDCARD calls this the XFP and says it is "the only way to verify your passphrase is correct"; COLDCARD). A match proves the passphrase; a mismatch means a typo, not an empty wallet.

Derivation paths (BIP32, BIP44 and friends) Intermediate

BIP32 defines hierarchical deterministic (HD) wallets: a tree of keys from one master. BIP44 gives the tree a standard shape: m / purpose' / coin_type' / account' / change / index.

Why it matters for backup: if your heir restores your words in a wallet that scans a different path, they may see a zero balance and wrongly assume the coins are gone. Record the wallet software, address type and any non-default accounts.

The BIP family at a glance Intermediate

Wallet settings screens often name these standards. Each one does a different job; the status shown is from the BIP or SLIP document itself.

The "ypub" and "zpub" prefixes come from alternative version bytes set in BIP49 and BIP84. BIP380 calls that approach a "layer violation", because key derivation should be separate from script type, which is one reason newer wallets record descriptors instead.

Extended public keys (xpub/ypub/zpub) Intermediate

An xpub lets software derive all your receiving addresses and see balances, but not spend. It powers watch-only wallets and is required (for every co-signer) to rebuild a multisig wallet.

• Not secret in the "can steal" sense, but privacy-sensitive: anyone with it sees your entire history and balance.
• For multisig, the xpubs are part of the wallet descriptor you must back up.
• The master fingerprint (8 hex characters) identifies a seed without revealing it — useful in inventories.

Who needs what: sharing the right piece Intermediate

People and services sometimes ask for "your wallet details". Give each the least it needs. Based on what each piece reveals (table above) and BIP32's warning about xpubs plus leaked child keys (xpub risks):

When a restore shows zero: checks in order Intermediate

Restoring correct words in the "wrong" way produces a valid but empty-looking wallet. Work through these on the hardware wallet and its app, never on a website.

1. Which standard? BIP39, SLIP-39, Electrum, aezeed and others are not interchangeable (see which standard is my backup?).
2. Passphrase? Was one used? Try it exactly: capitals, spaces and keyboard layout all count. Compare the result against a recorded fingerprint or first address.
3. Address type and path. Legacy (44'), nested SegWit (49'), native SegWit (84') and Taproot (86') are separate branches of the same seed. Many apps let you add an account of each type.
4. Account number. Funds may be in account 1 or 2 rather than account 0.
5. Gap limit. Wallets stop scanning after a run of unused addresses. BIP44 sets this gap at 20, and Electrum also uses 20 by default. If you handed out many addresses that were never paid, raise the gap limit in the software.
6. Right coin and network. The same seed controls Bitcoin, Ethereum and other chains on different paths. A Bitcoin app will not show tokens on Ethereum.

Entropy in one paragraph Beginner

Security comes entirely from the seed being unguessable. 128 bits of true randomness gives about 3.4 × 10³⁸ possibilities — far beyond any brute force. But if the generator is flawed, the real number of possibilities can collapse to billions, which attackers sweep in hours. That has happened repeatedly. Read the full Randomness & entropy guide.

Single private keys, WIF and paper wallets Intermediate

Older "paper wallets" printed a single private key (often in WIF format starting 5, K or L) and address. They are now discouraged: they invite address reuse, partial-spend change mistakes, and many were generated on compromised or weak-RNG websites (see Randstorm). If you hold one, sweep it into a modern HD wallet.

What must you actually back up?

Under the hood: from words to addresses Expert

This is a prose description of the published standards, for understanding only. This site has no tool that generates, checks or derives phrases or keys, and you should never use one on a connected computer for real funds.

1. Entropy and checksum (BIP39). Take 128–256 random bits. Append the first (bits ÷ 32) bits of their SHA-256 hash as a checksum. Split the result into 11-bit groups, and each group indexes one of 2,048 words.
2. Words to seed (BIP39). The mnemonic sentence, normalised to Unicode NFKD, is the password for PBKDF2 with HMAC-SHA512 and 2,048 iterations. The salt is the string "mnemonic" followed by the passphrase, also NFKD-normalised. The output is a 512-bit seed. The seed is computed from the words, not from the original entropy, which is why a translated phrase gives a different wallet.
3. Seed to master key (BIP32). HMAC-SHA512 with the key "Bitcoin seed" turns the 512-bit seed into a 256-bit master private key (left half) and a 256-bit chain code (right half).
4. Child keys (BIP32). Each extended key has 2³¹ normal and 2³¹ hardened children. Hardened indices (written with an apostrophe or h) can only be derived with the private key. Normal children can be derived from the extended public key, which is what makes watch-only wallets work.
5. Path shape (BIP44 and friends). purpose' / coin_type' / account' are hardened. change / index are normal, so an account xpub can generate every receive and change address.
6. Script type. The purpose (44', 49', 84', 86') tells software which address format to build from each public key. Output descriptors (BIP380 family) state this explicitly instead of relying on convention.

Test vectors. Developers check implementations against public test vectors. BIP39 points to the Trezor python-mnemonic vectors, which use the passphrase "TREZOR". SLIP-39 publishes its own. These phrases are public: anyone can derive their keys, so never send funds to them, and do not copy them into your own notes. We do not reproduce them here.

xpub leaks, hardened keys and prefixes Expert

BIP32 warns that knowing a parent extended public key plus any non-hardened private key derived from it is equivalent to knowing the parent extended private key. That is why the account level is hardened: a leaked address key can expose one account, never the master or other accounts.

BIP85 child seeds Expert

BIP85 (status: Deployed) derives independent-looking child entropy, such as new BIP39 phrases, from one master key, so a single backup can regenerate many child wallets. A child is only as random as the master it comes from: see where BIP85 entropy comes from.

One seed, many chains: what changes Expert

The same BIP39 words can control coins on several blockchains, because the path includes a coin-type number registered in SLIP-44. A wallet that does not support a chain, or uses a different path for it, will simply not show those coins.

• Different curves. Bitcoin and Ethereum use secp256k1 and BIP32. SLIP-10 extends the scheme to other curves, including ed25519, and says that for ed25519 only hardened private-to-private derivation is supported. So on those chains an extended public key cannot be used to derive new child addresses for a watch-only wallet in the way a Bitcoin xpub can.
• Taproot. BIP86 tweaks the public key so that it commits to an unspendable script path (BIP86). You do not need to understand the maths, but it is another reason why a Taproot account restores only in software that supports purpose 86'.
• What to record. For each chain: the app used, the coin, the account number and the first address. That metadata is not secret (see what to back up).

Primary sources for this page

• BIP39: mnemonic code
• BIP32: HD wallets
• BIP44: multi-account hierarchy and gap limit
• BIP85: deterministic entropy
• SLIP-132: HD version bytes
• BIP39 test vectors (Trezor python-mnemonic)
• Electrum seed version system
• Electrum FAQ: gap limit
• LND aezeed
• Trezor: what is a passphrase
• BIP49: nested SegWit accounts
• BIP84: native SegWit accounts
• BIP86: Taproot single-key accounts
• BIP48: multisig paths
• BIP380: output descriptors
• BIP39 wordlists
• SLIP-10: other curves
• SLIP-44: coin types

See also sources: core guides.

Last reviewed: 23 October 2026 · Educational information only — verify current details with official sources.