Ledger Restored but Tokens Are Missing: Find the Right Account

When tokens are missing after restoring Ledger, compare the expected public account address with the address the restored device derives. If they differ, investigate the original recovery setup and account path. If they match, check the network, token identifier and wallet display. Importing recovery words into a website is not a necessary diagnostic step and would expose the wallet’s secret material.

Recover a public reference before changing settings

Find an earlier transaction, withdrawal record or receive record that identifies the account which held the token. Record its chain and exact token identifier as well as the public address. A remembered account name such as “Ethereum 2” is weaker evidence: another application can assign that name to a different derived account.

Use a known transaction to establish the original recipient, then inspect that account on the correct network. The question is not whether you can make some balance appear in a wallet. It is whether the restored hardware setup can reproduce the account that actually received your assets, and whether the relevant asset remains there.

A derivation path selects an account; it does not move the token

Ledger’s explanation of addresses and derivation paths describes a hierarchy of keys selected through paths and account indexes. Restoring the secret basis is different from telling an application which branch to discover. Selecting another branch can show another address without moving anything out of the original one.

In a fictional example, Leo previously used an additional hardware-derived account through a companion wallet. After restoration, a different application shows only its first discovered account. Leo’s old receipt points to Address A, while the new screen shows Address B. Sending a small amount to B would fund another account; it would not prove that A was recovered.

Keep the investigation bounded by the original application and its supported options. Record the path family and account index if the old software exposes them. Do not assume that an option called “standard” or “legacy” has one identical meaning across every asset and wallet. Changing settings without retaining the expected address makes it harder to tell progress from another empty account.

Two current wallet examples show why discovery differs

Core’s Ledger account guidance explains a concrete mismatch between Ledger Live and a direct Core web connection for Avalanche accounts. Additional accounts can differ because the connections use different derivation conventions. The correct response is to recover the intended account through the appropriate supported connection, rather than transferring funds to make the views agree.

Phantom’s derivation documentation separately describes its supported account groupings and activity-based discovery of some alternate paths. Those product rules explain why one app’s list can omit an address another app used. Do not copy a Phantom path table into a universal Ledger restoration recipe: the relevant asset, connection type and previous account history still matter.

A useful result is an exact address match with a supported hardware connection. A long list of possible paths is not that result. If the previous wallet no longer offers the needed option, ask its official support which supported interface can discover the known address while keeping signing on the hardware device.

Passphrase context is separate from an app password

The BIP-39 specification includes the optional passphrase in seed generation; an empty passphrase and a different passphrase select different deterministic wallets. A restored mnemonic can therefore be valid without opening the expected passphrase wallet. This does not mean that the assets were deleted or that the token contract needs repair.

Establish whether you originally used a passphrase setup before changing one now. A local application password and a hardware PIN serve different purposes from that recovery input. Do not create a new passphrase to “fix” an empty account, and do not give the old one to a recovery operator. If you cannot reproduce the original context, describe that uncertainty honestly rather than treating a fresh account as the old wallet.

If the address matches, inspect the asset display separately

For an ERC-20 token, the Ethereum token-standard documentation describes account balances tracked by the token contract. A native ETH balance is not the same balance as an ERC-20 holding. Check the intended chain and exact contract identifier before interpreting a wallet total or deciding which token to display.

The same visible account address can be relevant on more than one EVM network, but the network context remains essential to this check. Find the original incoming transfer and the corresponding current holding. Adding a token display entry does not relocate a balance to another chain, restore spent tokens or grant a device control of a different address.

If the correct asset is present at the correct account, use the application’s documented synchronization or supported-token procedure. Preserve the address comparison so you do not start changing derivation paths again to solve a separate interface issue. If the holding is absent onchain, inspect the history instead of treating every missing token as an indexing problem.

Verify access without broadcasting a repair payment

1. Identify the original public account, chain and token from reliable prior records.
2. Determine whether the restored setup reproduces that account through a supported hardware connection.
3. If it does not, review the original passphrase context and the companion wallet’s supported derivation choices.
4. If it does, inspect the token on the correct network and compare the app’s display with the onchain evidence.
5. Use the device’s supported address-verification flow before treating a saved account row as verified access.
6. Keep public account notes for future restoration, while storing recovery secrets separately and privately.

The Ledger receive-address verification guide covers checking the address on the device. A public account visible in an app is not, by itself, proof that the currently connected hardware controls it. Read what any proposed signature would authorize; finding an account should not require sending assets to an unknown recovery address.

Keep your recovery words out of browser recovery tools and support chats; the seed storage guide explains exposure risks. Resume routine activity such as a simple swap after the account and asset are reconciled. The endpoint is a known account with verified access and a consistent balance explanation, not merely an application screen that stopped showing an error.