If a jetton transfer looks successful but the token is missing, first verify the receiving jetton wallet and its balance, not just the sender's transaction badge. TON uses a separate token-wallet contract for each holder of a jetton. A completed outgoing step, a delayed token list and a transfer of the wrong token can therefore produce very different explanations for the same empty wallet screen.
Keep three addresses on the investigation sheet
Record the receiving owner address, the intended token's master address and the holder's jetton-wallet address. The first is the destination account you meant to credit. The master identifies the token. The jetton wallet holds that owner's balance of that specific token. A long unfamiliar contract address in the trace does not by itself mean that the transfer went to a stranger.
The jetton standard describes this separation. Its wallet data includes the token balance, owner and master reference. The master can supply the expected wallet address for an owner. These are relationships to verify, not just labels to read from an arbitrary contract that calls itself a token wallet.
Start from the master published by the legitimate token project or the receiving service's supported-asset documentation. A copied name, ticker or image cannot authenticate it. Likewise, a contract's claim that it belongs to a trusted master is not enough on its own: compare the wallet derived from that trusted master with the one you are examining. Do not adopt a master supplied only by an unsolicited token message.
Trace the receipt rather than stopping at the first success
Open the transfer through the sending wallet's history or a trusted explorer. Follow the messages through to the receiving token wallet. TON's explorer guidance explicitly separates a successful sender transaction from the receiving execution. An overview can summarize a chain of actions, so inspect the part that should have changed the recipient's token balance.
Check execution errors, bounces and resulting token movements. Attached native network value is not the number of jettons received. For the token amount, use that token's own decimal metadata; do not infer its display precision from the network's native currency. If the receipt happened earlier and the current balance is zero, also inspect later outgoing activity before calling it a missing incoming transfer.
| Observation | Evidence still needed | Next useful action |
|---|---|---|
| Only the sender step is successful | The receiving token-wallet execution | Follow the message trace |
| A token wallet has the expected balance | Its verified master and owner relationship | Compare the trusted master's derived wallet |
| The correct balance exists but the app is blank | The selected owner address and wallet display settings | Refresh the view or check token visibility |
| The ticker matches but the master differs | Whether that master is actually the intended asset | Stop treating the name as proof |
| The historical receipt is correct, balance now zero | Later movements from that token wallet | Review the subsequent history |
| A service controls the receiving account | Its asset support and crediting record | Ask the service to investigate the specific deposit |
A verified balance and a missing display need different fixes
If the correct token exists at the correct owner's verified jetton wallet, focus next on the application. Check that you opened the intended account and network. Look for hidden-token controls using that wallet's current official help. A different restored account or a test-network view can make an otherwise correct receipt appear absent. Avoid importing your seed into another website merely to see a token list.
As one product-specific example, Walt's jetton help describes display delays and assets that are not shown because they are not reviewed or supported in the interface. This explains that product's behavior, not a universal Tonkeeper or other wallet menu. Its guidance is not evidence that an unfamiliar token is valuable or that another application supports the same asset.
Token visibility and market value are separate. Adding a genuine but unsupported token to a display does not create a market for it. Hiding a token does not erase its chain history. A missing fiat price is also different from a missing token quantity. Record exactly which of these is absent instead of asking support only why the balance is wrong.
Use a fictional comparison to narrow the cause
Suppose you expected 12 units of Example Jetton at owner A. The first trace shows a transfer instruction for 12, but the verified receiving wallet still has no incoming credit. You have not yet established delivery. In a second case, that wallet records the 12-unit receipt and still holds 12, while the app has no asset row. That is a display investigation. In a third, 12 units exist under another master with the same symbol. That is an asset-identity problem.
These examples are diagnostic alternatives, not claims about any real customer's transfer. They show why repeating the send is a poor first test. A new transfer can add a second payment without explaining the first. Paying an unsolicited agent an activation or verification fee likewise supplies no evidence about the original token contract.
Escalate with enough information to reproduce the check
- Save the original sending record and the expected owner address, token master and amount.
- Follow the trace to the receiving token wallet and record any execution failure or later outgoing movement.
- Verify the wallet relationship from the trusted master; distinguish current balance from the historical receipt.
- If chain evidence is correct, check the app account, network and token visibility using its official help.
- Send support the trace link, verified master, receiving owner, time and the exact display symptom. Keep recovery words and private keys out of the conversation.
A custodial deposit is a separate branch: onchain receipt at a service address does not automatically prove credit to your user account. The service may require supported assets and routing information. See USDT on TON and deposit comments for that distinction rather than trying to repair a service balance through your own wallet's visibility controls.
For a no-account swap, compare the actual order's asset, network and receiving instructions before sending. The order workflow is the relevant reference for that service step. Neither a successful sender badge nor a token appearing somewhere in TON replaces the check that the intended asset reached the intended destination.
FAQ
Why is my jetton balance missing after a successful transfer?
Check the receiving token-wallet execution and verified master relationship first. If the correct balance is there, investigate the selected account and the application's token display instead of sending again.
Why is the jetton wallet address different from my TON address?
The jetton wallet is a separate contract holding that owner's balance of a particular token. Verify that the trusted master derives that contract for your owner address rather than assuming any different address is an error.
Does a jetton transfer estimation failure prove that a token was sent?
No; an estimation error is not evidence of a completed receipt. Check whether a real transaction was submitted and follow any actual record to the recipient before deciding what to do next.