Event Log Decoder from Raw Topics

WHAT IT DOES

Event Log Decoder from Raw Topics takes raw event data — the cryptic hex topics and data fields emitted by a transaction — and turns them into readable structured output. Given a transaction hash, it fetches the receipt, extracts every log, and attempts to decode each one. If you provide a contract ABI (or if the contract is verified on a block explorer, which the tool can fetch automatically), it matches each log's first topic (the event signature hash) against known events, then parses the indexed topics and non-indexed data into named parameters with their proper types. The result is a clean table showing event name, parameter names, EVM types (uint256, address, bytes32, etc.), and decoded values — no more squinting at raw hex.

HOW TO USE

Paste a transaction hash into the input field. Optionally, paste the contract's ABI as a JSON array — this improves decoding accuracy and restores original parameter names. If you skip the ABI, the tool still extracts the event signature hash and attempts to decode standard events (ERC-20 Transfer, Approval, etc.) from a built-in minimal ABI, but for custom events you need the ABI. Click "Decode logs" and the tool fetches the receipt from your connected EVM chain, iterates through each log, and renders each decoded event in an expandable card showing every parameter with its name, type, and value. For anonymous events (which have no topic0), the tool displays the raw topics and data because they cannot be matched to a signature.

THE REAL MECHANISM — why this beats copying logs into an online decoder

Most online decoders force you to paste each log individually and guess the ABI. This tool automates the entire receipt: it fetches the full transaction receipt via the RPC provider, then for each log it uses ethers.js's Interface to parse the log against the provided ABI. The key insight is that the tool precomputes the event signature hashes (keccak256 of "EventName(type1,type2,...)") from your ABI and builds a fast lookup map from topic0 to the corresponding event fragment. When a log arrives, the tool checks if its first topic exists in that map — if yes, it uses the fragment to decode all indexed and non-indexed parameters in one pass, correctly handling dynamic types (strings, bytes, arrays) by reading the data offsets. For logs without a matching ABI, it still shows the raw topics and data but marks them as "unknown". The tool also handles edge cases like nested tuples and indexed address arrays, which naive splitters miss. And because it uses the provider's native getTransactionReceipt, it respects the chain's actual log format — no assumptions about padding or ordering.

WHAT IT CANNOT SEE

- Cannot decode events for unverified contracts if you do not provide an ABI; the tool has no oracle for unknown event signatures.

- Cannot recover original parameter names or types if the ABI is incomplete or omits the event entirely.

- Cannot detect anonymous events (those with "anonymous": true in the ABI) because they lack topic0 — they are displayed as raw hex only.

- Cannot verify that the decoded data matches the actual event structure if the ABI you supply is incorrect, outdated, or from a different contract version — the tool will happily decode garbage as if it were valid.

- Cannot fetch the ABI from explorers if your RPC endpoint does not support the eth_getCode method or if the contract is not verified.

- Cannot decode logs from transactions that have been pruned or are older than the node's archive retention — you may get a "receipt not found" error.

- Cannot detect reverted transactions that emit no logs, nor can it decode internal calls that do not appear in the receipt.

PLEASE NOTE

This tool works exclusively on EVM-compatible chains (Ethereum, Goerli, Sepolia, Polygon, Arbitrum, Optimism, and any chain that supports standard eth_getTransactionReceipt). It does not support non-EVM chains (Solana, Sui, Aptos, etc.) or chains that lack receipts. The tool is read-only — it never sends transactions or signs anything. No data is stored remotely; all decoding happens in your browser. For best results, always paste the exact ABI from the contract you are inspecting.