Why a restored Litecoin wallet can show zero: three controlled tests

Our test wallet had the correct private key and could sign a message for an address that had received 3 LTC. Its displayed balance was zero. The coins had not moved. The wallet had not looked through the blocks containing the payment.

That happened on a fresh, isolated Litecoin regtest chain using Litecoin Core 0.21.5.8. We then tested a different failure: an old backup that could not recover a key imported after the file was created. A separate offline experiment with Electrum-LTC 4.2.2.1 examined an address beyond the range prepared by a fresh seed restore.

The distinction matters when troubleshooting an empty wallet: missing history, missing key material and a different address range require different checks. These are controlled cases with synthetic wallets, not a recovery service or a success-rate estimate. The evidence page contains all observations and the source repository.

Test 1: the key was present, but the payment was missing

We created a test address, paid it 3 regtest LTC and mined the payment. Next, we created a separate blank wallet and imported that address's private key with history rescanning explicitly disabled. No real wallet or mainnet connection was involved.

Core reported that the address belonged to the new wallet. Its balance was 0 and its transaction list was empty. Nevertheless, the wallet signed a proof message, and Core verified the signature. This is the useful negative control: a zero displayed balance did not mean that the signing key was wrong.

The funding transaction was in block 102. We first rescanned from block 103, which could not include that earlier payment. The result remained empty. A subsequent scan from height 0 found the 3 LTC output. We then signed a candidate spending it, checked that the regtest node would accept it, broadcast it on the isolated test chain and mined it.

Core's implementation and help text for importprivkey distinguish importing a key from rescanning transaction history. The experiment confirms that distinction in this pinned release. It does not establish how long a scan of the real Litecoin chain will take.

Boundary: all historical blocks were available locally. A pruned node may no longer have the blocks a recovery requires. This experiment did not restore those blocks, rebuild a fresh mainnet node or test MWEB recovery. Repeatedly running a scan that cannot access the needed history would not reproduce our conditions.

Test 2: a full rescan could not repair an incomplete backup

For the second case, we made a backup of a wallet with an existing HD receiving address. After that backup, we imported a separately generated private key into the live wallet. The original address received 2 regtest LTC; the later imported address received 3. The live wallet showed 5 LTC across two payments.

We loaded an independent copy of the earlier backup on the same test chain. It found the 2 LTC payment to its known address, but it did not own the later imported address. A full rescan left its balance at 2. There was no missing block to discover that could supply the absent private key.

The refreshed file restored both payments and ownership of the imported address. This tests one specific backup boundary: an independently imported key added after a wallet-file backup. It does not imply that every newly generated HD address needs a new file backup, or that we tested restoring a Core HD root from a mnemonic.

The practical question is therefore more precise than “Is my backup old?” Ask what changed after it was made: an external key, an additional wallet, a script policy, or only another address derived from already backed-up material. Our first recovery study explains the separate checks for address identity, history discovery and spending authority.

Test 3: the seed reproduced an address outside the initial range

The Electrum experiment was deliberately narrower. We used the signed Windows executable, a deliberately public native Electrum seed and the offline command line. No Electrum server was contacted, and no history or balance was queried.

A fresh restore prepared 20 receiving addresses, at zero-based indices 0 through 19. In the source wallet we created sixteen additional addresses, reaching index 35. Restoring the same seed into another fresh wallet again prepared only the initial 20. The address at index 35 was absent from that prepared list.

We then changed the fresh wallet's gap setting to 40 using the pinned CLI. On the next load, it prepared 40 receiving addresses. Address 35 matched the source wallet exactly and signed a proof message that Electrum verified.

This establishes deterministic address recovery beyond the initially prepared range. It does not establish online payment discovery. An actual history scan also depends on its server responses, synchronization and the application's discovery rules. The pinned wallet implementation makes the receiving range and history-dependent extension explicit.

Forty was a controlled test setting, not a recommended gap limit for every wallet. We did not test BIP39 restoration through the graphical wizard, another account, change-address discovery or a mobile application in this experiment. The raw result records the exact public test address and verified signature.

What to check when a restored wallet looks empty

Preserve the original backup and compare a known earlier receiving address before changing recovery settings. Do not treat the address itself as proof that the wallet can sign: our earlier watch-only control reproduced addresses without the account private key.

A public transaction lookup can help establish what an external data source reports about a known payment. It cannot recover private keys or diagnose a wallet's local scan. The backup verification path provides a structured checklist. No recovery phrase, private key or wallet file should be entered into this website.

Evidence, versions and reproduction

Release 2026-09-27.2 contains 14 Core assertions and 7 Electrum assertions. These are checks within fixed scenarios, not 21 independent user recoveries. Both executables ran on Windows on 27 September 2026; exact UTC timestamps, binary hashes, stage values and limitations are recorded in the release summary and Core stage CSV.

The versioned source repository includes the previous release, this release, an executable runner and the confirmation observer's control tests. The runner separates checking published artifacts from actually launching the pinned wallet software. Independent runs create different Core keys and transaction IDs; the measured stage balances and fixed Electrum address should reproduce.

Observations and diagrams are available under CC BY 4.0; our scripts under MIT. Dependencies retain their own licences. Preparation used AI-assisted coding and drafting, actual executable runs and scripted verification. No independent human review is claimed. A useful correction report includes the release, case, software version and reproducible difference, sent through the corrections process.