HD Wallets and Key Derivation: How One Seed Creates Every Address You'll Ever Use

A hierarchical deterministic (HD) wallet uses a single seed phrase to generate every address you'll ever need across every coin, through a deterministic tree of derived keys. The standards that make this possible (BIP-32 for the derivation mechanism, BIP-44 for cross-chain conventions) are why a 12-word backup can restore a multi-chain wallet, and they are also the source of "missing funds" support tickets when derivation paths don't match across applications.

What is an HD wallet?

An HD wallet is a wallet that generates all of its private keys, public keys, and addresses from a single root seed, using a deterministic algorithm so the same seed always produces the same tree of keys. The "hierarchical" part means keys are organized in a parent-child tree; the "deterministic" part means the tree is fully reproducible from the seed alone.

Before HD wallets, every Bitcoin address came from a separately generated keypair, and users had to back up each keypair individually. Wallet files grew, backups went stale, and a user could easily generate addresses that no backup covered. Pieter Wuille's BIP-32 specification introduced the HD model in 2012, and it has become the default for almost every modern wallet across every chain. Your BIP-39 seed phrase is the input to that derivation; HD is what makes the seed phrase a complete backup of every address the wallet has ever shown you or will ever show you.

The same seed, run through the HD derivation function with different paths, produces different keys. That property is what lets one backup restore a wallet across Bitcoin, Ethereum, Solana, and other chains.

How does BIP-32 derive a tree of keys from one seed?

BIP-32 turns your seed into a master extended private key by running it through HMAC-SHA512, splitting the 512-bit output into a 256-bit master private key and a 256-bit chain code. The chain code is the "extra" data that makes child-key derivation deterministic and prevents an attacker who learns one child key from deriving siblings.

From the master extended private key, BIP-32 derives child keys using the Child Key Derivation (CKD) function. Each child is identified by an index number, and applying CKD recursively produces grandchildren, great-grandchildren, and so on, forming an arbitrarily deep tree. Each node has its own private key, its own public key (derived from the private key via secp256k1), and its own blockchain address (derived from the public key via chain-specific encoding).

Chapter 5 of Mastering Bitcoin walks through the math step by step (source: Mastering Bitcoin Chapter 5). What matters operationally is that every address you see in your wallet has a coordinate in this tree, and that coordinate is what determines whether a different wallet application can find your funds when you restore from the seed.

What is a derivation path and how do you read one?

A derivation path is a string of slash-separated numbers that describes a node's coordinates in the BIP-32 tree, starting from the master key. The path m/44'/0'/0'/0/0 reads as "starting from the master, descend through purpose 44 (hardened), coin type 0 (hardened), account 0 (hardened), external chain 0, address index 0." Most wallets display this path in their advanced settings.

The structure is defined by BIP-44 as m / purpose' / coin_type' / account' / change / index. Each segment has a specific role:

• m: master node (the seed-derived root).

• purpose': the BIP that defines this layout. 44' for the original BIP-44 (legacy Bitcoin addresses); 49' for BIP-49 (P2SH-wrapped SegWit); 84' for BIP-84 (native SegWit); 86' for BIP-86 (Taproot).

• coin_type': which blockchain. The registry is SLIP-44 and assigns Bitcoin = 0, Ethereum = 60, Solana = 501, Litecoin = 2, and dozens of others.

• account': separates user accounts within one wallet. Most wallets default to account 0 and never expose this segment in their UI.

• change: 0 for receiving addresses (shown to senders), 1 for change addresses (where leftover transaction outputs return).

• index: the sequential address number within that account and chain combination. Starts at 0 and increments as the wallet generates new addresses.

The apostrophe after the first three segments marks hardened derivation, which is the next section's topic.

How does one seed produce addresses for Bitcoin, Ethereum, Solana, and other chains?

The same master seed produces different addresses for different chains by changing the coin_type segment in the derivation path. SLIP-44 assigns each chain a unique number, and a wallet that knows your seed and the chain's SLIP-44 code can derive the correct address tree without any additional input from you. This is what lets MetaMask, Trust Wallet, and other multi-chain wallets show your Bitcoin, Ethereum, and Solana balances from a single seed.

The table below shows the canonical first-address path for the major chains:

Solana and Polkadot use different sub-tree shapes than Bitcoin and Ethereum because their ecosystems standardized later, when single-address-per-account patterns were preferred. The headline point: the SLIP-44 number is the address-tree fork point. Change the coin type, and the same seed reveals an entirely different set of addresses on a different chain.

Hardened versus non-hardened derivation (the apostrophe)

A hardened derivation step (marked with an apostrophe, e.g., 44') requires the parent private key to produce the child, while non-hardened derivation (no apostrophe) can produce the child public key from the parent extended public key alone. The distinction matters because non-hardened derivation has a specific attack: if an attacker has the parent extended public key (xpub) and obtains any one child private key, they can recover the parent private key, and from there the entire subtree.

BIP-44 uses hardened derivation for the first three segments (purpose, coin type, account) because compromise at those levels would expose every address in the wallet. Below the account level, change and index segments use non-hardened derivation so a watch-only application (a server, a block explorer, a public auditor) can be given the account's extended public key and use it to monitor every address the wallet generates, without ever holding any private key.

The tradeoff: anyone with the xpub can compute every address and watch every transaction. Sharing an xpub is not sharing a private key, but it is sharing complete on-chain history visibility across that account branch. Many users don't realize this when they hand an xpub to a portfolio tracker or block explorer; the privacy cost is real even though no funds are at risk.

Which wallets use HD derivation today?

Effectively every modern self-custody wallet uses BIP-32/44 HD derivation. Differences are in which derivation paths the wallet supports by default, whether it exposes path selection to the user, and how it handles cross-chain configurations. Vendor documentation describes the specific paths each device uses (source: Trezor BIP-32 Guide) and how account-level path selection works on each device (source: Ledger Support — Unusual Derivation Path).

The pattern across all of them: HD support is universal, but the specific default paths a wallet uses are an application-level decision. This is exactly why the same seed can produce "empty" results when restored into a different wallet: the new wallet is scanning a different path than the old one used.

For more on which wallet to choose for your situation, see our hardware wallets explainer.

Common HD wallet pitfalls

Five pitfalls account for most HD-related support tickets: derivation-path mismatch during restoration, gap-limit gaps, xpub privacy leaks, change-address confusion, and forgetting which BIP-purpose the original wallet used. Each of these failures has a recognizable signature, and each is recoverable if you know what to check, which is why understanding the pattern matters more than memorizing fixes.

Derivation-path mismatch on restore. The most common failure pattern. A user creates a wallet in MetaMask using m/44'/60'/0'/0/x, imports the seed into a different application that defaults to a different path, and sees an empty wallet. The funds are not lost; they're at the address the new wallet didn't scan. The fix is to enter the correct derivation path manually in the new wallet's advanced settings, or to use an application that supports the original path. Our wallet recovery reference covers the systematic restoration process.

Gap limit. Most wallets default to a gap limit of 20, meaning if you have 20 consecutive unused addresses, the wallet stops scanning further. If your transaction history includes a gap of more than 20 unused addresses in a row, funds beyond the gap may not auto-appear after restoration. The fix is to increase the gap limit setting (most wallets allow this) and rescan.

xpub leaks. Sharing an extended public key with a watch-only service grants permanent transaction-history visibility into every address derived from that branch. The xpub doesn't expose private keys, but it exposes every payment, every balance, and every address you'll ever use under that account. If you've shared an xpub, treat the account as semi-public for as long as that xpub is held.

Change-address confusion. Change addresses (the 1 branch in the path) are where leftover outputs from your transactions return. Some users see change appearing at unfamiliar addresses, assume the wallet has been compromised, and panic. The fix is understanding that change addresses are normal and your wallet manages them automatically.

Wrong BIP-purpose on restore. A wallet created with native SegWit (m/84'/0'/0'/0/0) won't show its balance if restored into an application that defaults to legacy (m/44'/0'/0'/0/0). The two paths describe entirely different address sets on the same seed. The fix: know which purpose code your original wallet used (44' / 49' / 84' / 86') and select the matching one on restore.

From Blofin's customer-support inbox, derivation-path mismatch is the single most common cause of "missing funds" tickets we receive about self-custody restorations. The funds are almost always still on the blockchain; the new wallet just isn't looking at the right address. Coaching the user through entering the correct path resolves the issue in nearly every case. The pattern is so consistent that any "missing funds after restore" report should start with verifying the derivation path before assuming a deeper failure.

For backup principles that prevent these scenarios in the first place, see our seed phrase backup reference.

Frequently asked questions

What's the difference between BIP-39 and BIP-32?

BIP-39 defines how a seed phrase (12 or 24 words from a 2,048-word wordlist) maps to a 512-bit binary seed; an optional BIP-39 passphrase is part of that mapping. BIP-32 takes that binary seed and turns it into a hierarchical tree of keys. The two standards work together: BIP-39 is the human-friendly backup format; BIP-32 is the algorithm that generates every key from that backup. A wallet supports both because you need both.

Can I change my derivation path after I've already set up my wallet?

Yes, but it creates a new address tree separate from your existing one. Most wallets let you change derivation paths in advanced settings, but doing so points the wallet at a different set of addresses, and your existing balance stays at the original path's addresses. To move funds onto the new path, you send a transaction from the old addresses to addresses in the new tree. Test with a small amount first to verify the new path is producing the addresses you expect.

What is an xpub and is it safe to share?

An xpub is an extended public key: a parent public key plus its chain code, sufficient to derive every child public key (and therefore every address) below it in the BIP-32 tree. Sharing an xpub does not expose private keys, but it does expose every address and every transaction across that subtree to whoever has it. Share xpubs only with services you trust to handle that visibility responsibly (block explorers, portfolio trackers, multisig coordinators), and understand that the privacy cost is permanent for as long as the xpub holder retains it.

What is gap limit and why does it matter?

Gap limit is the maximum number of consecutive unused addresses a wallet will scan before assuming there are no more to find. The default in most wallets is 20. If your wallet history includes a gap larger than 20 (for example, you generated 25 addresses but only used the first 3 and the 25th), the wallet may not display the balance at address 25 after restoration. The fix is to increase the gap limit setting and rescan. This is purely a wallet-software issue; the funds are always on the blockchain regardless of whether your wallet has located them.

Should I use the same wallet across multiple chains, or separate wallets per chain?

Either approach is valid. A multi-chain HD wallet (MetaMask Snaps, Trust Wallet, Trezor Suite with integrations) using one seed across Bitcoin, Ethereum, Solana, and others is convenient and means one backup covers everything. Separate wallets per chain (a Bitcoin-only Coldcard for cold storage; a MetaMask for daily Ethereum) lets you tune security per use case. The choice depends on whether you value convenience or compartmentalization. Both rely on HD derivation under the hood; the difference is whether one seed serves multiple chains or you maintain a separate seed per chain.

Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the BIP-32 specification (Wuille), BIP-44 specification, SLIP-44 coin types registry (SatoshiLabs), Mastering Bitcoin (Antonopoulos & Harding, 3rd edition), Trezor documentation, and Ledger Live documentation. All facts independently verified against cited documentation current as of May 2026.

This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.