Importing a Wallet: Derivation Paths and Empty Balances

A derivation path is the line of settings that turns a seed into a specific set of addresses. Get the words right and the path wrong and you will open a wallet that is valid, functional, and empty. The funds are not gone; they are at addresses the software did not think to look for.

A derivation path mismatch is one of the most common false alarms in self-custody. Someone restores a wallet after a phone dies, sees a zero balance, and concludes they were hacked. In most cases the seed is intact and the software is walking a different branch of the same key tree. The empty screen looks exactly like a loss until you check.

• The path selects addresses; the phrase selects keys. Same seed plus a different path equals a different, valid wallet with its own history.
• Address format narrows the search. An address starting with bc1q points at a different purpose value than one starting with 1 or 3.
• Empty is not evidence of theft. Confirm the address you expected on a block explorer before drawing any conclusion.
• Try paths before panicking, but never type the seed into a site. Use a wallet or offline tool that lets you set the path explicitly.

What a derivation path actually selects

It selects a branch of a deterministic key tree. The seed is the root; every path below it produces a different private key, and therefore a different address, with no overlap between branches.

From seed to address, in order

The seed is stretched into a master key, and each level of the path applies a one-way derivation step. A typical path such as m/84’/0’/0’/0/5 reads as: purpose 84 (native segwit), coin type 0 (Bitcoin mainnet), account 0, external chain 0, address index 5. Change any number and you land somewhere else in the same tree.

The apostrophes mark hardened steps, which cannot be derived from a parent public key. That is why an extended public key exported for one account cannot be used to compute a sibling account.

Why wallets disagree about the default

Standards describe how to derive, not which branch a wallet should show first. A wallet built around legacy addresses defaults to 44; one built around segwit defaults to 84; a newer one may default to 86 for taproot. Restore the same words in two wallets and you can get two different home screens, both correct by their own rules.

The paths worth trying first

Start with the handful that cover most wallets in use. If the balance appears under one of them, you have found the answer and can stop.

Two cautions about the table. Ethereum and other EVM chains share one address space, so a correct path still shows the same address on every EVM network; if the balance is missing there, the problem is the network setting, not the path. And on Solana and other ed25519 chains, implementations differ in how many levels they use, so a wallet may need m/44’/501’/0′ rather than the longer form.

How to try each derivation path safely

Work through the list in order and stop as soon as the addresses match your records. Each step costs a minute; none of them requires moving funds.

1. Confirm the seed itself first. Check the word count, the checksum and the spelling against the original backup. A single wrong word usually fails validation outright, but a valid alternative phrase is possible.
2. Look at the address you used to receive funds. Its prefix tells you which purpose value to try: 1 for 44, 3 for 49, bc1q for 84, bc1p for 86.
3. Use software that exposes the path setting. Many consumer wallets hide it, so a desktop wallet with an advanced restore option, or a reputable offline tool, is usually needed.
4. Hold the account index at 0 and vary the purpose value first. Only then step the account index from 0 upward, one at a time.
5. Scan beyond the first address. Standard wallets look twenty addresses ahead before deciding an account is unused, so funds at address index 40 of a quiet account can be missed by a shallow scan.
6. Check whether a passphrase was set. If one was, no path will help; the tree itself is different and you need the exact passphrase before the search means anything.
7. Verify each candidate address against a block explorer before you consolidate anything. Confirm the history, not just the balance.

The arithmetic is reassuring. Four common purpose values, five account indices and twenty addresses each is 4 × 5 × 20 = 400 candidate addresses. Deriving 400 keys takes seconds on ordinary hardware, and checking them against a full node or explorer is minutes. A search that broad is cheap enough that panic is never the first response.

When a restore shows zero, the useful question is not “who took it” but “which branch did this software read”. One is answerable in ten minutes; the other is not answerable at all.

When a different path is not the explanation

Some empty balances have nothing to do with derivation. Rule these out before you spend hours on paths.

The passphrase changes the root

A BIP39 passphrase is mixed into the seed before any key is derived, so it produces an entirely separate tree. There is no path that recovers a passphrase-protected wallet without the passphrase, and there is no way to tell from the words alone whether one was used. If you ever typed anything into a passphrase field, treat that as a live possibility.

Smart accounts and contract addresses

Some accounts are contracts deployed by a wallet rather than keys derived from your seed. A seed restore does not recreate one of those by derivation; it needs the deployment record or the recovery mechanism the wallet provides. The same applies to accounts created through a service that holds a key share.

Watch-only imports and the wrong network

A wallet added by address or extended public key shows balances without holding keys, and a restore that replaces it with a seed-derived account will look empty. Equally, a correctly derived address viewed on the wrong network shows nothing. Both are configuration, not loss.