Skip to main content

Type a word from a question or an article title.

3 · Under the hood

HD wallets - how 12 words yield all your keys (BIP-39, BIP-32, BIP-44)

How a seed phrase turns into keys: BIP-39 entropy and wordlist, PBKDF2, the BIP-32 hierarchy, the BIP-44 path for Ethereum and the passphrase. With examples.

4 min readUpdated:
In this article

When you create a wallet it asks you to write down 12 or 24 words. This single phrase restores all your addresses on all networks. How is that possible? Three standards stand behind it: BIP-39, BIP-32 and BIP-44. Practical rules for storing the phrase are in the security checklist; here we examine the design.

The problem: many keys, many backups

A good wallet uses a new key for each address (privacy, convenience). But storing a copy of every key is a nightmare. The HD wallet (hierarchical deterministic) idea: one secret deterministically generates an endless tree of keys. Save one secret, and you have saved everything.

Step 1. Entropy and words (BIP-39)

Everything starts with a random number - entropy: 128 bits for 12 words or 256 bits for 24 words.

  1. A checksum is added to the entropy: the first bits of its SHA-256 hash (4 bits for 128, 8 bits for 256).
  2. The resulting string is cut into groups of 11 bits.
  3. Each group - a number from 0 to 2047 - is the index of a word in a list of 2048 words.

In total: 128 + 4 = 132 bits → 12 words; 256 + 8 = 264 bits → 24 words.

Properties of the list: the words differ in the first four letters, none look alike; the checksum lets you notice a typo (though not all).

Step 2. From words to a seed

The words (as a string) are turned into a 512-bit seed by the function PBKDF2-HMAC-SHA512 with 2048 iterations. The "salt" is the string "mnemonic" plus an optional passphrase.

  • Without a passphrase the seed is determined by the words alone.
  • With a passphrase (the "25th word") a completely different seed and different wallets result. Without the passphrase the phrase is useless. But if you forget the passphrase, the money is lost forever. This is powerful protection and a powerful risk.

Step 3. The key tree (BIP-32)

From the seed the master key is derived: HMAC-SHA512 with the key "Bitcoin seed" yields 64 bytes. The first 32 bytes are the private key, the other 32 are the chain code, extra entropy for deriving descendants.

From any key child keys can be derived by index: child(parent, i). It is HMAC again, and the result is deterministic. This builds the tree:

text
master
├── 0
│   ├── 0  (address 1)
│   └── 1  (address 2)
└── 1

There are two kinds of children:

  • Normal (index < 2^31): can be derived from the parent's public key without the secret.
  • Hardened (index ≥ 2^31, marked with an apostrophe '): require the parent's private key; a leaked child key cannot reveal the parent.

Step 4. The derivation path (BIP-44)

BIP-44 agreed which path to use to find keys, so that different wallets give identical addresses:

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

For Ethereum the standard path is:

text
m/44'/60'/0'/0/0   -  the first address
m/44'/60'/0'/0/1   -  the second address

Here 60 is Ethereum's code in the registry. All EVM networks (Base, Polygon, BNB Chain) use the same path, so you have one address on every network. For Bitcoin the code is 0, so the keys there differ.

What this means for you

  1. The phrase = everything. Anyone who knows the words (and the passphrase, if any) owns all addresses and all assets on all EVM networks.
  2. Wallets are compatible. The phrase can be restored in another standard wallet to get the same addresses. You are not tied to an app.
  3. A hardware wallet keeps the seed inside and signs on the device; the words are only a backup.
  4. One address - one key. From one address you cannot derive the others. But from the seed all are derived.
  5. Roles can be separated. Different "accounts" (account') give different independent sets of addresses from one phrase. For different roles, though, it is safer to use different phrases (why separate wallets).

Extended public keys (xpub)

An extended public key lets you derive all child addresses without knowing the secret. Convenient: a service can show you new addresses. But leaking an xpub together with any child private key exposes the parent: guard an xpub from publication.

Example: recovery

Maria lost her phone. She buys a new one, installs any compatible wallet and enters the 12 words. The wallet:

  1. checks the words' checksum;
  2. builds the seed (with the passphrase, if there was one);
  3. derives keys along the path m/44'/60'/0'/0/i;
  4. computes the addresses (how a key becomes an address) and checks the blockchain for balances.

All her former addresses reappear. If a thief stole the phone and the phrase was stored only there, the money is lost. But a paper copy saves the day.

Learn how these keys are used for signatures: ECDSA and EIP-712. Or how wallets become "smart": account abstraction.

Mentioned in

Ready to try it?

Create your first deal in a couple of minutes. The money is locked in a smart contract and paid out by rules you can see in advance.