How Do You Read a Blockchain Transaction on a Block Explorer?

How do you read a blockchain transaction on a block explorer?

A block explorer is a search engine for a blockchain: paste in a transaction hash or an address and it shows you the raw public record, dressed up for humans. Since every transaction on a public chain is visible to everyone — a core property described in NIST's blockchain overview — anyone can verify a payment without trusting the sender's word for it. The catch is that the page is full of jargon. Here is what the fields on a typical Ethereum transaction page mean, one by one.

The identity fields

• Transaction hash (TxID). A long hex string that uniquely identifies this transaction. It's what you share when someone asks for "proof of payment."
• Status. Success means the transaction executed; failed means it was included in a block but its execution reverted — and the fee was still paid, because the network did the work of processing it either way.
• Block and confirmations. The block number where the transaction landed, and how many blocks have been built on top since. More confirmations mean the record is more deeply buried and harder to reverse — the layered structure explained in our walkthrough of how a blockchain transaction works.

From, To, and Value

The official transaction documentation lists the core components of an Ethereum transaction: a sender, a recipient, a signature, an ETH value, optional input data, and gas parameters. On an explorer:

• From is the sending address — the account whose signature authorized this and whose ETH paid the fee.
• To is either a person's address or a smart contract. This distinction trips up beginners constantly. When you send an ERC-20 token, the "To" field shows the token's contract, and the actual recipient is buried in the input data. Explorers compensate by showing a separate "Tokens Transferred" line that decodes who really received what — that line, not the "To" field, tells the human story of a token transfer. (What is an ERC-20 token? covers why tokens work this way.)
• Value is the amount of ETH moved. For token transfers this is usually zero — no ETH changed hands, only token balances inside a contract.

The fee fields

Explorers show several gas numbers, all defined in the gas and fees documentation:

• Gas limit — the most work the sender agreed to pay for.
• Gas used — the work actually consumed. A plain ETH transfer uses exactly 21,000 gas; contract interactions use more.
• Gas price / base fee / priority fee — the price per unit of gas, quoted in gwei (one billionth of an ETH). The base fee is set by the protocol and destroyed; the priority fee tips the validator.
• Transaction fee — gas used times price: the ETH the sender actually spent to make this happen.

Nonce and input data

• Nonce is the sender's transaction counter — this transaction's position in that account's history. It's how the network prevents the same signed transaction from being replayed twice.
• Input data is the payload sent along with the transaction. Empty for a simple ETH transfer; for a token transfer, it encodes the contract instruction. Explorers often decode it into a readable form like `transfer(recipient, amount)`.

Reading a Bitcoin transaction instead

Bitcoin explorers look different because the model is different: instead of accounts and balances, a Bitcoin transaction lists inputs (previous coins being spent) and outputs (new coins created), as documented in the Bitcoin Developer Guide. Expect to see multiple outputs even for a simple payment — one going to the recipient and one returning change to the sender — which is normal, not suspicious.

One habit worth building

When checking whether a payment arrived, search the transaction hash, not the address, and read the decoded transfer line rather than eyeballing "To" and "Value." Those two habits prevent most beginner misreadings of an explorer page.