What it means
Deterministic means that the same inputs reproduce the same derived keys, so the wallet does not need to choose an unrelated random private key for every new address and instead follows a defined derivation process from parent to child keys. Hierarchical means the keys form branches, and different branches can support accounts, receiving addresses or other uses.
The structure can help organise access without giving every system the full wallet's capabilities. BIP 32 describes a Bitcoin HD-wallet standard and a tree of key pairs derived from a seed, and it also describes extended keys and selective sharing.
The specification supplies technical structure, not a guarantee that every product advertised as an HD wallet implements every feature identically. An extended key contains a key and a chain code used in derivation, where an extended private key can support private-key derivation within its branch and an extended public key can support certain public-key derivation without directly containing the private spending keys.
This can allow a receiving system to generate fresh addresses without access to spending keys, so a webshop, for example, can allocate addresses while a separate system holds signing authority. The arrangement reduces one exposure but does not make the receiving system harmless if compromised.
Public information can still be sensitive, because an extended public key may reveal addresses and activity across a branch, which creates privacy and business-information risks even though it is not itself equivalent to a private key. BIP 32 distinguishes normal and hardened derivation, and hardened derivation requires private-key material and does not permit the same public-only child derivation.
These choices affect which branches can be shared and how compromise risks propagate. A particularly important limitation concerns normal derivation, because knowledge of a parent extended public key together with a corresponding non-hardened child private key can compromise the parent private key, so a single leaked child key should not be treated as necessarily isolated from the hierarchy.
Backup requires more than assuming every wallet uses an identical recovery phrase, since a mnemonic system can represent seed material while BIP 32 itself concerns key derivation. Recovery also depends on compatible paths, wallet conventions and any additional information required by the implementation.
Recovery should be tested with an appropriate safe procedure before it becomes urgent, protecting sensitive material from disclosure and avoiding entering it into unverified software. Managers should separate payment acceptance from spending authority, since a system that creates receiving addresses can have different permissions from one that signs transfers.
Document which branch and capabilities each system receives. An organised hierarchy helps recovery only if the necessary information remains secure and usable.
In practice
Real-world examples.
Example
A merchant gives its online receiving system an extended public key for one branch. The system creates customer addresses, while signing keys remain elsewhere; the merchant still treats branch activity as sensitive information.
Example
A team stores a seed backup but forgets the derivation convention used by its wallet. During recovery, the seed alone does not immediately reveal the expected accounts without compatible configuration.
Example
A developer proposes sharing a normal child private key alongside its parent extended public key. Security review rejects the assumption that this combination exposes only one isolated address.
Formula
Calculation
Conceptual derivation: seed -> master extended key -> account or purpose branch -> child keys and addresses. This is a structure, not a balance equation or an instruction to disclose the seed.
For a normal branch, public derivation and private derivation follow related rules. Hardened derivation changes the required inputs, so a public-only system cannot be assumed to generate every possible child address from every path.Case study
Seen in the real world.
Fictional case study: Cedar Payments moved address generation to a webserver and initially planned to copy the wallet's complete seed there. The proposal exposed spending authority merely to support receiving payments. The team reviewed the hierarchy and gave the server only the appropriate receiving-branch public capability.
It documented the privacy exposure and kept private signing material outside that system. Cedar also tested its recovery information with compatible wallet conventions. The revised design used selective sharing without claiming that an HD wallet prevents theft or that every public key is safe to distribute freely.
Watch out
Common mistakes.
- Confusing a recovery phrase with a universal wallet standard. Seed representation and derivation conventions are distinct.
- Treating an extended public key as risk-free information. It can reveal branch activity and interact dangerously with leaked child private keys.
- Giving address-generation systems full signing authority. Match the shared branch and key type to the actual role.
Questions
People also ask.
Can an HD wallet generate many addresses from one seed?
Yes, through defined derivation rules and branches.
Does public-only access permit spending?
Not by itself, but privacy and key-combination risks still need review.
Does the hierarchy prevent theft?
No. Compromised seed or private-key material can give an attacker control.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%