Keys, wallets & account abstraction

BIP-44

BIP-44 is the convention that gives BIP-32's abstract key tree a meaningful, standardized shape, so that different wallets agree on where each coin's addresses live. Without it, two wallets restoring the same seed could derive keys along different paths and seem to show different (empty) balances. BIP-44 fixes a five-level path so any compliant wallet finds the same accounts.

The path is m / purpose' / coin_type' / account' / change / address_index. The purpose level is hardened and pinned to 44' to mark the BIP-44 layout. The coin_type level (also hardened) selects the asset using the registered SLIP-0044 numbers — 0' for Bitcoin, 60' for Ethereum, and so on — which is how one seed cleanly separates many chains. The account level (hardened) lets a user keep distinct, isolated sub-wallets, like 'savings' and 'spending', under the same backup.

The final two levels are non-hardened so that a watch-only extended public key can scan ahead. The change level is 0 for external addresses you hand out to receive funds and 1 for internal 'change' addresses a wallet generates to receive the leftover of a UTXO spend. The address_index simply counts up, 0, 1, 2, …, giving a fresh address per payment. Wallets follow a 'gap limit' (commonly 20): they stop scanning for more addresses once they hit that many consecutive unused ones, which is why importing a seed into a different wallet can occasionally miss addresses placed far beyond the gap.

m / 44' / 60' / 0' / 0 / 5 → the 6th external Ethereum address of account 0

A standard BIP-44 path: purpose 44', coin 60' (Ethereum), account 0, external chain, index 5.

Ethereum wallets often diverge from strict BIP-44: many (including MetaMask) keep change at 0 and only increment the last index, so accounts appear at m/44'/60'/0'/0/0, m/44'/60'/0'/0/1, … rather than bumping the account' level. This historical quirk is a frequent cause of 'my balance is missing' when moving between wallets.

Also called
multi-account hierarchy多帳戶層級