Reading a blockchain critically

A starting question

You open an explorer and read: "Transfer of 150 USDT from Alice (Exchange X) to Bob, 3 minutes ago, fee $0.40". How many of these words are facts written in a block? Very few. To see it, follow the data's path.

The data's path

node (blocks, state)  ->  indexer (decodes, files)  ->  database
                      ->  API  ->  website or app  ->  your screen

1. The node (the program that downloads blocks, checks the rules and holds the state; workshop 113) holds the blocks and state. It is the only stage that holds consensus bytes.
2. The indexer is software that reads the blocks, decodes them (which function was called? what amount?), and files them in an ordinary database so it can answer "all transactions of this address" quickly. It decides what it keeps and how to show it.
3. The API and the site add labels, prices, converted timestamps and charts.

Each stage is software written by a team, with its bugs, delays and choices.

Sorting the example

Out of six lines, only the amount and the status come from consensus data (the amount after decoding, the status after reading the receipt when the chain produces one); the relative time, the token's name, the label and the dollar price are derived or supplied by third parties. Even the amount is not "directly in the bytes": for a token, the indexer computes it from an event or the call data, and from a token metadata item (its number of decimals).

What is raw, what is not

Raw (consensus): a block's header and body, the signed transactions, the result of applying the rules (the state after the block, and receipts when the protocol produces them).

Derived: any interpretation, any grouping, any fiat value, any label ("Exchange X"), any ranking ("top holders"), any "internal transfer" reconstructed by replaying calls.

Example: a block's time

On Bitcoin and Ethereum-style chains, the displayed time is the timestamp the block producer wrote in the header, within limits the protocol checks only loosely. It does not come from a trusted clock. (On CometBFT, the time comes from a computation among validators: each chain family has its own rule.) The explorer converts it to a time zone (often UTC or your browser's). Two explorers may thus show "different" times for the same block without either lying: one shows UTC, the other local time (UTC+1 in Cameroon, with no daylight saving).

What this does NOT guarantee

• A well-known explorer is not an authority: it can lag, have a bug, be hacked (web page or domain) or be slow to follow a chain reorganisation.
• A figure consistent across three sites is not verified: they may read the same indexer or the same node provider.
• "It's on the blockchain" does not mean "it's true": it means "a participant signed it and the chain accepted it".

Recap

For each line on a screen, ask: is this fact in the block's bytes, or did someone compute, guess or add it? Only the first case can be verified directly against a node.

The problem

An explorer shows: "Block 9,000,010, contains your payment, 12 confirmations". How do you verify it without believing the explorer? By querying a node — ideally your own (workshop 113) — through its JSON-RPC interface.

JSON-RPC 2.0 in three lines

JSON-RPC 2.0 is a convention: you send a JSON object with four main fields, the server answers with an object carrying the same id.

-> {"jsonrpc":"2.0","method":"chain_getBlockByNumber","params":[9000010,false],"id":7}
<- {"jsonrpc":"2.0","result":{"number":9000010,"hash":"0x…","txCount":142},"id":7}

• jsonrpc is always "2.0"; method is the call's name; params the argument list; id links the response to the request. In the specification, params and id are optional (a request without id is a notification: the server does not answer it); in this course we always write them.
• On failure, the response contains error instead of result. The specification defines standard codes: -32700 (unparseable JSON), -32600 (invalid request), -32601 (unknown method), -32602 (invalid params), -32603 (internal error). Codes -32000 to -32099 are reserved for server-defined errors: real nodes use them for their own messages, hence the value of reading their documentation.

Three checks you can run

1. Does the block exist, with this hash? Ask for the block at the given number and compare the hash with the explorer's. If hashes differ, one of the two follows another branch or is behind.
2. Is the transaction in this block? The body is summarised by a Merkle root (workshop 106) in the header. A full node can give you the list; a light client asks for an inclusion proof and recomputes it: leaf, siblings, root. In the Merkle explorer, edit a leaf: the root changes, so the proof fails. With the hash tool, recompute a parent node yourself from two children.
3. What was the execution result? On chains that produce receipts, the "status" is in the receipt; ask the node for the receipt, do not trust a green icon.

Confirmations and finality

"12 confirmations" usually means that the transaction has 12 blocks in total since its inclusion block, that block included: it counts as the first confirmation, then 11 more blocks have been built after it (the workshop 109 convention; some tools count differently). It is not a finality guarantee. On a deterministic-finality chain (workshop 109), a transaction is final when the protocol says so, regardless of the number of blocks. On a probabilistic-finality chain, the more blocks, the less likely a reorganisation, without it becoming impossible.

Some node interfaces let you query state at a finality tag ("latest", "finalized" …). When your chain offers them, use them: reading "the most recent" and reading "the finalised" are two different claims.

Worked example: three sources, one disagreement

You are given:

• Explorer A: block 9,000,010, hash starting 0x4f3a.
• Explorer B: block 9,000,010, hash starting 0x4f3a.
• Your node: block 9,000,010, hash starting 0x91c2.

Two sources out of three agree, so A and B are right? No. A disagreement is a question, not a vote. Hypotheses: A and B read the same provider; your node is still syncing; or a reorganisation happened. You resolve it by asking your node for the finalised height and querying again later, not by counting heads.

Your own node is itself an assumption

If you query a provider's node, you trust that provider. If you query your own node, you trust your software, your version and the peers it is connected to (a node surrounded by malicious peers can be deceived, see workshop 113).

What this does NOT guarantee

• A node's answer is not a proof: it is an answer. Only a proof (Merkle, signatures) recomputed against a trusted header is one.
• Comparing block hashes does not verify that the rules were obeyed: only a full node that replays the block does.
• Querying once says nothing about finality.

Recap

To verify: ask a node for the raw data, recompute what can be recomputed, treat any disagreement as an investigation, and distinguish "most recent" from "final".

The problem

A dashboard announces: "1,000 active addresses per day". A young start-up uses it to say it has "1,000 users". Is that true? To find out, you must know each figure's definition, window and source.

What an indexer does — and assumes

An indexer turns blocks into queryable tables. In doing so it:

• decodes data: it must know the structure of calls (a contract's interface). If it is unknown or wrong, it shows raw bytes or a wrong name;
• chooses what to keep: some ignore failed transactions, malformed events or internal traces;
• handles reorganisations: when a block is replaced, it must undo what it filed. A poor indexer can keep data from an abandoned branch;
• lags by a variable number of blocks: it reads the chain, then writes to the database;
• adds external data: entity labels, fiat prices, rankings.

These are design choices, not errors. The danger is reading the result as a raw fact.

Metrics: ask three questions

For any figure:

1. Definition: what exactly is counted?
2. Window: over what period, with what cut-off time?
3. Reproducibility: can I recompute the figure from node data? If not, it is a claim, not a measurement.

Four traps with numbers

1. "Active addresses" ≠ users. An address is a key, not a person (workshop 112). One person can have hundreds of addresses; a script can create thousands in minutes. Example: the dashboard says 1,000 active addresses; an analysis shows 600 of them are controlled by one operator. There are therefore at most 400 + 1 = 401 distinct operators, and probably fewer. The most flattering figure is not the most accurate one.

2. Volume can be manufactured. An actor trading an asset with itself (wash trading) inflates "volume" without changing who holds what. Example: account A sends 100 units to an account B it controls, B sends them back, and this round trip repeats 50 times: displayed volume 10,000 units (50 × 2 × 100), capital actually at stake 100.

3. Locked value can be counted several times. Alice deposits 100 units into protocol P1 and receives 100 receipt tokens. She deposits those receipt tokens into P2 and receives 100 P2 receipt tokens, which she deposits into P3. Each protocol announces 100 of "value locked": the dashboard sum is 300 while the real distinct capital is 100.

4. Off-chain definitions. A "circulating supply" is not in the chain: the team decides which accounts do not count (reserves, locked). It is a published judgment, not a fact computed by the protocol.

Example: redoing a calculation

Figure to check: "1,000 transactions per day on average". Procedure: take a day's blocks (fixed cut-off time), count each block's transactions (txCount), add them up, compare. If the gap exceeds a few percent, look for the cause: failed transactions counted or not? time zone? blocks in the middle of a reorganisation?

What this does NOT guarantee

• Reproducing a figure does not make it relevant: a definition can be consistent and useless for your question.
• An "official" indexer is no more consensus than another: it is one more program.
• The absence of visible manipulation is not proof of its absence: read the definition before interpreting.

Recap

Every aggregate figure carries a definition, a window and assumptions. If it is not reproducible from node data, treat it as an opinion with a source, not as a fact.

The problem

Someone receives 200 "BACUSD" in their wallet and thinks it is a gift. The token is worthless: it is a decoy, and the "approval" page they are then offered can be used to obtain a signature that gives access to valuable funds. Display traps exploit a simple fact: names are not identities.

A token's identity = the contract address

A token's name ("BACUSD") and symbol are strings chosen by whoever deploys the contract. Nothing in the protocol stops two contracts having the same name or logo. The identity is the chain + the contract address, to be compared with the project's official source (its documentation or repository).

Fictitious example:

Official token contract (from the project's docs):  0xAAAA...0001
Token transfers received by your account:
 +500  "BACUSD"  from contract 0xAAAA...0001
 +200  "BACUSD"  from contract 0xBBBB...0042

The two lines look the same; only one is the real token. An identical symbol, a copied logo, a "verified" badge on a platform: none of these replaces the address comparison.

Other classic traps

• Address poisoning: an attacker sends you a tiny transaction from an address whose start and end resemble your contact's. Later you copy the address "from history" and send to the attacker. Defence: compare the full address, character by character or through a trusted address book, and never copy from history.
• Name-squatting contracts: a contract carries a name close to a known project's. A contract's name is not unique.
• Unsolicited transfers: anyone can send you a token; receiving it does not mean you asked for it or that it has value. An interaction (approving, signing) is a separate act.
• Dollar values without a market: an illiquid token can show a fanciful price. The displayed value comes from a provider, not from the chain.

Centralisation and trust assumptions

An explorer or node provider is a centralised service: a company, a domain, servers, a team.

A "decentralised" dashboard may depend on a single node provider or a single database. Before believing a system, look for its single point of failure.

What an explorer can — and cannot — prove

An explorer proves nothing by itself: it is a witness, not a proof. It can point you to a block and a transaction that you then verify (lesson 2). It cannot prove:

• that the label "Exchange X" is accurate;
• that the block is final (it often shows the latest);
• that the token shown is the right one;
• that the dollar price is that of a real market;
• that you see the same thing as everyone else.

A reasonable practice

For any decision involving money: (1) read the full address and the contract's address; (2) confirm the data over a second, independent path, ideally your node; (3) wait for the finality suited to the amount; (4) sign nothing you do not understand.

What this does NOT guarantee

• Comparing a contract's address with the official documentation does not protect you if the documentation itself is spoofed: check that you are on the official source (site address typed by hand, or the organisation's official repository).
• A verified contract (published source code) is not an honest contract: "verified" means the published code matches the deployed code, not that it is safe.
• These rules reduce risk, they do not remove it.

Recap

Names and logos are not identities; the address is. An explorer is a centralised witness. For a money decision, confirm over an independent path.