RPC error -32005 / -32000: query returned more than N results
Last updated:
At a glance
| Property | Value |
|---|---|
| Applies to | Ethereum, Polygon, BNB Smart Chain, Base and Robinhood Chain |
| JSON-RPC code | -32005, or -32000 with the same text |
| N is | The serving node's ceiling, not a product constant |
| Observed values | 50,000 (Robinhood log planner), 1,000 and 500 (Tron sources) |
| Triport behaviour | Robinhood splits the range and re-queries automatically |
| BNB Smart Chain | A per-node block-range limit applies as well — up to 100 blocks per request |
Cause
Public nodes cap how many log entries a single eth_getLogs may return, and report the overflow either as -32005 or as -32000 with the same wording. The number in the message is the serving node's threshold and differs between sources, so a client that hard-codes one value will be wrong somewhere. On Robinhood Chain the log planner treats this answer as an instruction to split the block range and re-query, rather than failing the call.
Solution
- Halve the block range and retry, repeating until the window fits — this is what our Robinhood log planner does internally.
- Narrow the filter itself: a specific address and topic set usually shrinks the result far more than a smaller range.
- Read the number out of the message rather than assuming a constant; nodes publish different ceilings.
- For whole-block work, eth_getBlockReceipts returns a block's receipts in one call instead of a wide log query.
Example
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32005,
"message": "query returned more than 1000 results"
}
}FAQ
- Is the limit always the same number?
- No. The ceiling belongs to the node that answered; values of 50,000, 1,000 and 500 all appear in our sources. Parse the number from the message instead of hard-coding one.
- Does a narrower range always help?
- It helps when the range is what makes the result large. If a single block matches thousands of entries, narrow the address or topics instead.