Lesson 1 — Block explorer literacy: addresses, transactions, event logs

**Addresses.** Every account on an EVM chain is identified by a 20-byte address, displayed as a 42-character hex string starting with `0x`. There are two kinds. **Externally-owned accounts (EOAs)** are controlled by a private key; they can send transactions and sign messages. **Contract accounts** are controlled by code; they can hold tokens, execute logic, and be called by other accounts. On the explorer, an EOA address page shows incoming and outgoing transactions, current token balances, and ETH balance. A contract address page shows the same plus a 'Contract' tab with verified source code (if published) and a 'Read Contract' / 'Write Contract' interface that lets you call view-only functions or compose transactions to write-functions.

**Transactions.** A transaction has a from-address, a to-address, a value (ETH being sent), and (for contract interactions) calldata. The transaction hash is its unique identifier — 32 bytes, displayed as a 66-character hex string starting with `0x`. The transaction's receipt records: success or failure, gas used, gas price, block number, timestamp, and any events emitted. Etherscan shows all of this on the transaction page, plus a 'Tokens Transferred' summary (parsed from event logs) and 'Internal Transactions' (value movements inside the transaction execution).

**Internal transactions.** When contract A calls contract B during execution, that's an internal transaction. Internal transactions are not separately stored on-chain — they exist only as part of their parent transaction's execution trace — but block explorers reconstruct them from the trace. This is how you follow funds through a multi-hop swap, a drainer contract, or any complex DeFi flow. The 'Internal Txns' tab on an address page is essential for tracing where money actually went.

**Event logs.** When contracts want to make off-chain observers aware of something — a transfer, an approval, a swap — they emit events. Events are written to the transaction's logs section, indexed (up to three topics) so off-chain tools can search them efficiently. Etherscan parses logs against the contract's verified ABI to show human-readable event names. The ERC-20 `Transfer(from, to, value)` event is the most-emitted event on Ethereum and is what powers the 'token transfers' you see on every address page.

**Calldata.** The encoded input to a transaction — what tells the EVM which function to call and what arguments to pass. Calldata starts with a 4-byte 'function selector' (the first 4 bytes of the Keccak-256 hash of the function signature, e.g., `0xa9059cbb` for `transfer(address,uint256)`), followed by ABI-encoded arguments. If the contract is verified on Etherscan, the explorer auto-decodes calldata into a human-readable function-name + arguments view. If it isn't verified, you see raw hex — but you can paste the first 4 bytes into 4byte.directory to look up the function signature, and you can use ABI-decoder tools to parse the rest if you know the ABI.

**Reading order.** When you land on an unfamiliar transaction, scan in this order: success/failure status (top of page) → from/to addresses → ETH value transferred → Tokens Transferred summary → Internal Transactions → Logs (events) → calldata input. If you understand each layer, you know exactly what the transaction did. If you don't recognise one of the addresses, click through to its page and check whether it's an EOA (recent activity, no contract code) or a contract (verified source, recent calls), and what its other interactions look like.

**Cross-chain explorers.** Etherscan covers Ethereum mainnet. The same family of explorers exists for major chains: BscScan (BNB Chain), Arbiscan (Arbitrum), Optimistic Etherscan (Optimism), Polygonscan (Polygon), Snowtrace (Avalanche), Basescan (Base). For Solana, the leading explorers are Solscan and Solana Explorer; the data model is different (instructions and program invocations rather than calldata and event logs), but the principles transfer. For Bitcoin, Blockchair and mempool.space are the standard explorers; the UTXO model is again different but the read-the-chain skill is the same.