HD Wallets and Derivation Paths, Explained

A Hierarchical Deterministic wallet, or HD wallet, is a system that uses a single master seed phrase to mathematically generate a virtually infinite tree of private and public keys. Through a standardized map known as a derivation path, wallet software navigates this tree to find specific addresses for different assets, accounts, and transactions. Understanding this architecture explains how modern self-custody works, how extended public keys function, and why restoring a wallet on a new device occasionally results in a zero balance.

The architecture of HD wallets

Before the standardization of HD wallets, cryptocurrency users relied on non-deterministic wallets. These early systems generated a random private key for every new transaction. Users had to back up their wallet file continuously; if they lost the file after generating a new key, the funds associated with that key were permanently inaccessible.

Bitcoin Improvement Proposal 32 (BIP-32) introduced the Hierarchical Deterministic architecture. In this system, a single master private key, usually derived from a 12- or 24-word seed phrase, acts as the root of a mathematical tree. Using a cryptographic hashing function, the master key derives child keys. Those child keys can derive grandchild keys, and so on. Because the cryptographic process is deterministic, the exact same master seed will always generate the exact same hierarchy of keys in the exact same order. This eliminated the need for continuous backups. A user only needs to secure the initial seed phrase, which contains all the data necessary to recreate the entire wallet structure. For more context on storage methods, see Crypto Wallets Explained: Custodial, Hot, Cold, and Hardware.

The map to the vault: Derivation paths

While BIP-32 created the tree structure, it did not dictate how users should organize it. Without a standardized map, one wallet software might store Bitcoin ($BTC) on the first branch and Ethereum ($ETH) on the second, while another might do the reverse. If a user moved their seed phrase between these two applications, the software would look in the wrong branches and fail to locate the funds.

Bitcoin Improvement Proposal 44 (BIP-44) solved this by establishing a universal indexing standard called a derivation path. The derivation path acts as a set of coordinates telling the wallet exactly which branch to travel down to find a specific key.

Standard BIP-44 derivation paths follow this structure: m / purpose' / coin_type' / account' / change / address_index.

Consider a worked numeric example for the very first Bitcoin address in a standard wallet. The path is m/44'/0'/0'/0/0.

• m represents the master node.
• 44' represents the purpose, indicating the wallet follows the BIP-44 standard.
• 0' is the coin type. In the official registry, Bitcoin is registered as coin 0, while Ethereum is 60.
• 0' is the account index, allowing users to separate funds (e.g., Account 0 for savings, Account 1 for checking).
• 0 is the change indicator. It is 0 for external addresses designed to receive funds, and 1 for internal addresses used to receive change from transactions.
• 0 is the address index. This iterates sequentially (0, 1, 2, 3...) for every new address generated.

The evolution of address types

As blockchain protocols updated, the derivation path standards evolved to accommodate new network features. For Bitcoin, network upgrades introduced new address formats designed to reduce transaction fees and improve efficiency. Because derivation paths are strict maps, sending funds to a new address format required defining a new path so wallets would not mix legacy addresses with upgraded ones.

BIP-49 was introduced for Nested SegWit addresses (which start with a 3), changing the purpose level in the path from 44' to 49'. Later, BIP-84 was implemented for Native SegWit addresses (which start with bc1q). A wallet looking for Native SegWit Bitcoin will search the path m/84'/0'/0'/0/0. If a user holds funds in a Native SegWit address but their wallet software only scans the BIP-44 legacy path, the funds will not appear on the user interface, even though they remain secure on the blockchain.

Extended public keys

At each account level in the HD wallet tree, the software can generate an extended public key, commonly referred to as an xpub. A standard public key can only show the balance and transaction history of a single specific address. An extended public key, however, contains the public key data and a structural chain code, granting it the ability to view the balances and histories of all child addresses derived below it in the hierarchy.

This functionality allows users to create watch-only wallets. By importing an xpub into an application, a business can generate new receiving addresses for every customer invoice and monitor incoming payments without ever exposing the private keys on an internet-connected device. Different address formats use different prefixes for these extended keys to avoid confusion: xpub for legacy addresses (BIP-44), ypub for Nested SegWit (BIP-49), and zpub for Native SegWit (BIP-84).

While an xpub cannot be used to spend funds, it poses significant privacy risks. Anyone in possession of an extended public key can see the total balance and entire transaction history of the associated account. If an attacker acquires an xpub, they can map out the user's financial footprint.

Why coins disappear during restoration

When users import their seed phrase into a new wallet application, they frequently encounter an empty balance, leading to panic. This phenomenon is almost always the result of derivation path mismatches or gap limit protocols, rather than actual theft or data loss.

First, different wallet developers may default to different derivation paths. If a user originally stored their assets using a wallet that defaults to BIP-84 (Native SegWit), and restores the seed phrase into a wallet that defaults to BIP-44 (Legacy), the new software searches the wrong mathematical branches. The keys exist, but the software is looking in the wrong place.

Second, wallet software utilizes a gap limit to determine when to stop searching for transaction history along the address index. A common default gap limit is 20. When a wallet restores from a seed phrase, it checks address 0, then address 1, progressing sequentially. If it checks 20 consecutive addresses and finds no transaction history on the blockchain, it assumes the user never generated keys past that point and stops scanning. If a user previously generated 25 addresses without using them, and then deposited funds into the 26th address, the restored wallet will stop scanning at 20 and fail to display the funds. Users must manually adjust the gap limit in the software settings to force the wallet to scan deeper into the derivation path.

Common misconceptions

• Seed phrases contain the funds. Seed phrases only generate the mathematical keys required to authorize transactions. The actual assets exist exclusively on the distributed ledger.
• Wallets scan the entire blockchain. Wallets do not indefinitely search the blockchain for a user's funds. They only search specific, programmed derivation paths and stop scanning once they hit the software's designated gap limit.
• Extended public keys risk theft. An xpub, ypub, or zpub cannot derive private keys. While exposing an extended public key destroys financial privacy by linking all child addresses together, it does not give an attacker the cryptographic authorization required to move the assets.

What to watch

As the industry matures, standardization across wallet providers continues to improve, reducing the friction of restoring accounts across different software. However, the proliferation of new Layer-1 networks and Layer-2 scaling solutions requires constant updates to the official coin type registry. Software developers must manually implement these paths, meaning hardware and software wallets will periodically desync in their default settings during major network upgrades. Additionally, the rise of account abstraction and smart contract wallets introduces entirely new paradigms for key management that bypass traditional BIP-32 and BIP-44 structures entirely, pushing the ecosystem toward models where users rely on programmable logic rather than strict mathematical hierarchies.