Module 3: How Blockchains and Transactions Work
Reading a Block Explorer Like a Professional
Chapter 6 of 13 · about 6 minutes
6.1 The source of truth
Mint's friend claimed to have sent the 50 USDC they owed Mint. "Check your wallet," the friend said. "I sent it an hour ago."
Nothing had arrived. The friend sent a screenshot of a wallet saying "sent." Mint was about to argue when Hash said, "Don't argue. Ask for the transaction hash. The blockchain will settle it."
The hash showed the transaction had failed. The friend's wallet had shown "sent" because the transaction was submitted, but it ran out of gas. No USDC ever moved.
Wallets, exchanges, and apps all show you their interpretation of the blockchain. A block explorer shows you the blockchain itself. Learning to read one is like learning to read a bank statement, except it's public, permanent, and doesn't depend on trusting anyone's interface.
6.2 The transaction page
When you paste a transaction hash into an Ethereum block explorer, you'll see a page with many fields. Here are the ones that matter most.
| Field | What it tells you |
|---|---|
| Transaction hash | The unique ID of this transaction |
| Status | Success, failed, or pending. The single most important field |
| Block | Which block included it, and how many confirmations it has |
| Timestamp | When the block was produced |
| From | The address that signed and sent it |
| To | The recipient address, or the smart contract that was called |
| Value | The amount of the native coin (ETH) sent. Often 0 for token transactions |
| Token transfers | Which tokens moved, between which addresses, and how much |
| Transaction fee | The total gas fee paid |
| Gas price, gas used, gas limit | The components of the fee, from Chapter 2 |
| Nonce | The sender's transaction count, from Chapter 4 |
| Input data | The instructions sent to a smart contract, often decoded into a readable function name |
6.3 Value versus token transfers
This catches out many beginners. When Mint's friend sent USDC, the "Value" field showed 0 ETH, even on a successful transaction. That's because USDC is a token, not ETH.
When you send a token, the transaction is actually a call to the token's smart contract, saying "transfer 50 USDC from my balance to this address." The ETH value is zero. The token movement appears in a separate token transfers section.
| What you sent | "To" field shows | "Value" field shows | Where to see the amount |
|---|---|---|---|
| ETH | The recipient's address | The ETH amount | Value field |
| A token like USDC | The token's contract address | 0 ETH | Token transfers section |
| A swap | The DEX contract address | Often 0, or the ETH amount if swapping from ETH | Token transfers section, showing tokens in and out |
"So if I see 'Value: 0' I shouldn't panic," said Mint.
"Check the token transfers first," said Hash. "And the status."
6.4 Reading a swap
Let's read the transaction from one of Mint's swaps: 1,000 USDC for ETH on a decentralised exchange.
| Field | What Mint saw | Interpretation |
|---|---|---|
| Status | Success | The swap executed |
| From | Mint's address | Mint signed it |
| To | A DEX router contract | Mint called the DEX's main contract |
| Method | Swap exact tokens for ETH (or similar) | The function name, decoded from the input data |
| Token transfers | 1,000 USDC from Mint to a liquidity pool; WETH from the pool to the router | USDC went in, wrapped ETH came out of the pool |
| Internal transactions | 0.33 ETH from the router to Mint | The router unwrapped WETH and sent ETH to Mint |
| Fee | 0.0033 ETH | The gas cost |
Two new terms appear here. WETH is "wrapped ETH," an ERC-20 token version of ETH that many smart contracts use internally, since ETH itself isn't an ERC-20 token. Internal transactions are movements of ETH triggered by smart contracts during execution, rather than by the sender directly. They don't have their own transaction hash, so explorers show them in a separate tab.
6.5 Logs and events
Smart contracts publish events, also called logs, when important things happen: a transfer, an approval, a swap, a deposit. The token transfers section is built from these events. Advanced users read the logs tab directly to see exactly what a contract reported.
You don't need to read raw logs often. But when an explorer's summary seems confusing, the logs usually explain what happened.
6.6 The address page
Paste an address instead of a transaction hash, and you'll see its full history: its native coin balance, the tokens it holds, every transaction it has sent or received, and often a label if the address is publicly known, such as an exchange hot wallet, a well-known protocol, or a flagged scam address.
Two cautions:
Token balances can include spam. As Module 2, Chapter 9 explained, scammers send fake tokens to many addresses. Explorers often hide or flag these, but not always.
Labels can be wrong or missing. A label is helpful context, not a guarantee. Most addresses have no label at all.
6.7 The contract page
When an address is a smart contract, the explorer shows a Contract tab. If the developers have published and verified the source code, you'll see it there, along with options to read the contract's current data and, with a connected wallet, write to it by calling its functions.
Verified contracts have source code that the explorer has confirmed matches the deployed code. Unverified contracts only show compiled bytecode, which is nearly impossible for humans to read. An unverified contract asking for your approval is a serious warning sign.
6.8 Using explorers to protect yourself
Block explorers aren't just for curiosity. They're a safety tool.
Verify payments by checking status and token transfers, not screenshots.
Check token contracts before buying: is it the verified, official contract (Module 1, Chapter 5)? How many holders does it have, and how concentrated are they?
Check approvals, since many explorers include an approval checker (Module 2, Chapter 8).
Investigate a suspicious address before interacting: is it labelled as a scam? Is it brand new with no history?
Provide evidence: when contacting an exchange or reporting a theft, the transaction hash is what everyone will ask for (Module 2, Chapter 14).
"Every blockchain has its own explorer?" Node asked.
"Most blockchains have at least one, and many have several," said Hash. "They all show the same underlying data. The layout is different, but once you can read one, you can read them all."
6.9 Try it yourself
Find a swap transaction from your testnet practice in Module 2, or any recent swap on mainnet. Using the table in section 6.4, identify the status, sender, contract called, method, tokens in and out, any internal transactions, and the fee.
Then open the token contract for a major stablecoin on an explorer. Find the Contract tab, confirm it's verified, and use the "Read" section to look up its total supply.
Key takeaways from this chapter
- Block explorers show the blockchain directly, not an app's interpretation of it.
- The status field is the first thing to check. Submitted is not the same as successful.
- Token transactions show 0 ETH in the value field. The amounts appear in the token transfers section.
- Swaps often involve wrapped tokens and internal transactions, which explorers show separately.
- Events or logs record what contracts did and power the token transfers view.
- Address pages show balances, history, and sometimes labels, which are helpful but not guaranteed.
- Verified contracts publish readable source code. Unverified contracts asking for approvals are a warning sign.
- Use explorers to verify payments, check tokens and approvals, investigate addresses, and provide evidence.