When working with logs and events on EVM-based chains, you may encounter a block range limit of 10,000 blocks when using methods like eth_getLogs or eth_getFilterLogs. This limit is in place to ensure maximum reliability for your calls and to prevent resource-intensive requests that could lead to degraded service.

If you attempt to query a larger range of blocks, you will receive an error message like this:

{ "jsonrpc": "2.0", "id": 1, "error": { "code": -32602, "message": "eth_getLogs and eth_newFilter are limited to a 10,000 blocks range" } }

Why is there a limit?

Requesting larger block ranges can have some side effects. For example, if you request an extensive range, the chain client may stop syncing until the request is finished, resulting in data that is not up-to-date. If the client stops syncing, we have to temporarily remove it until it reaches the tip of the chain, which can lead to degraded service. Additionally, if the request is not correctly sent with the appropriate parameters, it often results in timeouts.

The 10,000 block range limit is not a limit on how far back in time you can query but rather a limit on the number of blocks you can query in a single request. 

Workaround and benefits

It's important to note that this limit only applies to the block range and not the response size or the number of logs. To work around the limit, we recommend breaking down your queries into smaller chunks of 10,000 blocks or less. Doing so will provide you the following benefits: 

• Increase the likelihood of receiving your response faster without timeouts
• More control over a smaller chunk of data, thus better error handling
• Better response time due to our load-balancing setup
• Ability to retry the requests faster in the case of failure
• Additionally, you can add concurrency, and your request will be load balanced between our backends, so the 2 x 10k range will be served in parallel in comparison to 1 x 20x or 100x in one flow

Don't hesitate to contact us if you have further questions 🚀