The same TON recovery phrase can open separate V4 and V5 wallet accounts, each with its own address and balance. An empty account after restoration therefore does not, by itself, prove that your coins disappeared. Find the previously used address and match its wallet version, key derivation and wallet ID before funding or replacing anything.
Start with the address you actually used
A recovery phrase is a way to derive keys; it is not a complete description of every account those keys can control. TON wallets are contracts. Their addresses are derived from their initial code and data, rather than being a direct display of the public key. The wallet architecture documentation explains why changing the contract or its instance settings can produce another account while preserving the underlying signing key.
Before trying another restoration, find an old incoming or outgoing transaction, a saved receive address, or a withdrawal record from the platform you used. Open that address in a TON explorer and establish whether the expected transaction and asset are still there. This separates a genuine account-history question from an application that simply opened a different wallet instance. A screenshot of a fiat valuation is less useful than the actual address and transaction reference.
The settings that change an address are not all equivalent
| Difference | Why the display can change | Does it identify another account? | Recovery evidence to find |
|---|---|---|---|
| V4 versus V5 contract | Different wallet contract code and initial data | Normally yes | The contract version of the previously funded account |
| Different wallet or subwallet ID | A different instance is derived from the same key | Yes | The original app or SDK settings and known receive address |
| Different mnemonic scheme | The same word list can be processed into different keys | It can | The original application's recovery scheme |
| Mainnet versus testnet settings | Network-aware wallet defaults and ledger selection differ | Check both derivation and selected ledger | Which network held the real transaction |
| Bounceable versus non-bounceable presentation | Flags and checksum wrap an underlying account identifier | Not if the decoded identifier matches | Decoded workchain and account ID |
The last row is a useful boundary. A different prefix may be only another representation of the same account. A different contract-derived account ID is a separate destination. You cannot repair the second case by converting EQ to UQ, nor can you establish the first case by matching a few visible characters. Use the address format reference when deciding which difference you are looking at.
V5 does not sweep the balance out of your V4 account
Consider an illustrative restoration, not a reported customer case: an owner received assets at a V4 account and later installs an app whose default selection is V5. The recovered V5 address has no history. The old V4 address still shows the earlier deposit. These observations are compatible: the interface is looking at another account. They do not demonstrate that an upgrade transferred or destroyed the old balance.
Find whether the verified application supports discovering or selecting the older contract version. Menu names and supported versions differ between applications and releases, so do not follow an unrelated screenshot as if it were a network requirement. Once you can inspect the old address in the app, compare it with the known transaction record before attempting a transfer. A balance appearing in the interface is useful, but the address match is the stronger check.
The V5 contract repository describes a distinct wallet contract and additional authorization mechanisms. Its existence does not mean every wallet app implements every feature, nor that a new V5 account is an automatic migration target for your older holdings. There is no need to send money to a stranger's activation address to make the app discover your own historical account.
A familiar word list can still use a different recovery scheme
TON-native mnemonics and multichain BIP39 mnemonics are not interchangeable merely because the words come from the same list. The TON wallet interoperability guideline distinguishes their key derivation and import behavior. Word count can help describe a backup, but it is not sufficient evidence that another application's import routine will reconstruct the same key and account.
Record which application created the backup, whether it came from a hardware device, and which recovery option you selected. Do not paste the phrase into an online converter to see which address appears. A legitimate support investigation can start with the public address, app name and contract version; publishing the secret words would create a new security problem without establishing which import setting is correct.
Wallet IDs require similar care. The wallet interaction guide shows that mnemonic data alone does not uniquely specify an address. If an account was created with a custom instance ID, using a default value can open another account. Do not guess random settings and then fund the first plausible result. Match a candidate to the old public address before deciding you have recovered the right instance.
Recover the account in a controlled order
- Collect the old public address and one transaction that demonstrates the expected history. Keep secret recovery material out of screenshots and support messages.
- Check the address on the correct network and identify the wallet contract version where the explorer provides it. Distinguish an empty account from the absence of the expected account in your app.
- Verify the installed application's source, then inspect its supported recovery scheme and wallet-version selection. Reconstruct the original configuration rather than assuming today's default is the old one.
- Compare the candidate's complete account identifier with the known address. Check each expected token separately; a hidden asset is a different issue from a different account.
- Only after that match, decide whether to keep using the old account or deliberately move to another one. Review the destination and current network costs before signing any transfer.
If the address still does not match, write down the precise divergence: correct phrase scheme but another version, correct version but another network, or an unexplained key-derivation difference. This is a useful support question. Repeating the same import without changing the unresolved setting is unlikely to provide new evidence. If the original backup was compromised during previous attempts, treat account recovery and protection of the exposed assets as separate urgent tasks.
Use the recovered account deliberately in a swap
A format validator can help check a proposed receiving address, but cannot discover a secret phrase or confirm control of an account. For USDT transfers on TON, verify the token and receiving requirements after finding the correct wallet instance. Restoring a native-coin account view does not automatically prove that every token has been displayed or that an exchange supports the same route.
If you later prepare a no-account swap, use an address you have actually recovered and verified as the destination. Record which wallet version and network produced it for your own future recovery notes. Do not create a swap as an experiment to discover whether an empty address belongs to you; resolve that question before a third party sends funds to it.
FAQ
What is the difference between a TON V4 wallet and W5?
They are different wallet contract versions, so the same key can correspond to separate accounts. Features and application support also differ; changing the selected version does not merge their balances.
Is a TON wallet recovery phrase enough to reproduce my old address?
It must be interpreted with the right key-derivation scheme and wallet configuration. Contract version and wallet ID can affect the address even when the recovered signing key is the same.
How do I recover a Tonkeeper wallet if the restored account is empty?
Start with the previously used public address and confirm its on-chain history. Then check the verified app's recovery and wallet-version options, rather than assuming the first empty account is your old one.