Glossary

BIP-32 derivation path

A BIP-32 derivation path describes how a hierarchical deterministic wallet derives child keys from a single seed.

A BIP-32 derivation path is the slash-separated string a hierarchical

deterministic (HD) wallet uses to derive a specific child key from a

single seed. BIP-32 defined the derivation algorithm; BIP-44 layered a

multi-account, multi-coin convention on top, which is what most wallets

use today. Paths look like m/44'/60'/0'/0/0.

Anatomy of a path

Each segment is a non-negative integer, optionally suffixed with ' (or

h) to mark it as hardened. A hardened step uses an extended derivation

function that prevents a child public key from leaking the parent's

private key.

The conventional BIP-44 layout is:

m / purpose' / coin_type' / account' / change / address_index
  • m is the master node derived from the seed.
  • purpose' is 44' for BIP-44, 49' for BIP-49 (P2SH-wrapped segwit),

84' for BIP-84 (native segwit Bech32), and so on.

  • coin_type' identifies the chain. SLIP-44 assigns numbers: 0 for

Bitcoin, 60 for Ethereum, 501 for Solana, and many more.

  • account' is a hardened account index, starting at 0.
  • change is 0 for receive addresses, 1 for change addresses (a

UTXO-era distinction).

  • address_index is the leaf index, also starting at 0.

Default paths by ecosystem

Wallets generally pick a default path per chain. Three common ones:

  • Ethereum and EVM chains: m/44'/60'/0'/0/0. The same path produces

the same EVM key, so the address you get is the same on

ethereum, base,

arbitrum one, optimism,

polygon, bsc, and the other EVM

networks tx.taxi routes to. The 40-character hex

wallet address derived from that key is

reused across chains.

  • Solana: m/44'/501'/0'/0'. Solana wallets typically use four

hardened segments and no change / address_index distinction. The

derived key is an Ed25519 keypair; the address is the raw public key

encoded as base58. See solana.

  • Bitcoin: m/44'/0'/0'/0/0 for legacy P2PKH, m/49'/0'/0'/0/0 for

P2SH-wrapped segwit, and m/84'/0'/0'/0/0 for native segwit Bech32.

Each derives the same underlying secp256k1 key but the address encoding

differs by purpose. See bitcoin.

Other chains have their own conventions, with coin types from SLIP-44.

tron uses 195, ton uses 607, and so on.

Why the path matters when looking up an address

If you restore a seed in a wallet that uses a different default path than

the wallet that originally generated it, you will see a different

address, even though the seed is the same. Many "I lost my funds"

support cases come down to a mismatched derivation path.

When you paste a wallet address into tx.taxi

and land on the explorer page, you are looking at one specific leaf in

some HD tree. The path itself never appears on-chain; only the resulting

address does.

Common gotchas

  • Hardened steps are required at the top of the path. Skipping the

apostrophe changes the derivation completely.

  • Some EVM wallets historically used m/44'/60'/0'/0 (no final index) or

m/44'/60'/0'/i (no change segment). Both produce different

addresses than the BIP-44 default. Trezor and Ledger have historical

edge cases worth checking when migrating.

  • Solana wallets vary on whether the final segment is hardened. Always

match the originating wallet's exact path when restoring.

  • BIP-32 paths are capabilities, not secrets. Knowing a path does not

reveal a key; knowing the seed plus the path does.

Related