An example first: a seed phrase copied wrong
Suppose you wrote your 12 words on a sticky note. It got folded during a move, the ink smeared across one stretch, and you filled a word back in from memory, in the wrong position. The 12 words on the note no longer add up to the original set. The money at the address is still on the chain, but nobody can move it, you included.
A seed phrase is not like a bank card PIN, where customer service can reset it after a wrong entry. It is not like a house key either, where you can change the lock after losing it. It is the entire control over those assets: there is only this one, every copy of it is as good as the original, and nobody can reissue it if it is lost.
The sections below take five terms that are often used loosely (private key, public key, address, seed phrase, derivation path) and lay them out in their actual hierarchy. You do not need to be able to write code, but when you see options like Derivation Path or Passphrase on a wallet's settings page, you should know what you are choosing. Wherever a standard is involved, the original text is linked: BIP-39, BIP-32 and BIP-44.
What a private key is and why it cannot be worked out backwards
It is just a very large random number
Strip away the jargon and a private key is a number: an integer between 1 and 2256. 2256 is roughly 1.16 × 1077. The long hexadecimal strings you see in tutorials, such as e9873d79c6d87dc0fb6a577…, are simply that 256-bit integer written in hexadecimal, 64 characters in all.
Generating a private key therefore means picking one number at random from a range that large. Wallets use the cryptographically secure random source provided by the operating system, so that nobody can predict the number, the wallet's developers included. If the random source is flawed, someone else can recompute the private key, which is why keys should only be generated with a wallet from a trustworthy source.
Why the private key cannot be computed from the public key
The public key is computed from the private key, so why not the other way round? The answer lies in elliptic curve cryptography. Bitcoin and Ethereum use the curve secp256k1: multiplying a fixed generator point
on the curve by the private key gives another point on the curve, and that point is the public key.
This multiplication is fast in the forward direction. Going backwards, from the result to how many times the point was multiplied, is called the elliptic curve discrete logarithm problem, and no efficient method of solving it is known. What keeps a private key safe is that this problem is out of reach for current mathematics and computing power. The often-mentioned threat from quantum computers targets exactly this step: Shor's algorithm can in theory solve discrete logarithms efficiently.
How private key, public key and address are derived step by step
The three are not the same thing
Address, account and private key are often used as if they meant the same thing. In fact they form a one-way chain:
| Level | What it is | Length / form | Can it be made public? | How it comes from the level above |
|---|---|---|---|---|
| Private key | A 256-bit random integer | 64 hex characters / 52-character WIF | Never | Generated at random |
| Public key | A point (x, y) on the elliptic curve | 33 bytes compressed / 66 hex characters | Technically yes, but in practice it is not volunteered either | Private key × generator point |
| Address | A short string made by hashing the public key | Bitcoin 26–62 characters / Ethereum 42 characters | Yes, it exists to receive payments | Public key → SHA-256 / Keccak-256 → truncation / encoding |
The middle row deserves a second look: publishing the public key unprompted is not recommended either. The common Bitcoin address formats put a hash of the public key on the chain rather than the key itself, and the public key only becomes public with the transaction when you first spend from that address. For everyday use, all you need to remember is that the thing you can send to other people is the address.
How Ethereum addresses differ from Bitcoin addresses
A Bitcoin address has a checksum and an encoding step applied after hashing, which is why it looks like 1… or bc1q…, and a wallet will usually reject it if one character is copied wrong. An Ethereum address is the last 20 bytes of the Keccak-256 hash of the public key with 0x in front, and has no checksum of its own; EIP-55 later added one through the capitalization of the letters. So when sending a transfer, still check the full address character by character, and do not go by the first and last few characters alone.
Where the seed phrase comes from: what BIP-39 specifies
What people backed up before seed phrases
The Motivation section of BIP-32 puts it plainly: the Bitcoin reference client used randomly generated keys, so the wallet file had to be backed up again every so often, and deterministic wallets do not need backups that frequent. One step further is to put that starting point into a form a person can copy and read.
BIP-39 was created on 10 September 2013, and its listed authors are Marek Palatinus, Pavol Rusnak, Aaron Voisine and Sean Bowe. It specifies how to turn a piece of random data into a set of words, and that set of words is the seed phrase (the standard calls it a mnemonic).
2,048 words plus a checksum
BIP-39 uses a fixed wordlist of 2,048 words. 2,048 equals 211, so each word encodes exactly 11 bits. Twelve words are 132 bits: the first 128 are random entropy and the last 4 are a checksum taken from the SHA-256 hash of the entropy. Twenty-four words are 264 bits: 256 bits of entropy plus 8 of checksum. Because of the checksum, 12 words picked off the list at random have on average only a 1-in-16 chance of happening to pass; the rest are rejected by the wallet.
The wordlist is also designed for copying by hand. According to the standard, the list is built so that typing the first four letters is enough to identify a word uniquely, and it avoids pairs that look too alike and are easy to miscopy, such as build and built, or woman and women.
From seed phrase to seed, then to the master private key
The seed phrase itself is not a private key. Under BIP-39 it goes through the key derivation function PBKDF2: the phrase is the password, the string mnemonic plus an optional passphrase is the salt, and 2,048 rounds of HMAC-SHA512 produce a 512-bit seed. That seed is the starting point for all the derivation that follows.
One consequence matters a great deal: the same seed phrase combined with a different passphrase gives a completely different seed, and so a completely different set of wallets. The standard says every passphrase generates a valid seed. A wallet therefore never tells you the passphrase was wrong; a wrong one just opens an empty wallet. If you use a passphrase, it has to be backed up just like the seed phrase.
Which part BIP-39, BIP-32 and BIP-44 each cover
How the three standards divide the work
The three numbers are often quoted together, but the division of labor between them is clear:
| Standard | Year created | Problem it solves | Input | Output |
|---|---|---|---|---|
| BIP-39 | 2013 | Turns random data into words a person can copy down | 128–256 bits of entropy | 12 / 15 / 18 / 21 / 24 words, from which a 512-bit seed is computed |
| BIP-32 | 2012 | Derives layer upon layer of child private keys from one seed (the HD wallet structure) | The seed | A tree of private keys derived level by level |
| BIP-44 | 2014 | Gives the tree a path naming convention so that different wallets can import from one another | The BIP-32 tree | A path convention of the form m/44'/60'/0'/0/0 |
Put together: BIP-39 turns random data into words a person can copy and then computes the seed; BIP-32 derives a whole tree of private keys from that one seed; BIP-44 assigns a meaning to each level of the tree so that different wallets number things the same way. The three combined are what is usually called an HD wallet (Hierarchical Deterministic Wallet).
How to read a slash-separated path like m/44'/60'/0'/0/0
A string like m/44'/60'/0'/0/0 in a wallet's advanced settings is a BIP-44 path. The format given in the standard is m / purpose' / coin_type' / account' / change / address_index, and the segments map as follows:
m: the root node, the master private key computed from the seed44': purpose, fixed at 44', meaning this subtree follows the BIP-44 rules (the apostrophe marks hardened derivation)60': the coin type. The numbers are registered in SLIP-0044: 0 is Bitcoin, 60 is Ethereum, 195 is Tron, 501 is Solana0': the account number, starting at 0; funds in different accounts are kept apart0: 0 is the external chain used for receiving, 1 is the chain used for change0: the address index, starting at 0 and counting up
So m/44'/60'/0'/0/0 means: under BIP-44, Ethereum, account 0, receiving chain, address 0. The next address is m/44'/60'/0'/0/1, and so on. Under BIP-32, the index for normal derivation runs from 0 to 231−1.
How many addresses one seed phrase controls, and why they can differ after switching wallets
More addresses than you could ever use
Working from the path above: under a single coin type there are 231 account numbers, about 2.1 billion, and each account's receiving chain has another 231 addresses. Multiplied together that is 262, about 4.6 × 1018, or more than four quintillion. One seed phrase therefore covers all your addresses across multiple chains, and there is no need to keep a separate phrase for each chain.
Wallets do not all use exactly the same path
BIP-44 sets the format, but default paths are not fully consistent from wallet to wallet, and some wallets do not use BIP-39 at all. Two examples that can be checked in official documentation:
- Phantom's help page lists its default Solana path as
m/44'/501'/{index}'/0', along with one alternative form and one deprecated older form; for Ethereum and other EVM chains the default ism/44'/60'/0'/0/{index}. - Electrum's documentation states that it does not generate BIP-39 seed phrases and uses its own seed format with a version number.
The result is that the same seed phrase imported into a different wallet may show only some of your addresses, or none that match. The coins are not lost when this happens; most likely the two wallets are following different derivation paths. Do not move anything yet. Look for a derivation path option in the new wallet's advanced settings, or look up the path given in the original wallet's official documentation, set the two to match and check again.
Word order, language, switching wallets: three common misconceptions
Can the words be in any order?
No. BIP-39 joins the entropy and checksum into one long bit string in order and then cuts it into words of 11 bits each. Change the order and the whole bit string changes, giving a different wallet, and most likely the checksum fails too.
If you know for certain which 12 words they are and have only forgotten the order, the numbers still leave room to try. Twelve words can be arranged in 12! ways, about 479 million; roughly one in sixteen of those passes the checksum, about 30 million, and each of those can be compared against a known address. That holds only if the 12 words are exactly right, with none extra, none missing and none wrong. The difficulty with the sticky note at the start is that it is no longer certain which 12 they are. Any such attempt has to be made on a device that is not connected to the internet.
Can you use a seed phrase in another language, or mix languages?
BIP-39 has wordlists in languages other than English, but each list is independent, and you cannot swap a few words of a phrase for words from another language. The standard takes a clear position on this: because the vast majority of BIP-39 wallets support only the English wordlist, it strongly discourages generating seed phrases from non-English wordlists. Follow that advice and stick to English.
Will a seed phrase still work in a different wallet?
That depends on whether the two wallets use the same standards and the same path. If both generate the seed under BIP-39 and derive along the same BIP-44 path, the addresses you see after importing are identical. If the paths differ, the import can succeed and still show no balance; check the path as described in the previous section. Some chains also use a curve other than secp256k1. Solana, for example, uses Ed25519, and its addresses can only be derived in a wallet that supports that chain.
One way to keep it straight: the seed phrase is the raw material, and each wallet processes it into addresses along its own path. Same raw material, different path, different addresses.
How to check offline that a seed phrase was copied correctly
If you want to confirm that the phrase you wrote down has no mistakes, there is one rule: do not enter a seed phrase into any web page that is online, or into any program other than the wallet itself, whether it calls itself a checker, a recovery tool or a derivation path calculator, and whether or not it claims to run locally
. A web page's code can be swapped at any time, and nothing on the page shows you whether it is sending what you type somewhere else.
The safe way is the check built into a hardware wallet, where the phrase is entered only on the device's own screen and buttons:
- Trezor: in Trezor Suite, open the device settings, and under Wallet backup click Check backup, then enter the words in order on the device. According to Trezor's official guide (using the Safe 5 as the example), the device compares the backup you just entered with the one it holds; if they match, the device screen confirms the backup is fine, and if not, it shows an error. The device does not retain what you entered during this process. The Safe 3, Safe 7 and Model T each have their own guide.
- Ledger: Ledger offers a device app called Recovery Check. According to its description in the official LedgerHQ code repository, the app has you enter the phrase on the device, compares it with the seed already on the device, and tells you whether they match.
If the check does not match, the backup you are holding is wrong. Trezor's guide says that in that case you should move your funds as soon as possible to a new wallet with a correct backup; otherwise, if the device is ever lost or damaged, the coins are gone for good.
If you use a software wallet on a phone or in a browser and have no hardware wallet, do the check after writing the phrase down and before sending any money in. Note the first address, delete the empty wallet in the same official wallet app, import it again from the phrase you wrote down, and see whether the first address matches the one you noted. If it does, the phrase was copied correctly. Do not delete and re-import a wallet that already holds money; use the wallet's own backup verification feature first.
What to do if a seed phrase is lost or leaked
Lost: tell total loss apart from a partial one
With total loss, say the paper is destroyed and the device is broken too, there is no password reset on a blockchain. Nobody can recover out of thin air a seed phrase you have no trace of, and anyone who claims to be able to should not be believed: if such a method existed it could recover anyone's seed phrase, and the whole system would have stopped working long ago.
With a partial loss, say one or two of the 12 words are missing, or the words are all there but the order is forgotten, the numbers still leave room to try the candidates one by one, along the lines of the passage on word order above. Be especially wary of paid services that claim to fill in missing words. Do not use any that ask you to send over the words you have, or to pay first.
Leaked: treat it as public and move at once
If there is any chance a seed phrase has leaked, even just a suspicion, treat it as already public. Move every asset that can still be moved, as quickly as possible, to addresses controlled by a freshly generated seed phrase that has never appeared on any internet-connected device, and do not hold off to save on fees. What to move first, where to move it and how to deal with approvals is covered in the emergency steps after a private key leak.
For the details of the standards in this article, the BIP and SLIP texts linked above are authoritative. What medium to write the backup on and where to keep it is covered in how to store your seed phrase.