An HD wallet derives every key it will ever use from a single starting point.

That starting point is the master seed, and every private key, public key, and address in the wallet flows from it through a structured path called the derivation path.

Understanding how that path works explains why wallets recover correctly, and why using the wrong path after a restore shows a zero balance rather than your bitcoin.

What is a Hierarchical Deterministic Wallet?

Before 2012, Bitcoin wallets generated each private key independently. There was no mathematical relationship between keys, so every key required its own backup. Because these keys often existed only in the computer's RAM until the wallet file was manually saved and backed up, a sudden system crash could instantly vaporize the only copy of a key and the funds were permanently lost. Managing a wallet with hundreds of addresses meant managing hundreds of independent backups.

The introduction of BIP32 in 2012 changed that by introducing the hierarchical deterministic wallet. The practical result is that every key the wallet generates (every private key, public key, and receiving address) flows from one starting point. This meant you only had to back up the seed phrase, and all subsequent private keys could then be restored.

What Does "Hierarchical" and "Deterministic" Mean?

"Hierarchical" describes the tree-like structure, with a single source that branches out to produce individual branches and leaves. "Deterministic" describes how same seed always produces the same structure and results in the same keys After the initial seed generation, there is no randomness involved in the process, only computation.

This determinism is what makes wallet recovery work. If your wallet software fails, you can restore using any BIP39/BIP32-compatible wallet and your seed phrase. The new software recomputes the same keys in the same order and all of your associated addresses reappear, including your ability to spend from them. The wallet software simply redoes the same math.

The one requirement is that the new wallet must use the same derivation path as the original. That is where path notation becomes important.

How Does Key Derivation Work?

Each key in the tree is produced by a derivation function that takes three inputs: a parent key, a chain code, and an index number.

In practice, the parent key is like an account-level key sitting near the top of the hierarchy, and the child keys derived from it are the individual keys tied to each address you can receive bitcoin on. The chain code is an extra piece of data that travels alongside each key through the hierarchy, and exists to solve a specific security problem. Without it, knowing the parent key and an index number would be enough to derive any child key, which means a compromised child could potentially help an attacker reconstruct the parent. The chain code acts as a second required ingredient, so neither piece of information alone is sufficient to derive a child.

The derivation function produces two outputs, a child key and a new chain code. That new chain code is what the next derivation step will use. The function is one-way, so given the child key and chain code, you cannot recover the parent. A compromised child key cannot be used to work back up the tree.

The index number is what distinguishes positions at the same level. Index 0 produces the first child, index 1 produces the second, and so on. This is how wallets generate a fresh receiving address each time, by simply incrementing the index.

Hardened vs Non-hardened Derivation

There are two modes of derivation: hardened vs non-hardened derivation.

• In non-hardened derivation, the child key can be derived from the parent's extended public key, with no private key required. This means a watch-only wallet can generate receive addresses for an account without ever holding the private key.

• In hardened derivation, only the parent private key can produce the child. The extended public key is not sufficient. The purpose of this constraint is to prevent a specific type of attack. If a non-hardened child private key and its parent chain code are both compromised, the parent private key can be mathematically reconstructed. Hardened derivation closes that gap by keeping the private key as the required input.

To make this a bit easier to undertand, consider how watch-only wallets work. When you want a wallet to track your balance and generate receive addresses without holding your private key, you export your extended public key, or xpub. This is your account-level public key bundled with its chain code, and it contains enough information to derive all the child public keys (and therefore addresses) in that branch.

If you share that xpub with a watch-only wallet, with non-hardened derivation throughout an attacker who also obtained a private key from one of your addresses could combine it with the chain code in your xpub to reconstruct your master private key. Hardened derivation at the account level would block this attack. Because the xpub cannot produce hardened children on its own, the escalation path is closed.

Sensitive levels of the derivation path (purpose, coin type, and account) always use hardened derivation. In path notation, hardened levels are marked with an apostrophe. m/44' means purpose level 44, hardened. A level without an apostrophe is non-hardened.

What is a Derivation Path?

A derivation path is the location within the key tree, a sequence of steps specifying exactly which key to derive from the master key. The notation encodes each step as a number, separated by slashes.

A standard Bitcoin derivation path looks like this:

m / 44' / 0' / 0' / 0 / 0

Starting from the left, m is the master key, the root of the entire tree. Each subsequent segment is one derivation step. Following this path produces the first receive address of the first Bitcoin account in a BIP44-compatible wallet.

Breaking down the example:

• m is the master key, derived from the 512-bit master seed
• 44' is the purpose level. This wallet uses BIP44 conventions (hardened).
• 0' is the coin type. Bitcoin mainnet (hardened).
• 0' is the account level. The first account, account zero (hardened).
• 0 is the chain. The external chain generates receive addresses you share.
• 0 is the index. The first address at this position.

Given the same seed phrase, any BIP44-compatible wallet software will derive the same address at m/44'/0'/0'/0/0, every time.

What Do the Numbers in a Derivation Path Mean?

Each level of a derivation path serves a defined purpose, specified by BIP44. Understanding what each level controls explains why two wallets can produce different addresses from the same seed, and what to do about it.

Purpose (first level after m)

The purpose level specifies which BIP standard the wallet follows. Different purpose values produce different address types, and therefore different addresses, from the same seed.

• 44' uses BIP44 conventions for legacy addresses beginning with 1 (P2PKH)
• 84' uses BIP84 conventions for native SegWit addresses beginning with bc1q (P2WPKH)
• 86' uses BIP86 conventions for Taproot addresses beginning with bc1p (P2TR)

A wallet set to use m/84' paths and a wallet set to use m/44' paths will derive completely different addresses from the same seed. Neither is wrong, but they are generating different branches of the same tree. But if you back up a wallet using m/84' and restore using m/44', the new wallet will show a zero balance. The funds are still recoverable, you just need to configure the correct path.

Coin type (second level)

The coin type level identifies the cryptocurrency. For Bitcoin mainnet, this is always 0', whereas for Bitcoin's testnet it is 1'. Every Bitcoin wallet uses 0' at this level.

Account (third level)

The account level separates funds into logical groupings within one seed. Account 0' is the default. Using account 1' produces a completely separate set of addresses, all still recoverable from the same seed phrase. Some users maintain separate accounts for different purposes. A savings account might sit at account 1' while everyday spending stays at 0'. Both derive from the same seed phrase and recover automatically on any compatible wallet. The funds are isolated on-chain but unified in backup.

Change (fourth level)

The change level has two values, 0 and 1.

0 is the external chain, meaning the addresses you share with others to receive bitcoin. 1 is the internal chain, meaning the change addresses your wallet generates automatically when a transaction returns unspent funds back to your own wallet. Most users only ever see external chain addresses. The wallet manages change addresses silently.

Address index (fifth level)

The index is the sequential position within the chain. 0 is the first address, 1 is the second, and so on. Modern wallets auto-increment this with each new receive request, ensuring a fresh address is used each time.

The practical implication of this structure is that if you are restoring a wallet and your balance appears as zero, a potential cause could be a path mismatch. Check whether the restoring software is using the same purpose level as the original wallet. The addresses would still there, just located at a different branch of the tree.

What is an xpub and How is it Used?

An extended public key, or xpub, is a public key combined with a chain code that allows a wallet to derive all non-hardened child public keys below it. It is the tool that makes watch-only wallets possible.

The xpub should be treated as sensitive even though it cannot be used to spend funds. Anyone who holds your account-level xpub can derive every receive address and every change address for that account, and can trace your full transaction history for it. As a result, it reveals financial information without conferring spending capability. Share it only with software or services you intend to give that level of visibility.

Using XPubs with Hardware Wallets

The practical setup for an xpub is to be used with a hardware wallet, also known as a signing device. The signing device holds the full seed and all private keys, kept offline, while a watch-only wallet operates on an internet-connected computer and holds only the xpub at the account level (typically the key at m/84'/0'/0' for a native SegWit wallet). From that xpub, the watch-only wallet can derive every receive address and every change address for that account. It can monitor balances, track incoming transactions, and construct unsigned transactions. It cannot sign anything, because it holds no private key.

This separation ensures your private keys are never exposed to the internet and any associated malware or keylogger type attacks. The signing device handles the signing operation in isolation and only signed transaction data is passed to the networked computer.

One practical behavior to know is that when importing an xpub into new software, the wallet scans forward from address index 0 and checks each address against the blockchain. It stops scanning when it finds a consecutive run of unused addresses (the default gap limit is 20). This is how imported wallets surface existing balances, not by storing history, but by rediscovering it through the scan.