The canonical path table for every chain, single-signature wallets and vault cosigner keys
A recovery phrase is not an address. It is a seed from which an unlimited number of keys can be
derived, and a derivation path names which one. The same phrase under two different paths yields two
completely unrelated wallets, both valid, only one of them yours.If an imported wallet shows an empty balance, the path is the first thing to check.
{index} is the wallet number within the chain: your first Bitcoin wallet is index 0, your second is
index 1, and the counter is separate per chain. What it varies is not the same level on every chain.
Chain
{index} varies
Consequence for recovery
EVM, Tron, XRP, Bitcoin
the address leaf, inside one account
Any wallet that lists several addresses under one account finds them all
Solana, Cardano
the account level
Each wallet is a separate account with its own subtree; a wallet that only shows account 0 will not show your second wallet
The index counts only the wallets derived from the phrase. A wallet imported by private key occupies
no index, so “my third wallet” and “index 2” can disagree if such a wallet sits in the list. Match by
address, not by position.
On Solana and Cardano a restore can silently omit every wallet after the first. On those two
chains, wallet #1 and above are separate accounts. A third-party wallet that restores only account
0 will show you wallet #0 and give no indication that the others exist. You need a wallet that can
enumerate or select accounts. See Cardano and Solana.
Cardano has a second way to land on an empty wallet that the path cannot explain: Trustodian derives
under the Icarus master-key scheme, and a wallet on the Ledger scheme produces different
addresses from the same phrase. See Icarus, not Ledger.
A vault is a script, not a key. What derives from your phrase is only your cosigner key inside that
script. The table below covers Bitcoin and Cardano, the two chains whose vault configuration is not
on the chain and therefore comes from the Recovery Kit. EVM, Solana, Tron and XRP vaults need no
separate cosigner path: your seat is held by the ordinary wallet key for that chain. See
How vaults recover.
Chain
Account path
Notes
Bitcoin
m/48'/0'/{account}'/2'
BIP-48; the trailing 2' is the script type P2WSH
Cardano
m/1854'/1815'/{account}'
CIP-1854 multisig; role 0 is payment, role 2 is stake, each at index 0
Under the Bitcoin account node, the signing leaves are <account path>/0/{n} for receive addresses
and <account path>/1/{n} for change: the branch and index the descriptor ranges over.
{account} here is a third, separate number. It is not the wallet index from the table above.
Three different counters use the word “index” in this system:
a Bitcoin wallet’s index varies the BIP-84 address leaf,
a Cardano wallet’s index varies the CIP-1852 account,
a vault’s account index varies the BIP-48 or CIP-1854 account.
They never collide, but they are routinely confused. Read the account index off the vault’s page in
the Recovery Kit rather than assuming it matches a wallet number.
Your Recovery Kit prints, per cosigner, the Derivation path (the account origin), the Master
fingerprint, and the Account xpub for Bitcoin, or the Payment key hash and Stake key
hash for Cardano. Those are the fields to match against when you check that a restored key is the
right one.
Do not check the balance first: a balance of zero is ambiguous. Compare the first derived address,
character for character, against the address shown in Trustodian or printed in your Recovery Kit, and
only then look at the balance.If it does not match, the cause is the derivation path, the passphrase or the account index — the
phrase itself is almost never wrong, because a mistyped one fails its checksum and is rejected
outright. Troubleshooting works through them.