# How to read a transaction on a block explorer line by line

A field-by-field walkthrough of an Ethereum transaction on Etherscan, written for settlement professionals who need to verify, audit, and confirm onchain payments with confidence.

---


For a closing attorney, escrow officer, or OTC desk operator, the question "did the money move?" has always had one definitive answer: the bank statement, the wire confirmation, the signed disbursement ledger. On Ethereum, the equivalent document is a transaction record on a block explorer — and it tells you more than any bank confirmation ever could. It shows you exactly what happened, when, to whom, in what amount, and whether the network considers it permanently settled. The challenge is that the interface can look intimidating the first time you open it.

This guide walks through every field on a typical Etherscan transaction page, in the order you will actually read them. It explains what each line means, why it matters to anyone responsible for funds-flow verification, and what to look for when something is not right. No programming knowledge required.

<figure class="keyfacts">
<div class="keyfacts-grid">
<div><b>~12 seconds</b><span>between blocks, each new one adding a confirmation on top of your transaction</span></div>
<div><b>~13 minutes</b><span>to finality, reached after 2 epochs under normal network conditions</span></div>
<div><b>0 ETH</b><span>what the Value field shows for most ERC-20 transfers, such as a USDC settlement</span></div>
</div>
<p class="fig-src">Figures from the Block and Value sections of this guide, for Ethereum mainnet.</p>
</figure>

## What a block explorer actually is

Think of a block explorer as a search engine built specifically for the Ethereum blockchain — one where you can look up any wallet address, transaction hash, block number, or smart contract. The difference between this and a bank's transaction portal is transparency: every time ETH or an ERC-20 token moves, the details are written to the chain permanently, and the explorer reads that data and presents it in a way that any beginner can understand — no coding required, no account needed.

A blockchain explorer is a website that lets you scan through a blockchain's entire history. Etherscan is the gold standard for the Ethereum blockchain. For the purposes of this guide, every example refers to Etherscan on Ethereum mainnet, though the concepts translate directly to any EVM-compatible explorer.

To arrive at a transaction page, you need one piece of information: the **transaction hash** (also called the tx hash or txid). Every transaction is identified by a transaction hash: the 66-character identifier (0x + 64 hex chars) that uniquely identifies that transaction across Ethereum history. Paste it into the Etherscan search bar and the full transaction record opens.

## Line 1 — Transaction Hash

The hash at the top of the page is your receipt number. It is generated deterministically from the transaction's content: the sender, the recipient, the value, the gas parameters, and the signature. If any one of those components changes, the hash changes entirely.

For practical verification purposes, the hash is the anchor. When a counterparty sends you a payment confirmation, they should send you this hash. Copy it, paste it into Etherscan, and everything else on this page is the authoritative record of what happened.

## Line 2 — Status

Look at the Status row at the top of the transaction page. The badge will read either **Success** or **Fail**.

A **Success** badge means the transaction executed completely: state changes were applied, tokens moved, contract logic ran. A **Fail** badge means the opposite — the call was attempted but reverted. A failed transaction means one of the require() or revert checks inside the called contract rejected the execution, so no state changes were applied. Critically, a failed Ethereum transaction still consumes gas because the network expended computational work executing the contract logic, even when it reverted.

<aside class="callout">
<span class="callout-label">Payment verification</span>
<h4>A Fail transaction moved no funds</h4>
<p>The reason a failed status matters is blunt. If a counterparty sends you a tx hash as proof of payment and the status reads Fail, no disbursement occurred. The hash exists; the funds did not move.</p>
</aside>

There is a subtler failure scenario worth knowing: if Gas Used equals the gas limit at 100%, the transaction ran out of gas and reverted, and the Status badge will be Fail. This can happen when a user sets too low a gas limit on a complex multi-party contract call. The transaction is broadcast, it gets mined, but it fails on execution. Always check Status before reading anything else.

## Line 3 — Block

The Block field shows which block the transaction was included in, plus how many confirmations have stacked on top of it since.

Blocks are the fundamental unit of Ethereum's ledger. Ethereum groups transactions into blocks, which are validated and added to the chain approximately every 12 seconds. Each new block that builds on top of the block containing your transaction is called a **confirmation**. The higher the confirmation count, the deeper the transaction is buried in the chain, and the more costly it would be for any actor to reverse it.

Finality in blockchain systems refers to the point at which a transaction is considered irreversible and permanently part of the blockchain — a concept crucial for ensuring transaction security and reliability. On Ethereum, finality is typically achieved after 2 epochs, which translates to approximately 13 minutes under normal network conditions. At that point the transaction does not merely have many confirmations on top of it; the network's consensus mechanism has cryptographically committed to it. As outlined in the Ethereum documentation, "In Ethereum, finality is the guarantee that a set of transactions cannot be reverted without burning at least 33% of the total staked ETH."

For a settlement professional, this is the meaningful threshold. A finalized Ethereum transaction is not just recorded — it is settled. There is no recall, no reversal, and no dispute window. The block number and confirmation count on this line are the evidence.

## Line 4 — Timestamp

The Timestamp is the exact time the block containing the transaction was validated. It is expressed in UTC and, on Etherscan, also translated to your local offset.

For escrow and settlement workflows, the timestamp is the equivalent of the wire cut-off time. It answers: did this payment arrive before the contractual deadline? Because block times on Ethereum are approximately 12 seconds and timestamps are set by validator consensus, they are reliable to within a few seconds. Courts in multiple jurisdictions have begun accepting block explorer timestamps as documentary evidence in commercial disputes, precisely because no single party controls the timestamp.

## Line 5 — From

The **From** address is the externally owned account (EOA) that signed and broadcast the transaction. Only EOAs can be the transaction "from" signer. Externally owned accounts are derived from a private key and are able to generate transactions on the Ethereum network.

You cannot tell who owns the wallet unless a site like Etherscan has labeled it. Etherscan's labeling system tags known addresses — major exchange hot wallets, protocol treasuries, custodial services — but most addresses appear as raw hex strings. In a deal context, you will typically match the From address against the wallet address your counterparty declared before the transaction. If the addresses do not match, ask before proceeding.

## Line 6 — To (Interacted With)

The **To** field is where a critical distinction lives. A transaction involving a decentralized application can look very different from a straightforward ETH transfer. The recipient may be a smart-contract address, and the ETH value alone may not explain what the transaction actually did.

Contracts are deployed by EOAs and can be called in the "to" field of a transaction. If you click on an address, the explorer will show on the top left whether it is a contract or an account.

This is the most important line to verify when confirming a payment to a multi-party routing contract. Confirm the To address matches your expected destination wallet or contract, and for any token transfer, click the ERC-20 Token Transfers tab to check that the token contract is the canonical contract address at the expected amount.

When a payment is routed through a tool like shaka.deal, the **To** address on the main transaction line will be the Shaka router contract. The actual disbursements to each party in the deal show up in the Token Transfers and Internal Transactions tabs — which we will cover shortly. This is normal and expected. It does not mean the funds stayed in the contract; it means the contract executed the splits atomically and the final recipients received their shares within the same block.

## Line 7 — Value

The Value field shows the amount of ETH transferred. Contract interactions may list "0 ETH" but still execute token swaps or other operations.

This trips up professionals reading a transaction for the first time. For most ERC-20 transfers, the Value field shows zero, because the tokens move through the contract's internal ledger rather than as native value. If you see a USDC transfer with "Value: 0 ETH," that is normal. The actual USDC amount lives in the input data and the event logs, not in the Value field.

If the deal was settled in USDC (USD Coin) or another stablecoin — say $500,000 USD (approximately AU$775,000) split across four parties — the Value field on the main transaction line may still read 0 ETH. Do not stop here. Read the Token Transfers tab to find the actual amounts. The Value line is only conclusive for native ETH payments.

## Line 8 — Transaction Fee and Gas

Transaction Fee is what the sender actually paid, denominated in ETH and converted to USD at the price at the time of the block. Gas Price is shown in Gwei, where 1 Gwei equals one billionth of an ETH.

After EIP-1559, Etherscan also breaks the gas price into Base Fee (burned) and Max Priority Fee (paid to the validator), so you can see how much of the fee was tip and how much was protocol-burned.

Gas Used by Transaction tells you how computationally heavy the transaction was. A simple ETH transfer uses 21,000 gas as a protocol minimum. An ERC-20 transfer typically uses 50,000 to 65,000. A multi-party split through a routing contract will use more gas than a simple transfer — because the contract logic is executing multiple disbursements simultaneously — but the fee is still a single line item paid by whoever broadcast the transaction.

The key distinction for understanding fees is between gas limit (the maximum the sender authorized) and gas used (what was actually consumed). If gas used comes in well under the gas limit, the transaction ran efficiently. If they are equal, look at the Status — it likely failed.

For a settlement professional, the gas cost is a transaction cost, not unlike a wire fee. What matters is that it is transparent, fixed at time of inclusion, and verifiable down to the Gwei.

## Line 9 — Nonce

The nonce is the sender's transaction sequence number — useful to detect replaced transactions or stuck sequences. The number is initialized at 0 and is incremented by 1 for each transaction sent.

Most of the time, the nonce is background information. You would only care about it in a specific scenario: if a pending transaction appears stuck (it has been broadcast but not mined), a sender can attempt to replace or cancel it by submitting a new transaction with the same nonce and a higher gas price. A replacement transaction generally uses the same nonce as the pending transaction it is intended to replace.

If you are waiting on a settlement payment and the explorer shows the transaction as Pending for an unusually long time, check the nonce. If it has since been superseded by another transaction from the same address using the same nonce, the original is effectively cancelled. The replacement will carry its own hash and its own status.

## Line 10 — Input Data

For any contract call, the Input Data field is where the real semantics live. Raw input data looks like gibberish — a long hex string starting with 0x. The first 4 bytes (8 hex chars after 0x) are the function selector, a hash of the function signature. The rest is the ABI-encoded arguments.

For a professional who simply wants to confirm what happened, there is good news: Input Data shows which smart contract function was executed, and when possible, Etherscan decodes this into a readable format. Click the "Decode Input Data" button on Etherscan. If the contract is verified — meaning its source code has been submitted to and confirmed by Etherscan — the raw hex is translated into a human-readable function call with labelled parameters.

For example, on a shaka.deal routing transaction, the decoded input data will show the function name (something like `route`), the total incoming amount, and the array of recipient addresses with their corresponding share values. This is the preset deal structure executing onchain. You can read it directly without any programming knowledge.

A simple ETH transfer may contain little or no input data. A smart-contract transaction can use this field to specify the function being called and the parameters being passed to the contract.

## The tabs below the fold: Token Transfers, Internal Transactions, and Logs

The main transaction overview covers the outer shell of the transaction. The tabs below it reveal what happened *inside* the execution. This is where multi-party payments become readable.

### Token Transfers

Many transactions include a Token Transfers tab, which records the movement of ERC-20 or ERC-721 tokens. This tab provides the most explicit confirmation for checking a token transfer result.

For a USDC settlement, this tab is the definitive record. Each row shows: the token contract address (confirm it matches the canonical USDC contract), the From address, the To address, and the amount. If a single incoming payment of $500,000 USD (approximately AU$775,000) was split to four parties at preset shares, you will see four rows in this tab — each with the correct recipient address and the correct amount — all produced by a single transaction.

This is what simultaneous, atomic settlement looks like on a block explorer. Four rows. One timestamp. One transaction hash. No sequential wires, no reconciliation required.

### Internal Transactions

Internal transactions, also known as "message calls" or "contract interactions," occur within smart contracts on the Ethereum blockchain. Unlike normal transactions, which are direct transfers of Ether or tokens between wallet addresses, internal transactions happen as a result of executing code within a smart contract.

Internal transactions are created when a smart contract calls another smart contract or sends Ether to a contract during its execution. They do not have their own transaction hashes and are not explicitly recorded on the blockchain like normal transactions. Etherscan reconstructs them by tracing the execution.

While not visible in the main transaction list, internal transactions can be viewed under the "Internal Transactions" tab on Etherscan associated with the relevant contract or wallet.

For a routing transaction where ETH is being split, the Internal Transactions tab is where you will see each outbound leg: the contract sending ETH to Party A, Party B, Party C, Party D — all within the same atomic execution. If you are auditing a deal and want to prove that every party received their share in the same block, this is your evidence.

### Logs (Event Logs)

Events, also called logs, are Ethereum's native way of recording what happened inside a transaction without modifying state. Events are how contracts tell the outside world that something happened. They live in transaction receipts, not in storage, and can be queried directly.

Events are information emitted by transactions taking place on a blockchain. A transaction onchain represents a change of state to the underlying blockchain ledger. Every ERC-20 transfer emits a `Transfer` event that records the sender, recipient, and amount. Smart contracts like Shaka's router emit their own events that record the full deal disbursement.

For an auditor or attorney reviewing a transaction months after the fact, the Logs tab is the most granular source of evidence. Each log entry includes an address (the contract that emitted it), a topic (the event type), and data (the encoded parameters). When decoded, they read like a structured settlement statement — who sent what to whom, in a single atomic event.

## A worked scenario: verifying a real estate split payment

Consider a commercial property settlement where the total proceeds of $2,800,000 USD (approximately AU$4,340,000) need to be distributed in a single closing: the seller receives the net proceeds, the buying agent and selling agent each receive their commission, and the title company receives its fee. Traditionally, this requires a settlement agent to issue four separate wires after the inbound funds clear — a process that can take hours and that leaves a gap between receiving and disbursing.

In an onchain version of this transaction, the buyer sends a single USDC payment to the shaka.deal routing contract. The contract's preset distribution logic executes instantly: all four parties receive their shares in the same transaction, in the same block, at the same timestamp.

Now open the transaction on Etherscan. Here is what you verify:

<figure class="fig">
<figcaption><b>Six checks on the transaction page</b><span>Worked example: one USDC payment split to four parties</span></figcaption>
<ol class="steps">
<li><b>Status: Success</b>The routing contract executed without reverting.</li>
<li><b>Timestamp</b>The exact time settlement occurred — verifiable, immutable.</li>
<li><b>To</b>The Shaka router contract address. Confirm it matches the address your counterparty shared in the deal documentation.</li>
<li><b>Value</b>0 ETH — expected, because this is a USDC settlement.</li>
<li><b>Token Transfers tab</b>Four rows. Each row shows the USDC contract address, a From (the router contract), a To (each respective party's wallet), and the exact amount matching the preset share. Cross-check each To address against the addresses declared by each party beforehand.</li>
<li><b>Logs tab</b>The router's disbursement event records all four disbursements in structured, decodable form — the deal's permanent receipt.</li>
</ol>
</figure>

That single page on Etherscan is the complete settlement record. No separate reconciliation document, no waiting for counterparty confirmations, no ambiguity about timing. The settlement agent can share that tx hash with every party and each can independently verify their receipt in under a minute.

## Common mistakes and red flags

**Stopping at Value: 0 ETH.** As noted above, most ERC-20 token transfers show 0 ETH in the Value field. Always check the Token Transfers tab before concluding no funds moved.

**Confusing the contract address for the recipient.** When funds are routed through a smart contract, the To address is the contract, not the final recipient. The Internal Transactions and Token Transfers tabs show where funds ultimately landed. One of the biggest differences between transferring ERC-20 tokens versus transferring Ether is that the transaction is addressed to the token's contract address rather than the account you want to send the tokens to.

**Treating Pending as confirmed.** A transaction is Pending until a validator includes it in a block. When you search a tx hash, it shows you the exact status of that single transaction — confirmed, pending, or failed. Never release anything contingent on a pending transaction. Wait for the Status badge to read Success.

**Misreading a failed transaction as a successful one.** The gas was spent, the hash exists, but the Status is Fail. A revert can happen because slippage tolerance was exceeded, a condition inside the smart contract was not met, or the sender set an insufficient gas limit. No state changes were applied. The payment did not occur.

**Not verifying token contract addresses.** For any token transfer, check that the token contract is the canonical contract address at the expected amount. There are fraudulent tokens with names identical to USDC, USDT, or WETH that are entirely separate contracts. The canonical USDC contract on Ethereum mainnet is `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`. If the Token Transfers tab shows a different contract address, it is not USDC.

## Reading the explorer as a professional workflow

Learning how to read a blockchain transaction is the single most useful onchain skill you can pick up. Every swap, transfer, approval, and contract call leaves a public receipt, and once you can scan one in under a minute you stop relying on wallet UIs to tell you what actually happened.

The reading order that works best for payment verification is fast and repeatable:

1. **Status** — did it succeed?
2. **Timestamp** — when exactly?
3. **To** — is this the correct contract or wallet?
4. **Token Transfers** — what amounts moved to which addresses?
5. **Internal Transactions** — if the To is a contract, where did execution send funds?
6. **Logs** — for a full structured record of the contract's own event emissions.

You do not need to understand every field to check a transaction. Start with its status and block information, then look at confirmations, addresses, value, and fees if you need more detail. As you verify more transactions, the pattern recognition becomes fast and intuitive.

## Why this matters for structured deal payments

Settlement professionals — closing attorneys, escrow officers, brokers, title companies, and OTC desks — already understand disbursement structure. Preset shares, simultaneous payout, documented finality: these are the goals of every closing, in every asset class. The block explorer is simply the instrument that lets all parties read the same, unalterable record of whether those goals were met.

Tools like shaka.deal are built on this model. One incoming payment, preset shares for every party, simultaneous execution, and a single transaction hash that all parties can independently verify in real time. No waiting for a settlement agent's confirmation email. No parsing a PDF disbursement statement. The evidence is the transaction, and the transaction is public.

Understanding how to read that transaction — field by field, tab by tab — is what allows a professional to treat that hash as a complete closing document. Once you can do it fluently, you will not want to go back to reconciling wire confirmations.