Seed derivation

The function is PBKDF2 with HMAC-SHA512, run over the words themselves rather than the randomness behind them. BIP-39 pins the iteration count at 2,048 and the output at 64 bytes, with your passphrase appended to the fixed word "mnemonic" to form the salt. Nothing in that step checks whether the words were ever valid, so a mistyped phrase still yields a well-formed seed and an empty wallet.

How it works

Seed derivation takes two inputs and returns one output, in one call with no state and no memory of whatever produced the words. The mnemonic sentence is the password. The salt is the text "mnemonic" with any passphrase stuck on the end, and an empty string stands in when no passphrase was set. Both go through Unicode NFKD normalization first, so accented characters in a French or Spanish phrase hash identically whatever keyboard typed them.

BIP-39 states that this half of the standard is "completely independent" from the half that generates a phrase, and it says so approvingly: there are no constraints on sentence structure, and clients may write their own wordlists or even whole sentence generators. The practical reading is blunter. Feed the function twelve words of gibberish and it returns 64 perfectly usable bytes. BIP-39 requires software to compute the checksum outside this step and "issue a warning if it is invalid", a warning rather than a refusal, which is why some tools will restore a phrase they have just told you is broken.

Two consequences follow from hashing the sentence instead of the entropy behind it. Translating a phrase word for word into another language yields a completely different seed, because the input bytes changed even though the underlying randomness did not. And the direction never reverses: an arbitrary BIP-32 seed cannot be written back out as a BIP-39 phrase, which is why "export the seed" and "export the words" are different requests.

Where you see it

Seed derivation surfaces the moment two pieces of software disagree about which function to run. Multi-share backup on the Trezor Safe 3 and Safe 5, both reviewed here, is SLIP-39 rather than BIP-39: a 1,024-word list read 10 bits at a time, giving 20 words per share for a 128-bit secret and 33 words for a 256-bit one. Those shares never touch BIP-39's PBKDF2 step. SLIP-39 was published by BIP-39's own authors as a replacement, and blames "the overly coupled design of BIP-0039 and its use of a one-way derivation function" for the fact that shares cannot be converted back; going the other way works but forces every resulting share to 59 words, whatever length you started with.

The Coldcard review on this site shows what derivation cannot do for you. A firmware migration in March 2021 left seed generation pulling from a software pseudorandom number generator rather than the hardware one, and Coinkite updated its advisory on 1 August 2026. Derivation itself never faltered. It turned a weak secret into a well-formed 64-byte seed sitting behind a valid checksum, and no wallet downstream had any way to notice.

To watch the function run without risking anything, BIP-39 publishes test vectors lining up entropy, mnemonic and resulting seed, with the passphrase "TREZOR" used for every vector.

Seed derivation vs derivation path

Seed derivation happens once, before a single key exists; a derivation path is consulted afterwards, every time an address is needed. That difference decides how bad an empty-looking restore turns out to be. A wrong path is a setting: change the script type, rescan, and the balance appears. A wrong passphrase changes the seed, which changes the whole tree beneath it, and no setting anywhere brings the old one back.