[{"data":1,"prerenderedAt":41},["ShallowReactive",2],{"blog-content-en-how-to-read-a-block-explorer":3},{"slug":4,"title":5,"excerpt":6,"description":7,"bodyHtml":8,"howToSteps":9,"faqItems":25},"how-to-read-a-block-explorer","How to Read a Block Explorer: Etherscan, Solscan and Tonviewer","To read a block explorer, paste a hash or address into Etherscan, Solscan or Tonviewer and read status, fee and token transfers — the fields that show what actually happened. Here is how to check total supply, contract verification, your own approvals, and whether a claimed burn was real.","How to read a block explorer: transaction status, fees, token transfers and logs on Etherscan, Solscan and Tonviewer, plus supply and contract verification, approval checks, and auditing a burn claim such as the ATS burn behind the WATS fee model.","\u003Cblockquote>\u003Cp>To read a \u003Cstrong>block explorer\u003C\u002Fstrong>, 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.\u003C\u002Fp>\u003C\u002Fblockquote>\n\u003Ch2>What a block explorer actually is\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\n\u003Ch2>Is a block explorer the same as the blockchain?\u003C\u002Fh2>\n\u003Cp>No — and the distinction matters. The chain itself is raw data replicated across thousands of nodes. An explorer is one company's indexed \u003Cem>view\u003C\u002Fem> 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 \u003Ca href=\"\u002Fblog\u002Fwhat-is-an-rpc-node\">an RPC node\u003C\u002Fa>, which is why a wallet can work perfectly while an explorer is down or lagging.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\n\u003Ch2>How do you read a transaction page?\u003C\u002Fh2>\n\u003Cp>Paste any transaction hash into the search bar and you get the full anatomy of what happened. The fields worth reading, in order:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Status\u003C\u002Fstrong> — success or failed. Success means the code executed without reverting; a failed transaction changed nothing but still paid a fee.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Block and confirmations\u003C\u002Fstrong> — where it landed and how many blocks have been built on top since.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>From and to\u003C\u002Fstrong> — the signing address and the target, which for a token transfer is the token \u003Cem>contract\u003C\u002Fem>, not the recipient.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Transaction fee\u003C\u002Fstrong> — what was actually paid, in the chain's native coin.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Token transfers and logs\u003C\u002Fstrong> — the events the contracts emitted: which tokens moved, from whom, to whom, in what amounts.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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 \u003Ca href=\"\u002Fblog\u002Fwhat-is-blockchain-finality\">blockchain finality\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Ch2>How do you read a token page?\u003C\u002Fh2>\n\u003Cp>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. \u003Cstrong>Total supply\u003C\u002Fstrong> is read directly from the contract. \u003Cstrong>Holders\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Contract verification\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\n\u003Ch2>How do you check your own approvals?\u003C\u002Fh2>\n\u003Cp>Search your own address and you get your complete public history — and, more usefully, your standing \u003Cstrong>token approvals\u003C\u002Fstrong>: 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.\u003C\u002Fp>\n\n\u003Ch2>Did that token burn actually happen? Check it yourself\u003C\u002Fh2>\n\u003Cp>Projects love announcing burns; explorers let you audit them. A real \u003Ca href=\"\u002Fblog\u002Fwhat-is-a-token-burn\">token burn\u003C\u002Fa> 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.\u003C\u002Fp>\n\n\u003Ch2>What changes on Solscan and Tonviewer?\u003C\u002Fh2>\n\u003Cp>The literacy transfers; the objects differ. On Solana, a transaction is a bundle of \u003Cem>instructions\u003C\u002Fem> 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 \u003Cem>messages\u003C\u002Fem> 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.\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>\u003C\u002Fth>\u003Cth>Ethereum — Etherscan\u003C\u002Fth>\u003Cth>Solana — Solscan\u003C\u002Fth>\u003Cth>TON — Tonviewer\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Unit you read\u003C\u002Ftd>\u003Ctd>Transaction in a block\u003C\u002Ftd>\u003Ctd>Bundle of instructions\u003C\u002Ftd>\u003Ctd>Chain of messages\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Fee shown in\u003C\u002Ftd>\u003Ctd>ETH (gas)\u003C\u002Ftd>\u003Ctd>SOL (base plus priority)\u003C\u002Ftd>\u003Ctd>TON (gas, storage, forwarding)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Token model\u003C\u002Ftd>\u003Ctd>Balances inside the token contract\u003C\u002Ftd>\u003Ctd>Per-owner token accounts\u003C\u002Ftd>\u003Ctd>Per-owner jetton-wallet contracts\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\n\u003Ch2>How WATS fits in\u003C\u002Fh2>\n\u003Cp>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 \u003Ca href=\"\u002Fhot-wallet\">WATS Hot Wallet\u003C\u002Fa> every transaction is charged in one token, \u003Cstrong>ATS\u003C\u002Fstrong>, 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.\u003C\u002Fp>\n\u003Cp>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 \u003Ca href=\"\u002Fats-fee\">ATS fee page\u003C\u002Fa> in terms you can go and verify on chain rather than believe.\u003C\u002Fp>",[10,13,16,19,22],{"title":11,"body":12},"Open the transaction by its hash","Copy the transaction hash from your wallet's activity view and paste it into the search bar of the right explorer — Etherscan for Ethereum (its sister explorers cover most other EVM chains), Solscan for Solana, Tonviewer for TON. If you only have an address, open the address page instead and locate the transaction in its history by time and amount. Bookmark the transaction page; the hash is your permanent receipt.",{"title":14,"body":15},"Read the status and the fee first","Check the status line before anything else: success means the code ran without reverting, failed means nothing changed except the fee was spent. Then read the fee itself — the amount actually paid in the chain's native coin — and the block number with its confirmation count, which tells you how deeply buried, and therefore how settled, the transaction is.",{"title":17,"body":18},"Inspect token movements and logs","Scroll to the token-transfers section and read what actually moved: which tokens, in what amounts, between which addresses. This is the ground truth of the transaction — a swap may emit several transfers as it routes through pools. If something looks off, open the logs: the raw events emitted by each contract, which record exactly what the code did rather than what any interface claimed.",{"title":20,"body":21},"Verify a contract or supply claim","Open the token's page by its contract address, never by ticker. Confirm the contract is verified — source code matched to on-chain bytecode — and read the total supply straight from the page. For a claimed burn, ask for the transaction hash and check that tokens went to a dead address or that supply actually decreased; a transfer to a team-controlled wallet is not a burn.",{"title":23,"body":24},"Audit your own approvals","Search your own address and review the token approvals you have granted over time — permissions for contracts to move your tokens. Use the explorer's approval checker where one exists, look for unlimited allowances to contracts you no longer use, and revoke anything you do not recognize. Make this a quarterly habit; stale approvals are the quietest risk an address carries.",[26,29,32,35,38],{"q":27,"a":28},"Is a block explorer the same as the blockchain?","No. The blockchain is raw data replicated across many nodes; an explorer is one company's indexed, human-readable view of that data, served as a website. Explorers can lag, and their name tags and warning labels are editorial additions, not consensus data. Raw fields — balances, transactions, contract code — should match on any explorer of the same chain, and the chain itself remains the source of truth.",{"q":30,"a":31},"How do I verify a token burn on a block explorer?","Ask for the transaction hash and open it. A genuine burn shows tokens transferred to a dead address — one with no known private key, whose balance anyone can inspect — or a burn function call that visibly reduces the token's total supply. Then check the token page: supply should be lower than before. If the tokens simply moved to a wallet the team controls, nothing was burned. The same check applies to the ATS burn behind the WATS fee model, which takes supply from 100M down toward a 30M floor: WATS states the mechanism, and the explorer is where you confirm it.",{"q":33,"a":34},"Why does my transaction say success but the tokens have not arrived?","First check the token-transfers section of the transaction page — it shows what actually moved, and success only means the code executed without reverting, not that it did what you expected. If the transfer is there, the recipient wallet may simply not display that token yet; adding the contract address usually fixes it. If it points to a different address, re-check where you actually sent the funds.",{"q":36,"a":37},"Why does the explorer show my fee in ETH when my wallet charged me in a token?","Because the network is always paid in its own coin, whatever you were charged. The WATS Hot Wallet is a concrete example: it charges every fee in ATS using an ERC-4337 paymaster on EVM chains and the equivalent fee-payer on Solana and TON, so the explorer's transaction-fee field still shows native gas — handed over by the paymaster — while the ATS you actually spent appears as a token transfer in the same transaction's logs. Reading those two fields side by side is the clearest way to see the mechanism: it changes which token pays, not what the block space costs.",{"q":39,"a":40},"Which explorer should I use for the chain I am on?","Etherscan for Ethereum, with its sister explorers covering most EVM chains — Arbitrum, Optimism, Base, Polygon and BNB Chain each have one — plus Solscan for Solana and Tonviewer for TON. A multi-chain wallet therefore spans several explorers at once: WATS supports Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, so reading a full history means opening the right explorer per chain rather than one universal site. On every one of them, search a token by its contract address rather than its ticker, since anyone can deploy a token under any name.",1786059326946]