HD Wallet (BIP-32/44)

A hierarchical deterministic (HD) wallet turns one secret, a single seed, into an unlimited tree of key pairs, all recomputable from that seed alone. Without this, a wallet holding ten different addresses needs to back up ten different private keys, and losing the backup for any one of them loses that address's funds permanently. With HD derivation, backing up the seed once backs up every key the wallet will ever derive, including ones that don't exist yet.

The seed is usually shown to a person as a list of words, twelve or twenty-four, drawn from a fixed 2048-word list (BIP-39), because words are far easier for a human to write down correctly and recover from than a raw string of hexadecimal. That word list is stretched, mathematically, into 64 bytes of actual key material.

Why hierarchical, and why it matters

BIP-32 doesn't just derive many keys from one seed, it derives them along a path, like a filesystem: a seed produces a master key, the master key derives child keys, and each child can itself derive grandchildren. Two properties fall out of that structure:

• Reproducibility. Running the same derivation path against the same seed always yields the identical key. Nothing needs to be stored except the seed and the path convention: the keys themselves are recomputed on demand.
• A shared map. Because the path structure is standardized (not just the math), two independently-written wallets, say, Trezor's and MetaMask's, can derive the same address from the same seed and agree on what it's for. That shared convention is BIP-44: path segments for "which cryptocurrency," "which account," and "which address in that account," in a fixed order, so any compliant wallet can rediscover any other compliant wallet's accounts from nothing but the seed phrase.

This is the property that lets one seed phrase drive a Bitcoin address, an Ethereum address, and dozens of other chains' addresses simultaneously, each recoverable independently, none of them requiring their own separate backup.

Who actually built this

Pieter Wuille wrote BIP-32 in 2012, formalizing the tree-derivation math (built on earlier deterministic-wallet ideas circulating in the Bitcoin community). Marek Palatinus and Pavol Rusnak, founders of SatoshiLabs, the company behind the Trezor hardware wallet, wrote BIP-44 in 2014, standardizing the path convention so wallets from different vendors could interoperate. Rusnak later authored BIP-84 to register a distinct path prefix for native SegWit Bitcoin addresses. None of this involves Solidus; it is over a decade old, and it is what nearly the entire multi-chain wallet industry uses as-is rather than reinventing.

Solidus status

The Solidus wallet generates one real BIP-39 seed and uses it three ways, but only two of those three follow BIP-32/44. Its Ethereum address is derived at the standard path m/44'/60'/0'/0/0; its Bitcoin testnet address at m/84'/1'/0'/0/0 for native SegWit. Both are conventional, standards-conformant derivations, readable in the wallet's own source.

The third use of that same seed, deriving Solidus's own DID and the keys that hold value on Solidus's chain, deliberately does not use BIP-32. It uses a separate HKDF-based hierarchy Solidus wrote itself (see Pairwise DID for what that scheme is for). So "the Solidus wallet does HD derivation" is true; "the Solidus chain uses BIP-32" is not, canon supports the former claim and does not support the latter, and this entry states that distinction rather than letting the two blur together, which is the error a reader familiar with BIP-32 would otherwise reasonably make. There is no mainnet; every address above is testnet or Sepolia, and none of this has been through an external wallet-security audit.

See also

Seed Phrase is the human-readable form of the BIP-39 seed this whole tree derives from. Pairwise DID is the identity-side analog worth noting the parallel to, carefully: both take one seed and deterministically fan it out into many keys, one indexed by chain/account number (BIP-44), the other indexed by verifier identity (Solidus's own HKDF scheme), but they are two different derivation schemes solving two different problems, not the same mechanism applied twice.