RPC rate limits cap how many requests your application can send to a blockchain node inside a fixed time window. Cross that ceiling and the node stops answering: it returns an HTTP 429 “Too Many Requests” response instead of your data. Every developer who ships anything real on-chain hits this wall eventually, usually during a traffic spike, at the worst possible moment.
Understanding RPC rate limits is the difference between an app that degrades gracefully and one that falls over when it matters. This guide covers what the limits are, why nodes enforce them, what a 429 actually means, plus the architecture patterns that keep your workload flowing when demand climbs. The goal is not to fear rate limits. It is to design so they never become your outage.
What are RPC rate limits? (the simple version)
A rate limit is a rule that restricts how many requests a client can make to a service in a given period. On a blockchain node, that usually means a cap on requests per second (RPS), requests per minute, or a weighted budget where heavier methods count for more.
Most providers implement this with a token-bucket algorithm. Picture a bucket that refills with tokens at a steady rate. Every request spends one token. When the bucket is empty, further requests are rejected until it refills. This is why a burst of traffic can trip a limit even when your average request rate looks modest: the bucket drains faster than it fills.
Rate limiting is not unique to blockchain. It was standardized for HTTP APIs long before Web3 existed. The 429 status code was formalized in RFC 6585 in 2012. The broader pattern of controlling traffic flow to protect a shared resource goes back to the earliest multi-user systems. Blockchain RPC nodes simply inherited a well-understood technique.
Why rate limits exist
Nodes enforce limits for three practical reasons:
- Fairness on shared infrastructure. A public or shared endpoint serves thousands of clients. One noisy application must not starve everyone else.
- Abuse and DDoS protection. Uncapped endpoints are trivial to overwhelm. Rate limiting is a first line of defense against both accidental floods and deliberate attacks.
- Cost and resource control. Serving RPC traffic costs CPU, memory, disk I/O. Limits keep any single consumer from running up unbounded infrastructure cost on the operator.
What is an acceptable RPC rate limit? (RPS)
There is no single correct number. An acceptable RPS rate limit depends entirely on your workload. A wallet that reads a balance when a user opens a screen needs very little headroom. A liquidation bot polling positions across dozens of markets needs far more.
As a rough map of the landscape, public and free endpoints often sit somewhere between 5 and 50 requests per second per IP. Some chains publish hard ceilings. The BNB Chain docs, for example, list a public endpoint limit of 10,000 requests per five minutes. Paid and dedicated plans raise these ceilings substantially. The best model removes the per-second cliff entirely in favor of a monthly budget.
To size your own requirement, separate your traffic into three buckets:
- Reads (balances, block data, contract calls): high volume, easy to cache.
- Writes (
eth_sendRawTransaction): lower volume, latency-sensitive, must not be dropped. - Event streams (logs, subscriptions): bursty, spike hard during volatile markets.
Size for the peak of the sum, not the average. Rate limits bite at the peak.
What does an HTTP 429 “Too Many Requests” error mean?
A 429 Too Many Requests response is the node telling you that you have exceeded its rate limit. It is not a bug in your code. It is not a node failure. It is the limit working as designed.
A well-behaved endpoint includes a Retry-After header in the 429 response, telling you how many seconds to wait before trying again. The correct client behavior is simple: read that header, wait, then retry with exponential backoff so that repeated failures widen the gap between attempts instead of hammering the node.
Here is a production-ready retry handler in JavaScript. It wraps a raw JSON-RPC call, honors Retry-After, then backs off exponentially with jitter:
// Exponential backoff with Retry-After support for JSON-RPC over HTTP
async function rpcWithBackoff(url, payload, maxRetries = 5) {
let attempt = 0;
while (true) {
const res = await fetch(url, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(payload),
});
if (res.status !== 429) {
return res.json();
}
if (attempt >= maxRetries) {
throw new Error("RPC rate limit: max retries exceeded");
}
// Honor Retry-After if present, else exponential backoff with jitter
const retryAfter = Number(res.headers.get("retry-after"));
const base = Number.isFinite(retryAfter) && retryAfter > 0
? retryAfter * 1000
: Math.min(2 ** attempt * 250, 8000);
const jitter = Math.random() * 250;
await new Promise((r) => setTimeout(r, base + jitter));
attempt += 1;
}
}
// Usage
const ENDPOINT = "https://eu.endpoints.matrixed.link/rpc/polygon?auth=YOUR_API_KEY";
const block = await rpcWithBackoff(ENDPOINT, {
jsonrpc: "2.0",
id: 1,
method: "eth_blockNumber",
params: [],
});The same principle applies in Python with web3.py or a plain requests loop. On Solana with @solana/web3.js, a 429 from a Solana RPC method carries the same meaning and the same fix. Backoff logic is chain-agnostic: the transport is HTTP, so the HTTP contract governs. For a deeper treatment of error codes beyond 429, see how to handle RPC errors in Web3.
Why are some RPC methods rate limited more strictly?
Not all methods cost the same to serve, so many providers weight them differently. A cheap method like eth_blockNumber reads a single value. A heavy method like eth_getLogs over a wide block range can scan gigabytes and return enormous payloads. debug_* and trace_* methods are heavier still.
Providers respond to this in one of two ways. Some apply stricter per-second caps to expensive methods. Others move to a weighted request unit model, where each method consumes a published number of units. Under weighting, one eth_getLogs call might cost several times what a eth_blockNumber call costs, which is a more honest reflection of the real load.
This weighting is exactly why cost prediction matters. If you know the unit cost of every call before you build, you can budget precisely instead of discovering your ceiling in production. BoltRPC publishes fixed, transparent per-method unit weights for this reason. See how RPC request units work and RPC pricing and compute units explained for the full breakdown.
Rate limiting vs throttling: what is the difference?
The terms get used interchangeably, but there is a useful distinction.
- Rate limiting rejects requests once you cross the ceiling. You get a 429 and the request fails. It is a hard boundary.
- Throttling slows requests to keep you under the ceiling. Instead of rejecting the excess, the system queues or delays it so your effective rate stays within bounds.
In practice, providers combine both. A client-side throttle (a request queue that paces your calls) keeps you comfortably under the server-side rate limit, so you rarely see a 429 in the first place. Throttling is your defense. Rate limiting is the wall you are avoiding.
How to design around RPC rate limits (the architecture)
This is where most guides stop short. Understanding a limit is easy. Architecting so it never constrains you is the real work. Here are the patterns that matter, roughly in order of impact.
1. Batch your requests. JSON-RPC supports batching: send an array of calls in a single HTTP request. Many providers count a batch against your limit intelligently. Even where each call still counts, you save connection overhead and round-trips. Batching is the single easiest win for read-heavy workloads.
2. Cache immutable and near-immutable data. A finalized block never changes. A token’s decimals never change. A historical transaction receipt never changes. Cache these aggressively at the edge or in memory. That removes them from your request budget entirely. Most applications can cut RPC volume dramatically with a modest cache.
3. Multiplex and load-balance across endpoints. Spread traffic across multiple endpoints or keys so no single one absorbs the whole load. A simple round-robin or least-loaded strategy smooths bursts. See RPC load balancing patterns for concrete strategies.
4. Fail over to a backup provider. When your primary returns 429s or errors, route to a secondary automatically. This turns a rate-limit event from an outage into a hiccup nobody notices. See RPC failover architecture.
5. Move off shared nodes for critical paths. Shared public endpoints impose the tightest limits because they serve everyone. A dedicated node gives you headroom that a shared pool never will. See shared vs dedicated RPC nodes.
6. Choose a quota model that fits your spikes. If your traffic is bursty, a hard per-second cap will always be the wrong shape for it. A monthly budget that lets you spend freely within your quota fits real-world spikes far better than a rigid RPS ceiling.
That last point leads directly to how BoltRPC is built.
How BoltRPC handles rate limits
BoltRPC is designed around a monthly Request Unit (RU) budget rather than a per-second wall. Inside your quota there is no per-request throttling: you are not fighting a per-second ceiling in the middle of a market spike. The RU budget is the ceiling. You spend it on your own schedule. The platform is built for high-throughput workloads, so bursts are the expected case, not the exception.
Three things make this predictable:
- Fixed, published per-method RU weights. You know the unit cost of every call before you build, so you can budget precisely instead of guessing.
- Globally distributed infrastructure with automatic failover. Traffic is served from multiple regions with failover built in, so a single point of pressure does not become your problem.
- Scale that assumes bursts. BoltRPC serves 2 billion daily requests across its network. It is trusted by teams including Chainlink, Tiingo, Enjin.
The result is that the design-around work above becomes simpler. You still batch and cache because those are good engineering. But you are no longer architecting your entire application around dodging a per-second cliff, because the cliff is not there. Compare tiers on the pricing page, or start a free 2-week trial at trial.boltrpc.io.
Frequently Asked Questions
What is the rate limit of BSC RPC?
Public BNB Chain (BSC) endpoints publish a limit of 10,000 requests per five minutes on testnet and mainnet, applied per IP. That is fine for light usage but tight for any production workload with real traffic. A dedicated BSC endpoint removes that shared ceiling. See the BNB Chain network page for a dedicated endpoint.
Do batch requests count as one request?
It depends on the provider. Some count a JSON-RPC batch as a single request against your limit, others count each call inside the batch. Even where each call counts, batching still saves connection overhead and round-trip latency, so it remains worth doing. Check your provider’s documentation for the exact rule.
Does streaming (WebSocket) avoid rate limits?
Partly. A WebSocket subscription replaces repeated polling with a single persistent connection that pushes updates, which sharply reduces request count for event-driven workloads. Providers may still cap the number of concurrent connections or subscriptions, so streaming reduces rate-limit pressure rather than removing every limit.
How do I stop getting rate limited?
Combine client-side throttling with the architecture patterns above: batch reads, cache immutable data, load-balance across endpoints, fail over on 429s. For workloads that spike, move critical paths onto a dedicated endpoint or a quota model without a per-second cap so bursts are not fighting a ceiling. The fastest structural fix is choosing infrastructure built for high-throughput traffic.
Conclusion
RPC rate limits are not an obstacle to fear, they are a constraint to design for. Understand the limit and the 429 that enforces it. Architect around it with batching, caching, load-balancing, failover. Then pick infrastructure whose quota model fits how your traffic actually behaves, so a spike is a normal Tuesday instead of an incident. Do those three things and rate limits stop being the thing that wakes you at 3am.
BoltRPC is built for exactly this: a request-unit budget with no per-request throttling inside your quota, fixed published weights, plus globally distributed infrastructure that assumes bursts. Start your free 2-week trial at trial.boltrpc.io.
