The cool thing about extended keys is that they can derive children, and these child keys can derive more children, and so on. This allows you to create a tree of extended keys, with each key having its own unique derivation path from the master key.
You can derive keys in any way you want. But to help with compatibility between wallets, we have a set structure for how we derive keys for use in a hierarchical deterministic wallet.
The most common derivation paths used in Bitcoin are:
Bitcoin wallets use common derivation paths for deriving new addresses. This helps with compatibility and the recovery of keys between different wallets.
Notation
What does a derivation path mean?
First, we have a basic notation for describing the derivation path for a specific extended private key in an HD wallet.
For example:
m/0/1/3'
The slashes / indicate a new level in the tree (a new child).
The numbers (e.g. 0, 1, 3') indicate the index number of the child from the parent.
The ' (or h) indicates a hardened child (starting at index number 2147483648).
You can derive up to 4,294,967,296 (just over 4 billion) children from a single extended key. The first half are for normal children, and the second half are for hardened children.
Normal Children (0 to 2147483647) – These children have corresponding extended public keys that can be used to generate public keys independently without generating the private keys at the same time.
Hardened Children (2147483648 to 4294967295) – These do not have the same ability as normal children. You can only generate the private keys and public keys from the extended private key.
Deriving hardened children is the default.Normal children are only derived when it would be useful to have a corresponding extended public key for deriving public keys independently.
The keys and addresses you use in a typical HD Wallet will be from a normal child. This means that you can use the parent extended public key to generate addresses on a different computer for receiving payments without exposing the private keys on that computer.
The ' syntax saves on having to write the full index numbers for hardened children. For example, 3' means index 2147483651 (or 2147483648 + 3).
Wallet Structure
To help with consistency between wallets, BIP 44 introduced the following structure for HD wallets:
m / purpose' / coin_type' / account' / change / index
m: Master
This is the master extended key, which is the first extended private key at the top of the HD wallet tree.
All derivation paths start with an m.
This master extended key is created from the seed.
m/44': Purpose(hardened)
The first level specifies the upcoming wallet structure.
There are three schemes currently being used by wallets:
This number reflects the number of the BIP (Bitcoin Improvement Proposal).
m/44'/0': Coin Type(hardened)
The second level indicates the specific cryptocurrency the keys will be used for.
Different cryptocurrencies can use the same private keys and public keys. So instead of having separate seeds for different currencies (or using the same public keys on different chains), we can use the same seed with different derivation paths instead.
This is useful in hardware wallets (e.g. Trezor), where you can have a single seed and use it for holding a variety of different coins.
m/44'/0'/0': Account(hardened)
The third level allows you to create separate accounts for funds.
For example, you can create separate "pots" from the same seed, and the coins in these separate accounts will not be mixed.
The default account index is 0'.
You could obviously create many different accounts at random indexes at this level. But to keep recovery simple, a wallet should create accounts in sequential order, and not create a new account if a previous one has not been used.
m/44'/0'/0'/0: Change
The fourth level separates the keys and addresses in to "Receiving" and "Change":
Receiving = 0 - Addresses that we will give out to people to receive payments.
Change = 1 - Addresses we use for sending change back to ourselves when we make transactions.
This allows you to differentiate the coins that have arrived from external payments from the coins that you have sent back to yourself as change.
These are normal children. This means they have corresponding extended public keys, which can be used to derive the public keys independently for the children below.
m/44'/0'/0'/0/0: Index
The fifth level contains the keys that you actually use for sending and receiving payments in the wallet.
So every time you generate a new address to receive a payment, you're incrementing the index for the child key at this level (starting from 0).
So the actual keys used for addresses are in the lowest level of the key tree; the first few levels in the path are just used to structure the hierarchical deterministic wallet in a functional way.
You don't actually need to use extended keys at this level because you don't need to derive further children. You use the child keys at this level for their basic private keys and public keys.
Derivation Paths
What derivation paths do bitcoin wallets use?
Here are the most common derivation paths used by bitcoin wallets.
BIP 32: m/0'/0/0(deprecated)
This is the original derivation path specification from BIP 32.
It uses the first child for accounts, and the next child below for separating external (receiving) and internal (change) addresses. The children of these are used for their actual private keys and public keys to create addresses.
This is a simple derivation path, but it doesn't allow for the option of creating alternative derivation path schemes.
BIP 44 builds upon the original BIP 32 scheme to include a purpose (which is like a version number to identify the upcoming scheme), as well as a coin type so that the same seed can be used to generate keys for different cryptocurrencies.
The first level of 44' indicates that the wallet uses 1addresses (P2PKH).
BIP 44 Extended Key Addresses
The address for an extended key in the BIP 44 derivation path scheme starts with a xprv or xpub.
The first level of 86' indicates that the wallet uses bc1paddresses (P2TR).
The BIP 86 specification is used to create key path spend-only P2TR outputs. Therefore it does not include any script path spend conditions (which means the merkle root is always empty).
BIP 86 Extended Key Addresses
The BIP 86 derivation path scheme does not actually specify a unique address format for extended keys. So the extended keys look the same as those used in BIP 44 (i.e. they start with a xprv or xpub).
Here are a couple of quotes that explain why BIP 86 extended keys do not have their own unique prefix:
There is no ypub/zpub similar thing for Taproot. The recommendation is to use xpriv/xpub along with some extra information indicating that the script to create is Taproot, (e.g. with a tr() descriptor).
This is because it is a layer violation to have the extended keypair indicate the script type to create. The keys should not and do not care about what scripts to create. Additionally, xprv and xpub are not supposed to indicate legacy addresses - they are for BIP 32 extended keys which are script agnostic. To use them to indicate legacy addresses is incorrect.
As the xpub standard had become interpreted as P2PKH only (rather than an address-agnostic way of describing public keys), something other than xpubs were needed. This is why some people adopted ypub/zpub for this purpose.
I believe this is confusing, as it is unclear now what an xpub means, and it is not scalable: we can't keep inventing new xpub-like formats for all types of addresses that may be invented. Especially with the introduction of multisig and more complex constructions, which simply don't fit into a single xpub-like thing (because you'll need to combine multiple of them).
For this reason, Bitcoin Core is using (and further developing) an approach called Output Descriptors. These are strings that specify exactly and unambiguously what scripts/addresses are desired, based on the involved public keys.
The gap limit refers to how many unused addresses a wallet will scan through before it stops looking for a balance at further addresses.
The standard gap limit is 20.
Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain.
So when recovering an HD wallet from a seed, the wallet will start by checking for a balance on the first 20 addresses. If no balance is found at any of these addresses, the wallet will stop checking further addresses and assume that the wallet has not received any payments.
For example, if you generated your own mnemonic seed and decided to receive your first payment at an address sitting at the index m/44'/0'/0'/0/20, if you import this seed into a different wallet it will likely display a balance of zero.
This gap limit applies to all addresses in the wallet too. So if you receive a payment to the address at m/44'/0'/0'/0/5 (which is fine), but then decide to receive your next payment to an address at m/44'/0'/0'/0/26 (a gap of 21), that second payment will not get picked up if you decide to import your seed into a different wallet later on.
So basically, you should avoid leaving a gap of 20 addresses between payments.
Your coins will not be "lost" if you exceed the gap limit. It's just that they will not be visible if you import your seed into a new wallet. So you would need to adjust the settings in the wallet to increase the gap limit, or recover the keys and addresses using a custom tool.
The gap limit isn't something to worry about as a typical bitcoin user. A good wallet will warn you before you create a gap of over 20 unused addresses.
Tips
Some general tips for working with derivation paths:
Store the derivation path alongside your seed phrase. This will be helpful if you need to recover your coins using a different wallet at a later date. It's not essential, but it might save you from a fright if you end up restoring your wallet and find that there are no coins in it, as the wallet you're now using may be using a different derivation path by default.
Stick with a standard derivation path. When creating a wallet, it's best to stick with one of the default derivation paths on offer. You may have the option to choose a custom one, but if you use a custom derivation path and forget it, you will have some difficulty recovering your coins later on. It does little to improve security, and it's not worth the headache it will inevitably cause.
Don't worry if you don't know the derivation path for your current wallet. There are only a handful of standard derivation paths in common usage, so just try the most common ones when recovering your wallet later on (should you need to). The worst part will be the initial sinking feeling that you've lost your coins, but all you need to do is try a different derivation path to get your addresses back. A good wallet will allow you to use different derivation paths for your seed (e.g. Sparrow, Electrum). See walletsrecovery.org for a list of the derivation paths used by different wallets.
Be aware of the different derivation path notations. Most bitcoin wallets just use the first 3 levels to identify the different derivation paths (e.g. m/44'/0'/0') and calculate the addresses from there. However, when using some tools (like the one on this site), to get to the actual keys and addresses in the wallet you need to specify the full derivation path (e.g. m/44'/0'/0'/0/0). So if you're not getting the right results, check the notation.
Never enter your seed phrase into a website. As always, you should never enter your seed phrase into a website. The tool on this website is for educational and development purposes only. If you need to work on recovering a wallet using different derivation paths, use trustworthy software on your local computer (or use your own code).
Code
Here are some code snippets to show you how you can create different derivation paths from a seed.
I've used existing libraries to help keep the code simple.