BIP 44 Wallet Paths Explained: Purpose, Coin, Account and Address

This guide explains BIP 44 Multi-Account Hierarchy for Deterministic Wallets in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

The five path levels

The conventional form is m / 44 prime / coin_type prime / account prime / change / address_index. The first three levels use hardened derivation, while change and address indexes are public children. Each number has a role; dropping a hardening marker or changing one level produces a different branch.

Purpose and coin type

Purpose 44 identifies this hierarchy under BIP 43. Coin type separates asset subtrees and uses an external registry now maintained in SLIP 44. A registered number prevents accidental cross-asset reuse but does not verify that a wallet supports the asset correctly or that two networks share address semantics.

Account boundary

Accounts are hardened branches intended as separate user identities or organisational groups. The BIP expects sequential discovery and discourages creating a new account while the previous one has no history. Wallet interfaces may label accounts differently, so recovery records should preserve the numeric account index.

External and internal chains

Change value zero represents external receive addresses, while value one represents internal change. Wallets should not hand change addresses to outside payers. Misclassifying the branch can hide change during a partial restore or expose internal address management assumptions to an external system.

Address indexes and gap limit

Indexes advance from zero on each chain. Account discovery scans the external chain and stops after the address gap limit, specified as twenty consecutive unused addresses. Heavy pre-generation or manual address skipping can push funds beyond a default scan and create a false zero-balance recovery.

Modern script-type paths

BIP 44 originally describes its own purpose branch; later conventions use different purposes for nested SegWit, native SegWit or Taproot. The same seed can produce many valid wallets. Descriptors express scripts and key origins more directly than a seed phrase plus a guessed purpose number.

How specialists test it

Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.

Conclusion

BIP 44 gives deterministic wallets a predictable account tree, but it cannot identify itself from the seed. Reliable recovery pairs the mnemonic or root with exact path, script, account, change and discovery information.