A friend sent me a transaction hash a while back, convinced his wallet had been drained. He had opened it on Etherscan, seen a wall of addresses and hex, and assumed the worst. It took about two minutes to work out what actually happened: he had signed a token approval to a contract weeks earlier, and that contract had just moved his tokens exactly as he had authorized it to. The drain was real, but the mechanism was different from what he thought, and everything needed to understand it was sitting on that one page. He just could not read it yet, and most people can't. So here is how I read a transaction page, top to bottom, because this one skill sits underneath everything else in wallet forensics.
The header: from, to, and the value trap
Every transaction has exactly one From address. That is the account that signed it and paid the gas, and it cannot be faked. Whatever else is going on, the From field tells you who initiated the thing.
The To field is where people start misreading. If To is a regular wallet, you are probably looking at a plain ETH transfer and the story ends quickly. If To is a contract, and Etherscan labels most of the well known ones, the transaction is an instruction to that contract, and the addresses that actually end up with assets can be completely different from anything in the header. When someone swaps on Uniswap, the To field says the router contract. The counterparty to the trade appears nowhere in the header at all.
Value is the field that burns beginners the most. It is the amount of ETH attached to the transaction, and only ETH. A transfer of a million dollars in USDC shows a value of 0 ETH, because tokens do not move through the value field, they move through contract state changes recorded in the event logs further down the page. I have watched people dismiss a transaction as empty because the value was zero, when it moved more money than everything else in the wallet's history combined.
Gas is mostly noise for forensics, with two exceptions. A failed transaction still pays gas, so a wallet with a string of failures and fees spent tells you someone was trying and failing to do something, often racing a deadline or fighting a bot. And an unusually high gas limit on a simple looking transaction hints that whatever the contract does under the hood is heavy, which is a reason to look closer.
The method call: what the sender asked for
Below the header Etherscan shows the input data, and the first four bytes of it are the method selector, a fingerprint of the function being called. Etherscan decodes the common ones for you: transfer, approve, the various swap functions, mint, and so on. This is the sender's stated intent, and it is the fastest way to classify a transaction. A few patterns cover most of what you will see:
- No input data, value above zero, To is a wallet: a plain ETH transfer. Nothing else to decode.
- Method is transfer and To is a token contract: an ERC-20 transfer. The real recipient and the amount live inside the input data, not in the header, because the token contract keeps its own ledger and this call just updates it.
- Method is approve: no assets moved at all. The sender granted a contract permission to move tokens later. Check the amount, because an unlimited approval, which renders as a comically large number, means that contract can pull the entire balance of that token whenever it wants until the allowance is revoked.
- Method is a swap variant and To is a router: a trade. Skip straight to the token transfer logs to see what changed hands.
- The To field shows a newly created contract instead of a recipient: a deployment. The From address wrote code to the chain, which matters when profiling a wallet, since deployers behave differently from traders.
One caveat. The method name is what the sender claims to be calling. On a verified contract that is reliable, but scam contracts deliberately name malicious functions things like claimReward or securityUpdate. The name gives you intent as advertised, and the logs give you what happened, so the two need to be read together.
Internal transactions and logs: what actually happened
The Internal Transactions tab confuses everyone at first, because nothing on it was ever signed or broadcast on its own. These entries are ETH movements that happened inside contract execution, and Etherscan reconstructs them from execution traces. When you swap a token for ETH on a router, the ETH you receive typically arrives as an internal transaction, because the router unwrapped WETH and forwarded it to you mid execution. If you only look at a wallet's main transaction list, you will miss every ETH payout that arrived this way, and in an active DeFi wallet that can be most of them.
The Tokens Transferred section is the closest thing the page has to a plain answer. Etherscan builds it by parsing the ERC-20 Transfer events out of the logs, and it reads as a simple list: this address sent this many of this token to that address. For a swap you will typically see multiple legs, tokens leaving the sender into a pool, tokens arriving from a pool to the sender, sometimes hopping through two or three pools in between. My habit is to find the sender's address in that list and trace only their legs first, what left the wallet and what entered it. Everything between the pools is routing detail.
Logs are also where you catch address poisoning. Attackers send zero value token transfers, or tiny dust amounts, from addresses crafted to visually match ones you have interacted with, so their address shows up in your history and you copy it by mistake later. A transfer event with a zero amount, or an unknown token arriving unprompted, is decoration meant to be misread, and it should never be treated as evidence of a real relationship between two wallets.
The two minute read, in order
When I open an unfamiliar transaction, the sequence is always the same. Check the status first, because a failed transaction changed nothing except gas. Read From, then check whether To is a wallet or a contract. Look at the method name for stated intent. Then go straight to Tokens Transferred and the internal transactions for ground truth, and reconcile the two: does what happened match what was asked for? If the method says approve and no tokens moved, fine, but that allowance now exists, and the next transaction that touches those tokens may come from an unrelated address using it. If the method is unrecognized hex on an unverified contract and value or tokens flowed out, that is where I slow down.
None of this needs tooling beyond the block explorer. It needs the page read in the right order, without trusting any single field on its own. The header tells you who signed and how much ETH moved directly, the method tells you the claim, the logs tell you the truth. Get those three straight and most transactions stop being mysterious in under a minute, which is roughly the pace you need before chaining hundreds of them together into an actual investigation.