HD Wallet (Hierarchical Deterministic Wallet)

What Is an HD Wallet?

An HD wallet (hierarchical deterministic wallet) is a cryptocurrency wallet that generates all of its keys from a single root secret called a master seed. The "hierarchical" part refers to the tree-like structure of derived keys: a master key produces child keys, which produce grandchild keys, and so on. The "deterministic" part means the same seed always produces the same tree of keys: recovery is guaranteed as long as you have the seed.

Before HD wallets, Bitcoin wallets generated each private key independently and at random. These "random wallets" (sometimes called JBOK wallets, for "just a bunch of keys") required frequent backups because every new address introduced a new key that wasn't covered by previous backups. If you generated 100 addresses after your last backup, those 100 keys were at risk of permanent loss.

HD wallets solved this by making key generation reproducible. The concept was formalized in BIP-32 (2012), with subsequent standards building on it: BIP-39 defined mnemonic seed phrases for human-readable backups, BIP-43 introduced purpose-based derivation, and BIP-44 standardized multi-coin, multi-account key hierarchies. Today, virtually every Bitcoin wallet is an HD wallet.

How It Works

HD key derivation starts with entropy (randomness) and applies a series of one-way cryptographic functions to produce a tree of keys. The process works in layers:

From Entropy to Master Seed

1. The wallet generates 128 to 256 bits of random entropy
2. BIP-39 encodes this entropy as a mnemonic phrase (12 or 24 words drawn from a standardized 2048-word list)
3. The mnemonic is passed through PBKDF2-HMAC-SHA512 with an optional passphrase to produce a 512-bit master seed
4. The master seed is fed into HMAC-SHA512 to produce the master private key (256 bits) and master chain code (256 bits)

The chain code is critical: it adds entropy to child key derivation so that knowing a child key alone is not enough to derive sibling keys.

Child Key Derivation

From the master key, child keys are derived using a parent key, the parent chain code, and an index number. Each derivation produces a new key pair and a new chain code. The index allows up to 2^31 normal children and 2^31 hardened children per parent, totaling over 4 billion children at each level.

# BIP-32 derivation (simplified)
# Normal child:   CKDpriv((key, chaincode), index)
#   = HMAC-SHA512(chaincode, serP(point(key)) || ser32(index))
#
# Hardened child:  CKDpriv((key, chaincode), index)
#   = HMAC-SHA512(chaincode, 0x00 || ser256(key) || ser32(index))
#
# The left 256 bits become the child key offset
# The right 256 bits become the child chain code

This process is recursive: each child can derive its own children using the same algorithm. The result is an arbitrarily deep tree of keys, all traceable back to the original master seed.

Hardened vs. Normal Derivation

BIP-32 defines two derivation modes that differ in their security properties:

• Normal (non-hardened) derivation: uses the parent public key as input. This means anyone with an extended public key (xpub) can derive all child public keys in that branch. Useful for watch-only wallets and payment servers that need to generate addresses without access to private keys.
• Hardened derivation: uses the parent private key as input. The extended public key cannot derive hardened children, creating a security firewall. If a normal child private key leaks alongside its parent xpub, all sibling private keys are compromised. Hardened derivation prevents this.

Hardened indices are conventionally written with an apostrophe or "h" suffix. Index 0' means hardened index 0 (actual value 2^31 + 0 = 2147483648).

The BIP-44 Derivation Path

BIP-44 standardizes a five-level derivation path that organizes keys by purpose, coin type, account, change status, and address index:

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

m           - master key (root of the tree)
purpose'    - 44' for BIP-44, 84' for native SegWit (BIP-84),
              86' for Taproot (BIP-86)
coin_type'  - 0' for Bitcoin mainnet, 1' for testnet
account'    - user-defined account index (0', 1', 2', ...)
change      - 0 for receiving addresses, 1 for internal change
address_index - sequential index (0, 1, 2, ...)

# Examples:
# m/84'/0'/0'/0/0  - First receiving address, native SegWit, account 0
# m/84'/0'/0'/1/0  - First change address, native SegWit, account 0
# m/86'/0'/0'/0/0  - First receiving address, Taproot, account 0
# m/44'/0'/1'/0/5  - Sixth receiving address, legacy, account 1

The first three levels use hardened derivation (indicated by the apostrophe), which means sharing an account-level xpub does not expose keys in other accounts. The change and address_index levels use normal derivation, enabling xpub-based address generation. This design, combined with SegWit and Taproot address formats, gives wallets a structured way to manage thousands of addresses across multiple purposes.

Extended Keys

An extended key packages a key together with its chain code and metadata (depth, parent fingerprint, child index). This self-contained bundle allows any software to continue deriving child keys from that point in the tree:

• xpub (extended public key): contains the public key and chain code. Can derive all non-hardened child public keys. Used for watch-only wallets, payment processors, and accounting software that needs to monitor addresses without spending ability.
• xprv (extended private key): contains the private key and chain code. Can derive all child keys (both public and private, hardened and normal). Must be kept as secret as the seed itself.

Different address types use different version bytes, resulting in prefixes like ypub/zpub for SegWit variants, though these are functionally identical to xpubs with different encoding.

Use Cases

Single-Backup Wallets

The most immediate benefit of HD wallets is backup simplicity. A user writes down their 12 or 24-word seed phrase once. That single backup covers every address the wallet has generated or ever will generate. Even if the wallet creates thousands of addresses over years of use, the same seed phrase recovers all of them.

Privacy Through Address Rotation

Because generating new addresses is free and automatic, HD wallets can use a fresh address for every incoming transaction. This breaks the on-chain link between payments: an observer cannot trivially connect multiple UTXOs to the same wallet just by seeing a shared address. Address rotation is a basic privacy best practice that HD wallets make effortless.

Watch-Only and Payment Processing

By sharing an xpub with a payment server, a merchant can generate unique deposit addresses for every customer or invoice without exposing private keys. The payment server derives child public keys from the xpub and monitors the blockchain for incoming payments. The corresponding private keys remain offline in a cold storage environment. This separation of key generation from key storage is foundational to secure payment processing.

Multi-Account Organization

The account level in BIP-44 derivation paths lets users segment funds logically. A business might use account 0 for operations, account 1 for savings, and account 2 for payroll. Each account has its own sequence of addresses and can be exported independently. Because accounts use hardened derivation, sharing one account's xpub reveals nothing about another account's addresses or balances.

Multisig and Complex Setups

HD wallets integrate naturally with multisig configurations. Each signer in a multisig setup contributes an xpub, and the wallet software derives corresponding public keys at each index to construct multisig addresses. Standards like PSBT (BIP-174) include fields for derivation path information, allowing hardware signers to verify that a requested signing key matches the expected path in the HD tree.

Risks and Considerations

Single Point of Failure

The master seed is a single point of failure. Anyone who obtains the seed (or the mnemonic phrase encoding it) gains access to every key in the wallet. This concentration of risk makes seed storage critically important. Physical backups (metal plates, paper stored in secure locations) are standard practice. Digital copies of the seed should never exist on internet-connected devices.

Xpub Privacy Leaks

Sharing an xpub reveals all past and future addresses in that derivation branch. Anyone with an xpub can monitor every transaction associated with that branch, including balances and payment flows. Treat xpubs as sensitive information: share them only with trusted services and understand that the recipient gains full visibility into that account's activity.

Normal Derivation Key Leakage

If an attacker obtains both an xpub and any single normal (non-hardened) child private key from that branch, they can compute every other private key in the branch. This is a mathematical property of non-hardened derivation: the child private key combined with the parent chain code (embedded in the xpub) reveals the parent private key. Hardened derivation at the account level prevents this from cascading across accounts, but it remains a risk within a single branch.

Address Gap Limits

When recovering a wallet from a seed, software must scan the blockchain for used addresses. It derives addresses sequentially and stops after encountering a gap of unused addresses (typically 20, per BIP-44). If a user generated addresses out of order or skipped indices, some funds may not appear in the recovered wallet without manually increasing the gap limit. Wallet software should let users configure this parameter for edge cases.

Derivation Path Compatibility

Different wallet software may use different derivation paths for the same seed. A wallet created with BIP-44 paths (m/44'/0'/...) stores funds at different addresses than one using BIP-84 (m/84'/0'/...) or BIP-86 (m/86'/0'/...) paths. When restoring from a seed in a different wallet application, users must ensure the new wallet scans the same derivation paths. Some wallets scan multiple paths automatically; others require manual configuration.

HD wallets represent a foundational advance in key management. By combining the UTXO model with deterministic derivation, they make self-custody practical: one backup secures unlimited addresses, organized hierarchies enable complex workflows, and standards like BIP-32/39/44 ensure interoperability across the Bitcoin ecosystem. For a deeper look at how UTXOs interact with wallet design, see the UTXO model vs. account model comparison.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.