Skip to content
Financial Context Wiki

Hierarchical deterministic (HD) wallet

Learn how an HD wallet derives a tree of keys from one seed, how hardened and normal derivation differ, and what a complete, testable wallet backup must preserve.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A hierarchical deterministic (HD) wallet derives a reproducible tree of cryptographic key pairs from one root seed. BIP-32 defines the key-tree mechanism: every node is an extended key containing a key plus a 32-byte chain code, and each child is selected by an index. The same root material, derivation rules, and path reproduce the same child keys.

“Deterministic” makes backup practical; it does not make every wallet interchangeable. A mnemonic phrase is one possible way to encode entropy and produce a seed, while a derivation path chooses a node and an address or script rule turns its public key into something a chain recognizes. Restoring only the words can show an empty wallet when the passphrase, path, network, script type, or account-discovery rules differ.

“Hierarchical” means authority can be divided into subtrees. An account-level extended public key can let a watch-only service derive normal descendant public keys without holding spending keys. An extended private key can derive the corresponding private subtree and must be protected like a collection of private keys, not like one address.

An HD wallet is a key-management design, not an on-chain wallet object. The blockchain does not store the mnemonic, seed, path, labels, or backup. Those are off-chain records maintained by wallet software and the user.

How it works

1. From entropy to the root

BIP-39 is commonly used before BIP-32, but the standards are distinct. BIP-39 encodes 128-256 bits of entropy plus a checksum as 12-24 words, then applies PBKDF2-HMAC-SHA512 with 2048 iterations to the normalized mnemonic and optional passphrase to produce a 512-bit seed. Every passphrase produces a valid but different seed, so a missing or mistyped passphrase is not reliably detected by an “invalid password” message.

BIP-32 uses HMAC-SHA512 with the key Bitcoin seed to turn seed bytes into a master private key and master chain code. This root extended private key is the source of the BIP-32 tree. Not every deterministic wallet uses BIP-39 or BIP-32, so recovery must identify the actual scheme rather than infer it from the presence of recovery words.

2. Extended keys and child derivation

A BIP-32 extended private key combines a private key with a chain code; its neutered extended public key combines the matching public key with the same chain code. Normal child derivation uses the parent public key, chain code, and child index, so an extended public key can derive normal child public keys. It cannot derive child private keys.

Hardened children use indexes from 2^31 through 2^32 - 1 and incorporate parent private-key material. They cannot be derived from the parent extended public key. Paths usually mark them with an apostrophe, as in m/84'/0'/0'. Hardening limits the damage from a specific BIP-32 failure: a parent extended public key plus one corresponding non-hardened child private key can reveal the parent extended private key.

3. Paths give the tree meaning

BIP-44 defines m / purpose' / coin_type' / account' / change / address_index. The first 3 levels are hardened; change and address_index are normal so account public keys can generate receiving and change addresses. By convention, branch 0 is external and branch 1 is internal change. BIP-44 discovery scans transaction history and uses a gap limit of 20 consecutive unused external addresses.

The path is metadata, not a secret and not a universal guarantee. BIP-84 assigns purpose 84' to native SegWit P2WPKH accounts, while other purposes or wallet-specific layouts produce other subtrees. The coin type is a namespace convention, not a rule enforced by a blockchain.

4. Keys are not the whole wallet

A public key still needs network and address or script rules. For Bitcoin, the same key can participate in different output scripts, and a multisignature wallet also needs the threshold, cosigner keys, key order, and derivation origins. BIP-380 output descriptors bind keys and origins to explicit script expressions and may include a checksum. This is why a seed-only backup can be insufficient to recreate what the original wallet watched or could spend.

Wallet labels, contacts, transaction notes, imported keys, account names, and some contract or smart-account recovery settings are generally not deterministically derived. They require separate export or documentation.

5. Backup and recovery are tested processes

Record the wallet implementation, mnemonic or seed format, whether a passphrase exists, master fingerprint, relevant paths, networks, account indexes, and Bitcoin descriptors or equivalent policy data. Keep root secrets offline and separated from public recovery metadata where practical. An xpub cannot spend by itself, but it can expose balances, address relationships, and future normal descendants.

Test recovery in a trusted environment before relying on the backup. First compare known addresses or descriptors without moving funds; then verify both receiving and change branches, later accounts, transaction history, and signing with a controlled small transaction. Never type a mnemonic, passphrase, or xprv into an untrusted website or support chat.

Example

Consider a native SegWit Bitcoin account at m/84'/0'/0'. The 84' purpose selects the BIP-84 convention, 0' selects the Bitcoin coin-type namespace, and the final 0' selects the first account. A watch-only system can receive the account extended public key and derive normal branches without receiving the account private key.

The first external receiving key is at m/84'/0'/0'/0/0; the next is at m/84'/0'/0'/0/1. The first internal change key is at m/84'/0'/0'/1/0. All descend from the same account, but the branch and index select different keys. Reusing the seed with m/44'/0'/0'/0/0 selects another subtree and another output convention; an empty result does not prove that the seed is wrong.

For a complete Bitcoin recovery record, preserve the root-secret backup separately from the descriptor or equivalent metadata that identifies the fingerprint, path, extended public key, script type, and checksum. Verify several previously used addresses on both branches. Finding only the first receiving address is evidence of one correct leaf, not proof that every account, change output, or wallet policy has been recovered.

Risks

  • Single-root concentration: compromise of a root seed or sufficiently high-level extended private key can expose every descendant in its scope.
  • Backup loss: losing the only seed backup, or separately losing an undocumented BIP-39 passphrase, can make every derived key unrecoverable.
  • False passphrase confidence: a wrong BIP-39 passphrase creates a different valid wallet, which may look like a successful but empty restoration.
  • Path or script mismatch: the correct seed under the wrong purpose, account, branch, network, or output type generates valid but unrelated addresses.
  • Incomplete policy backup: a seed and path alone may not reconstruct multisignature, descriptor, smart-account, or wallet-specific spending conditions.
  • Extended-public-key privacy leak: an xpub can reveal an address cluster and allow continued tracking of normal descendants.
  • BIP-32 parent compromise: a parent xpub plus a leaked corresponding non-hardened child private key can reveal the parent private subtree.
  • Untrusted recovery tools: websites, extensions, counterfeit devices, clipboard tools, or screen sharing can capture the entire root secret.
  • Untested media: paper, metal, encrypted files, or hardware backups can fail through transcription, corrosion, forgotten passwords, or unsupported formats.
  • Incomplete migration: moving visible coins while leaving tokens, change outputs, contract roles, approvals, or later accounts under the old root preserves exposure.

Common misconceptions

Does one backup phrase include every wallet detail?

No. It may reproduce root key material, but not necessarily the passphrase, derivation convention, network, scripts, multisignature policy, labels, imported keys, or account-discovery history. Preserve the metadata needed by the actual wallet.

Is an xpub safe to publish because it cannot spend?

No. It normally cannot sign, but it can reveal past and future normal descendant addresses and their combined history. In the BIP-32 failure described above, pairing it with a corresponding non-hardened child private key can also compromise the parent subtree.

Do fresh addresses create independent backups?

No. Fresh addresses improve address reuse and privacy, but deterministic descendants remain controlled by the same ancestor. Root compromise affects the subtree even when every payment used a new address.

Does restoring one familiar address prove the wallet is complete?

No. It validates one combination of root material, path, and address construction. Recovery still needs to cover receiving and change branches, all used accounts, scripts or policies, and relevant networks.

Sources

Navigation

Search the wiki...