Skip to content

Litecoin.watch · Research & practical tools

Litecoin wallet recovery tests

What did a backup actually restore: the addresses, the balance, or the ability to sign? Inspect the tested versions, exact cases and downloadable evidence.

Release 2026-09-27.1 · Editorial responsibility: Jarosław Wasiński · Read the experiment report

Two wallet implementations and one wallet engine. Core was tested on isolated regtest; Electrum-LTC through its offline Windows CLI; Trust Wallet Core through WebAssembly. The Trust Wallet mobile app and Electrum's graphical BIP39 restore were not tested.

What each test established

Fixed synthetic cases; these results do not estimate a recovery success rate.
Backup and destinationAddressesBalance / historySigning evidenceBoundary
Encrypted Core wallet file → Core 0.21.5.8Three owned address types restored3 regtest LTC restored on the same test chainThree signed candidates accepted; one spend minedWallet-file RPC workflow. No mnemonic or MWEB test.
Native Electrum seed → Electrum-LTC 4.2.2.120 receive + 10 change addresses matchedNot tested; offlineRestored wallet signed a verified messageNo graphical interface or real payment tested.
Electrum master public key → Electrum-LTC 4.2.2.120 receiving addresses matchedNot tested; offlineNo signature: public-key-only walletMatching addresses do not recover private keys.
BIP39 phrase → Trust Wallet Core 4.8.4 engine42 fixed derivations matched after fresh restoresNot testedNot tested in this engine runLibrary test. No mobile app or account-discovery test.
BIP39-derived account private keys → Electrum-LTC10 P2PKH/P2WPKH addresses matched across implementationsNot tested; offlineBoth imported accounts signed verified messagesAccount-key import; not Electrum's BIP39 seed wizard.

A message signature tests access to the signing key. It does not prove a transaction was accepted by the Litecoin network. Only the Core part includes a transaction accepted and mined, and only on its isolated regtest chain.

Small differences that change a recovery

A different passphrase still works

The public BIP39 fixture was restored with no passphrase, recovery-lab and recovery-lab-typo. All three created a wallet; their first addresses differed. A valid address or a successful import is not proof of the intended wallet.

An address match can be watch-only

Electrum's master public key reproduced the receiving-address list. It had no account private key and could not sign our proof message. The CLI returned a generic error, recorded in the JSON, rather than a friendly watch-only explanation. A backup plan has to preserve spending authority, not only a way to view addresses.

Actual fixture outputs from the engine, same path m/84'/2'/0'/0/0. Public test wallets: never fund these addresses.
Synthetic passphraseDerived first address
Emptyltc1qjmxnz78nmc8nq77wuxh25n2es7rzm5c2rkk4wh
recovery-labltc1qavu8d2556s3x3hsna7nlk5nlj6rqpsmvfqy227
recovery-lab-typoltc1q20a8z8sa6cxk9zj8efw2rs7zdj8khfm8ada59p

The fixture set also changes the account, receive/change branch and address index. Deriving index 20 succeeds. This does not establish whether an application automatically discovers a transaction there; no online gap-limit scan was performed.

Identify your backup before restoring it

This page has no recovery input or upload. Keep your wallet files, seed words and private keys off websites and out of support messages.

I have a wallet file

Record the originating application and version, file format and whether it is encrypted. Preserve the original and work from a separate copy. The Core test here covers an encrypted legacy wallet file restored in the same Core version on an existing regtest chain. It does not establish cross-wallet file compatibility or a rescan from scratch.

I have recovery words

Identify the seed format and any additional passphrase. Word count alone is insufficient. Record the coin/network, script type, account and derivation path where relevant. A native Electrum seed and BIP39 words use different restoration paths. Compare a known address before treating an empty result as evidence that your funds are gone.

I have an extended public key

It can restore an address view without restoring signing authority. Locate the corresponding signing backup or device and, for multisig, the full wallet policy and sufficient cosigner keys. This experiment does not cover multisig recovery; our separate Core multisig experiment explains that distinction.

  1. Authenticate the software and identify the exact backup format.
  2. Reproduce a known receiving address using the intended configuration.
  3. Check history discovery, change addresses and the relevant account or wallet policy.
  4. Verify signing capability using an appropriate controlled procedure; a displayed balance alone is insufficient.
  5. Record the scope and limitations of the check, and retain the original backup.

Inspect and reproduce the observations

Core: 2026-09-26T23:41:18.979963+00:00. Electrum: 2026-09-26T23:53:53.620108+00:00. Wallet Core: 2026-09-26T23:41:04.950Z. Timestamps are UTC. All cases use synthetic wallets. The reproduction package intentionally includes a public Electrum test phrase; it must never be used for funds.

Reproduction scripts and dependency lock

Original observations and diagrams are published under CC BY 4.0; our reproduction scripts under MIT. Dependencies retain their own licences. Cite the release number and this page. Software versions are pinned for reproducibility, not presented as security recommendations.

Prepared using AI-assisted coding and drafting, actual software runs and scripted checks. No independent human review is claimed. Report discrepancies through the corrections process, citing the release and case.