Solana RPC on Chainstack in 2026: higher limits, GPA and more

We rebuilt Solana RPC on Chainstack. We spent the last few months on two things: methods hitting rate limits under real traffic, and getProgramAccounts calls that never finish. One number sums up the result: median getLatestBlockhash latency in Chainstack Cloud Frankfurt dropped from about 17 ms to about 2 ms once we moved Solana to our new architecture.

Why we rebuilt our Solana infrastructure

Solana is hard on shared infrastructure. A handful of heavy methods can starve everything else on the same node, so adding more nodes of the same kind never fixed the real problem. The cause was contention, not capacity: we watched getTokenAccountsByOwner sit at an 18-second weighted-mean response time while basic methods on the very same node answered in 20-40 ms.

What changed

1. Up to 10x lower latency: Solana is fully on GEN 2.0

The old stack sent your request through an edge proxy layer that alone added about 17 ms in Frankfurt. GEN 2.0 removes it: DNS sends your request to the nearest healthy region, and method-aware routing picks the right pool. The Frankfurt median came out about 10x lower; other regions vary.

2. Up to 150x higher limits on heavy methods

We split Solana into a scan pool and a general pool and send each method to the one that fits. Isolation let us raise per-method limits we could never touch before, and they are the same in every region. getSupply went from 2 to 300 RPS, and your plan's overall RPS limit still applies on top.

3. Faster getProgramAccounts

We rebuilt the account indexes in-house and preload them at node startup. On top sits a cache that now picks up programs that get repeated requests automatically, and serves them at confirmed and finalized commitment.

4. Up to 20x RPS for getProgramAccounts

Limits are now set per program by size, and requests with filters get more than those without. Programs under 10K accounts went from 1 to 20 RPS with filters. Very large programs are limited tighter than before, and we say so in the full article.

💡 Want the full breakdown with the size tiers, p95 numbers and FAQ? Read the complete article on Chainstack Blog →

5. No more hanging scans

Scan methods now run under a 60-second execution limit and a per-request memory limit, enforced inside the node. Over either limit, a scan returns error -32012 right away instead of hanging until your client times out.

6. Faster heavy reads: newer client, new hardware

Global Nodes run Agave v4.3.0 tuned for RPC load, and part of the Frankfurt, New York and Singapore capacity moved to new bare-metal servers. In our rollout measurements, getProgramAccounts p95 went from 25-60 seconds to under 2, and getTokenAccountsByOwner from up to 2 minutes to about 1 second.

7. Shred feed gaps cut by about two thirds

We moved to a new dedicated shred feed across five clusters with no restarts and no customer impact. The share of block data a node had to rebuild itself dropped on every cluster, for example Frankfurt 1 from 16.65% to 5.36%.

💡 The full article has the getProgramAccounts size tiers, the p95 and shred feed numbers cluster by cluster, how to get started on the free plan, and an FAQ on limits and error codes.

Read the full article on Chainstack Blog →