Skip to content
Financial Context Wiki

Wallet Derivation Paths: Standards, Discovery, and Recovery

Learn how wallet derivation paths select deterministic child keys, how hardened levels and account conventions differ, and how to verify paths during recovery.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A wallet derivation path is an ordered sequence of child indices that tells a deterministic key-derivation algorithm which node to select from a key tree. In common BIP-32 notation, m/84'/0'/0'/0/7 starts at the master private node m and traverses five children. The apostrophe marks a hardened BIP-32 child. A path is routing metadata: it is not a private key, does not encrypt a seed, does not itself identify a blockchain balance, and cannot recover anything without the correct root material and derivation algorithm.

For BIP-44-style wallets, the template is m / purpose' / coin_type' / account' / change / address_index. The levels have agreed meanings, not arbitrary labels. purpose selects a wallet convention, coin_type separates registered asset namespaces, account separates logical accounts, change normally distinguishes external receive addresses (0) from internal change addresses (1), and address_index selects one leaf. BIP-44 hardens the first three levels and leaves the last two non-hardened so an account extended public key can derive receive and change addresses without holding private keys.

The same mnemonic can lead to many valid but unrelated address sets. For Bitcoin, common single-key paths include m/44'/0'/account'/change/index for P2PKH, m/49'/0'/account'/change/index for P2WPKH nested in P2SH, m/84'/0'/account'/change/index for native SegWit P2WPKH, and m/86'/0'/account'/change/index for single-key Taproot P2TR. A wallet must also know the output or script construction; a path alone is not a complete Bitcoin wallet policy.

Other ecosystems reuse parts of this notation without guaranteeing identical semantics. Ether is registered as BIP-44 coin type 60, and m/44'/60'/0'/0/index is a common externally owned account convention, but wallet implementations have used multiple account layouts. The same EVM key can produce the same account address on several EVM networks even though balances and transaction histories are chain-specific. Ethereum validator BLS keys use ERC-2333 and ERC-2334 rather than BIP-32; their m/12381/3600/account/use path has no apostrophes and is not interoperable with a BIP-32 tree. Recovery therefore requires the exact implementation, curve, seed or passphrase, path convention, network, and address construction, not a plausible-looking string.

How to identify and verify a derivation path

1. Establish the root material and derivation algorithm

Inventory the mnemonic format, wordlist, optional passphrase, raw seed or extended key, and the software or hardware implementation that created the wallet. BIP-39 converts 128 to 256 bits of entropy into a mnemonic and derives a 512-bit seed from that mnemonic plus the exact passphrase; every passphrase produces a syntactically valid but different seed. BIP-32 then derives secp256k1 extended keys from a seed. Other wallet families may use different mnemonic schemes, curves, key-derivation functions, or master-key rules, so matching words do not prove a matching root.

2. Identify the standard, network, and key role

Determine whether the target is a Bitcoin payment key, an EVM externally owned account, a validator key, a multisig signer, a contract administrator, or another authority. Record the chain and network, the applicable standard and version, key curve, output or address type, and wallet application. A SLIP-0044 coin-type registration allocates a namespace; it does not prove that every wallet for that asset follows BIP-44, endorse a project, or prevent another chain from deriving the same key elsewhere.

3. Parse every path component exactly

Treat / as a parent-child boundary and preserve every index, depth, and hardening marker. Under BIP-32, normal children use indices 0 through 2^31 - 1; hardened children use 2^31 through 2^32 - 1, commonly written with ', h, or H. Thus 7' encodes child number 2^31 + 7, not ordinary child 7. Confirm how an import interface represents the root, whether it accepts a full path or a relative suffix, and whether an exported extended key already sits below part of that path.

4. Bind the path to address or output semantics

For BIP-44-family Bitcoin wallets, confirm the purpose, coin_type, account, change, and address_index, then independently confirm the intended script type and network. BIP-49, BIP-84, and BIP-86 deliberately use different purpose values so incompatible output types do not silently appear in one account. For multisig or descriptor wallets, preserve each key origin, master fingerprint, derivation suffix, threshold, key order, script construction, and checksum; one path cannot reconstruct the complete policy.

5. Reproduce account and address discovery

Do not infer loss from one empty default account. BIP-44 discovery checks accounts in order and scans the external chain, using an address gap limit of 20 consecutive unused addresses. Wallets that created addresses beyond that gap, used internal branches unusually, skipped accounts, or applied a proprietary layout may not be found by a default scan. Search only with trusted watch-only data or offline derivation, set explicit bounds, document every branch searched, and avoid uploading a mnemonic or extended private key to a website.

6. Verify identity before relying on a balance

Compare the master fingerprint, account-level extended public key where appropriate, full origin path, and several previously recorded receive and change addresses. For Bitcoin, derive the expected output scripts or descriptor and query the correct network for transaction history, including spent outputs. For account-based chains, verify the exact chainId, address, token contracts, and historical activity. An empty balance is weak evidence: the address may be wrong, the network or index may differ, or the assets may already have moved.

7. Recover or migrate through a controlled workflow

Use verified, compatible software on a trusted environment; prefer importing a watch-only descriptor or account public key for discovery before exposing signing material. Test signing and recovery with an isolated account or small transaction, then reconcile the derived addresses, on-chain history, output ownership, fees, and final state. If secrets were entered into an untrusted recovery tool, treat them as compromised and migrate all assets, contract roles, approvals, validator duties, and recovery authorities to a fresh root rather than continuing to use the recovered wallet.

Worked examples

Parsing a hardened Bitcoin path

Consider m/84'/0'/2'/1/17. The semantic fields are native SegWit purpose 84', Bitcoin coin type 0', account 2', internal or change branch 1, and address index 17. Because BIP-32 hardened indices add 2^31 = 2,147,483,648, their serialized child numbers are 84' = 2,147,483,732, 0' = 2,147,483,648, and 2' = 2,147,483,650. The final two indices remain ordinary 1 and 17; dropping one apostrophe selects a different subtree rather than an equivalent spelling.

A discovery gap that hides a used address

Suppose the external branch has used addresses at indices 0 and 5, then the wallet scans indices 6 through 25 and finds 20 consecutive unused addresses. Under BIP-44’s gap rule, discovery stops at 25. A used address at index 26 is therefore missed because it lies beyond the stopping condition. Expanding the scan with a documented bound can find it, but the root cause is a source wallet that created an address beyond the standard gap without activity in between.

A recovery record is uncertain among 4 Bitcoin purpose families (44', 49', 84', and 86'), 3 accounts, 2 branches, and the first 20 indices. The initial search contains 4 × 3 × 2 × 20 = 480 leaf candidates. Finding one familiar address identifies a candidate path but not necessarily the complete wallet: the reviewer still checks change, later indices, other accounts, descriptor details, and transaction history. Explicit dimensions make recovery reproducible and prevent an unbounded guess-and-check exercise.

Why an account xpub is not ordinary public data

For a non-hardened BIP-32 child, the private-scalar relationship is child = parent + tweak (mod n). In a toy modulus of 101, if the derivation data exposed by an account extended public key determines tweak = 37 and a corresponding child private scalar leaks as 12, then parent = 12 - 37 mod 101 = 76. Real BIP-32 uses the secp256k1 group order and HMAC-derived values, but the algebraic consequence is the same: a parent xpub plus one descendant non-hardened private key can reveal the parent extended private key and its subtree. Hardened account boundaries are designed to contain that failure.

Risks and review failures

  • Wrong mnemonic or passphrase: one word, word order, normalization rule, or passphrase difference produces another root that may look valid.
  • Wrong derivation scheme: applying BIP-32 to a wallet that used another mnemonic, curve, KDF, or master-key algorithm derives unrelated keys.
  • Wrong network or coin type: the correct root under another namespace can show plausible addresses while the intended chain remains unsearched.
  • Wrong purpose or script: confusing 44', 49', 84', or 86' can omit the funded Bitcoin output family.
  • Missing hardening marker: 7, 7', 7h, and 7H may be parsed differently or rejected, and hardened and normal children are not interchangeable.
  • Wrong account index: checking only account 0' can miss funds or authority under later logical accounts.
  • External/change confusion: scanning only branch 0 can miss change outputs on branch 1 or a wallet-specific branch layout.
  • Wrong address index: a familiar first address does not prove that later indices, skipped indices, or imported addresses were covered.
  • Discovery-gap failure: 20 consecutive unused external addresses can stop a standard BIP-44 scan before a nonconforming later use.
  • Skipped-account failure: sequential account discovery can stop before an account created after an unused predecessor.
  • Incomplete Bitcoin policy: paths without descriptors, scripts, thresholds, key order, fingerprints, or checksums may not recreate funded outputs.
  • Wallet-specific convention: applications can use legacy, proprietary, or migration layouts that a generic recovery tool does not enumerate.
  • Extended-public-key privacy leak: an xpub can reveal an address cluster, transaction history, balances, and future non-hardened descendants.
  • Extended-private-key overexposure: importing an xprv can expose an entire subtree rather than the one leaf needed for a transaction.
  • BIP-32 parent compromise: a parent xpub combined with a corresponding non-hardened child private key can reveal the parent private subtree.
  • Address-format false confidence: a syntactically valid address does not prove the intended seed, path, network, script, or ownership.
  • Same-address chain confusion: one EVM key can map to the same address across networks while balances, nonces, tokens, and risks differ.
  • Malicious recovery software: a website, extension, screen-sharing helper, clipboard, logger, or counterfeit device can capture the root secret.
  • Import-versus-sweep error: importing a key keeps the old authority active; sweeping or migrating creates a transaction and needs fee and destination review.
  • Incomplete recovery: finding one balance without testing signatures, change, token contracts, roles, approvals, validator keys, and backups can leave assets hidden or exposed.

Common misconceptions

Is the derivation path a password or secret?

No. A path normally describes public structure and should be preserved as recovery metadata. It does not replace the mnemonic, passphrase, seed, private key, or wallet policy. Publishing a path may reveal organizational information, but possession of the path alone does not confer signing authority.

Does the same mnemonic always restore the same wallet automatically?

No. The result also depends on the mnemonic scheme, exact passphrase, seed processing, derivation algorithm, path, curve, network, and address or script construction. Wallet software may choose different defaults even when it accepts the same words.

Does coin type prevent a key from being used on another chain?

No. Coin type is a derivation namespace and compatibility convention, not a protocol permission. Software can derive or reuse a key elsewhere, and EVM networks commonly expose the same account address for the same private key.

Does an empty recovered account prove the assets are gone?

No. It proves only that the particular addresses and network queried currently show no detected balance. Wrong paths, accounts, branches, script types, discovery limits, token indexing, or network selection can all hide the intended history.

Can a recovery tool safely try every possible path?

No. The search space can be large, wallet conventions are not fully universal, and exposing a root secret to an untrusted tool is itself a loss event. Use provenance, recorded fingerprints and addresses, bounded offline discovery, and verified software to narrow the search.

Sources

Navigation

Search the wiki...