How to read a block explorer, and why it settles most arguments

Almost every anxious question in crypto — where is my transfer, did it go through, was that the right address, is this token real — is answerable in under a minute from a public source that requires no account and no permission. That source is a block explorer, and most people never learn to read one.

This matters beyond convenience. The entire argument for a public ledger is that you do not have to take anyone’s word for the state of it. An explorer is where that promise becomes usable, and it is the same principle behind our own insistence that every figure we publish carries its source and the moment it was read.

What an explorer actually is

It is a search interface over the chain. It runs a full node, indexes everything that node sees, and presents it in a readable form. It has no privileged access and cannot alter anything — it is a reader, exactly like you, with better tooling.

That has a useful consequence: if two explorers disagree about something, one of them has an indexing bug, because the underlying data is identical. Checking a second explorer is a free sanity test and occasionally a revealing one.

The fields worth understanding

Status. Pending means broadcast but not yet included in a block. Success means included and executed. Failed means included, executed, and reverted — and it is the field people most often misread, because a failed transaction still consumed its fee and still appears in the history. Money left your wallet and nothing else happened.

Confirmations. How many blocks have been added since. This is a measure of confidence accumulating rather than a state that flips, which is why platforms require different numbers for different amounts.

From and To. The addresses involved. If the destination is a contract rather than a wallet, the explorer will usually say so, and that distinction matters a great deal.

Value and fee. The amount moved and what it cost. On a failed transaction the value is zero and the fee is not.

Nonce. On account-based networks, a per-account counter. Transactions must process in order, so a stuck low-nonce transaction blocks every later one from that account — which explains the otherwise baffling situation where a new transaction will not confirm no matter what fee you attach.

Input data or method. What the transaction actually asked for. A transfer looks like a transfer. An approval looks like an approval, and knowing the difference is genuinely protective.

The checks that answer real questions

“Did my withdrawal actually happen?” A platform saying “processing” has told you about its internal queue, not the network. If there is no transaction hash, nothing was broadcast and the delay is entirely on their side. If there is a hash, paste it into an explorer and you will see the truth regardless of what the dashboard says.

“Is this the right token?” Anyone can create a token with any name and symbol, and impersonation is trivial. The contract address is the only real identifier. Take it from the project’s own documentation, never from a search result or a message, and check that the explorer shows it as verified with a plausible holder count and history. A token created last week with eleven holders is not the established asset it is named after.

“What did I approve?” Most explorers list the approvals an address has granted. Reviewing that list periodically, and revoking what you no longer use, closes the most common route to losing tokens long after the interaction that caused it.

“Is this address what they say it is?” Age, transaction count and balance history are all visible. An address described as an established treasury that was created a fortnight ago is telling you something.

Reading a contract page

An address belonging to a contract shows more than a wallet does, and three parts of it are worth knowing.

The source code tab shows whether the deployed bytecode has been matched against published source. Verified means the code you can read is genuinely the code that runs. Unverified does not prove malice — plenty of legitimate contracts are unverified — but it means nobody outside the deployer can review what it does, and that is a meaningful thing to accept before granting it permission over your tokens.

The read functions let you query the contract’s current state without spending anything: total supply, an owner address, whether transfers are paused. For a token, checking that supply matches what the project claims takes a few seconds and occasionally does not match.

The holders view shows distribution. A token where a handful of addresses hold nearly all supply behaves very differently from one that is widely distributed, and that concentration is visible before you buy rather than after.

When two explorers disagree

Occasionally an explorer will show a balance or a status that contradicts your wallet, and the instinct is to assume the chain is wrong. It almost never is. Wallets cache aggressively and sometimes display a stale figure; explorers index continuously but can lag by moments during heavy activity.

The resolution is to check a second explorer and, if they agree with each other, treat the wallet as the outlier and refresh or re-add the account. The chain is the authority, and the tools around it are conveniences that can each be wrong in their own way.

What an explorer cannot tell you

It shows what happened, not what it meant. Addresses are pseudonymous, so unless an entity is labelled you cannot know who controls one, and labels are the explorer’s own annotation rather than fact.

It cannot tell you whether a contract is safe. Verified source code means the published code matches what is deployed — it does not mean the code is sound or benign. It cannot recover anything, reverse anything, or contact anyone. And it will not tell you a transfer went to the wrong person, only that it went where it was addressed.

Why we think this is worth learning

A reader who can check the chain is not dependent on any publication, including this one. That is the correct arrangement. We publish our provider and timestamp beside every market figure precisely so the claims can be tested rather than trusted, and our Methodology lists what we do not verify.

The habit generalises. Verify the transaction rather than the dashboard, the contract address rather than the name, and the approval list rather than your memory of it. Terms used here are defined in the glossary, and the defences that follow from this are in our security coverage.