HD Wallets Explained: How BIP-32 Turns One Seed into a Tree of Keys

A hierarchical deterministic (HD) wallet derives an unlimited number of keys from a single seed. Understanding the mechanism matters for recovery: it explains why one seed can produce many valid-looking wallets, and why the derivation path and account index decide which addresses hold your coins.

The master key

BIP32 starts with a binary seed, usually derived from a BIP39 phrase. The binary seed goes through HMAC-SHA512 with a fixed key ("Bitcoin seed"), producing 64 bytes: the first 32 become the master private key, the last 32 become the master chain code. Both are needed to derive child keys, which is why an extended key contains a key plus a chain code.

Child keys and chain codes

Every child key is derived deterministically from its parent:

• Normal derivation: HMAC-SHA512 of the parent public key, parent chain code and an index. Anyone with an xpub (the extended public key) can derive children, which is what makes watch-only wallets work.
• Hardened derivation (the apostrophe, e.g. m/44'): HMAC-SHA512 of the parent private key, chain code and index. It can only be done by someone holding the private key, and it isolates the branch from its parent's public key.

The chain code is a 32-byte value used in key derivation. It is included in both extended private keys and extended public keys: each extended key combines a key with its chain code.

The purpose levels (BIP43, BIP44, BIP49, BIP84, BIP86)

BIP43 reserved the first level of the tree for a purpose. The common purposes are:

• BIP44: m/44'/coin'/account'/change/index, legacy addresses (1...)
• BIP49: m/49'/coin'/account'/change/index, SegWit nested in P2SH (3...)
• BIP84: m/84'/coin'/account'/change/index, native SegWit (bc1q...)
• BIP86: m/86'/coin'/account'/change/index, Taproot (bc1p...)

Below the purpose sit the coin type (0' Bitcoin, 60' Ethereum, and so on), the account, the change branch (0 = receiving, 1 = change) and finally the address index. Each level is a branch in the tree; the same seed under two different purposes produces two entirely different sets of addresses.

Deterministic vs non-deterministic

• HD wallets: one seed, one tree, restorable anywhere with the right path.
• Non-HD wallets (early Bitcoin Core, MultiBit Classic): keys were generated into a keypool file; without that file (or its backup), a seed cannot rebuild them. That is why old wallet files matter.

What this means for recovery

• A correct seed is only half the answer: the derivation path and account index decide which addresses are checked.
• A wrong path or account produces valid-looking but empty addresses, not an error.
• An xpub lets software derive non-hardened public child keys and their addresses within its branch, but cannot restore private keys. It includes node metadata, not the full derivation path; that path requires separate information.
• Gap limits and change addresses are the practical consequences of this tree structure: wallets scan a bounded window of unused addresses.

The path reference lists the practical defaults; this page is the mechanism behind them.