Bitcoin derivation paths explained

A derivation path is the address of one key inside an HD wallet's key tree, written like m/84'/0'/0'/0/0. Each number picks a branch: the purpose (which standard and address type), the coin, the account, receive or change, and the address index. The same seed phrase gives completely different addresses on different paths, so a wallet must use the right path to find your coins.

Updated 2026-10-20 · 9 min read

What is a derivation path?

A modern Bitcoin wallet doesn't store a pile of unrelated keys. It stores one seed and derives every key from it in a tree, as defined by BIP 32, hierarchical deterministic (HD) wallets, written by Pieter Wuille in 2012.

A derivation path is the route from the root of that tree to one key. Reading m/84'/0'/0'/0/0 from left to right:

• m is the master key, made from your seed.
• Each /n is one step down to child number n.
• An apostrophe (or h) means the step is hardened.

So m/84'/0'/0'/0/0 means: from the master key, take hardened child 84, then hardened child 0, then hardened child 0, then normal child 0, then normal child 0. The key at the end is the one behind your first receive address.

How the BIP 32 key tree works

Every extended key in BIP 32 is a key plus a 32-byte chain code. Feeding the parent key, chain code and a child number into HMAC-SHA512 produces the child key and its own chain code, and so on down the tree. Each key has 2^31 normal children (indices 0 to 2^31 - 1) and 2^31 hardened children (indices 2^31 to 2^32 - 1).

The difference matters for extended public keys (xpubs):

• Normal (non-hardened) children can be derived from the parent's xpub alone. That is what lets a watch-only wallet or a payment server generate fresh addresses without holding any private key.
• Hardened children can only be derived from the parent's private key.

Hardening exists because of a weakness BIP 32 spells out: anyone who knows a parent xpub and any one of its non-hardened child private keys can compute the parent private key, and with it every key below. Hardening the upper levels of the path puts a firewall between accounts, so a leaked key in one account can't expose the rest of the wallet.

Hardened notation: ' vs h

BIP 32 writes a hardened index i as i with a subscript H, meaning i + 2^31. Later BIPs use an apostrophe: BIP 44 defines its purpose as 44' "(or 0x8000002C)", which is 44 + 2^31 in hexadecimal. Output descriptors accept both h and ', and BIP 48 and BIP 87 say "h or '". So m/84'/0'/0' and m/84h/0h/0h are the same path. The h form is easier to type in a shell, where an apostrophe has special meaning.

BIP 43: the purpose field

BIP 32 alone left too many choices open: two "BIP 32 compatible" wallets could lay out their trees differently and fail to find each other's coins. BIP 43, by Marek Palatinus and Pavol Rusnak (2014), fixed the first level of the path as the purpose:

m / purpose' / *

The purpose number is normally the number of the BIP that defines the structure below it. That is why paths start with 44', 49', 84' or 86'. BIP 43 reserves purposes 10001 to 19999 for SatoshiLabs' SLIP documents, and notes that m/0'/* was already used by BIP 32's default layout.

BIP 44: the five levels of a path

BIP 44, by the same authors, defines the layout almost every single-signature wallet still follows:

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

Two rules from BIP 44 explain a lot of wallet behavior:

• The gap limit is 20. When restoring, a wallet scans receive addresses in order and stops after 20 unused addresses in a row. Wallets should warn you before you create addresses past that limit.
• Account discovery. A wallet checks account 0, then account 1 and so on, stopping at the first account with no transaction history. That is why wallets shouldn't let you create a new account while the previous one is unused.

Common derivation paths for each address type

BIP 49, BIP 84 and BIP 86 copy the BIP 44 layout and only change the purpose number, so a wallet can tell which address type to generate from the path alone.

A few notes on the less common ones:

• BIP 48 adds a sixth level, script_type', between account and change: 1' for nested SegWit multisig and 2' for native SegWit multisig. The BIP recommends 2' as the default.
• BIP 45 uses a non-hardened cosigner index instead of coin type and account, so each cosigner generates addresses on their own branch.
• BIP 87 keeps the five BIP 44 levels and leaves the script type to an output descriptor, arguing that a per-script path is redundant once descriptors record the script.
• Other BIPs reuse the pattern for their own purposes: BIP 47 payment codes use 47', BIP 352 silent payments use 352', and BIP 85 derives child seeds under 83696968'.

For head-to-head comparisons, see BIP 44 vs BIP 84, BIP 49 vs BIP 84, BIP 84 vs BIP 86 and BIP 44 vs 49 vs 84 vs 86. Multisig paths are covered in the multisig guide.

Example: first receive address for each path

Here is what one seed produces on each standard path. The seed is the public test phrase used in the BIPs ("abandon" eleven times, then "about"), with no passphrase. Its master key fingerprint is 73c5da0a. Never use this phrase for real funds: anyone can spend from it.

The BIP 84 and BIP 86 addresses match those BIPs' own test vectors. The first change address on the BIP 84 path is m/84'/0'/0'/1/0, and the second receive address is m/84'/0'/0'/0/1. You can take any path apart level by level with the derivation path tool, which never asks for a seed phrase.

Coin type: 0' vs 1'

The second level separates networks. Bitcoin mainnet uses coin type 0'; Bitcoin testnet uses 1'. BIP 87 says 1' covers all test networks: testnet, regtest and signet. BIP 44 lists only these two values itself and points to SatoshiLabs' SLIP-0044 registry for other coins. A testnet path for the first BIP 84 address is therefore m/84'/1'/0'/0/0, and its addresses start with tb1q instead of bc1q.

xpub, ypub and zpub: what the prefixes mean

An extended public key (xpub) is the public half of an account-level node, serialized as a 111-character Base58 string. Its first four letters come from version bytes at the start of the data:

The key data inside is identical: a zpub and an xpub for the same account differ only in their first bytes and checksum. The prefix is a hint to the importing wallet about which addresses to generate.

Two things are worth knowing. First, BIPs 49 and 84 define ypub and zpub themselves, but the capital Ypub and Zpub (and more) are listed in SLIP-0132, a SatoshiLabs document that is not a BIP. Second, BIP 380 calls these version bytes "a layer violation", since key encoding shouldn't decide the script type, and each prefix only covers one derivation path and script type. BIP 86 didn't define a new prefix for Taproot: Taproot accounts use a plain xpub. The general replacement is an output descriptor, such as wpkh([73c5da0a/84h/0h/0h]xpub.../<0;1>/*), which states the script, the key origin and the path explicitly.

Why does my recovered wallet show zero balance?

If you restore a seed phrase and see no coins, the seed is usually fine. The new wallet is most likely looking on a different branch of the tree. Work through these in order:

1. Address type and purpose. Coins received on bc1q addresses live under 84', on 3 addresses usually under 49', on 1 addresses under 44', and on bc1p addresses under 86'. Try each.
2. Passphrase. A missing or slightly different BIP 39 passphrase opens a different, empty wallet. There is no error message.
3. Account number. If you used a second account, it is under /1', not /0'.
4. Gap limit. If you handed out more than 20 addresses that were never paid, the scan may stop early. Raise the gap limit in the wallet's settings.
5. Network. Testnet coins live under coin type 1'.
6. Non-standard paths and formats. Some older wallets used custom paths such as BIP 32's original m/0'/0/k layout, and some use their own seed formats (see the seed phrase guide).
7. Multisig. A seed from a multisig wallet only holds one key. You also need the other cosigners' xpubs, or the wallet's descriptor.

Pasting an old receive address into the address checker shows its type, which tells you which purpose to try first.

Derivation paths vs output descriptors

Fixed paths per address type solved the "which addresses does this seed have?" problem for simple wallets, but the information still lives outside the seed. You have to know, or guess, the path. Output descriptors write the whole answer down: script type, master fingerprint, path, xpub and which children to scan. If your wallet can export a descriptor, keeping it alongside your seed backup removes the guesswork.