You approved the swap contract, sent the legacy balance, and the explorer marked the transaction green. The old ticker has gone and nothing has taken its place. Either the new units do not exist, or they exist and nothing is drawing them. Those two cases look identical on a wallet screen and need completely different responses.
What a completed swap actually certifies
A confirmed swap transaction tells you that your call reached a block and that the outermost piece of execution did not revert. That is the whole of it. A receipt status of success is a statement about the call, not an inventory of what it credited.
A migration swap has two legs, which is why that gap matters here. One pulls your legacy units away. The other pays new units back. The receipt covers the transaction as a whole, and a contract can be written so the second leg does less than you expected, or nothing at all, without the first leg unwinding.
So the question to answer is not whether the swap worked. It is whether a new balance now exists with your address written against it, and if it does, why nothing is drawing it. Those are two separate investigations, and running them in that order keeps you from arguing with a support desk about a balance you already hold.
Where the new balance is actually recorded
The new token is an ordinary contract with its own ledger, and the ERC-20 token standard records your position in it twice over: once as an event at the moment of the credit, and once as a value the contract answers with on request.
The event is the Transfer event, which the standard says MUST trigger when tokens are transferred, including zero value transfers. It adds that a token contract which creates new tokens SHOULD trigger a Transfer event with the sender address set to 0x0 when tokens are created. A migration that mints against your address therefore leaves a transfer from the zero address to you, and one paying out of a funded reserve leaves a transfer from that reserve. Either way there is a line to look for.
The value is balanceOf, which the standard describes as returning the account balance of another account with a given owner address. It is a read, it costs nothing, and it answers for the present rather than for the moment of the swap. Open the new contract on a block explorer and call balanceOf with your own address. The figure it returns is the authoritative answer.
| What you can read | What it settles |
|---|---|
| The receipt status on the swap | Only that the outer call did not revert |
| A transfer event to your address | That new units were credited to you then |
| The balanceOf reading at the new contract | What you hold in that ledger now |
| Your wallet list of assets | Nothing about ownership |
Why the balance can be yours and the wallet show nothing
The last row resolves the version of this that costs nothing to fix. A wallet does not scan every contract on the chain for your address. It draws a list of assets it was told to track, and a contract deployed last week is not on that list until something puts it there.
That is a known gap rather than a fault. EIP-747, the standard behind the wallet_watchAsset method, describes it as a way to allow a client to suggest a token for the user's wallet to track, and states that without it, each wallet either needs to pre-load a list of approved assets, or users must manually add assets to their wallet. A migration produces exactly that case.
The fix is to add the contract by hand, using the address from the project's own announcement rather than a search result or a chat message. Once the wallet tracks it, the balance appears at once if it was there all along, because nothing about your holding changed. If it still reads zero, display is ruled out and everything remaining is on chain.
When the swap credited an address that is not yours
A swap contract has to decide who to pay, and that address is not always the one you had in mind. If the contract credits the caller, the account that signed is the account that received, which is the wrong one when two accounts sit in the same browser profile.
The harder version involves an intermediary. Legacy units held at a centralised platform sit at that platform's address, and a swap sent from a deposit address pays whoever owns it. The same holds for a smart contract wallet or a multisig. Read the transfer event and note its recipient field: it names the address credited, and if that is not one of yours, the tokens were never going to appear where you are looking.
One clerical case is worth eliminating first. Some migrations issue the new token on a different chain from the legacy one, so the credit lands on a network your wallet is not pointed at. Switching networks settles that in seconds.
When the legacy units left and nothing came back
If the transfer event is absent and balanceOf reads zero while the legacy balance has gone, the payment leg did not run, and the reasons are few.
The first is an empty reserve. A swap paying out of pre-funded tokens rather than minting them can accept your deposit and fail to pay, because the account it pays from has been emptied. That is the failure the swap window exists to prevent, and why reading the reserve before sending matters more than reading the announcement.
The second is an amount smaller than expected rather than absent. Check the conversion ratio and the decimals of both contracts before deciding nothing arrived. A wallet holding 40,000 legacy units, consolidating at one new unit for every four legacy units, is owed 10,000 new units, which is 25% of the figure it was used to seeing. On a contract with a different decimals value, a correct credit can also render with the decimal point in an unfamiliar place.
The third is that the legacy units went somewhere with no payment leg attached. Sending tokens straight to a contract address instead of through the interface that calls it does not trigger the swap. The standard makes that possible because approve allows a spender to withdraw from your account up to a set amount, and transferFrom is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. A swap contract expects to pull from you, not to be handed something it was never told about.
Migrations a platform ran for your account
A different path produces the same complaint for different reasons. If you held the legacy token on a centralised platform through the migration, the platform converted its own pooled balance and rewrote your account entry, and the event showed up as a ticker change with no transaction of yours attached.
On that path there is no swap transaction to inspect, so none of the on chain checks apply. What applies is that platform's schedule: a suspension of deposits and withdrawals for the legacy token, a conversion applied to account balances, and a resumption under the new ticker. A balance not yet converted during that suspension is paused, not lost.
The two paths also escalate differently. A platform that has not credited you is a support question with a named counterparty. An on chain swap that did not pay has no counterparty in the loop, because the contract executed what was written into it.
What to check, in order
| Order | What to check | What a negative answer rules out |
|---|---|---|
| 1 | Is your wallet on the network the new token was issued on | A wrong chain display problem |
| 2 | Have you added the new contract address by hand | The wallet not tracking a new contract |
| 3 | Does balanceOf answer for your address | Any remaining display explanation |
| 4 | Does the swap carry a transfer event to you | A credit that happened and later moved |
| 5 | Which address does that event name | A credit paid to a deposit address |
| 6 | Do the ratio and decimals match what arrived | A correct credit misread as a wrong one |
| 7 | Did a platform run the migration for you | An on chain path that never applied |
Work down that list rather than across it. Each row removes a class of explanation, and the rows below only make sense once those above are settled. The first three cost nothing.
One warning attaches to the whole exercise. A wallet that appears to have lost a balance is the condition impersonators look for, and every check above is a public read you can perform for free. Nobody needs your recovery phrase to read a balance, and an offer to restore missing migrated tokens in exchange for one is a second loss dressed as a fix for the first.
The bottom line
A green swap transaction certifies that a call executed, and nothing more. The new balance is recorded at the new contract, as a transfer event at the moment of the credit and as a balanceOf reading afterwards, and both are readable without asking anyone. Until you have read them, you do not know whether this is a display problem or a payment problem.
When it is a display problem the sequence is short: switch to the right network, add the contract address by hand, and the balance is already there. When it is not, the transfer event names the address that was actually credited, and that field separates a payment sent to the wrong account from a payment that never happened. Settle which of the two you are looking at before you send anything else anywhere. To keep learning the fundamentals, follow more from Bitbase Academy.
Related reading
Other Bitbase articles on this topic:
- How to Calculate a Token Treasury Runway
- What Is a Crypto Token? Tokens vs Coins Explained
- Buy Walls, Sell Walls, and Order Book Depth
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.
References
[1] Ethereum Improvement Proposals, ERC-20: Token Standard (EIP-20, status Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-747: wallet_watchAsset RPC Method (status Final) eips.ethereum.org
