HD Wallets Explained: BIP-32, BIP-39, and BIP-44

One seed. A whole tree of keys, every one of them derived from it deterministically, the same seed always produces the same tree, on any wallet that implements the standard correctly. That's a hierarchical deterministic wallet, or HD wallet, and it's the reason a twelve- or twenty-four-word phrase can back up an entire wallet's worth of accounts and addresses instead of just one.

The mechanism is not something any single wallet vendor invented. It's three separate Bitcoin Improvement Proposals, each with named authors, each solving a different piece of the problem: BIP-39 turns randomness into a word list a human can write down. BIP-32 turns that word list into a tree of keys. BIP-44 defines which branch of the tree means what. Solidus Wallet composes these standards; it did not write them, and this page describes the specs, not a Solidus-specific implementation claim.

BIP-39: the seed phrase itself

The words you're asked to write down on setup, "abandon ability able about above absent..." style lists, are BIP-39's contribution: "Mnemonic code for generating deterministic keys," authored by Marek Palatinus, Pavol Rusnak, Aaron Voisine, and Sean Bowe in 2013.

What actually happens under the hood: the wallet generates a block of random entropy (128 to 256 bits), appends a checksum, and maps fixed-length chunks of the result onto a standard 2048-word list. The same list every BIP-39-compliant wallet uses, which is why the words are recognizable across different wallet brands. Twelve words encode 128 bits of entropy; twenty-four words encode 256. The checksum means a wallet can catch a mistyped or misremembered word before you lose access over a typo, not after.

Writing the words down isn't the last step. BIP-39 also specifies how to turn the word list back into a cryptographic seed, stretched through PBKDF2 with 2048 rounds, which is the actual input to the next proposal in the chain.

See Seed Phrase (BIP-39) for the full mechanism, including the optional passphrase extension.

BIP-32: the derivation math

BIP-32, "Hierarchical Deterministic Wallets," is Pieter Wuille's 2012 proposal, and it's the actual tree math: given a seed, derive a master key; given any key in the tree (a "parent"), deterministically derive any number of "child" keys from it, and children of children, indefinitely. Every derivation is one-way, a child key doesn't reveal its parent, and every derivation is reproducible: the same seed and the same derivation path always produce the same key, on any correct implementation, forever.

That's the property that makes backup meaningful. You don't need to write down every address a wallet will ever generate; you need the one root seed, because every key the wallet has ever shown you or ever will was derived from it by a fixed, public algorithm. Lose the wallet software, keep the seed, and a different BIP-32-compliant wallet reconstructs the identical tree.

BIP-32 says nothing, on its own, about which branch of that tree is "for Bitcoin" versus "for anything else." That convention is a separate proposal.

BIP-44: the standard derivation path

BIP-44, "Multi-Account Hierarchy for Deterministic Wallets," authored by Marek Palatinus and Pavol Rusnak (SatoshiLabs, makers of the Trezor hardware wallet) in 2014, is the part that makes HD wallets interoperable rather than merely deterministic. It fixes a path structure:

m / purpose' / coin_type' / account' / change / index

purpose' is a constant marking "this is BIP-44." coin_type' picks which chain's convention the branch follows (a registry assigns these). account' lets one seed hold multiple independent accounts. change distinguishes receiving addresses from change addresses. index counts individual addresses within that branch. Because the path is a public standard rather than a per-wallet convention, any BIP-44-compliant wallet given the same seed can find the same accounts a different wallet derived from it: the path tells it exactly where to look in the tree.

Full detail, including how BIP-32 and BIP-44 compose, lives at HD Wallet (BIP-32/44).

Checking the specs yourself

None of the three numbers above are Solidus documents. They're public Bitcoin Improvement Proposals, open to read in full:

git clone https://github.com/bitcoin/bips
cat bips/bip-0039.mediawiki
cat bips/bip-0032.mediawiki
cat bips/bip-0044.mediawiki

Reading the actual spec text, rather than taking a summary's word for it, is the point of linking the repo directly instead of just describing the mechanism from a distance.

Where Solidus fits

Solidus Wallet is non-custodial: keys generate and sign on the user's own device, by design. Whether that client-side key handling conforms to BIP-32/39/44 specifically is an engineering detail this page does not assert one way or the other: the only reference found for that claim was an aspirational, unconfirmed product document, not a verified implementation fact, and this page isn't the place to guess. What can be said plainly: the standards above are the industry baseline for deterministic key derivation across the self-custody wallet space, they long predate Solidus, and understanding them is useful regardless of which wallet you use, including if you never use this one. For what happens if the seed itself is lost rather than merely explained, see What Happens When You Lose a Seed Phrase; for how Solidus Wallet handles keys architecturally, see How Solidus Wallet Handles Your Keys.