How to Read a Block Explorer: Etherscan, Solscan and Tonviewer

To read a block explorer, paste a transaction hash or an address into the explorer for that chain — Etherscan for Ethereum, Solscan for Solana, Tonviewer for TON — and read four things in order: the status (success or failed), the block and confirmation count, the fee actually paid in the chain's native coin, and the token-transfer log, which is the only place that shows what really moved. An explorer is not the blockchain itself; it is one company's indexed, human-readable view of it, so the raw fields are consensus data while name tags and warning labels are the explorer's own editorial additions. Those fields are what turn an unverifiable claim into a checkable one: a token page reads total supply straight from the contract, an address page lists the approvals you have granted, and a burn is only real if a hash shows tokens reaching a dead address or total supply actually falling. That last check applies to any project's numbers, including the ATS burn from 100M down toward a 30M floor behind the WATS fee model — it is on-chain, so the public explorers above are what prove it, not anything WATS runs itself.

What a block explorer actually is

An explorer is a searchable, human-readable index of blockchain data. It ingests every block as it is produced, decodes the contents into fields a person can read — status, fee, token transfers, contract source — and puts a search bar in front of them. No account, no permission, no fee: the chain is public data, and the explorer is simply the reading interface most people use.

Everything on an explorer is a link: click a block and see its transactions, click an address and see its history, click a token and see every wallet that holds it. Learning to follow those links is what turns 'trust me' claims into things you can check yourself, and the rest of this guide is a tour of the fields that do the checking.

Is a block explorer the same as the blockchain?

No — and the distinction matters. The chain itself is raw data replicated across thousands of nodes. An explorer is one company's indexed view of that data: it runs nodes, parses every block into a database, and adds a presentation layer on top. Your wallet does not need an explorer to move funds — it reads and writes the chain through an RPC node, which is why a wallet can work perfectly while an explorer is down or lagging.

Raw facts — balances, transactions, contract code — should match on any explorer of the same chain. Labels are different: name tags and warning flags are editorial additions by the explorer's team, useful but not consensus data. Trust the raw fields; treat the annotations as helpful opinion.

How do you read a transaction page?

Paste any transaction hash into the search bar and you get the full anatomy of what happened. The fields worth reading, in order:

• Status — success or failed. Success means the code executed without reverting; a failed transaction changed nothing but still paid a fee.
• Block and confirmations — where it landed and how many blocks have been built on top since.
• From and to — the signing address and the target, which for a token transfer is the token contract, not the recipient.
• Transaction fee — what was actually paid, in the chain's native coin.
• Token transfers and logs — the events the contracts emitted: which tokens moved, from whom, to whom, in what amounts.

The transfers section is the one that answers 'what did this transaction really do' — a single swap can emit half a dozen transfers as it routes through pools. And note what status does not tell you: success means included and executed, not irreversible. Whether a transaction can still be reordered out of the chain is a separate question of blockchain finality.

How do you read a token page?

Search a token by its contract address — not its ticker, since anyone can deploy a token with any name — and the token page shows the numbers that matter. Total supply is read directly from the contract. Holders is the explorer's count of addresses with a balance, and the holder list shows concentration: a token where three wallets hold most of the supply behaves very differently from one spread across a hundred thousand.

Contract verification is the quiet trust signal. A verified contract means the developer uploaded the source code and the explorer confirmed it compiles to the exact bytecode on chain — so anyone can read what the contract actually does. Unverified code is not automatically malicious, but it removes your ability to check, and established projects verify as a matter of course.

How do you check your own approvals?

Search your own address and you get your complete public history — and, more usefully, your standing token approvals: permissions you have granted contracts to move tokens on your behalf. Etherscan offers a dedicated token-approval checker for exactly this. Old, unlimited approvals to contracts you no longer use are the classic slow-burning risk attached to an address; reviewing them a few times a year, and revoking what you do not recognize, is basic hygiene that takes minutes.

Did that token burn actually happen? Check it yourself

Projects love announcing burns; explorers let you audit them. A real token burn is publicly verifiable in one of two shapes: tokens sent to a dead address — an address with no known private key, whose balance anyone can inspect — or a burn function call that reduces the contract's total supply on the spot. Ask for the transaction hash, open it, and read the transfer yourself. If the tokens merely moved to a wallet the team controls, that is not a burn — it is a relabel. The habit generalizes: any on-chain claim that cannot be shown as a hash deserves suspicion.

What changes on Solscan and Tonviewer?

The literacy transfers; the objects differ. On Solana, a transaction is a bundle of instructions executed together, one account is designated the fee payer, and tokens live in dedicated token accounts rather than as entries inside one contract — and how settled a transaction is comes from Solana's commitment levels, processed, confirmed and finalized, rather than from a running count of blocks built on top. On TON, everything is a smart contract, including your wallet; a transfer is a chain of messages between contracts that can bounce back on failure, and each token — a jetton — is held by a small per-owner jetton-wallet contract. Tonviewer renders those message chains as a single flow.

	Ethereum — Etherscan	Solana — Solscan	TON — Tonviewer
Unit you read	Transaction in a block	Bundle of instructions	Chain of messages
Fee shown in	ETH (gas)	SOL (base plus priority)	TON (gas, storage, forwarding)
Token model	Balances inside the token contract	Per-owner token accounts	Per-owner jetton-wallet contracts

How WATS fits in

WATS does not run a block explorer, and that is the right arrangement: a wallet's claims are worth more when a neutral third party is what proves them. What WATS does have is a claim that belongs in this article. In the WATS Hot Wallet every transaction is charged in one token, ATS, instead of each chain's native gas coin — through an ERC-4337 paymaster on the EVM chains and the equivalent fee-payer on Solana and TON. Because ATS is a LayerZero OFT, a single balance covers Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, and collected ATS is burned, taking supply from 100M down toward a 30M floor.

That last sentence is exactly the kind of statement this guide tells you not to take on faith — so do not. Run the burn check from the section above on it: get a hash, open it on the explorer, and confirm the tokens reached a dead address or that total supply on the token page actually fell. The practical step this article leads to is choosing tools whose claims survive that treatment, and WATS is built to be read that way — non-custodial, so you hold your keys and WATS never holds one, with the fee mechanics laid out on the ATS fee page in terms you can go and verify on chain rather than believe.