"I imported my seed and my balance is zero": derivation paths explained

You type your twelve or twenty-four words into a new wallet, the import succeeds, and the balance reads zero. It is a frightening moment, and in most cases nothing is lost. The words are right; the new wallet is simply looking in a different place.

This guide explains why, how to find where your coins are, and why an SSP seed on its own behaves differently.

One seed, many wallets

A recovery phrase does not hold addresses. It produces a master key, and from that master key a wallet walks a derivation path — a route through a tree of keys — to reach each address. Change any step of the route and you reach a different, perfectly valid, and usually empty set of addresses. No error appears, because nothing is wrong.

A path looks like this:

m / purpose' / coin_type' / account' / change / index

The purpose picks the standard, coin_type picks the chain, account separates accounts, change separates receive (0) and change (1) addresses, and index counts addresses upward from 0. The BIP-48 explainer covers the tree in more depth.

The usual suspects

When an import shows zero, one of these is almost always the reason.

The address type (Bitcoin). The same seed gives four different families of Bitcoin addresses:

• BIP-44, m/44'/0'/0' — legacy addresses starting with 1
• BIP-49, m/49'/0'/0' — wrapped SegWit, starting with 3
• BIP-84, m/84'/0'/0' — native SegWit, starting with bc1q
• BIP-86, m/86'/0'/0' — Taproot, starting with bc1p

If your old wallet used native SegWit and the new one defaults to legacy, you see nothing. An old receiving address's prefix tells you which to choose.

The Ethereum variant. Most Ethereum wallets use m/44'/60'/0'/0/i, counting the last number upward for each new address. Ledger Live increments the account level instead: m/44'/60'/i'/0/0. Both agree on the very first address, which is why the mismatch often goes unnoticed until you look for the second or third one.

A passphrase. A BIP-39 passphrase (the "25th word") turns the same seed into an entirely separate wallet. Leave it out, or mistype one character, and you open a different, empty wallet with no warning. The passphrase trade-off guide explains why this is both the feature's strength and its danger.

The account index. If you used "Account 2" in your old wallet, your funds are under account' = 1, not 0. Many wallets only restore the first account unless you add more.

The gap limit. Wallets cannot check every index forever, so they scan addresses in order and stop after a run of unused ones — conventionally 20. If you once handed out address #35 while #15 to #34 stayed unused, a standard scan stops before reaching it. Raising the gap limit in the wallet's settings, where it is offered, usually finds the missing coins.

How to diagnose it calmly

1. Don't panic, and don't move anything. A zero balance after import is almost always a path question, not a theft.
2. Find one address you know held funds — from an old receipt, an exchange withdrawal record, or your own notes. Check it on a block explorer to confirm the coins are still there.
3. Note its format. Prefix (1, 3, bc1q, bc1p, 0x) tells you the address family; then match it in the new wallet.
4. Check which wallet created the seed — its documentation states its paths.
5. Try account indexes, the Ledger variant, and the gap limit one at a time, comparing addresses against the one you know.
6. Never type your seed into a website that promises to "find" your funds. Use reputable, offline-capable wallet software only.

Why an SSP seed alone shows an empty wallet

SSP is a 2-of-2 multisig wallet, and that changes the picture entirely. SSP Wallet in your browser and SSP Key on your phone each have their own seed. In the code, both derive their keys under BIP-48 — m/48'/coin'/0'/script' — and for Bitcoin the script type is native SegWit multisig (P2WSH), so the account sits at m/48'/0'/0'/2'. Each SSP address is then built from two public keys, one from each side, combined into a 2-of-2 script. EVM and Solana vaults likewise take both keys as input.

So if you import your SSP Wallet seed into a normal single-signature wallet, it will derive single-key addresses that SSP never used. They will be empty, and that is expected. Your coins sit at multisig addresses that no single seed can reconstruct: the wallet needs the other side's public key to even know the address, and both signatures to spend from it.

The way to restore SSP is to restore both halves in SSP. Restore SSP Wallet from its seed, then sync it with SSP Key so the wallet receives the key's public data again. If only your browser is gone, SSP Key can bring it back without the seed — see recovering SSP when you lose your browser. Recovery 101 covers what each scenario requires.

One SSP-specific detail on address scanning: SSP Wallet does not use a gap-limit scan. Each chain holds the addresses you have added, up to 20 per chain, created in order from index 0. After a restore, if an address you used before is missing, adding addresses again regenerates the same ones in the same order.

The honest summary

A seed is the key to a tree, not to a single list of addresses. Address type, coin path, passphrase, account index and gap limit all decide which branch a wallet looks at, and a zero balance after import usually means the wrong branch, not missing coins.

For SSP, a single seed is never the whole wallet. Your funds live at 2-of-2 addresses built from both SSP Wallet and SSP Key, so restoring means restoring both halves inside SSP, not importing one seed elsewhere.