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
mis the master node derived from the seed.purpose'is44'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.changeis0for receive addresses,1for change addresses (a
UTXO-era distinction).
address_indexis 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
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/0for legacy P2PKH,m/49'/0'/0'/0/0for
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.