Ethereum
eth_getLogs
eth_getLogs is the workhorse for reading Ethereum events. Every emit in a Solidity contract — an ERC-20 Transfer, a Uniswap Swap, an Aave borrow — leaves a log on Ethereum mainnet (chain ID 1, the EVM network where gas is paid in ETH), and this method pulls back all the logs that match a filter object you describe. You filter by address (one contract or several), by indexed topics, and by a block range with fromBlock/toBlock, or pin a single block with blockHash. Unlike the stateful filter API, it's a one-shot query: no eth_newFilter registration, no polling cursor. That makes it the standard tool for backfilling and indexing event history. Send the request to https://ethereum.therpc.io/YOUR_API_KEY.
Use cases
- Backfill an ERC-20's
Transferhistory by settingaddressto the token andtopics[0]to theTransfer(address,address,uint256)signature hash, walking the range in chunks. - Feed an analytics dashboard: pull
Swap,Mint, andBurnevents from Uniswap pools or borrow events from Aave to reconstruct volumes and TVL over time. - Rebuild contract state from its event trail when there's no view function for what you need — replaying ordered logs is often the only way to recover historical positions.
- Confirm a specific event fired inside one transaction by pinning the query with
blockHashand matching on the contract address and topic.
Parameters
| # | Name | Type | Required | Description |
|---|---|---|---|---|
| 1 | filter | object | Yes | Filter object. Fields: `fromBlock` (string, default "latest"), `toBlock` (string, default "latest"), `address` (string | string[]), `topics` ((string | string[] | null)[]), `blockHash` (string — mutually exclusive with fromBlock/toBlock). |
Response
| Type | Description |
|---|---|
| array | Array of log objects. Each log: `address`, `blockHash`, `blockNumber`, `data`, `logIndex`, `removed` (bool — true on reorg), `topics`, `transactionHash`, `transactionIndex`. |
Example request
Try it live in the Ethereum playground.
Errors & troubleshooting
| Code | Message | Cause |
|---|---|---|
-32005 | query exceeds max block range | The fromBlock–toBlock window exceeds the provider's block-range cap. |
-32005 | query returned more than 10000 results | Too many matching logs; narrow the filter or paginate. |
-32602 | invalid argument | blockHash combined with fromBlock/toBlock, or malformed topic format. |
Common pitfalls
- Logs from blocks that aren't yet finalized can vanish in a head reorg. Watch the
removedfield, and for anything that moves value, re-query once the block reachesfinalized(roughly 12.8 minutes, two epochs, after it was proposed). - A wide range with no
addressortopicsmakes the node scan far too much and you'll hit a block-range cap or the 10,000-result ceiling — both surface as-32005. Paginate in chunks of about 1,000 to 5,000 blocks and always narrow by address or topic. - Looping
eth_getLogswithfromBlock: "latest"to fake a live feed is wasteful and races the chain head. For streaming, useeth_newFilter+eth_getFilterChanges, or subscribe tologsover WebSocket witheth_subscribe.
Supported networks
- Mainnet — Chain ID: 1
- Sepolia — Chain ID: 11155111
See also
Parameters
Filter object. Fields: `fromBlock` (string, default "latest"), `toBlock` (string, default "latest"), `address` (string | string[]), `topics` ((string | string[] | null)[]), `blockHash` (string — mutually exclusive with fromBlock/toBlock).