Why TON breaks ordinary explorers
TON is built on an actor model. Every contract is an independent actor with its own state, and contracts communicate only by sending messages. There are no synchronous calls — a contract cannot call another and wait for the answer within the same execution.
So a single user action decomposes into a sequence. You send a message to your wallet contract. It sends a message to a jetton wallet. That sends a message to the recipient's jetton wallet. That may send a notification onward. Each hop is a separate on-chain transaction, in a separate block, possibly in a separate shard.
An explorer that shows you "the transaction" shows you the first hop. Everything that mattered happened afterwards, and if something failed three hops down, the first hop still looks entirely successful.
This is the same structural pattern as NEAR receipts and Polkadot XCM, and it produces the same category of confusion. On TON it is more acute because it affects even the simplest token transfer.
Jetton wallets, and where your tokens actually are
TON's token standard is called Jetton and it does not work like ERC-20.
On Ethereum, one token contract holds a mapping of every holder's balance. On TON, each holder gets their own jetton wallet contract, deployed separately, holding only their balance. The master contract governs the token; it does not store who owns what.
This is a deliberate scaling decision — it avoids a single contract becoming a bottleneck across shards — and it produces a specific, recurring confusion: your token balance is not at your wallet address. It is at a derived jetton wallet address that your wallet owns.
People send tokens to the wrong one of these constantly. Tonviewer labels them explicitly, showing the owner alongside every jetton wallet, which is what makes the model comprehensible rather than alarming.
The other consequence is that receiving a jetton for the first time requires deploying your jetton wallet, which costs a small amount attached to the transfer. If the sender attached too little, the transfer bounces — and that is the failure mode the next section covers.
Bounced messages, TON’s version of a revert
When a TON message cannot be processed, it bounces: the value returns to the sender, minus fees. This is the normal failure mode and it is nothing like an EVM revert, because the original transaction has already succeeded by the time the bounce happens.
The practical implication is worth stating twice. On TON, a successful transaction does not mean a successful outcome. It means your message was accepted for delivery. What happened at the other end is a separate event that may arrive seconds later.
Tonviewer marks bounced messages clearly in the trace. If a transfer "went through" and the recipient reports nothing, this is the first place to look, and it explains the overwhelming majority of those cases.
In our own testing we traced a jetton transfer that two explorers showed as successful. The first hop succeeded, the second succeeded, and the third bounced because the recipient's jetton wallet had not been deployed and the attached value was insufficient to deploy it. Only the full message trace revealed it.
Working with TON without being surprised
Three habits make TON considerably less confusing.
First, always look at the full trace rather than the transaction. If your explorer does not offer one, you are using the wrong explorer for that question.
Second, identify jettons by their master contract address rather than by name. Jetton names are arbitrary and duplicated freely, exactly as token names are on every other chain, and the separate-wallet architecture makes it slightly easier to become confused about which contract you are actually looking at.
Third, keep both explorers bookmarked. On a chain this structurally unusual, a second rendering of the same data has resolved more confusion for us than on any other network. When Tonviewer and Tonscan disagree, the disagreement itself is information — it usually means one of them is handling an unusual message pattern differently, and the raw view is the one to trust while you work out which.
Shards, and why block heights do not mean what you expect
TON is sharded, and the sharding is dynamic — the network splits and merges shards according to load rather than running a fixed number.
The consequence for anyone reading an explorer is that there is no single block height. There is a masterchain, which coordinates, and workchain shards each producing their own blocks. A transaction lives in a shard block, which is then referenced by a masterchain block.
So comparing "block height" figures between TON and another chain is meaningless, and comparing them between two TON explorers may be comparing different things. Explorers generally surface the masterchain sequence number as the headline figure, which is the sensible choice and not the only defensible one.
Finality follows the masterchain. A transaction included in a shard block is final once that shard block is referenced by a masterchain block, which happens quickly but is a second step rather than the first.
None of this affects ordinary use. It matters when you are reconciling data between tools, building anything that tracks confirmations, or trying to understand why two explorers report different numbers for what looks like the same thing.
It is also the underlying reason for the asynchrony that dominates the rest of this page. Contracts on different shards cannot call each other synchronously because the shards are not in lockstep — the message model is not a design preference, it is a consequence of the sharding.