Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

BIP-44 derivation paths

Each coin uses BIP-44 derivation path scheme. If the coin is UTXO-based the path should have all five parts, precisely as defined in BIP-32. If it is account-based we follow Stellar’s SEP-0005 - paths have only three parts 44'/c'/a'. Unfortunately, lot of exceptions occur due to compatibility reasons.

Keys are derived according to SLIP-10, which is a superset of the BIP-32 derivation algorithm, extended to work on other curves.

List of used derivation paths

coincurvepathpublic nodenote
Bitcoinsecp256k144'/c'/a'/y/iyes1
Ethereumsecp256k144'/c'/0'/0/ayes2
Ethereumsecp256k144'/c'/0'/ayes2
Ripplesecp256k144'/144'/a'/0/03
EOSsecp256k144'/194'/a'/0/03
Tronsecp256k144'/195'/a'/y/i
Cardanoed2551944'/1815'/a'/y/iyes4
Stellared2551944'/148'/a'
NEMed2551944'/43'/a'5
Moneroed2551944'/128'/a'

c stands for the SLIP-44 id of the currency, when multiple currencies are handled by the same code. a is an account number, y is change address indicator (must be 0 or 1), and i is address index.

Paths that do not conform to this table are allowed, but user needs to confirm a warning on Trezor.

Public nodes

Some currencies allow exporting a public node, which lets the client derive all non-hardened paths below it. In that case, the conforming path is equal to the hardened prefix.

I.e., for Bitcoin’s path 44'/c'/a'/y/i, the allowed public node path is 44'/c'/a'.

Trezor does not check if the path is followed by other non-hardened items (anyone can derive those anyway). This is beneficial for Ethereum and its MEW compatibility, which sends 44'/60'/0'/0 for getPublicKey.

Notes

  1. For Bitcoin and its derivatives it is a little bit more complicated. p is decided based on the following table:

    ptypeinput script type
    44legacySPENDADDRESS
    48legacy multisigSPENDMULTISIG
    49p2sh segwitSPENDP2SHWITNESS
    84native segwitSPENDWITNESS

    Other p are disallowed.

  2. We believe this should be 44'/c'/a', because Ethereum is account-based, rather than UTXO-based. Unfortunately, lot of Ethereum tools (MEW, Metamask) do not use such scheme and set a = 0 and then iterate the address index i. Therefore for compatibility reasons we use the same scheme. Also to support “Ledger Live” legacy paths we allow 44'/60'/0'/a paths.

  3. Similar to Ethereum this should be 44'/c'/a'. But for compatibility with other HW vendors we use 44'/c'/a'/0/0.

  4. Cardano has CIP-0003 algorithm that allows non-hardened derivation on ed25519.

  1. NEM’s path should be 44'/43'/a' as per SEP-0005, but we allow 44'/43'/a'/0'/0' as well for compatibility reasons with NanoWallet.

Sign message paths are validated in the same way as the sign tx paths are.

Allowed values

For UTXO-based currencies, account number a needs to be in the interval [0, 20] and address index i in the interval [0, 1 000 000].

For account-based currencies (i.e., those that do not use address indexes), account number a needs to be in the interval [0, 1 000 000]