{"id":3851,"date":"2026-10-08T11:15:23","date_gmt":"2026-10-08T11:15:23","guid":{"rendered":"https:\/\/nownodes.io\/blog\/?p=3851"},"modified":"2026-10-08T11:15:24","modified_gmt":"2026-10-08T11:15:24","slug":"how-to-get-event-logs-and-transaction-history-with-eth_getlogs","status":"publish","type":"post","link":"https:\/\/nownodes.io\/blog\/how-to-get-event-logs-and-transaction-history-with-eth_getlogs\/","title":{"rendered":"How to Get Event Logs and Transaction History with eth_getLogs"},"content":{"rendered":"\n

eth_getLogs<\/code> is the Ethereum JSON-RPC method that returns every event log matching a filter you supply \u2014 a contract address, a block range, and a set of topics. It’s the standard way to pull historical crypto logs after the fact: the token transfers, swaps, and state changes a contract recorded while it ran. Point it at the right filter and you can rebuild most of an address’s on-chain activity without replaying a single block of execution.<\/p>\n\n\n\n

This guide covers what those logs are, why they exist as a separate data type, who pulls them, and how to query them correctly once your filter reaches past a handful of blocks. The mechanics are standard across every provider; the limits around them are not.<\/p>\n\n\n

What Is an Event Log on Ethereum?<\/h2>\n\n\n
\"\"<\/figure>\n\n\n\n

An event log is a record a smart contract writes during execution to mark that something happened, stored on the transaction’s receipt rather than in the contract’s own storage. When a Solidity contract runs emit Transfer(from, to, amount)<\/code>, the Ethereum Virtual Machine appends a log entry to that transaction \u2014 cheap to write, and permanent, but something the contract itself can never read back.<\/p>\n\n\n\n

Each log splits its information into two places. Indexed parameters go into an array called topics<\/code>, which the node can filter on directly. Everything else gets packed into a data<\/code> field as raw hex that you decode later using the contract’s ABI.<\/p>\n\n\n\n

The split matters because only topics<\/code> is searchable. A log holds up to four topics: the first slot is reserved for the keccak-256 hash of the event’s signature, which leaves three slots for parameters a contract marks as indexed<\/code>. That ceiling is why filtering is fast but limited \u2014 you can narrow a query to an event type and a few indexed values, and nothing more.<\/p>\n\n\n

Why Query Logs Instead of Reading Contract State?<\/h2>\n\n\n

Logs are the only affordable way to see what a contract did over time, rather than only what it holds right now. Contract state answers “what is this balance”; logs answer “every transfer that produced it.” Re-deriving that history by replaying past transactions would mean re-executing the chain, which no application can do on each request.<\/p>\n\n\n\n

Events exist to sidestep that. A decentralized exchange doesn’t keep a list of every trade in storage \u2014 it emits a Swap<\/code> event per trade and lets anyone reconstruct the record from logs. An ERC-20 token works the same way: the contract tracks balances, but the Transfer<\/code> event is the audit trail, and wallets and explorers collect it themselves.<\/p>\n\n\n\n

There’s also a cost reason the design holds. Writing a value to contract storage is one of the more expensive operations on Ethereum, while a log entry is far cheaper, as the ethereum.org gas documentation<\/a> lays out. Logs were built as a write-only, low-cost record \u2014 which is exactly what makes a method like eth_getLogs<\/code> possible.<\/p>\n\n\n

Who Relies on Event Log Data?<\/h2>\n\n\n

Different teams pull the same logs for different reasons, and most of them care about history rather than live state:<\/p>\n\n\n\n