How Does an HD Wallet Work? BIP39 and BIP32 Explained
Key Takeaways
- An HD (Hierarchical Deterministic) wallet derives a hierarchy of keys from one root seed. BIP32 defines this model for secp256k1-based networks; Ed25519-based networks such as Solana require a compatible scheme like SLIP-0010. Backing up the seed once makes the wallet’s derived accounts recoverable, provided the same derivation scheme and paths are used to restore them.
- BIP39 defines how cryptographic entropy is encoded as a human-readable 12- or 24-word mnemonic, and how that mnemonic is converted into a binary seed, with a built-in checksum to catch transcription errors.
- Wallets use chain-specific derivation paths and coin types. Common implementations use m/44’/60’/… for EVM accounts, m/44’/501’/… for Solana, and m/44’/195’/… for TRON. Getting this wrong doesn’t throw an error; it silently derives a different, technically valid key.
- BIP39/BIP32 solve key generation, not key protection. A wallet still needs encrypted, platform-native storage for the seed once it exists.
- A single 12- or 24-word backup is what lets a multi-chain wallet support EVM, Solana, and TRON from one recovery flow instead of one per network.
BIP39 vs BIP32 vs BIP44: What Each Standard Actually Does
Five different standards get used interchangeably in wallet documentation, and they’re not the same thing:
| Standard | What it does |
| BIP39 | Mnemonic phrase → binary seed |
| BIP32 | Hierarchical key derivation (defined for secp256k1) |
| BIP44 | Standard structure for derivation paths |
| SLIP-0044 | Registry of coin_type numbers per network |
| SLIP-0010 | Extends HD derivation to curves BIP32 doesn’t cover, including Ed25519 |
The distinction that trips up most explanations: BIP44 defines the shape of a derivation path (m/44’/coin_type’/account’/change/index), but the actual list of coin_type numbers, ETH is 60, TRON is 195, Solana is 501, isn’t part of BIP44 itself. That registry is SLIP-0044, maintained separately. And BIP32’s math is written for secp256k1, the curve Bitcoin, Ethereum, and TRON all use; Solana’s Ed25519 keys need SLIP-0010 to be derived hierarchically at all. More on why that matters below.
Most people who ask how a crypto wallet “remembers” their funds are really asking how one seed phrase can control a hundred different addresses across several blockchains. The answer is two Bitcoin Improvement Proposals that became foundational to modern wallet architecture: BIP32 (2012), which defines how a seed turns into keys, and BIP39 (2013), which defines the seed phrase itself.
Neither proposal was written with Ethereum, Solana, or TRON in mind. They became the universal standard anyway, because the underlying problem (deriving unlimited keys from one backup, deterministically) has nothing to do with which chain you’re on.
For wallet product teams specifically, this isn’t just backup UX. The derivation model determines whether a wallet is cross-compatible with other wallets on recovery, how account structure scales across chains, and how much rework it takes to add a new network later. Get the architecture wrong here and what looks like a small recovery bug can turn into a costly wallet-core refactor.
What Makes a Wallet “Hierarchical Deterministic”?
Early wallets generated a random private key for every new address and asked users to back up each one separately. Lose a key you never wrote down, and the funds at that address are gone, even if the rest of the wallet is intact.
A hierarchical deterministic wallet removes that failure mode. Every key (past, present, and any address the wallet will ever generate) is computed from a single root seed using a fixed, repeatable algorithm. “Deterministic” means the same seed always produces the same keys in the same order. “Hierarchical” means those keys are organized as a tree, with the seed as the root and every account, chain, and address as a branch derived from it.
Practically, this means one backup, the seed phrase, covers a wallet’s entire history and everything it will generate going forward, on any network the wallet supports.
How BIP39 Creates a Recoverable Seed Phrase
BIP39 is the layer users actually see: the 12 or 24 words shown once during setup. Getting to those words takes three steps.
Step 1: Generating entropy
The process starts with a random number: 128 bits for a 12-word phrase, 256 bits for 24. This has to come from a cryptographically secure source: SecRandomCopyBytes on iOS, SecureRandom on Android. A predictable or reused entropy source is the single most common way wallet implementations get compromised, because it makes the “random” seed guessable.
Step 2: Mapping entropy to mnemonic words and checksum
The entropy is split into 11-bit chunks, and each chunk maps to a word in the BIP39 wordlist: 2,048 words, chosen so each one is unambiguous from its first four letters. A checksum derived from the entropy’s hash is appended before this split happens, which is why an invalid mnemonic (a typo, a dropped word) gets rejected immediately instead of silently producing the wrong wallet.
Step 3: Stretching the mnemonic into a seed with PBKDF2
The words themselves aren’t the seed. They’re run through PBKDF2 with HMAC-SHA512, 2,048 iterations, to produce a 512-bit seed. The real security here comes from the entropy generated in step 1, 128 or 256 bits, not from this stretching step; PBKDF2’s iteration count adds a modest per-guess cost on top of that, but it isn’t what makes a 12-word phrase unguessable. That’s the entropy’s job.
How BIP32 Turns One Seed Into Unlimited Keys
Once the 512-bit seed exists, BIP32 takes over. The seed produces a master private key and a master chain code. From there, every other key in the wallet is a “child” derived from a parent using the chain code plus an index number, and each child can have children of its own. That’s what makes the structure a tree rather than a flat list.
Two derivation modes matter here. Non-hardened derivation can be reversed if a child key and the parent’s public key both leak. An attacker can work backward to the parent from there. Hardened derivation (marked with an apostrophe, like the 44′ in a standard path) uses the parent’s private key in the derivation, closing that route off entirely. This is why the account level of a derivation path is always hardened, even in wallets that expose non-hardened keys further down the tree for features like watch-only addresses.
One scope note that matters for multi-chain wallets: BIP32’s math is written specifically for the secp256k1 curve, the same curve Bitcoin, Ethereum, and TRON use. It doesn’t cover Ed25519, the curve Solana uses. Non-hardened derivation in particular isn’t defined for Ed25519, since Ed25519 doesn’t support the public-key-only child derivation that secp256k1 does. That’s why Solana wallets derive keys via SLIP-0010 instead of vanilla BIP32, using hardened derivation the whole way down.
BIP44 Paths by Network: Why m/44’/60’/… Isn’t Arbitrary
BIP32 defines how derivation works. BIP44 defines a standard structure for the path itself, so different wallets derive the same addresses from the same seed. The structure is m / purpose’ / coin_type’ / account’ / change / address_index. The coin_type field is what separates one blockchain from another, and the registry of which number belongs to which network is SLIP-0044, not BIP44 itself.
| Network | Coin type (SLIP-0044) | Curve | Standard path |
| EVM chains (Ethereum, Polygon, BSC, etc.) | 60 | secp256k1 | m/44’/60’/0’/0/{index} |
| Solana | 501 | Ed25519 (via SLIP-0010) | m/44’/501’/0’/0′ |
| TRON | 195 | secp256k1 | m/44’/195’/0′ |
The coin_type number isn’t a label: it’s an input to the derivation math. Change it, and the output is a completely different, mathematically valid key pair that doesn’t correspond to any address the user has ever funded. There’s no error message, because nothing is technically wrong. The wallet just derives the wrong key and shows an empty balance.
This is one of the more damaging bug classes in wallet development, because it doesn’t surface in normal use. It shows up only when someone tries to recover a wallet on a new device, months or years later, and finds their funds “missing.” Testing recovery against every supported network, not just signing and broadcasting, is the only reliable way to catch it before launch.
Why a Single Seed Phrase Can Back Up an EVM, Solana, and TRON Wallet at Once
The same BIP39 seed feeds every network’s derivation, one seed phrase can hold a separate, independently derived key for every chain a wallet supports, and all of it is recoverable from the same 12 or 24 words. This is the architectural basis for multi-chain wallet development: the wallet’s UI shows one backup flow, but underneath it, each chain gets its own correctly derived key.
What’s not shared is the derivation algorithm itself. EVM chains and TRON both use secp256k1 and standard BIP32 derivation, so adding a new EVM-compatible chain later is comparatively simple: same coin_type logic, same curve, just a different RPC endpoint and chain ID. Solana is a separate branch entirely, since Ed25519 needs SLIP-0010, not BIP32, to derive keys hierarchically. A wallet’s multi-chain layer has to implement both derivation paths correctly, from the same root seed, and treat them as genuinely different code paths rather than variations on one function.
HD Derivation Is Not the Same as Security: Where Non-Custodial Storage Comes In
BIP39 and BIP32 answer one question: how are the keys generated? They say nothing about how those keys are protected once they exist, which is a separate problem with a separate set of standards.
In a non-custodial wallet, the derived private keys (and ideally the seed itself) are encrypted at rest with AES-256-GCM and stored using platform-native secure storage, Apple Keychain on iOS, Android Keystore on Android, never as plain files. These are storage APIs, not the same thing as a hardware Secure Enclave: Keychain can optionally back a key with the Secure Enclave, but the Enclave itself only generates and holds its own keys, it doesn’t accept arbitrary imported private keys the way encrypted Keychain storage does. The encryption key is itself derived from the user’s PIN or passphrase through a slow key-derivation function, so the PIN never unlocks the private key directly. A wallet can implement BIP39/BIP32 perfectly and still be insecure if this storage layer is weak. The two problems are independent, and both have to be solved.
Where HD Wallet Implementations Go Wrong
The failure modes that show up in production wallets are rarely exotic:
- Wrong coin_type or account index, usually from copying a path template without checking it against the target network’s actual standard.
- Weak or reused entropy, particularly in cross-platform codebases where a JavaScript fallback random function gets used instead of the platform CSPRNG.
- Skipping checksum validation on mnemonic import, which lets a mistyped word produce a wallet that looks valid but isn’t the one the user meant to recover.
- Storing the mnemonic in plaintext, in logs, crash reports, or unencrypted local storage, even temporarily during onboarding.
- Never testing full recovery: signing and broadcasting get tested constantly during development; recovering a wallet from just the seed phrase, on a clean device, often isn’t tested until a user reports it broken.
Each of these is a one-line mistake with no visible symptom until someone tries to recover funds.
How OmiSoft Implements HD Wallet Architecture
Every multi-chain wallet OmiSoft builds uses this exact model: one BIP39 seed, correct per-curve derivation (BIP32 for secp256k1 chains, SLIP-0010 for Solana), and coin_type values verified against each chain’s own address format before launch, not just checked against documentation. That verification step is part of why our multi-chain wallet development covers 15+ chains without treating each new network as a rebuild of the wallet’s core.
We applied this exact architecture in a production wallet for ScratchApp, a fintech client launching in Colombia: nine networks (Ethereum, Polygon, BSC, Base, Arbitrum, Optimism, Avalanche, Solana, and TRON) from a single non-custodial seed phrase, with HD-based multi-wallet and account management, AES-256-GCM encrypted storage, and RPC failover across the full 2,500+ hour build.
For teams scoping their own build, the full crypto wallet development guide covers where HD derivation fits into the wider architecture, and the crypto wallet development cost breakdown covers what a correctly implemented multi-chain wallet costs to build.
