Hierarchical deterministic wallets generate an entire tree of private keys and addresses from a single starting secret, which is why one backup can restore thousands of accounts. Most modern cryptocurrency wallets use this design, often without users realizing how much depends on it.
This article explains the structure behind HD wallets, the standards that define them, and the security properties and pitfalls that come with deriving many keys from one root. It is aimed at users who want to understand their wallet and at developers integrating HD key derivation into applications.
One Secret, Thousands of Keys
Early wallets created each private key independently, so every new address required a fresh backup. Users who forgot to back up after generating new addresses could lose funds even if they had saved an older copy of the wallet file.
Hierarchical deterministic, or HD, wallets solved that problem. Deterministic means the same input always produces the same output, and hierarchical means keys are arranged in a tree of parents and children. Starting from one seed, the wallet can recreate every key it will ever use.
This design is defined mainly in BIP-32, a Bitcoin Improvement Proposal that has since been adopted far beyond Bitcoin. Combined with BIP-39 mnemonic phrases, it allows a short list of words to back up an entire wallet, across many accounts and, in many wallets, many networks.
How BIP-32 Builds the Key Tree
The process starts with a seed, a long random value often derived from a BIP-39 mnemonic. The wallet runs the seed through HMAC-SHA512, a keyed hash function, to produce a master private key and a chain code, an extra value that adds entropy to every derivation step.
Together, a key and its chain code form an extended key. From an extended private key, the wallet can compute child keys by index number, and each child can produce its own children, forming as many levels as the application needs.
The same mathematics also allows public-only derivation in some cases. From an extended public key, a wallet can compute child public keys and addresses without knowing any private key. That feature is useful, but as later sections explain, it carries privacy and security consequences.
Derivation Paths and the Standards Behind Them
A derivation path is the route through the tree to a specific key, written as a series of index numbers. BIP-44 proposed a standard layout so that different wallets would find the same keys from the same seed.
- Purpose: identifies the standard in use, such as BIP-44, BIP-49, BIP-84, or BIP-86 for different Bitcoin address types.
- Coin type: separates networks, so Bitcoin and Ethereum keys come from different branches of the same seed.
- Account: lets one seed hold several independent accounts, for example personal and business funds.
- Change: distinguishes receiving addresses from internal change addresses on UTXO-based chains like Bitcoin.
- Address index: counts individual addresses within each branch.
Because each element changes the resulting keys, two wallets using different paths will show different addresses from the same seed. Many apparent missing funds problems after a restore come down to a path mismatch rather than a lost or stolen phrase.
Hardened Versus Non-Hardened Derivation
BIP-32 defines two kinds of child derivation, and the difference has direct security consequences. Understanding them explains why wallets mark some path levels with an apostrophe or the letter h, which indicates hardened derivation.
Non-Hardened Children
Non-hardened children can be derived from the parent’s extended public key alone. This enables watch-only wallets and payment servers that generate fresh receiving addresses without access to any private key. The trade-off is a mathematical link: anyone with the parent extended public key and one child private key can calculate the parent private key, and with it every sibling key.
Hardened Children
Hardened children require the parent private key to derive, so an extended public key cannot generate them. This breaks the link described above. Even if a hardened child private key leaks together with a parent extended public key, the attacker cannot climb back up the tree to the parent private key and its other children.
Why Standard Paths Mix Both
BIP-44 hardens the purpose, coin type, and account levels, while change and address index levels stay non-hardened. That arrangement isolates accounts from one another but still allows each account’s extended public key to generate addresses for watch-only use.
The practical lesson is that the account level forms a security boundary. Compromise inside one account may spread across its addresses, but it should not reach other accounts derived from the same seed, which is why separating funds by account is worthwhile.
The Privacy Cost of Extended Public Keys
An extended public key, often shown as an xpub or a similar prefix, is not a secret in the sense that it cannot spend funds. It is still highly sensitive, because it reveals every address the account has used and will use.
Anyone holding it can see the account’s complete balance and transaction history, including future payments. Sharing it with an accounting tool, a block explorer, or a support agent hands that party a permanent view of your financial activity on that account.
Treat extended public keys as confidential information. Share them only with software you run yourself or services you trust with that visibility, and remember that revoking access is impossible. The only way to regain privacy is to move funds to a new account derived along a different hardened branch.
Developers who build services around extended public keys should restrict internal access to them, encrypt them at rest, and avoid displaying them in dashboards where support staff or contractors could copy them casually.
Why a Single Child Key Leak Can Spread
Because of the non-hardened link, leaking one child private key is more dangerous than it first appears. On its own, an exposed child key compromises only the funds at that address, which is serious but contained.
The danger grows if the same attacker also obtains the parent extended public key, perhaps from a watch-only server, a shared accounting file, or a compromised analytics tool. Combining the two lets them derive the account’s extended private key and every address it contains.
For this reason, developers should never export individual non-hardened child private keys from an account whose extended public key is shared elsewhere. If a single key must be exported, use a dedicated account or hardened path so that the exposure stays isolated.
Security Benefits That HD Wallets Provide
Despite those caveats, HD wallets improve security in meaningful ways. A single backup covers all future addresses, which removes the old risk of new keys being created after the last backup was made.
Generating a fresh address for each payment, which HD wallets make effortless, improves privacy by making it harder for observers to link payments to one identity. Separate accounts also let users segregate funds by purpose without managing several unrelated seeds.
Watch-only setups are another advantage. A business can run a payment server holding only an extended public key, so even a full compromise of that server does not expose spending keys. The private keys stay on a hardware or offline signer that approves outgoing transactions.
Those benefits depend on the wallet actually using fresh addresses. Some applications default to a single reusable address for simplicity, so check the settings and enable automatic address rotation where the option exists.
How a Passphrase Creates a Separate Tree
HD wallets that use BIP-39 can add an optional passphrase when converting the mnemonic into a seed. Because the passphrase changes the seed, it changes the master key, and therefore every key and address beneath it. One mnemonic can thus anchor several unrelated trees.
This property is sometimes used to create a hidden wallet. The mnemonic alone opens one tree, perhaps holding a small balance, while the mnemonic plus a passphrase opens another that holds most of the funds. An attacker who finds only the words sees the smaller wallet.
The trade-off is fragility. Wallets cannot tell you that a passphrase is wrong; they simply open a different, empty tree. A single typo or capitalization change therefore looks exactly like missing funds, so the passphrase must be recorded precisely and tested before significant value is stored behind it.
Common Pitfalls When Restoring or Migrating
Most HD wallet problems appear when users move a seed between wallet applications. Different software may default to different derivation paths, address types, or account numbers, so the new wallet can show an empty balance even though funds are safe.
Another pitfall is the gap limit. Wallets scan addresses in order and stop after finding a run of unused ones. If addresses were generated far ahead without receiving funds, a restored wallet may stop scanning too early and miss later deposits.
The fix is documentation. Record the wallet software used, the derivation path, the address type, and whether a BIP-39 passphrase is in place, and store that note with your backup. None of those details are secret, but losing them can make recovery slow and stressful.
Implementation Risks for Developers
Developers integrating HD wallets should rely on well-reviewed, widely used libraries rather than writing derivation code themselves. Small mistakes in key arithmetic, encoding, or path parsing can produce keys that work today but cannot be recovered by standard wallets later.
- Run the official BIP-32 and BIP-39 test vectors in continuous integration to catch regressions.
- Keep seeds and extended private keys out of logs, crash reports, and analytics events.
- Store extended public keys with the same care as customer financial records.
- Use hardened branches to isolate customers, environments, or services from one another.
- Generate seeds only from a cryptographically secure random number generator provided by the platform.
These practices do not make a wallet immune to attack, but they remove the most common self-inflicted weaknesses. An independent code review of the key-handling path is worthwhile before any system holds real customer funds.
HD Wallets in Multisig and Smart Contract Setups
HD derivation is also used inside multisignature wallets. Each participant contributes an extended public key, and the wallet derives matching child keys from each to build every shared address. This keeps addresses fresh without requiring the signers to coordinate for every payment.
Recovering such a wallet needs more than the seeds. The wallet must know every participant’s extended public key, the threshold, the address type, and the derivation paths, information often stored in a wallet descriptor or configuration file.
On account-based networks with smart contract wallets, the contract address stays fixed while signers change, so HD derivation mainly supplies the signer keys. Either way, documenting the full configuration is part of making an HD-based setup safely recoverable.
A useful habit is to export the descriptor right after setup and confirm that a second wallet application recognizes it. That check proves the configuration is complete while every signer is still available to fill any gaps.
Getting the Most From Your HD Wallet Safely
Start by checking which derivation path and address type your wallet uses, and write those details next to your backup. Confirm that a second, independent wallet application can restore the same addresses from the seed, using a small test balance.
Treat extended public keys as private, avoid exporting single child private keys, and use separate accounts for activities with different risk levels. Where privacy matters, rely on fresh addresses for each incoming payment rather than reusing one.
Wallet standards continue to evolve, with new address types and descriptor formats making configurations more portable. Following those developments, and updating your documentation when you migrate, keeps an HD wallet both convenient and recoverable for years.