The BIP Standards That Define HD Wallets
HD wallets are defined by a series of Bitcoin Improvement Proposals (BIPs) that have become the cross-chain standard for deterministic key generation:
● BIP 39: Defines the mnemonic phrase standard — the 12 or 24 random words that encode the wallet's master seed in a human-readable backup format.
● BIP 32: Defines the mathematical process for deriving an unlimited tree of child keys from a single master key using HMAC-SHA512. This is the core of the HD wallet mechanism.
● BIP 44: Defines a standardised derivation path structure (m/purpose'/coin_type'/account'/change/address_index) that allows different wallets and software to generate the same addresses from the same seed in a predictable way.
A payment gateway implementing HD wallet infrastructure for address generation uses BIP 32 derivation to produce a new child public key — and therefore a new unique receiving address — for every invoice, while the master private key remains in secure storage (typically an HSM or MPC system) and is never used directly for transaction signing.
How Child Key Derivation Works
Starting from a master seed (derived from the mnemonic phrase via BIP 39), the HD wallet generates a master private key and master chain code. Deriving a child key requires the parent public key, the parent chain code, and the child index number. The derivation uses HMAC-SHA512, which produces a 512-bit output: the left 256 bits become the child private key (by adding to the parent key modulo the elliptic curve order), and the right 256 bits become the child chain code for the next level of derivation.
The critical property is that child public keys can be derived from the parent public key alone, without knowledge of the parent private key. This means a payment gateway can distribute its ability to generate new receiving addresses to internet-connected servers (which need only the extended public key, or xpub) while keeping the master private key in isolated, offline storage.
xpub Keys — Deriving Addresses Without Exposing the Private Key
An extended public key (xpub) is a serialised representation of a parent public key plus its chain code. Any party with an xpub can derive the complete sequence of child public keys — and therefore child addresses — from that parent, without being able to sign transactions or access funds. Payment gateways use xpubs to enable their address generation servers to produce fresh receiving addresses on demand, while the signing keys remain offline.
This architecture is why a gateway's address generation system can be compromised without immediately resulting in fund loss: the attacker can see the addresses being generated and monitor incoming payments, but cannot sign outgoing transactions without access to the private keys, which are in a separate, offline system.
Key Compromise Isolation — Why HD Wallets Are Safer at Scale
In a traditional wallet architecture, a single private key controls a single address. Compromising that key means losing control of the funds at that address. In an HD wallet with thousands of child addresses, compromising one child private key exposes only the funds at that specific child address — the master key and all sibling keys are unaffected, provided the compromised child is a 'hardened' derivation.
HD wallets support two derivation modes: normal (unhardened) and hardened. In normal derivation, knowledge of a child private key plus the parent xpub is sufficient to derive all sibling child private keys. In hardened derivation, child keys are derived from the parent private key rather than the parent public key, so compromising a child private key reveals nothing about sibling keys. Payment gateways use hardened derivation at the account level to ensure that a compromise at any child level does not propagate upward.
HD Wallets and Address Gap Limits
When importing an HD wallet seed into a new system, the software must scan the blockchain to find all addresses that have received transactions. Since addresses are derived sequentially by index, the scanner increments the index and checks each address until it has found a configurable number of consecutive unused addresses — the 'gap limit', typically 20 by default in BIP 44 implementations. If a gateway has generated addresses up to index 50,000 for a particularly active merchant, recovery scanning must traverse the full derivation depth to locate all historical transactions.
Payment gateways maintain internal databases mapping each generated child index to its corresponding order, enabling fast lookup without blockchain scanning. This database is a critical operational asset: losing it without a seed backup would make it difficult to reconcile historical payments, even though the funds themselves would still be recoverable from the seed.
Compliance Note: This glossary entry is provided for general educational purposes only and does not constitute financial, investment, legal, or tax advice. Industry terminology may vary across jurisdictions and providers; definitions herein may not directly reflect the specific features, terms, or specifications of Finassets' services. For details on Finassets' offerings, please refer to official product documentation or contact our team directly.