Advanced Key Derivation Paths: BIP-44, BIP-49, BIP-84, BIP-86 and How to Read Any HD Path

A derivation path like m/84'/0'/0'/0/0 is a complete coordinate that tells your wallet which keys to derive from your seed. Each segment encodes a specific design choice (what BIP standard, which blockchain, which user account), and getting one segment wrong is the difference between seeing your balance and seeing an empty wallet. This guide walks through every segment, the four standard purpose codes (BIP-44, BIP-49, BIP-84, BIP-86), the SLIP-44 coin-type registry, custom paths, and how to recover when a path mismatch leaves your funds invisible.

For the underlying mechanism of how HD wallets work, see our HD wallet derivation explainer. This article picks up where that one ends.

What is a derivation path and why does it matter operationally?

A derivation path is a string of slash-separated indices that names a single position in the BIP-32 tree of keys derived from your seed phrase. Wallets use the path to find the specific private key for an address, and two wallets restoring the same seed phrase will only see the same balance if they look at the same path.

Operationally, paths matter because the same seed phrase generates entirely different addresses at different paths. A Bitcoin native-SegWit wallet uses m/84'/0'/0'/0/0 and produces an address starting with bc1q; a Bitcoin legacy wallet uses m/44'/0'/0'/0/0 and produces an address starting with 1. Both addresses derive from the same 24 words. Both hold separate balances. A user who sends Bitcoin to bc1q... and then restores the seed into a wallet that defaults to m/44'/0'/0'/0/0 will see zero balance, even though the funds still exist on the blockchain at the SegWit address.

The path is also the unit of compatibility across applications. When you "import a wallet" from one app to another, the import only succeeds if both apps support the same path conventions, or if you can manually specify the original path in the new app's advanced settings.

How do you read the BIP-44 path syntax segment by segment?

The standard HD wallet path follows the BIP-44 layout: m / purpose' / coin_type' / account' / change / index. Each segment is a number, the apostrophe denotes hardened derivation, and reading left to right walks deeper into the BIP-32 tree. The five elements after the master node correspond to specific design choices, and a wallet can only find your balance if it derives keys at exactly the position your funds were sent to.

Take m/44'/60'/0'/0/0 as a worked example, which is the default first Ethereum address in most wallets:

• m: the master node, derived directly from the seed phrase through BIP-32.

• 44': purpose code 44 (hardened), meaning "this wallet follows BIP-44 conventions" (source: BIP-44 Specification).

• 60': coin type 60 (hardened), the SLIP-44 identifier for Ethereum.

• 0': account 0 (hardened), the first account. Different accounts use different indices.

• 0: change 0 (non-hardened), meaning the external (receive) chain. The value 1 is reserved for the internal (change) chain.

• 0: index 0 (non-hardened), the first address in this chain.

The first three segments use hardened derivation because compromise at those levels would expose every address in the wallet. The last two segments use non-hardened derivation so a watch-only application can be given the account's extended public key (xpub) and use it to monitor every receiving address, without ever holding any private key. This tradeoff is why every wallet displays receiving addresses freely but treats the parent extended key as more sensitive.

For the underlying derivation mechanism (HMAC-SHA512, the chain code, the hardened-vs-non-hardened cryptography), see the BIP-32 Specification.

BIP-49, BIP-84, BIP-86: what's the difference between purpose codes?

The purpose segment (the first number after m) tells the wallet which BIP convention it should follow when interpreting the rest of the path and deriving the final address. For Bitcoin alone, four standard purpose codes exist: 44 for legacy addresses, 49 for P2SH-wrapped SegWit, 84 for native SegWit, and 86 for Taproot. The same seed phrase, run through each of these purposes, produces four completely different sets of Bitcoin addresses.

Many modern Bitcoin wallets (Trezor Suite, Sparrow, Bitcoin Core) automatically scan all four purpose codes when restoring a seed, so the user does not have to know which one their previous wallet used. Some wallets, particularly mobile apps, default to a single purpose and require manual configuration to see balances under other purposes.

The same logic applies to non-Bitcoin chains, but most chains use purpose 44 by convention and differentiate via the coin type rather than the purpose. The exceptions are chains that have introduced their own purpose codes for specific account models (notably some Cosmos-ecosystem chains).

Cross-chain coin types: how SLIP-44 assigns numbers

The coin type segment (second number, hardened) tells the wallet which blockchain the path points at. The registry is SLIP-44, maintained by SatoshiLabs, and it assigns each chain a unique integer. The same seed phrase derives entirely different address trees on different chains by swapping the coin type alone.

The table below lists 20 of the most commonly seen coin types. The full registry contains hundreds.

EVM chains in practice share Ethereum's coin type 60 because their address format and private-key derivation are identical to Ethereum. MetaMask and other multi-EVM wallets use m/44'/60'/0'/0/x for every EVM chain (Polygon, Arbitrum, Optimism, Base, BSC). The chain ID lives at the transaction layer, not the derivation layer.

When a wallet needs to support a chain not in the standard SLIP-44 list, it either picks an unused number and proposes it for registration, or it uses a custom path entirely.

When and how should you use a custom derivation path?

A custom derivation path is any path outside the standard BIP-44/49/84/86 conventions, manually entered by the user in the wallet's advanced settings. Three legitimate use cases justify a custom path: importing a wallet from an application that used non-standard paths, accessing addresses your standard wallet didn't auto-discover, and the rare paranoid setup where a user wants their wallet to use obscured paths as an additional layer of obscurity.

The most common case is import. A user creates a wallet in Application A, which (for historical reasons) uses m/44'/0'/0'/x for its receive chain instead of the standard m/44'/0'/0'/0/x. Years later, they restore the seed into Application B, which defaults to the standard layout. The wallet shows empty. Entering the custom path in B's advanced settings recovers the funds.

To enter a custom path:

• Ledger Live: open the account settings, switch to "Advanced", and enter the path string. Ledger Live supports paths for many coins beyond its default scan (source: Ledger Support — Unusual Derivation Path).

• Trezor Suite: use the "Custom backend" or developer-mode features for non-standard paths; most users only need the standard purposes (source: Trezor BIP-32 Guide).

• Sparrow Wallet: when creating or importing a wallet, the path field is editable directly.

• Custom command-line tools: Bitcoin Core's bitcoin-cli, Electrum's --derivation flag, and similar utilities let you specify any path.

Always pair a custom path with a written record of exactly what path you used. If the seed is the master backup, the path is the second piece of information required to find your funds. Without both, a future restoration may produce an "empty" wallet that is not actually empty. Our hardware wallets and hardware wallet setup guides cover wallet selection and initialization for users who anticipate working with custom paths.

For users combining custom paths with a BIP-39 passphrase, the combined complexity multiplies; a single missing detail across either dimension produces an inaccessible wallet.

Account separation: how account' lets one seed serve multiple wallets

The third segment in a BIP-44 path is the account index, and changing it produces a separate sub-wallet from the same seed. The path m/44'/0'/0'/0/x is "account 0"; the path m/44'/0'/1'/0/x is "account 1". The two accounts share no addresses and no balances, but both restore from the same seed phrase.

Account separation supports several real workflows:

• Work versus personal: account 0 for personal Bitcoin, account 1 for work-related Bitcoin. The accountant only sees account 1's xpub; personal balances stay outside their view.

• Tax-year segregation: a new account per tax year keeps long-term holdings cleanly separated from short-term trades for accounting purposes.

• Per-purpose sub-wallets: one account for cold storage, another for hot operational spending, all on one seed and one hardware wallet.

The tradeoff: most wallet UIs default to showing only account 0, so additional accounts may require enabling "advanced" or "multi-account" mode. Coldcard, Trezor Suite, and Bitcoin Core support arbitrary account indices; Ledger Live does too, but typically through its account-creation flow rather than as raw path entry. The private keys for each account are derived independently, so the security model holds: a compromise of account 0's extended key does not expose account 1.

For users who want hard separation rather than soft segregation, a second seed phrase or a BIP-39 passphrase variation is stronger than account separation alone. Account separation is a UI organization tool, not a primary security boundary.

Troubleshooting wrong-path symptoms

The single most common symptom of a derivation path issue is "I restored my seed and the wallet shows empty, but I know I had funds." This is almost never lost funds; it is almost always a path mismatch. Five diagnostic steps recover the funds in nearly every case.

Step 1: identify what the original wallet was. Different wallets default to different paths. Bitcoin Core uses BIP-84 by default; Electrum used BIP-44 historically and now offers BIP-84; MetaMask uses BIP-44 with coin type 60 for all EVM chains; Phantom uses Solana's m/44'/501'/x'/0' shape.

Step 2: identify what address types you had. A Bitcoin address starting with 1 is legacy (BIP-44); starting with 3 is P2SH-wrapped SegWit (BIP-49); starting with bc1q is native SegWit (BIP-84); starting with bc1p is Taproot (BIP-86). Match the address to the BIP.

Step 3: enter the matching path in the new wallet's advanced settings. If you had bc1q... addresses, enter m/84'/0'/0'/0/0. If you had 1... addresses, enter m/44'/0'/0'/0/0. Most modern wallets either scan all paths automatically or accept manual entry.

Step 4: check the gap limit. If you generated more than 20 unused addresses in sequence, the wallet may stop scanning before reaching your funds. Increase the gap limit setting (most wallets allow this) and rescan.

Step 5: try BIP-39 passphrase variations. If you had an optional passphrase enabled on the original wallet, the new wallet must also have the exact passphrase, or it shows the no-passphrase wallet (which is also empty for that user).

From Blofin's support inbox, derivation-path mismatch is the dominant cause of "missing funds" reports during self-custody restoration. Three patterns recur: restoring a SegWit wallet into a legacy-default mobile app, restoring a Trezor Taproot wallet into a wallet that hasn't enabled BIP-86 support yet, and entering a custom path one segment off from the original (a stray apostrophe, a wrong account index). Each is recoverable when the user works through the five steps above. The wallet recovery process reference covers the broader recovery workflow.

Frequently asked questions

What does the apostrophe (') mean in a derivation path?

The apostrophe marks a hardened derivation step. A hardened step requires the parent private key to compute the child; a non-hardened step can compute the child public key from just the parent extended public key. Hardened steps protect against an attacker who has the parent xpub and one child private key recovering the parent private key. BIP-44 hardens the first three segments (purpose, coin type, account) because compromise at those levels would expose every address under them.

Can I switch my wallet from BIP-44 to BIP-84 to get lower fees?

Yes, but switching is a one-way operation in practice. Your existing legacy (BIP-44) addresses keep their balances; the new SegWit (BIP-84) addresses are a separate set, derived from the same seed but at a different path. To move funds to lower-fee SegWit, you send transactions from the legacy addresses to addresses at the new path. The old addresses still exist as long as you keep the seed phrase. Many users keep both sets active as they migrate over time.

Why does Solana use a different path shape than Bitcoin?

Solana's wallet conventions standardized after the BIP-44 community had already adopted the m/purpose'/coin'/account'/change/index shape, but Solana's account model treats each address as a single-key entity rather than a tree of receive and change addresses. Solana wallets therefore use m/44'/501'/0'/0' (four hardened segments, no change/index pair). Polkadot adopted a similar pattern with m/44'/354'/0'/0'/0'. The differences reflect ecosystem-specific design choices, not departures from BIP-44 in principle.

How do I find the derivation path my old wallet was using?

Check the wallet's documentation or settings. Most wallets document their default path in their support pages. If the wallet is no longer available, the address format itself reveals the BIP purpose: 1... means BIP-44, 3... means BIP-49, bc1q... means BIP-84, bc1p... means BIP-86 for Bitcoin. For EVM chains, almost all wallets use m/44'/60'/0'/0/x. For chains with their own conventions, search the wallet's name plus "derivation path" to find their published default.

Is it safe to use a custom (non-standard) derivation path?

Yes, but you take on the responsibility of remembering the exact path. The cryptographic security is identical at any path; the practical risk is forgetting which path you used. A custom path that the user records carefully (alongside the seed and any passphrase) is as recoverable as a standard path. A custom path that the user forgets is effectively lost funds, because no wallet will auto-discover it. Recommend custom paths only when there is a specific operational reason and a clear backup plan for the path string.

Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the BIP-32, BIP-44, BIP-49, BIP-84, and BIP-86 specifications, the SLIP-44 coin type registry (SatoshiLabs), Trezor advanced derivation documentation, and Ledger Live custom-path documentation. All facts independently verified against cited documentation current as of May 2026.

This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.