Lesson 3 — HD wallets and derivation paths
One seed, infinite keys. How BIP-32 hierarchical deterministic wallets work, why the same seed in two different wallets can show different balances, and how to avoid the 'wrong path' trap on restore.
If you've ever restored a wallet from a seed and seen a zero balance even though you know there was money in it, you have probably encountered a derivation-path mismatch. The seed is correct. The wallet is correct. But the path the new wallet is checking is not the path the original wallet used. This lesson explains why, and how to never fall into that hole again.
BIP-32 defines a hierarchical deterministic (HD) wallet. The master seed produces a master private key. The master key, plus an index, produces a child private key. Each child, plus a further index, produces grandchildren — and so on indefinitely. The structure is a tree. Every leaf is a usable private key. The crucial property is determinism: given the same seed, you always get the same tree. Back up the seed, recover the whole tree.
BIP-44 standardises the shape of the tree: `m / purpose' / coin_type' / account' / change / address_index`. Each apostrophe denotes 'hardened' derivation (a security property that prevents one leaked child key from compromising siblings). `purpose'` is usually `44'` for legacy paths, `49'` for wrapped SegWit (BIP-49), `84'` for native SegWit (BIP-84), and `86'` for Taproot (BIP-86). `coin_type'` is `0'` for Bitcoin, `60'` for Ethereum and most EVM chains, and a few hundred others registered in SLIP-44.
Two wallets given the same seed but configured for different default paths will derive different addresses. Restore a Bitcoin seed that was originally used in a BIP-84 native-SegWit wallet into a wallet that only checks BIP-44 legacy addresses, and the balance looks like zero. Restore an Ethereum seed into a wallet that checks the Ledger Live legacy path (`m/44'/60'/0'/0/0`) when it was created in a MetaMask path (`m/44'/60'/0'/0`), and you see different addresses — sometimes with nothing in them, sometimes with something you didn't expect.
The defensive practice is to record the derivation path alongside the seed itself. The seed is the secret; the path is the recipe. Without the recipe, the secret unlocks the wrong wallet. Most reputable wallets show the active derivation path in advanced settings; for hardware wallets, the path is set per-account on the host application.
EVM chains share the same derivation tree. The Ethereum address derived at `m/44'/60'/0'/0/0` is also your Polygon address, your Arbitrum address, your Optimism address, and so on — same private key, same address, different chains. This is convenient for users but is also why a leaked seed on Ethereum compromises every EVM chain at once. Bitcoin and most non-EVM chains use different coin types and different paths, so they generate different addresses from the same seed.
Importing a seed into multiple wallets is safe in the sense that the seed itself doesn't 'wear out' — but each wallet then has the ability to see and sign for those addresses. If you import the seed into a phone wallet for convenience, every transaction that wallet can sign is one phone compromise away. The principle: the more devices that hold a seed, the larger the attack surface against the keys it derives.
Example
A common support story: a user restored a Bitcoin seed from 2017 into a modern wallet and saw a zero balance. The seed was correct; the wallet was correct. The original wallet had generated addresses on the legacy `m/44'/0'/0'` path, but the new wallet defaulted to `m/84'/0'/0'` (native SegWit). Once the user switched the new wallet to check the legacy path, the balance appeared. The seed had been protecting the funds the entire time — the user just couldn't see them. The lesson: if you change wallets, record the original derivation path before you change anything.
Common mistakes
- Writing down only the seed, never the derivation path. Months or years later on restore, the path is forgotten and the balance is invisible.
- Assuming all wallets default to the same path. They don't — and 'sensible defaults' have changed over time.
- Importing a seed into a casual wallet (browser extension, phone app) for convenience, multiplying the attack surface against the same keys.
- Forgetting that EVM chains share derivation. Compromising one EVM seed compromises all of them.
- Believing 'zero balance after restore' means the seed was wrong. Almost always it's a path mismatch, not a seed problem — but the temptation to panic and try multiple wallets only makes things worse.
Check your understanding
You restored a 24-word seed into a new wallet and see no balance, even though you are certain there were funds in the original wallet. What is the most likely cause?
Key terms covered
Sources & further reading
- PrimaryBIP-32 — Hierarchical Deterministic Wallets
Specification for the HD wallet tree structure underlying every modern wallet.
- PrimaryBIP-44 — Multi-Account Hierarchy for Deterministic Wallets
Standardised derivation-path layout.
- Primary
- PrimarySLIP-44 — Registered coin types
The registry that assigns `coin_type'` values to each blockchain.
We prioritise primary sources. Where a topic moves quickly (regulation, security incidents), we re-check sources on the cadence shown by the page's "Next review" date.