Solana RPC Rate Limits, Explained

Every Solana RPC provider rate-limits. The difference isn't whether limits exist — it's how they're enforced, how predictable they are under load, and what happens when you hit one. If your bot or agent has ever died mid-strategy on a 429, this is why.

The Short Answer

Rate limits exist because RPC infrastructure is shared and finite. Providers enforce them in one of three ways: request quotas (N calls per second/month), compute-unit metering (heavier calls cost more against your quota), or prepaid per-call credits (every call costs a known amount, and you can't outrun your balance). The model matters more than the headline number.

Why Providers Throttle

An RPC node can serve a bounded number of requests per second before latency degrades for everyone on it. Without limits, one customer's programSubscribe firehose would starve every other customer on the same hardware. Rate limits are the mechanism that keeps a shared node usable.

The problem isn't the limit — it's that most limits are invisible until you hit them. You find out where the ceiling is by falling through it, usually in production, usually at the worst possible time.

The Three Models

1. Request quotas (requests/second or requests/month)

The classic model. You get a plan that says "50 req/s" or "10M requests/month," and exceeding it returns 429.

The weakness: not all requests are equal. A getSlot and a getProgramAccounts both count as "1 request," but one costs the node a microsecond and the other can scan the entire account set. Under quota models, providers either silently throttle the heavy calls or ban them outright — and the behavior is often undocumented.

2. Compute-unit metering

An improvement: each method is assigned a weight, and your quota is denominated in compute units rather than raw requests. Heavy calls drain the quota faster. This is more honest, but the weights are provider-specific, so it's hard to predict cost without testing your exact call mix.

3. Prepaid per-call credits

The model Nodius uses. Every method has a published credit cost — getSlot is 1, simulateTransaction is 5, getTokenAccountsByOwner is 25 — and you spend down a prepaid USDC balance. There is no separate rate limit on top: if you have credits, the call goes through.

The practical consequence: your calls always go through when you're funded. Your cost is a pure function of your call mix, and it's knowable before you run — a funded balance is a guarantee, not a ceiling you'll hit.

Why This Matters for Bots and Agents

Human-driven apps can absorb a rate limit — retry, back off, show a spinner. Autonomous systems can't, or at least shouldn't have to. A trading bot that gets throttled during a volatility spike misses the trade. An agent that hits a quota wall mid-task fails the task.

For these workloads, predictability beats raw throughput. A provider that promises "higher limits" is less useful than one that promises "you always know exactly what a call costs and it will always go through if you're funded." That's the property prepaid credits give you.

How to Design Around Any Provider's Limits

Whatever model your provider uses, a few patterns make you resilient:

Batch where possible. Solana JSON-RPC supports batch requests — one HTTP call carrying many method invocations. On Nodius, each method in the batch is billed individually, but the batch counts as one request for connection overhead, which is friendlier to any concurrency cap.
Use getMultipleAccounts instead of N getAccountInfo calls. One call, many accounts, billed per account — strictly better than fanning out.
Cache stable data. getGenesisHash, program account layouts, token mint metadata — these don't change. Don't pay to re-read them.
Prefer subscriptions over polling. If you're polling getAccountInfo in a loop, a WebSocket accountSubscribe or Yellowstone gRPC stream pushes updates to you instead — and on Nodius, streaming is billed in a way that's cheaper than aggressive polling for high-frequency data.
Know your call mix. The single most useful exercise is logging your method distribution for an hour. Most teams find 90% of their cost is 2–3 methods, which makes optimization trivial.

The Takeaway

The question that matters isn't "what's your rate limit?" — it's "what exactly happens when I burst, and can I know my cost in advance?" A published per-method price list with prepaid billing answers that question completely: cost is knowable up front, and every funded call goes through. A headline "requests per second" number tells you neither.