How to find and filter event logs from a smart contract transaction

05 September 2026

Event logs are the primary way smart contracts communicate what happened during a transaction. They are not stored in the contract's state - they exist in the transaction receipt, appended to the block. Anyone can read them. You do not need to trust the contract's frontend.

Every event log has two parts: topics and data. Topics are indexed parameters. They are stored as 32-byte hashes. Data is the non-indexed payload. It can hold arbitrary bytes.

A standard ERC-20 Transfer event is the clearest example. The Solidity definition looks like this:

event Transfer(address indexed from, address indexed to, uint256 value);

Two parameters are indexed (from and to). One is not (value). The contract emits this log every time tokens move.

The structure of a Transfer log

When you look at a Transfer log on a block explorer, you see three topics and one data field.

• Topic[0] is always the event signature hash. For Transfer(address,address,uint256), that hash is 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef. This is computed by Keccak256 of the event signature string. It never changes across any contract that uses the same event definition.

• Topic[1] is the from address. The explorer shows a hex string like 0x000000000000000000000000a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0. The leading zeros pad the 20-byte address to 32 bytes. Some explorers truncate this display, but the raw log always contains the full padded form.

• Topic[2] is the to address. Same padding applies.

• Data contains the value (amount). It is a 32-byte hex number. If the transfer is 100 tokens with 18 decimals, the raw data is 0x0000000000000000000000000000000000000000000000056bc75e2d63100000. You decode it by reading it as a uint256.

A common mistake: people look for the amount in the topics. It is never there. The value parameter is not indexed. It lives in the data field. The gas cost of indexed parameters is cheaper for the first three topics, then becomes expensive. That is why contracts typically index only the addresses.

Filtering logs on Etherscan

Every transaction page on Etherscan has a Logs tab. It shows all event logs emitted by that transaction. You see the contract address that emitted each log, the topics, and the raw data.

To filter by address: use the Advanced filter on the Logs tab. Enter the contract address you care about. Etherscan shows only logs from that contract. This is useful when a transaction interacts with multiple contracts - DEX swaps often emit Transfer, Swap, and Sync events from different addresses.

To filter by topic: in the same Advanced filter, you can enter a topic hash. For example, paste 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef in the Topic 0 field. Only Transfer events appear. You can also filter Topic 1 by a specific address to see only transfers from that address.

Etherscan also offers the Event Logs page at etherscan.io/tx/0x.... The raw view shows the hex data exactly as it appears on chain. No decoding, no human labels. This is what you would see if you called eth_getTransactionReceipt from a node.

Why this matters

Event logs are the only reliable record of what a contract emitted. Frontends can lie. The log cannot. If a dApp shows you a transfer that does not appear in the logs, the dApp is wrong.

You can use event logs to track token movements without relying on an API. The same query pattern works across all EVM chains: Ethereum, BNB Chain, Polygon. The RPC method is the same. The log structure is the same.

To decode log data yourself: take the data hex, remove the 0x prefix, and parse it as a uint256 or address depending on the event definition. The ABI tells you the types. If you have the ABI, you can decode everything locally.

No single tool is required. Etherscan is convenient. A node RPC is more transparent. Both give you the same bytes.

A practical filter workflow

1. Open the transaction on Etherscan.
2. Click Logs.
3. In the filter input, paste the contract address of the token you care about.
4. Add 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef as Topic 0 to show only transfers.
5. Add an address to Topic 1 or Topic 2 to show only sends or receives from that address.

You now see exactly what moved and where it went. No other data from that transaction clutters the view.

Event logs are unforgeable. They are the truth layer of every transaction. Learn to read them, and you stop needing to trust anyone else's interpretation.

Back to on-chain data