HD Wallet Derivation (BIP-32/BIP-44) for Institutional Custody

Hierarchical deterministic wallets are the standard by which institutional custody manages the explosion of keys that modern digital asset operations produce. Without a derivation standard, a custodian serving a hundred clients across a dozen chains with multiple sub-accounts per client would face a key inventory of tens of thousands of independent secrets, each requiring its own backup, rotation and audit trail. With a derivation standard, the inventory reduces to a small number of master secrets from which the entire address space is reproducibly generated, and the operational surface becomes tractable.

BIP-32 defines the derivation mechanism; BIP-44 defines the conventional structure that applies the mechanism to multi-asset, multi-account wallets. Together they form the foundation of institutional wallet infrastructure. This article is a practitioner-level walkthrough aimed at readers configuring or evaluating an institutional custody stack. It is a companion to our pillar article on custody evaluation, our HSM architecture article and our multi-signature approval workflows article.

BIP-32 (Bitcoin Improvement Proposal 32, proposed in 2012) specifies how a single master secret can deterministically produce an unbounded tree of child key pairs. The seed — typically 128 to 512 bits of entropy — is processed through HMAC-SHA512 to produce a master extended private key: the private key itself plus a chain code. From this extended key, child keys are derived by applying a further HMAC-SHA512 operation parameterised by the index of the child. The derivation is deterministic: the same seed always produces the same tree.

The property that makes BIP-32 useful for institutional custody is that derivation is reproducible and hierarchical. A custodian who safeguards the master seed — and only the master seed — can regenerate the full address space at any time, in any environment authorised to hold the seed. Backup reduces from managing thousands of keys to managing one. Rotation becomes a matter of moving the seed, not the leaves. Recovery after an operational incident can be performed with confidence that the resulting key tree matches the original.

BIP-32 also supports non-hardened and hardened derivation. A non-hardened child key can be derived from the parent's extended public key alone, which enables a useful property: a custodian can share the extended public key of a sub-account with a reporting or reconciliation service, which can then generate all addresses for that sub-account without holding any private key material. Hardened derivation requires the parent's extended private key and is used where even the extended public key must not be shared, or where the specific subtree should be isolated from others. Institutional designs use hardened derivation aggressively above the account level to prevent a compromise of a child extended public key from propagating upward through sibling inference.

The seed itself is the crown jewel. A BIP-32 seed is the entire custody key hierarchy; anyone who obtains the seed can regenerate every key the custodian holds. Seeds are therefore stored inside HSMs (see our HSM architecture article), generated in ceremony, backed up in quorum-split form, and — in the strongest designs — shared across multiple HSM clusters through wrapped-key synchronisation so that no single hardware failure can render the seed unavailable.

BIP-32 is the mechanism; BIP-44 is the convention. A BIP-44-compliant derivation path has five levels: m / purpose' / coin_type' / account' / change / address_index. Each level plays a specific role.

The purpose level is set to 44' to indicate a BIP-44 wallet. Subsequent BIPs (49, 84, 86) use different purpose values for different script types (P2SH-P2WPKH, native SegWit, Taproot). An institutional stack typically supports multiple purpose values to represent different script types on the same chain.

The coin_type level identifies the asset. A registry (SLIP-0044) assigns a number to each supported coin: 0' for Bitcoin, 60' for Ethereum (and most EVM chains), 501' for Solana, and so on. Using the registered coin type consistently matters because compliance and reconciliation tooling expects it and because interoperability with standards-aligned wallets depends on it.

The account level distinguishes separate logical accounts under the same coin type. In institutional practice an account typically maps to a client, a fund, a sub-book or a custody tier. The account level is hardened, which means that compromise of one account's extended public key does not let an adversary derive sibling accounts.

The change level, in Bitcoin-style chains, distinguishes receiving addresses (0) from change addresses (1). In institutional custody the change level is often repurposed to distinguish internal sub-classes within an account — for example, 0 for operational addresses and 1 for settlement addresses — while preserving the standard semantics for chains where they apply.

The address_index level is the leaf: the specific address within the defined sub-tree. Addresses are typically generated sequentially and retired as they are used, with unused indexes forming the next available receive address for the account.

A concrete institutional path might look like m / 44' / 60' / 37' / 0 / 128: the 128th address within the operational receiving chain of account 37 (a specific client) under Ethereum, using BIP-44. The custodian's wallet catalogue is, in essence, a table of such paths mapped to client, tier and purpose. The table itself is part of the custody record; the private keys are never materialised outside the HSM.

The account level of BIP-44 is the primitive that makes multi-client institutional custody tractable. Assigning each client its own account (or a tree of accounts, one per sub-book) gives the custodian per-client key hierarchies without per-client seeds.

Three operational patterns follow from this design. The first is per-client extended public key disclosure. Because hardened derivation protects the parent, a custodian can share a client's account-level extended public key with the client or with the client's audit partner, who can then independently compute all addresses and balances for that account without the custodian's cooperation — a useful property for the client's own reconciliation. The client cannot infer any other client's keys from this disclosure.

The second is per-tier account assignment. A common pattern is to assign one account per (client, tier) pair: one account for the client's cold reserves, one for warm, one for hot. Movement between tiers is recorded as a transfer between accounts in the same hierarchy, and the policy engine (see our multi-signature article) applies tier-specific rules based on the account level of the derivation path.

The third is per-product segregation. An institution operating both a custody product and a treasury product on the same chain separates them at the account level: accounts in one subtree belong to custody, accounts in another to treasury. Policy, insurance and reporting are all parameterised by the subtree, and the derivation path itself becomes a structural control.

Multi-chain support is orthogonal. The coin_type level accommodates any registered chain, and the custodian's seed produces coherent account hierarchies across all supported chains simultaneously. A client who holds Bitcoin, Ethereum, USDC on Ethereum, USDC on Solana, and a tokenised asset on a Corda ledger can be represented by a single account number across all those chains, with each chain-specific sub-tree generated on demand.

Tiering is the risk response to the reality that operational convenience and asset protection pull in opposite directions. A hot wallet is convenient but online; a cold wallet is protected but offline; warm sits between. An HD wallet architecture expresses tiering through the account structure rather than through separate seeds.

In a typical institutional configuration the majority of assets (often 90% or more) are held in cold accounts whose keys are accessible only through ceremony-driven signing. A smaller warm tier (typically 5–10%) supports day-to-day settlement with policy-enforced approval requirements that still demand multi-signature and review. A small hot tier (under 5%) supports immediate-settlement flows such as client withdrawals and market-making operations, with strict limits, velocity checks and short time-locks.

The seed is the same across tiers; the difference is the account path and the policy that attaches to it. Movement from cold to warm is a rebalancing transaction that requires the higher cold-tier approval quorum. Movement from warm to hot is a lower-tier operation subject to daily limits. Outbound transactions from hot tier require the least approval overhead but are bounded by limit and velocity. The HD wallet design makes each of these transactions expressible as a transfer between accounts in a known tree, with the policy engine reading the account level as the tier indicator.

Cold-tier key access typically requires HSM partitions that are physically or logically isolated from the online signing path. In the strongest designs, the cold signing service exists only for the duration of a scheduled ceremony: the HSM partition is online for a controlled window, the signing operations occur under quorum, and the partition returns to offline state afterward. The HD wallet's determinism is what makes this viable: the ceremony can confidently reproduce the exact address tree without holding the keys online in between.

An HD wallet architecture is not complete without the surrounding operational patterns that make it a working custody service.

Address issuance and reuse policy defines how new addresses are handed out. The default for most institutional custody is single-use receive addresses — a fresh address per expected deposit — which improves privacy and simplifies reconciliation at the cost of a growing index space. Chains that price address creation (some EVM L2s, some account-model chains) may push the policy toward long-lived addresses per client; the choice is a cost-against-privacy decision, and the policy is recorded as part of the custody configuration.

Reconciliation is the reverse-direction operation. At any moment, the custodian must be able to demonstrate that on-chain balances at the derived addresses match the internal book-of-record. A correctly implemented HD wallet enables this at scale: the extended public keys of all client accounts are used to enumerate the expected address space, a blockchain scanning service queries balances for each, and the sums are reconciled against the ledger. Drift between expected and actual surfaces as exceptions for investigation. A well-run custody service publishes this reconciliation to clients on a defined cadence, often daily.

Audit trail integration is the third pattern. Each signing operation references the derivation path of the key used, the policy version under which it was authorised, the quorum that approved it, and the resulting on-chain transaction. The derivation path is therefore present at every layer of the audit record, which makes post-hoc reconstruction of custody history both feasible and reliable. The properties that satisfy SOC 2 Type II auditors depend on this consistency.

Key rotation under an HD wallet has a specific shape. Rotation of the seed itself is a major ceremony — new seed, new address tree, migration of balances — and is reserved for strategic moments (compromise recovery, major upgrade). Rotation of the account layer is cheaper: the old account is retired, a new account is derived, and balances move under policy. Address-level rotation is automatic when single-use addresses are the norm. Each level of rotation has a policy, a quorum and an audit expectation.

Bridge operates an institutional HD wallet stack rooted in HSM-held seeds (see our HSM architecture article). The account hierarchy is BIP-44 compliant, with hardened derivation above the address level and per-client account assignment. Supported chains span the Bitcoin, Ethereum and EVM, Solana and Corda ecosystems, with coin-type registry compliance across the set.

Tier separation is expressed at the account level and enforced by the policy engine. Each client's hierarchy contains cold, warm and hot sub-trees, with policy rules keyed to the account path. Extended public key disclosure at the per-client account level is available to clients and their audit counterparties for independent reconciliation.

Reconciliation runs on a defined cadence with results published to clients; audit trails include the derivation path and policy version at every signing operation. Seed rotation is ceremony-driven and rare; account rotation is supported for clients whose risk posture requires it. Cross-chain consistency — one account number, one client identity, many chains — is preserved as a first-class property of the design.

The point of an HD wallet is that it replaces a linear key-management problem with a structured one. Institutional custody is tractable only because the structure exists; evaluating a custody provider requires understanding how the structure is implemented and what guarantees follow. For the broader evaluation framework, return to our pillar article. For the HSM layer the seeds live in, see HSM architecture. For the governance above the signing, see multi-signature approval workflows. To discuss an institutional wallet deployment, contact us at /custody or /contact.