You still have your recovery phrase. You typed it into a wallet app, it accepted every word, and the balance came back zero. Or worse, it restored fine and the addresses are not the ones you remember. The natural conclusion is that the coins were stolen or the phrase is fake.
Usually neither is true. A phrase that a wallet accepts is a phrase that passed its checksum, and a checksum-valid phrase almost never belongs to nobody. What has gone wrong is far more often that the restoring app is looking in the wrong place. An empty-but-should-be-full restore is a derivation problem until proven otherwise.
This guide is about wallets you still control the keys to. If your coins were sent to someone else's address in a scam or a hack, that is a different situation with a different honest answer, and no derivation-path trick brings those back. Start at my Bitcoin was stolen, can you help instead.
Two rules before you touch anything. Do not type your seed phrase into a website, however official the "wallet checker" looks. Do not hand it to anyone who contacted you first. If you are working out who to trust, read how to tell a legitimate recovery service from a scam before you share anything with anyone.
Step one: read the addresses you got
Locked out of a wallet like this one?
We repair hardware wallets, crack forgotten passwords, and rebuild broken seed phrases — on our own bench in Denver.
Before diagnosing anything, look at the first receiving address the restore produced and write it down. Its shape tells you which derivation path the app used, and that single detail eliminates most of the guesswork:
| First address starts with | Address type | Path the app used |
|---|---|---|
1 |
Legacy (P2PKH) | m/44'/0'/0' (BIP-44) |
3 |
SegWit wrapped in P2SH | m/49'/0'/0' (BIP-49) |
bc1q |
Native SegWit (P2WPKH) | m/84'/0'/0' (BIP-84) |
bc1p |
Taproot (P2TR) | m/86'/0'/0' (BIP-86) |
If your old wallet paid you at addresses starting with 1 and the restore is showing you bc1q addresses, you have not lost anything. You are looking at a different branch of the same tree. Every one of those paths derives from the same seed, and each produces a completely different, completely valid set of addresses.
The five reasons a valid seed opens the wrong wallet
Roughly in order of how often they turn out to be the answer.
1. The wrong derivation path
The paths in the table above are conventions, not rules, and older wallets frequently ignored them. The best-documented example is MultiBit HD, which derived addresses under m/0' rather than the BIP-44 path modern wallets try by default. Restore a MultiBit HD seed into a wallet that assumes m/44'/0'/0' and you get a flawless restore of an empty wallet. The specifics, including how to enter the right path in Electrum, are in our MultiBit wallet files and derivation paths reference, and the same trick applies to other wallets of that era.
The fix is to restore again and specify the path manually. Most desktop wallets let you: in Electrum the option appears when you choose "BIP39 seed" during restore. Work through the standard paths first, then the wallet's historical one.
2. A passphrase you forgot was set
This is the one people rule out incorrectly. BIP-39 turns your words into a wallet seed by running them through PBKDF2 with HMAC-SHA512, 2048 iterations, using the string mnemonic plus your optional passphrase as the salt. The consequence is written into the standard itself: "every passphrase generates a valid seed (and thus a deterministic wallet) but only the correct one will make the desired wallet available."
There is no wrong passphrase. There is only a different wallet. Trezor builds this into the product as hidden wallets, and its documentation is blunt about the failure mode: mistyping a passphrase does not produce an error, it silently creates a new empty wallet, and a forgotten passphrase cannot be recovered from the device.
So if you ever enabled a passphrase, a "13th word", or a hidden wallet, an empty restore is the expected result of leaving it out. Test with an empty passphrase and with every variant you might have used, and mind the details that are easy to lose: capitalisation, a trailing space, a substituted character. For the hardware-wallet specifics, see restoring a Trezor with a lost PIN, wiped, or broken device and the Trezor recovery and repair page.
3. The gap limit stopped the scan early
Wallets do not scan an infinite number of addresses. BIP-44 sets an address gap limit of 20: "If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain." Electrum uses the same default and states plainly that addresses beyond the gap limit will not automatically be recovered from the seed.
If you generated a long run of addresses you never used and then received a payment further down the chain, a fresh restore stops before it reaches your money. The same logic applies at the account level: account discovery stops at the first account with no transaction history, so funds parked on account 3 stay invisible when accounts 0 through 2 are empty.
The fix is to raise the gap limit in the restoring wallet and rescan, and to check higher account indices explicitly. This is also why change addresses go missing: change lives on the internal chain (.../1/...), and a tool that only sweeps receive addresses will report a balance that is short rather than zero.
4. It is not a BIP-39 phrase at all
Not every 12-word phrase is a BIP-39 phrase. Electrum generates its own seed format and says so directly: "Electrum does not generate BIP39 seeds." Electrum seeds carry a version number derived from the phrase itself, and feeding one into a BIP-39 field, or a BIP-39 phrase into an Electrum-native restore, produces a valid but entirely unrelated wallet.
The oldest Blockchain.info wallets predate BIP-39 as well, and their recovery mechanism does not restore in a standard BIP-39 wallet. If your phrase came from a web wallet of that era, the keys live in the backup file rather than the phrase, which is covered in Blockchain.com backup file won't decrypt.
5. The coins were never derived from that seed
Some keys simply are not covered by the phrase. Any address you imported into a wallet was generated elsewhere, so a seed restore will never reproduce it. The same is true of paper-wallet keys swept in, and of altcoin balances sitting under a different coin type in the path. If a restore returns most of what you expected but not all of it, imported keys are the first thing to check, and the original wallet file is the thing to preserve.
Testing this safely
The whole point of a restore is that you get to be careful, because the seed already exists and nothing is time-critical.
- Never test on a website. Every "check your seed phrase" page is either a scam or one breach away from being one.
- Test watch-only first. Restore in a wallet that lets you derive an extended public key (xpub, ypub, zpub) and check that against a block explorer. You learn whether a path holds coins without ever exposing a private key.
- Use a machine you trust, ideally offline, and prefer a well-known wallet over a path-scanning utility you found in a search result.
- Keep a log. Write down every path, account index, gap limit, and passphrase variant you have tried and what came back. It stops you repeating work, and if you later hand the case to someone, they start from your notes instead of from zero.
- Do not wipe or re-initialise the original wallet or device while you are testing. It may still hold the only copy of something.
When it is worth handing off
Much of the above you can work through yourself. The cases that usually justify professional help:
- A phrase that will not validate anywhere, where the words are damaged, misspelled, out of order, or partly illegible. That is a structured search problem rather than guessing, and it starts at seed phrase recovery.
- A forgotten passphrase on an otherwise good seed, which is a targeted brute force informed by what you remember. See forgotten wallet password recovery.
- An obsolete or non-standard wallet where nobody publishes the path any more. This is routine work for MultiBit, Electrum, Bitcoin Core, Ledger, and Blockchain.com wallets.
- A wallet file that is damaged as well as unreadable, which is the corrupt wallet-file recovery problem.
For an honest read on which of these tend to succeed, see your recovery odds by scenario.
If you would rather not work through the paths yourself, that is the service: crypto wallet recovery by David Veksler through a Colorado LLC, with published pricing, a free evaluation, and no fee until your crypto is back. Describe the symptom and the address types you are seeing, not your seed words, in the first message. Start your free evaluation →
Sources
- BIP-39, mnemonic seed derivation and the passphrase: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki (retrieved 2026-07-28)
- BIP-44, path structure, account discovery, and the gap limit of 20: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki (retrieved 2026-07-28)
- BIP-49, BIP-84, and BIP-86, the
3,bc1q, andbc1paddress paths: https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki, https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki, https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki (retrieved 2026-07-28) - Electrum on the gap limit: https://electrum.readthedocs.io/en/latest/faq.html (retrieved 2026-07-28)
- Electrum on why it does not generate BIP-39 seeds: https://electrum.readthedocs.io/en/latest/seedphrase.html (retrieved 2026-07-28)
- Trezor on passphrases and hidden wallets: https://trezor.io/guides/backups-recovery/advanced-wallets/what-is-a-passphrase (retrieved 2026-07-28)