Bitcoin derivation paths: What they are and how to navigate them

If you’ve worked with self-custody bitcoin wallets, you may remember seeing some numbers and slashes that looked like: m/84’/0’/0’. This series of characters refers to a derivation path, also called a BIP32 path. It’s not uncommon to immediately brush it off as being too technical to understand.

However, derivation paths are not as complicated as they might seem. You don’t need a software engineering background—the basics are quite approachable for most intermediate-level bitcoin users, and understanding them can be valuable for managing keys and wallets with confidence.

What is a derivation path, and why do they matter?

As we covered in our recent article about wallet anatomy, a modern bitcoin wallet is constructed from entropy, which can be recorded as a set of words called a seed phrase. The seed phrase leads to a master private key, which can produce—and reproduce—an entire network of additional keys that are capable of building wallets and addresses. This architecture was introduced in 2012 via BIP32, to help bitcoin users control multiple wallets and addresses while only needing to secure one piece of information, rather than many separate private keys.

Specifically, BIP32 describes a method for using a bitcoin key to easily create many other bitcoin keys. Any of those keys could then use the same method to create even more keys. To draw an analogy, you can imagine a family tree—the master private key is like the common ancestor, and it can create child keys, which can create grandchild keys, which can create great grandchild keys, and so on.

If you wanted to navigate down the family tree from the common ancestor to a particular descendant, you’d need to know the lineage pathways that will lead you there. Similarly, if you want to derive a specific bitcoin key among the millions your master key is capable of producing, you’ll need the instructions of how to do so. These instructions are called the derivation path.

If you want to use a seed phrase to reproduce wallets and addresses—which is what allows you to check your balance and access your funds—you’ll also need to know the derivation paths involved. Fortunately, there is a standardized system of choosing paths, meaning that many bitcoin users can get by without memorizing, recording, or even knowing about their derivation paths.

However, not all wallet softwares use exactly the same defaults, which can cause problems when trying to recover bitcoin wallets across different platforms. This issue has led to the creation of websites like walletsrecovery.org, which helps keep track of the default derivation paths used by various wallets over the years.

Additionally, when someone uses a multisig wallet, there are multiple master private keys and multiple derivation paths coming together to create the wallet. This dynamic could cause extra confusion in a recovery scenario unless the paths are recorded. Therefore, multisig wallets have a wallet configuration file or wallet descriptor that contains all of the recovery information the wallet owner would need to locate their bitcoin in other software. At Unchained, we encourage clients to save their wallet configuration file immediately after building a vault.

How derivation paths work

A derivation path describes a chain of keys, beginning with the master key, and ending with the particular key that someone wishes to navigate to. As we will discuss in more detail below, the chain could be long (many keys on the route between) or short (few keys on the route between).

Chain code

To travel down the chain and get from one key to the next, something called chain code is needed. The chain code is combined with the prior key—called a parent—in order to find a subsequent key in the chain—called a child. If you’re interested in diving deeper into the technical specifics, you can find more information here.

If a key has chain code attached, it is called an extended key. When dealing with an extended key, it is implied that it will be used to produce further keys. One extended key can produce another extended key, and so on. Upon finally arriving at a key that will be used for sending or receiving bitcoin, the chain code is no longer useful, and you would have just a regular, plain key.

Derivation paths across private keys and public keys

It’s important to remember that bitcoin keys come in pairs: private and public. The private key component is sensitive and used for spending bitcoin. The public key component is less sensitive, and used to check balances or receive bitcoin. A private key can produce its corresponding public key, but a public key is unable to reverse-engineer its corresponding private key. 

When dealing with an extended key, the situation is the same, but with chain code. There is always an extended private key (or xprv for short) with a corresponding extended public key (or xpub for short). An xprv can produce an xpub, but not the other way around.

Using the family tree analogy, you can imagine that there are two sides of the tree in perfect parallel—the private key side and the public key side. At any point while operating on the private key side, you could produce a public key and continue to navigate down that side of the tree. However, you would be unable to transition from the public side back to the private side.

How to read a derivation path

Derivation paths appear as sections separated by “/” slashes, similar to how the location of a file on your computer might be displayed: “C:/user/desktop/folder1/folder2/file”. This provides another good analogy that can be helpful for understanding derivation paths.

The initial section of the path references the master key, which produces and controls all the keys derived from it. It will typically appear as an “m” for “master.” However, if several master keys are involved in an arrangement, such as in a multisig wallet, it can be helpful to indicate which master key a derivation path is referring to. Instead of an “m” the path might begin with the master fingerprint, which is 8 hexadecimal characters that reference a specific master key.

The next sections are called levels, and they each contain an index number. You can think of a level as an opportunity to choose another key to add to the chain, while the index number specifies the chosen option. Using the family tree analogy, you could imagine that each level is the next generation of children, and the index number points to a specific child of that generation among its many siblings.

Levels can be useful for organization, and the number of levels someone uses in a derivation path is customizable. Someone could use only one level (m/0) and stop there to find a key. Using the computer file analogy, this would be like pointing to a file on your desktop. Alternatively, someone could derive many keys across many levels (m/0/0/0/0/…/0/0) before stopping to arrive at a key that will be used for other practical purposes. This would be like pointing to a file within a folder, which is inside another folder, which is inside another folder, and so on. 

Standardized usage of levels

In 2014, a method of standardizing derivation paths across a wider range of applications was proposed in BIP44, which is still used to this day. BIP44 provides a framework of using five levels to meet the needs of most bitcoin wallets, and it’s also easily upgradable for future flexibility. Let’s examine each level and how it’s used. 

L₁: Purpose

The first level is called the purpose. The purpose is meant to provide more information about the context of the derivation path, such as the type of wallet being used, or how to interpret the subsequent levels. This is what allows for further upgrades, because someone could create a new purpose number that redefines the rest of the levels beyond the first.

Bitcoin users may run across various purpose numbers, which primarily reference different address types being used. Here are some of the most common:

• 44: This is the original default purpose, indicating BIP44 is being used. These days, it indicates a P2PKH address type for a legacy singlesig wallet.
• 45: This purpose indicates a P2SH address type for a legacy multisig wallet.
• 48: This purpose indicates a segwit multisig wallet. It redefines L₄ to designate a “script type” which would either be a “1” for P2SH-P2WSH nested segwit, or a “2” for P2WSH native segwit. The change and address indexes get pushed to L₅ and L₆.
• 49: This purpose indicates a P2SH-P2WPKH address type for a nested segwit singlesig wallet.
• 84: This purpose indicates a P2WPKH address type for a native segwit singlesig wallet.
• 86: This purpose indicates a P2TR address type for a Taproot wallet.

It’s worth reiterating that these purpose index numbers are merely suggestions and indicators within an optional system. Someone could build a native segwit singlesig wallet without using the number 84 in the first level of the derivation path. Similarly, someone could use the number 84 for a different type of wallet. However, such decisions would make a wallet less interoperable with other software. This remains true for all the BIP44 levels we’ll be covering in the following sections.

L₂: Coin type

Part of the motivation for BIP44 was to create a standardized system where one seed phrase and master private key could be used to control many different crypto tokens, simplifying custody for people interested in various experimental coins. Bitcoin is coin number 0, which is why bitcoin users will almost always see that number in their derivation path at the second level. 

For someone using bitcoin testnet (a system similar to bitcoin but with coins of no value, meant for developer testing and operational practice), the coin number is 1. Ethereum, for example, uses coin number 60, and if you’re interested you can find a full list of coin numbers here. You may notice the vast majority of altcoins which had numbers reserved for them have been abandoned and are now worthless.

L₃: Account

After the first two levels of information in a derivation path, it could be understood that someone is intending to utilize a specific type of bitcoin wallet. But what if someone wants to use their master private key to control multiple separate wallets of the same type? This is where the third level comes in handy, which serves as an organizational account number.

Typically, the number 0 will be used for the first wallet, and then the number will be incremented for each subsequent wallet. The account number determines the extended public key (xpub) that will be contributed towards building the wallet, as discussed in our earlier article covering wallet anatomy.

L₄: Change

By adhering to the guidelines of BIP44 and navigating through three levels of the derivation path, we’ve now arrived at an extended public key that can be used to build a wallet. One xpub is enough to build a singlesig wallet, while a multisig wallet will bring several xpubs together that were each produced from different master private keys. Given that a wallet is a collection of addresses, the next step is to navigate from the xpub to the plain public key children which will build the addresses.

The fourth level serves to indicate the purpose of the address being produced. If the address will be used to receive bitcoin from an external source (also called a deposit address), the number 0 will be used. Meanwhile, if the address will be used to receive bitcoin internally within the same wallet (also called a change address), the number 1 will be used. If you’d like to learn more about the circumstances in which someone might send bitcoin back to their own wallet and use a change address, check out our article covering the basics of UTXOs. 

To be clear, the change level of a derivation path (generally the level immediately after the xpub for the wallet) will always be either 0 or 1.

L₅: Address Index

The fifth and final level is the address index, which leads to the public key being used to build an address. Similar to the account index, it begins with 0 for the first address, and will be incremented for each subsequent address.

Let’s review a few simple examples. After deriving the xpub for a wallet, traveling two levels deeper using /0/0 will lead to the public key for the wallet’s first deposit address. Using /0/1 will lead to the second deposit address. Using /1/0 will lead to the first change address, and using /1/1 will lead to the second change address.

Understanding the apostrophe: hardened keys

You may have noticed that some index numbers within a derivation path are followed by an apostrophe, while others are not. This apostrophe notation is used to indicate that the key being derived is hardened. This aspect of derivation paths is a bit more technical, and may not be necessary to fully grasp as a basic wallet operator. Nevertheless, we will briefly touch on this topic for curious readers.

When hardened, a child public key can only be derived by someone with access to the parent xprv, not by someone who only has access to the xpub corresponding to the parent xprv. This is used as an additional nuanced security measure, which you can learn more about here. In the words of renowned bitcoin developer Pieter Wuille, “hardened derivation should be the default unless there is a good reason why you need to be able to generate public keys without access to the private key.”

Typically, you will notice that hardened keys are used up until the point of finding the xpub being used to build the wallet. In a derivation path following BIP44 guidelines, this means that the first, second, and third levels will be hardened and are shown with apostrophes. Past that point, someone might want to use that xpub to derive child public keys and build wallet addresses, without requiring access to any private keys. For this reason, the final two levels (change and address index) are usually unhardened.

Practical usage of derivation paths

Rounding out this article, let’s take a look at how derivation paths are commonly utilized when setting up a basic singlesig bitcoin wallet for self-custody.

The first step involves creating the master private key, which can be done safely with a hardware wallet, and backed up by physically recording a seed phrase. A hardware wallet is designed to keep the master private key—and all the private keys it can produce—protected from exposure. For security, the device doesn’t communicate directly with the internet. This also means it has no way of viewing the bitcoin blockchain to determine balance information. 

The next step is to apply a derivation path to the master key, for the purposes of calculating an xpub (for example, a common path would be m/84’/0’/0’). The xpub can then be exported to a laptop or phone, without exporting any private keys. 

Upon receiving the xpub, a wallet software program on a laptop or phone can independently use the xpub to continue the derivation path further, calculating additional child public keys and creating addresses (for example, [xpub]/0/0 could find the public key for the first deposit address, which from the master key would be m/84’/0’/0’/0/0). If the laptop or phone has an internet connection, it would be able to scan the bitcoin blockchain for any balances on the wallet addresses, and display them to the user. The balances would not be able to be transferred without having access to the private keys.

People familiar with securing a singlesig wallet using popular hardware (such as Trezor, Ledger, Coldcard, Jade, Bitbox, Passport) will remember using a corresponding wallet software on a computer or phone (such as Trezor Suite, Ledger Live, Sparrow Wallet, Blockstream Green, BitBoxApp, Envoy). The hardware wallet must share at least one xpub with the software companion to be functional. This may happen behind the scenes, to create a less technical experience for new users. Additionally, many of these wallet softwares allow the user to easily create multiple separate “accounts” for organizing bitcoin holdings. This is achieved by altering the derivation path and using a different xpub.

A multisig wallet is similar. Each participating master private key must contribute an xpub to the multisig platform. Those xpubs are then joined together, as discussed in our earlier article. At Unchained, you’ll notice that an xpub your hardware wallet contributes will be from a derivation path beginning with m/45’/… to prevent sharing information about any other singlesig wallets you might be using your device for. Unchained also allows you to increment your derivation path to use the same hardware wallets across different accounts, as we explain in our knowledge base guide. This reduces the amount of equipment you need to keep track of.

Avoid using uncommon paths

If a thief gets your seed phrase, they will use the common derivation paths to search for balances. They wouldn’t spend much effort on uncommon derivation paths, because of the sheer number of possible combinations. Theoretically, someone could use a derivation path with very deep levels and very large index numbers, that even a supercomputer couldn’t guess in any reasonable length of time.

Due to this fact, some people have suggested that uncommon derivation paths could be used as a method to hide funds within a singlesig wallet, and offer some degree of protection against theft. However, this is not recommended. It would amount to the same tradeoffs as using a BIP39 passphrase, but with less industry support and therefore a higher propensity for technical difficulties or mistakes.

Final thoughts

We hope you found this article about derivation paths helpful! Navigating the details of bitcoin custody involves a number of intricacies, which can cause individuals to be apprehensive of self-custody. People don’t know what they don’t know. 

This fact highlights the advantages of collaborative custody, where you are able to hold a controlling majority of keys to your bitcoin, but also have access to expert support that can help ensure you are doing things correctly and have the education you need. If this interests you, sign up for a free consultation call with Unchained to learn more!