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 to each other. 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 message 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 actually mattered happened afterwards, and if something failed three hops down, the first hop still looks entirely successful.
Tonviewer traces the tree. Open one action and you see the whole cascade, with each message's fate. That is the product, and it is the difference between understanding what happened and guessing.
Jetton wallets, which confuse everyone
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 the thing that makes the model comprehensible rather than alarming.
From our testing
We traced a jetton transfer that appeared to have failed. The first hop succeeded, the second hop succeeded, and the third bounced because the recipient’s jetton wallet had not been deployed and the attached value was insufficient to deploy it. Two of the three explorers we tried showed a successful transaction. Only the full message trace revealed the bounce.
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: 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 is the field that explains the overwhelming majority of those cases.
TonAPI
Tonviewer is backed by TonAPI, which offers a free tier with a key and paid plans beyond it. It is a considerably friendlier surface than raw TON node access, because it does the same reassembly work the web interface does — you get traces rather than isolated messages.
That reassembly is exactly why you would use it rather than querying a node directly. Reconstructing a message tree from raw transactions across shards is real work, and the API doing it for you is most of the value.
For lighter needs, public TON HTTP endpoints exist and Tonscan is open source, which makes it the better starting point if you want to see how the data is assembled rather than trust that it was.
Tonviewer or Tonscan?
Tonviewer when you need to understand what happened — a transfer that did not arrive, a contract interaction with an unexpected result, anything involving more than one hop.
Tonscan when you want speed and simplicity, or when you want an open-source tool. It is lighter, it renders faster, and it does less decoding, which is sometimes exactly what you want.
Use both. On a chain this structurally unusual, a second rendering of the same data has caught more confusion for us than on any other network. And whichever you use, remember the two TON-specific rules: your tokens are not at your wallet address, and a successful transaction is not a successful outcome.