Showing rather than interpreting
Every explorer sits somewhere on a line between raw data and interpretation. Tonviewer sits firmly at the interpretive end: it reassembles message trees, decodes contract calls and presents a narrative. Tonscan sits nearer the middle.
That is a real trade-off rather than a shortcoming. Interpretation is a rendering, and renderings can be wrong — a decoder that does not recognise a new contract pattern will silently present something misleading rather than admitting ignorance. A plainer explorer shows you the shape of what happened and lets you draw the conclusion.
It also makes it faster. Tonscan returns before Tonviewer has finished assembling, which on a chain producing blocks every five seconds is noticeable when you are checking repeatedly.
Why open source matters here specifically
TON's data model is unusual enough that explorers make real decisions about presentation. How do you attribute a bounced message? Which transaction in a chain is "the" transaction? How do you present a jetton balance that lives in a separate contract?
Different explorers answer differently, which is why two TON explorers can show the same activity in visibly different ways. With Tonscan you can read the answer rather than infer it, and when it disagrees with Tonviewer you can find out why instead of guessing which to trust.
It also means you can run it against your own TON node, which removes the third party entirely. That path is less documented than Esplora's or Blockscout's, but it exists, and on a chain where the alternatives are all closed that matters.
Jettons and NFTs
Tonscan lists jetton holdings clearly, with the master contract address alongside the balance. That second field is the one to use: jetton names are arbitrary and duplicated freely, and the master address is the only reliable identifier.
NFT handling covers collections and individual items, including TON DNS names, which are themselves NFTs. It will not show you the full provenance chain the way a dedicated marketplace does, but for confirming what an address holds it is direct and quick.
What it will not do is walk you through a failed jetton transfer. If a transfer bounced three hops in, Tonscan shows the transactions and leaves the reconstruction to you. That is precisely when to switch tools.
When to use which
A simple division that has worked well for us.
Tonscan for questions with short answers: what is this balance, does this address exist, did this transaction happen, what is the master contract of this jetton. It answers those faster and with less to read.
Tonviewer for questions that need a story: why did this not arrive, what did this contract interaction actually do, where did the value stop. Reassembly is its job and it does it well.
And when the two disagree, that disagreement 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.
What our reference tests showed
We put Tonscan through the same items we use on every TON explorer: a plain TON transfer, a jetton transfer to an already-deployed wallet, a jetton transfer to an address with no jetton wallet yet, an NFT transfer, and a deliberately underfunded message designed to bounce.
The plain transfer and both jetton transfers rendered correctly and quickly. Balances matched what Tonviewer reported to the last nanoton, which is the reassurance you want from a second source — when two independently-maintained indexes agree, the number is almost certainly right.
The NFT transfer showed ownership change cleanly, with the collection identified. Where Tonscan visibly did less was the bounce case. The bounced message was present in the transaction list, but it was not surfaced as a failure in the way Tonviewer's trace view does, and working out that the transfer had not completed required reading the individual messages rather than being told.
That is the trade-off stated plainly. On four of our five reference items Tonscan was equal to or faster than the alternative. On the fifth — the one that only matters when something has gone wrong — it required more of the reader.
The speed difference was consistent rather than marginal. Across repeated lookups Tonscan returned rendered pages noticeably sooner, which on a chain producing blocks every five seconds changes how it feels to check something repeatedly while waiting for confirmation.
Our conclusion from the testing is the same as our conclusion from using it: keep both open. Tonscan answers the question you have most often, and when the answer is confusing, the other one explains why.
Who should use Tonscan
Anyone checking a TON balance, a jetton holding or an NFT. It answers those faster than anything else and with less to read.
Anyone who wants an explorer whose code they can inspect. On a chain where the alternatives are closed, that is not a small thing, and the assembly logic for TON data involves real decisions worth being able to check.
Anyone running their own TON node, since pointing an open-source explorer at your own infrastructure removes the third party entirely.
Not anyone trying to work out why a transfer did not arrive. That is Tonviewer's job, the message-trace reconstruction is the thing it exists for, and Tonscan does not attempt it to the same depth. Keeping both bookmarked is the sensible arrangement rather than a compromise.