Read a block-explorer transaction without trusting its labels

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

Start with the record, not the story

A block explorer mixes at least three layers on one screen: fields returned by a node, a decoding of byte data, and labels maintained by the explorer. Only the first layer is the transaction record. Before accepting a green badge, an account name or a sentence such as 'swap 500 USDC', record the network and chain ID, transaction hash, block number, status, sender, recipient, value, input data, gas used and logs. Ethereum's JSON-RPC documentation defines those fields for eth_getTransactionByHash and eth_getTransactionReceipt. A second explorer may repeat the same label; that is not independent confirmation if both use the same tagging source.

Reconstruct the action in a fixed order

1. Confirm the chain. The same hexadecimal address can exist on several networks with unrelated code.
2. Check receipt status. A failed call may still have paid gas, but its state changes were reverted.
3. Separate the outer call from its effects. to identifies the first recipient, not every contract reached internally.
4. Take the first four bytes of non-empty input as the function selector. Match it against a verified ABI or the project's source repository, then check that the parameter types fit. A text signature database is a lead because selectors can collide.
5. Read receipt logs. For an ERC-20 transfer, the emitting contract address identifies the contract that emitted the record; indexed topics encode sender and recipient, while data carries the amount. Any contract can emit a Transfer-shaped log, so confirm the semantics against its code and relevant state changes rather than treating the log alone as proof that balances moved. The token symbol shown by an explorer is optional metadata, not identity.

This is the operational companion to what ERC-20 actually standardises. It also explains why a transaction can be included yet later lose its place during the reorganisation risk described in the confirmation guide.

Hypothetical example

Hypothetical: an explorer labels the recipient 'Blue Router' and renders a swap from 500 units of Token A to 498 units of Token B. The raw transaction only establishes a call to address 0xB… with certain calldata. The receipt establishes success and logs from contracts 0xA… and 0xC…. To support the swap description, verify code or ABI for 0xB…, decode the selector and parameters, then decode the two token contracts' logs using their decimals. If the name 'Blue Router' comes only from the explorer, write 'address labelled Blue Router by Explorer X', not 'Blue Router'.

Decision rule and limits

Treat a claim as chain-established only when it can be reproduced from RPC data plus the relevant contract interface. Treat ownership labels, intent, counterpart identity and economic purpose as separate claims needing first-party or legal evidence. Traces can expose nested calls, but trace methods are client-specific and a public endpoint may omit them. A verified source match improves decoding; it does not prove the operator's identity or that the code was safe. This workflow reads one execution record. It does not establish off-chain agreements, beneficial ownership, solvency or whether the transaction was prudent.