BIP-44 (Multi-Account Hierarchy)

What Is BIP-44?

BIP-44 (Bitcoin Improvement Proposal 44) is a standard that defines how hierarchical deterministic wallets organize their key trees. Published in April 2014 by Marek Palatinus (Slush) and Pavol Rusnak of SatoshiLabs, BIP-44 builds on the BIP-32 key derivation mechanism and the BIP-43 purpose field convention to create a five-level path structure that every compliant wallet can follow.

Before BIP-44, HD wallets could structure their key trees however they wanted. BIP-32 provided the cryptographic mechanism for deriving child keys from parent keys, but it offered too many degrees of freedom. Two wallets using the same seed phrase could derive entirely different addresses, making wallet recovery unreliable. BIP-44 solved this by defining a single, deterministic path structure that the entire ecosystem adopted.

The standard is universally implemented across hardware wallets (Trezor, Ledger, Coldcard), software wallets (Electrum, BlueWallet, Exodus), and multi-coin wallets alike. For a deeper look at how Bitcoin address formats have evolved alongside these derivation standards, see our guide to Bitcoin address types.

How It Works

BIP-44 defines a five-level derivation path. Each level serves a specific organizational purpose:

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

The apostrophe (') denotes hardened derivation, a BIP-32 mechanism where the parent private key is required to derive child keys. This creates a security boundary: knowing an extended public key at one level cannot reveal sibling branches.

Path Levels Explained

Hardened vs. Non-Hardened Derivation

The first three levels (purpose, coin type, account) use hardened derivation. This means you need the private key to derive child keys at those levels. Compromising one account's extended public key cannot reveal keys for sibling accounts.

The last two levels (change and address_index) use non-hardened (public) derivation. This allows generating new receiving addresses from the extended public key alone, enabling watch-only wallets and payment servers to create addresses without access to private keys.

Registered Coin Types (SLIP-44)

Coin types are maintained in the SLIP-44 registry managed by SatoshiLabs. Each cryptocurrency receives a unique index to prevent address collisions across chains:

New coin types are added to the registry only when a wallet implementing BIP-44 for that coin exists. The registry now includes hundreds of entries.

The Gap Limit

BIP-44 defines a gap limit of 20 consecutive unused addresses. During wallet recovery, the scanning algorithm:

1. Derives addresses sequentially starting from index 0 on the external chain
2. Checks each address for transaction history
3. Stops scanning if 20 consecutive addresses have no transactions
4. Moves to the next account and repeats. If account n has no transactions, stops account discovery entirely

This algorithm ensures deterministic recovery: any compliant wallet will discover all used accounts and addresses without needing metadata beyond the seed. Wallets should warn users when generating addresses beyond the gap limit, as those addresses would be invisible to other wallets during recovery.

Purpose Values and Address Types

BIP-44 originally defined paths for legacy P2PKH addresses. As Bitcoin introduced new address formats, the community adopted the same five-level structure with different purpose values:

Using separate purpose values means a wallet either fully recognizes a given account type or ignores it completely. This prevents silent failures where a wallet that does not support SegWit would miss UTXOs stored in SegWit addresses. For technical details on how Taproot and Schnorr signatures extend this system, see our Taproot deep dive.

// Derivation paths for Bitcoin mainnet, account 0, first receiving address:
// BIP-44 (Legacy):       m/44'/0'/0'/0/0  → 1A1zP1...
// BIP-49 (Nested SegWit): m/49'/0'/0'/0/0  → 3J98t1...
// BIP-84 (Native SegWit): m/84'/0'/0'/0/0  → bc1qw5...
// BIP-86 (Taproot):       m/86'/0'/0'/0/0  → bc1pw5...

Use Cases

Multi-Coin Wallet Management

A single seed phrase can manage Bitcoin, Ethereum, Litecoin, and hundreds of other cryptocurrencies simultaneously. Each coin occupies an isolated subtree, so there is no risk of address reuse across chains. Hardware wallets like Trezor and Ledger rely on this structure to offer multi-coin support from one device.

Wallet Recovery and Portability

When a user imports their seed phrase into a new wallet, the wallet follows BIP-44's path structure and gap limit algorithm to rediscover all accounts and balances automatically. This portability is essential for self-custody: users are not locked into a single wallet vendor.

Watch-Only Wallets and Payment Servers

Because address_index and change use non-hardened derivation, a merchant can export an extended public key (xpub) at the account level and give it to a payment server. The server generates fresh receiving addresses for each customer without ever having access to private keys. This pattern is widely used in Bitcoin commerce.

Account Segregation

The account level lets users separate funds for different purposes (savings, spending, business) within a single wallet. Each account is cryptographically isolated through hardened derivation, so sharing one account's xpub does not expose other accounts. For a comparison of how different wallet SDKs implement these patterns, see our wallet SDK comparison.

Why It Matters

BIP-44 is the reason a user can write down 24 words, store them securely, and know that any compliant wallet can recover their funds years later. Without this standard, key management would require users to track not just their seed but also the exact derivation paths their wallet used. Losing that metadata would mean losing access to funds even with the correct seed.

For wallet developers building on Bitcoin layer-2 solutions like Spark, BIP-44 compliance ensures that the underlying key infrastructure remains portable and interoperable. Users can manage their on-chain keys through standard BIP-44 paths while interacting with off-chain protocols through the same root seed, maintaining a unified self-custodial experience.

Risks and Considerations

Non-Standard Path Recovery

Some wallets historically used non-standard derivation paths. For example, certain Ethereum wallets omitted the change level entirely, using m/44'/60'/0' instead of the standard m/44'/60'/0'/0/0. When a user imports their seed into a different wallet that follows the standard path, the wallet derives different addresses and shows a zero balance. The funds are not lost but are invisible without the correct path.

Gap Limit Pitfalls

If a user generates receiving addresses beyond the 20-address gap limit (for example, creating address index 25 without using addresses 5 through 24), those addresses will not be discovered during standard wallet recovery. Funds sent to those addresses remain on-chain but are invisible to the recovering wallet unless the user manually adjusts the gap limit.

Script Type Conflicts

Older wallets occasionally used the same derivation path for different script types. A wallet expecting P2PKH addresses at m/44'/0'/0' would produce different addresses than one expecting P2WPKH at the same path. The adoption of separate purpose values (BIP-49, BIP-84, BIP-86) resolved this for new wallets, but legacy compatibility issues persist for seeds created before these standards were widely adopted.

Passphrase Complexity

BIP-44 paths derive from the master seed, which itself derives from the mnemonic plus an optional passphrase. If a user sets a passphrase and forgets it, the wallet generates an entirely different key tree. All accounts appear empty because the master seed is different. The passphrase is not recoverable from the mnemonic alone.

Privacy Considerations

Sharing an xpub at the account level reveals all past and future addresses for that account. Anyone with the xpub can track the account's entire transaction history and balance. Users should treat xpubs with the same care as they would a read-only view of their bank account. For strategies on managing cold storage and watch-only setups securely, see our custody solutions comparison.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.