If a restored Bitcoin wallet shows zero, compare its account and recovery settings with a known old receiving address before starting repeated rescans. You may be viewing a different derived account, an incomplete address search or a wallet whose transaction history has not synchronized. Also check whether the old outputs were already spent: recovering keys does not reverse previous transactions.
Preserve the backup and find one public reference
Keep the original backup unchanged and retain any working installation. Find a previously used receiving address or transaction identifier from your own records. That public reference provides a check independent of the restored app's balance. Do not upload the backup, seed or private keys to a recovery website merely to find an address. A support investigation can begin with the wallet product, backup type and public evidence.
Check the correct Bitcoin network and the relevant account. A new receiving address does not necessarily mean a different wallet, since deterministic wallets generate many addresses. Conversely, an application accepting a phrase is not proof that it restored the intended account. The goal is to connect a known historical address with the restored account's documented derivation and discovery, not demand that the newest receive screen repeat the first address you ever used.
Use the first mismatch to choose the investigation
| Observation | Possible explanation | Evidence to obtain | What a rescan cannot solve |
|---|---|---|---|
| The app accepts words, but expected addresses are not located | Backup interpretation, passphrase, account or discovery mismatch | Original wallet type and account settings | Inventing the missing recovery material |
| Known addresses match, history is incomplete | Synchronization or scan coverage | Connection state and relevant scan interval | Replacing keys that belong to another wallet |
| History appears, current balance is zero | The relevant outputs may have been spent | Actual output and spending records | Undoing completed transactions |
| Some old addresses appear, later ones do not | Address-discovery scope | How the original wallet generated and used addresses | Guessing every wallet's discovery settings |
| Balance returns but descriptions are gone | Local metadata was not restored | A separate label or app-data backup | Reconstructing private notes from the chain |
Treat these as diagnostic branches, not guarantees about the cause. A missing address in a short displayed list does not prove a wrong seed; the list may not cover it yet. Similarly, a matching historical transaction does not prove the current unspent amount. Our UTXO explanation helps separate a past receipt from the outputs that remain available today.
Confirm how the original wallet interpreted its backup
Identify whether the backup is a mnemonic, wallet file, descriptor-based record or another documented recovery format. Electrum's seed-version documentation explains its own phrase scheme and explicitly distinguishes it from generating BIP-39 phrases. The words looking familiar is therefore not enough to choose a recovery mode in another application. Follow the originating wallet's documented compatibility instructions.
For a BIP-39 wallet, an optional passphrase participates in deriving the seed, as described in the BIP-39 specification. A different passphrase can lead to a valid but different wallet rather than a simple wrong-password warning. Keep that separate from the password used to unlock an app. Do not randomly edit words or discard a backup because a newly opened account has no activity.
Also check the account and script type the original product used. Recovery software needs the appropriate derivation information to find the relevant addresses. Do not start importing private keys into several unfamiliar tools to compare balances. Use the documented configuration and public address matches first, preserving the original recovery material and any known account records.
Address discovery and chain scanning solve different problems
Address discovery decides which derived addresses to look for. Chain scanning searches history for the wallet's relevant scripts or accounts. A scan over the wrong scope can complete successfully while showing none of the expected activity. BIP 44 describes account and address discovery, including a stopping rule after unused addresses. That is one documented scheme, not a universal setting for all modern Bitcoin wallets.
If the original wallet deliberately generated or used addresses beyond its usual discovery window, record that fact and use its official recovery guidance. Avoid arbitrarily extending every possible account range or repeatedly scanning the whole chain. First establish which address family is relevant. A longer computation is not evidence of a more accurate recovery when the key scope or account interpretation is wrong.
For Bitcoin Core, inspect scan coverage and progress
Bitcoin Core's versioned rescanblockchain reference describes rescanning the local chain for wallet-related transactions with start and stop heights. It points to wallet information for progress. Use the documentation matching your installed version and preserve any reported errors. Do not infer scan completion merely because the app opened or the node itself reached the network tip.
The chosen interval must include the wallet's relevant history. If a scan begins after the first expected receipt, its absence is not surprising. If the application reports unavailable data or another scan restriction, address that documented issue instead of launching simultaneous retries. A rescan is a local reconstruction task, not a payment to a remote agent, and it cannot create missing keys or reverse an outgoing spend.
- Preserve the original backup and locate a known address or transaction from your records.
- Confirm network, original wallet type and the backup's supported recovery format.
- Check passphrase, account and address-type settings through the official recovery flow.
- Establish whether expected addresses are within the wallet's discovery scope.
- If they match, investigate synchronization and the relevant historical scan interval.
- Compare actual unspent outputs before declaring funds missing, and keep metadata recovery as a separate task.
Close the case against current outputs, not the old headline balance
An old screenshot proves what an interface displayed then, not what remains unspent now. Inspect the historical receipt and any later spending in a trusted explorer. Our mempool.space guide explains the transaction view. If an unfamiliar outgoing transaction appears, preserve it for a separate security investigation rather than claiming another rescan will return the coins.
Once access and balances are understood, prepare any later no-account swap from the correct account using its actual available funds and the current order instructions. Do not send an activation payment to prove recovery, and do not share the backup with supposed support. A useful result identifies the restored address scope, scan coverage and current outputs; it does not require a stranger to control your wallet.
FAQ
Why can Electrum restore a wallet from seed but show no expected balance?
Check the phrase scheme, account settings and synchronization against a known old address. A phrase being accepted does not by itself establish that the intended account and history were recovered.
What does rescanning a Bitcoin Core wallet do?
It searches local blockchain history for wallet-related transactions over the relevant interval. It does not generate missing recovery material or reverse previous spends.
How long should Bitcoin Core rescanning take?
There is no single duration for every wallet and machine. Inspect the documented progress and scan scope rather than launching repeated scans after an arbitrary timeout.