Derivation Path

What Is a Derivation Path?

A derivation path is a set of instructions that tells an HD (hierarchical deterministic) wallet exactly how to compute a specific cryptographic key from a master seed. Think of it like a file path on a computer: just as /home/user/documents navigates to a specific folder, a derivation path like m/84'/0'/0'/0/0 navigates to a specific key within a tree of billions of possible keys.

The concept was formalized in BIP-32, which defined the HD wallet standard. BIP-32 established that a single seed can produce a practically infinite tree of key pairs, with each node in the tree addressable by its derivation path. Later BIPs (44, 49, 84, 86) built on this by standardizing which paths to use for which address types, ensuring wallet interoperability.

Without standardized derivation paths, restoring a wallet from a seed phrase would be nearly impossible: the wallet software wouldn't know which keys to derive, and your funds would be effectively lost despite having the correct seed.

How It Works

Every derivation path follows a consistent structure. Each level in the path represents a branching point in the key tree, and the full path specifies the exact route from the root to a leaf key.

Path Structure

The standard format defined by BIP-44 and its successors is:

m / purpose' / coin_type' / account' / change / address_index

Each component serves a specific role:

• m: the master node, representing the root key derived from your seed
• purpose: identifies the BIP standard being used (44, 49, 84, or 86)
• coin_type: identifies the cryptocurrency (0 for Bitcoin mainnet, 1 for testnet)
• account: allows separation of funds into logical accounts (0, 1, 2, etc.)
• change: 0 for receiving addresses, 1 for internal change addresses
• address_index: sequential index for generating new addresses (0, 1, 2, etc.)

Hardened vs. Unhardened Derivation

The apostrophe (') after certain levels indicates hardened derivation. This distinction is critical for security.

In unhardened (normal) derivation, a child public key can be computed from the parent public key alone. This is useful because it enables watch-only wallets: given an extended public key (xpub), anyone can derive all child public keys and monitor addresses without access to private keys.

Hardened derivation requires the parent private key. This adds a security boundary: even if a child private key and the parent public key are both compromised, an attacker cannot compute the parent private key or sibling keys. The first three levels (purpose, coin type, account) use hardened derivation by convention, while the last two (change, index) use unhardened derivation to enable xpub-based address generation.

Hardened derivation ('):
  parent private key + index → child private key
  parent public key alone CANNOT derive child public key

Unhardened derivation:
  parent private key + index → child private key
  parent public key + index → child public key (watch-only capable)

Standard Derivation Paths

Bitcoin uses four major derivation path standards, each corresponding to a different address type:

BIP-84 native SegWit paths are the most widely used today, offering lower transaction fees than legacy addresses through the witness data discount. BIP-86 Taproot paths are newer and enable advanced features like Schnorr signatures and more complex spending conditions via Bitcoin Script trees. For a deeper look at how Taproot and Schnorr signatures work together, see the Taproot and Schnorr signatures deep dive.

Derivation in Practice

To illustrate, here is how a wallet derives the first receiving address for a native SegWit account:

Seed phrase → Master seed (BIP-39)
Master seed → Master key (m)

m
└── 84'  (purpose: BIP-84 native SegWit)
    └── 0'   (coin: Bitcoin mainnet)
        └── 0'   (account: first account)
            ├── 0    (change: external/receiving)
            │   ├── 0  → first receiving address (bc1q...)
            │   ├── 1  → second receiving address
            │   └── 2  → third receiving address
            └── 1    (change: internal/change)
                ├── 0  → first change address
                └── 1  → second change address

The full path for the first receiving address is m/84'/0'/0'/0/0. The second receiving address is m/84'/0'/0'/0/1. Change addresses follow the same pattern under the /1/ branch.

Use Cases

Wallet Recovery

The primary purpose of standardized derivation paths is wallet recovery. When you restore a wallet from a seed phrase, the wallet software scans standard paths to discover your funds. It derives keys at m/44'/0'/0', m/49'/0'/0', m/84'/0'/0', and m/86'/0'/0', then checks each derived address for transaction history.

This only works because wallets agree on which paths to scan. If a wallet used a nonstandard path, another wallet would never find those funds during recovery.

Account Separation

The account level in the path allows users to maintain separate balances within the same seed. A business might use account 0 for operational funds and account 1 for reserves:

m/84'/0'/0'/0/...  → Operational account addresses
m/84'/0'/1'/0/...  → Reserve account addresses

Both accounts derive from the same seed phrase, but their keys are cryptographically independent. Knowing the keys for one account reveals nothing about the other (thanks to hardened derivation at the account level).

Watch-Only Wallets and Xpubs

Because the last two levels use unhardened derivation, an extended public key exported at the account level can generate all receiving and change addresses. This enables watch-only wallets that monitor balances and generate fresh receiving addresses without holding any private keys. It also enables setups where a server generates addresses for customers while private keys remain on an air-gapped device.

Multi-Signature Wallets

In multisig wallet configurations, each cosigner contributes keys derived from their own seed at a specific path. BIP-48 extended the standard for multisig setups, adding a script type level:

m/48'/0'/0'/2'  → Native SegWit multisig (P2WSH)
m/48'/0'/0'/1'  → Wrapped SegWit multisig (P2SH-P2WSH)

All cosigners must use the same path convention to reconstruct the multisig address correctly. A mismatch in derivation paths means the resulting address won't match, and funds sent to it may become inaccessible.

Risks and Considerations

Wrong Path, Missing Funds

The most common derivation path issue is importing a seed phrase into a wallet that defaults to a different path than the one originally used. The seed is correct, and the wallet derives valid keys, but they are the wrong keys. The wallet shows a zero balance because it is looking at addresses that were never used.

If you encounter this problem, try switching the wallet's address type or manually specifying the derivation path. Most modern wallets scan all four standard paths (BIP-44, 49, 84, 86) during recovery, but older or simpler wallets may only check one.

Non-Standard Paths

Some wallets and services use custom derivation paths for specific features. While this is technically valid, it creates recovery risk: if the wallet software disappears, no other wallet will know to scan that path unless the user manually specifies it. Always document any non-standard paths used for your funds.

Xpub Exposure and Privacy

Sharing an xpub at the account level reveals all current and future addresses for that account. While it does not expose private keys, it completely eliminates privacy for that account. Anyone with the xpub can see every transaction, every balance, and every address. Treat xpubs with the same caution as you would a bank statement.

Gap Limit

When scanning for funds during recovery, wallets check addresses sequentially (index 0, 1, 2, ...) and stop after encountering a configurable number of consecutive unused addresses, known as the gap limit (typically 20). If you generated addresses beyond this gap without using the intermediate ones, recovery scanning will miss them. This is rare in normal usage but can occur with automated systems that generate addresses in bulk.

Hardened Derivation Tradeoffs

Hardened derivation provides stronger security isolation but prevents public-key-only derivation. This means you cannot create a watch-only wallet for hardened child keys: you need the private key to derive them. The standard convention (hardened for purpose, coin, and account; unhardened for change and index) balances security with usability, but custom schemes that over-use hardened derivation can limit functionality.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.