RPC limits

Batch size, server timeout, eth_getLogs range habits and connection reuse for the Supanode Robinhood Chain RPC and WebSocket endpoints.

// updated 2026-09-24

The hard limits below are enforced by the node. Throughput limits are set per subscription: your plan says what you get.

Hard limits

Limit	Value	What you see past it
Calls in one batch	1,000	Every item in the batch gets `-32600 batch too large`
Server-side request timeout	about 30 s	`-32002 request timed out`
Auth	`x-token` header only	`401` without it, `403` with a wrong token
Content type	`application/json` required	`415` `invalid content type, only application/json is supported`

eth_getLogs

A wide, unfiltered range is where requests go wrong. Robinhood Chain produces about 10 blocks per second, so 10,000 blocks is under 20 minutes of chain time, yet unfiltered it returns about 250 MB and takes close to a minute. A range large enough to run past 30 seconds is cut off by the server timeout.

Filter by address (and topics where you can).
Page through ranges of 2,000-5,000 blocks and walk forward.
For live events use a logs subscription over WebSocket instead of polling eth_getLogs.
For decoded Uniswap and launchpad history the Indexer answers in one SQL query what would take thousands of eth_getLogs calls.

Connections

Reuse connections. A fresh TLS connection costs about three round trips before the first answer. HTTP keep-alive works, so the second request on the same connection pays only the round trip.
Hold one long-lived WebSocket and open several subscriptions on it, instead of one connection per subscription. In our tests an idle connection stayed open for 150 s without traffic; send pings and keep a reconnect handler anyway.
Region. The node is in US East (New York). Round-trip time from your server dominates latency: the node itself adds 1-7 ms.

Need more

Higher throughput, archive state or your own region is a dedicated node. Start in the portal or ask Telegram support.