RPC Rate Limits
Rate limits applied to the public X1 RPC endpoints.
The public X1 RPC endpoints enforce per-IP rate limits to ensure fair access for all users.
Limits
Short burst
5 seconds
50
Sustained
1 hour
25,000
Heavy methods
5 seconds
20
Concurrent connections
—
15
Heavy methods — sendTransaction and simulateTransaction — are subject to a tighter per-window cap due to their higher processing cost.
Requests that exceed any limit receive an HTTP 429 Too Many Requests response.
Note: These limits are subject to change. The current values are always reflected in the response headers — see Rate limit headers below.
Rate limit headers
Every response includes headers so your application can monitor usage and back off gracefully:
X-RateLimit-Rate-Short
Your request count in the current 5s window
X-RateLimit-Limit-Short
Short window cap (50)
X-RateLimit-Reset-Short
Short window duration (5s)
X-RateLimit-Rate-Long
Your request count in the current 1h window
X-RateLimit-Limit-Long
Long window cap (25000)
X-RateLimit-Reset-Long
Long window duration (1h)
X-RateLimit-Rate-Heavy
Your heavy-method count in the current 5s window
X-RateLimit-Limit-Heavy
Heavy method cap (20)
X-RateLimit-Reset-Heavy
Heavy method window duration (5s)
X-Conn-Current
Your current concurrent connection count
X-Conn-Limit
Concurrent connection cap (15)
Checking your current usage
Tips for staying within limits
Poll at a reasonable interval. Fetching slot or block data every 400ms (roughly one slot) is sufficient for most dashboards.
Batch requests where possible using the JSON-RPC batch format.
Reuse connections. HTTP keep-alive avoids repeated handshakes and reduces connection count.
Handle 429s gracefully. Implement exponential backoff when you receive a 429 rather than retrying immediately.
If your application has a legitimate need for higher throughput, reach out to the X1 team.
Last updated