A restored deterministic Bitcoin wallet can reproduce the right keys yet initially show no balance because its search stopped before reaching a used address. Electrum explicitly warns that addresses generated beyond its gap limit may need additional discovery during restoration. An empty screen is therefore a reason to inspect the search, rather than immediately conclude that the backup failed. Electrum recovery warning
Recovery includes finding the history
Hierarchical deterministic wallets derive a tree of keys from a seed. That makes it possible to regenerate the keys without preserving a separate secret for every address. The tree can contain different branches, including receiving and change addresses. BIP32
Reconstruction still leaves software with a practical question: which parts of that tree have actually been used? The wallet must search for transactions associated with the relevant addresses or underlying output scripts. With a very large address space, recovery software needs a stopping rule.
What the gap limit counts
BIP44 specifies an address gap limit of 20: discovery stops after encountering 20 consecutive unused receiving addresses. “Unused” concerns transaction history. An address whose coins were spent remains used, even when its current balance is zero. Twenty is this specification’s convention, not a Bitcoin consensus rule or a universal setting for every wallet. BIP44 discovery rules
Consider an illustrative wallet whose first receiving address has activity, followed by 20 unused addresses, followed by another funded address. A recovery scan applying that stopping rule can finish before discovering the later payment. Generating addresses and receiving payments are separate events; a long stretch of generated-but-never-paid addresses can create the gap.
Electrum’s documentation describes increasing its gap limit or generating additional addresses as ways to reach such funds. Its FAQ’s numerical default is explicitly described for Electrum 2.0, so readers should check the instructions for their installed version before changing anything. Electrum’s gap-limit explanation
A full scan still has boundaries
Bitcoin Dev Kit’s Electrum interface distinguishes synchronizing a supplied set of scripts from a full scan for recovery when the used range is unknown. That full scan accepts a configurable stop gap for each keychain. Its batch-size setting controls how many scripts are requested together, which is a different parameter from how far discovery proceeds. BDK scan documentation
The practical implication is that repeatedly refreshing already-known addresses may leave a discovery problem untouched. Check whether the wallet is performing its documented recovery scan and what boundary that scan uses.
There is also a separate historical boundary. Bitcoin Core 30’s descriptor-import interface accepts both an address derivation range and a timestamp determining where the blockchain rescan begins. Its documentation reserves “now” for outputs known to be unused and allows zero to request the entire chain. An overly recent starting point can miss older activity even when the imported address range is correct. Core import parameters
Core also warns that addresses can be recognized while related transactions are still missing during a lengthy rescan. Wait for completion and inspect warnings before interpreting the balance. Core rescan warning
Looking farther requires the right branch
A larger gap limit cannot compensate for searching the wrong account or address scheme. For example, BIP84 uses a different derivation-purpose value for native SegWit accounts and warns that incompatible wallets will not discover them. Establish the original wallet’s supported account type before expanding the search. BIP84 compatibility
Account discovery can stop too. BIP44 proceeds through accounts using receiving-address history and stops at an account with none. That procedure relies on wallets preventing users from creating a new account before the previous one has history. A setup outside those assumptions may require explicitly checking later accounts. BIP44 account discovery
Investigate without exposing the secrets
A useful diagnostic record includes the original software, network, account type, known receiving addresses and approximate dates of activity. Compare those records privately with the restored wallet. Check receiving and change coverage, scan completion, and the documented discovery settings before making changes. Keep the original wallet files intact while investigating.
Use the wallet maker’s official recovery procedure. Never send recovery words or private keys to a person offering to extend a scan, and never paste them into an online “balance finder.” Trezor explicitly warns that its support team will never request a wallet backup. Trezor’s secret-handling guidance
Public-wallet information also deserves care: Sparrow notes that a public server can see a wallet’s balances. Searching more broadly through unfamiliar services can increase exposure. Sparrow privacy guidance
The aim is a verified search of the intended wallet, with a known scope and completed results. Expanding that scope can resolve missed-address problems; it cannot guarantee that expected funds remain unspent.