Derivation path builder and explainer

Pick a wallet type, account and address number to get the exact BIP 32 derivation path, what each level means, the address type it produces, the extended key prefix wallets show and a matching output descriptor. Or paste any path to check its format and decode it.

Updated 2026-10-20 · 5 min read

Free, and runs entirely in your browser: nothing you type is sent anywhere.

How to use the derivation path builder

1. Choose the wallet type. The purpose level decides the address type: 44 for legacy, 49 for nested SegWit, 84 for native SegWit, 86 for Taproot, and 48, 87 or 45 for multisig.
2. Choose the network. Mainnet uses coin type 0'; testnet, signet and regtest share 1'.
3. Set the account, chain and address index. Account 0 is the first account. Chain 0 holds receiving addresses and chain 1 holds change. Indexes start at 0.
4. Pick the notation. 84' and 84h mean the same thing.

The result updates as you type, along with the account-level path, the extended key prefix and a descriptor template. The settings are kept in the page address, so you can share or bookmark a result. To decode a path from a wallet's settings or documentation, paste it into Explain a path. Derivation paths aren't secret, and nothing you enter leaves your browser.

Anatomy of a derivation path

A derivation path is a list of steps through the key tree of a BIP 32 wallet, starting at the master key m made from your seed phrase. BIP 43 made the first step a "purpose", and BIP 44 defined the five levels most single-key wallets still use:

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

Hardened steps: what the apostrophe means

Each BIP 32 key has 2^31 normal children (indexes 0 to 2,147,483,647) and 2^31 hardened children (indexes 2^31 and up). A hardened step is written with a marker, so 84' means index 84 + 2^31 = 2,147,483,732. The builder shows that raw number under each hardened step.

Hardening matters because, as BIP 32 explains, an extended public key plus any one non-hardened child private key reveals the parent private key. Hardening the purpose, coin type and account levels keeps a leak inside one account. The last two levels stay normal so an xpub can derive every address without private keys.

BIP 44 writes hardened steps with an apostrophe ('). The letter h avoids quoting problems on the command line, where ' is a quote character, and BIP 380 descriptors accept either. BIP 32 itself writes a subscript H, and some software accepts a capital H, but BIP 380 lists 0H as invalid. The parser accepts all three and tells you which ones descriptors allow.

Common derivation paths

On testnet and signet, swap coin type 0' for 1': m/84'/1'/0' gives tb1q addresses and a vpub. The first receiving address of a BIP 84 wallet is m/84'/0'/0'/0/0, and its first change address is m/84'/0'/0'/1/0. For the differences between the single-key standards, see BIP 44 vs 49 vs 84 vs 86.

Multisig paths: BIP 45, 48 and 87

Multisig wallets need every cosigner's key, so the path is only part of the setup.

• BIP 45 (2014) uses m/45'/cosigner_index/change/address_index for P2SH multisig. Cosigners are numbered by sorting their public keys, and each one creates addresses on its own branch.
• BIP 48 documents the m/48' scheme that many wallets already used. It adds a script type level after the account: 1' for P2SH-P2WSH and 2' for P2WSH, which it recommends as the default.
• BIP 87 drops the script type level and relies on a descriptor to say which script the keys go into, so m/87'/0'/0' works for any multisig script.

The multisig guide explains how the keys, the descriptor and the backups fit together.

xpub, ypub, zpub: extended key prefixes

The account key (for example m/84'/0'/0') is what wallets export as an extended public key. Its first four characters come from version bytes. BIP 32 defined xpub and tpub; BIP 49 added ypub and upub, and BIP 84 added zpub and vpub, so a wallet could tell which address type an exported key was for. The capital Ypub, Zpub, Upub and Vpub for multisig come from SLIP-132, a SatoshiLabs document that isn't a BIP. Taproot accounts (BIP 86) use a plain xpub.

The key inside is the same whatever the prefix. BIP 380 calls such version bytes "a layer violation", because key encoding shouldn't decide the script type. Output descriptors replace them: a descriptor always uses xpub or tpub and names the script explicitly.

Derivation paths and output descriptors

A descriptor such as wpkh([fingerprint/84'/0'/0']xpub.../<0;1>/*) records everything a wallet needs to find its coins: the script type (wpkh for P2WPKH), the master key fingerprint and path in square brackets (the key origin), the account xpub, and the remaining steps. <0;1> is the multipath notation from BIP 389: one descriptor that covers both the receiving (0) and change (1) chains, and * stands for every address index. The builder fills in the template for the path you choose. Read the output descriptors guide for the full syntax.

What the path checker validates

When you paste a path, the tool checks that:

• every step is a whole number, optionally followed by ', h or H;
• a hardened step is between 0 and 2,147,483,647 before its marker, and a normal step is below 2^31 (a larger raw number such as 2147483732 is read as its hardened form, 84');
• there are no empty steps, wildcards (*) or multipath steps, which belong in descriptors rather than single paths;
• the path is at most 255 levels deep, since an extended key stores its depth in one byte.

It then labels each level using the standard that the purpose points to, and warns where a step differs from it, such as an unhardened account or a coin type other than 0' or 1'. A mismatch like that usually means a wallet is looking in the wrong place: the derivation paths guide covers how to recover funds in that case.