Solana RPC 2.0 and the RPC Working Group: rebuilding the read layer

Solana spent years optimising how fast it writes blocks. The thing that actually breaks for developers, though, is usually the read side — RPC. Querying accounts, fetching history, subscribing to changes. The Solana Foundation has now made the read layer a first-class project: an RPC Working Group to coordinate it, and a ground-up rebuild called RPC 2.0 that pulls reads out of the validator entirely.

The headline: reads leave the validator

Today the original RPC is bundled into the validator. RPC 2.0's core move is to remove reads from the Agave client entirely and serve them from a purpose-built layer that is "faster, cheaper, and far more expressive." It's built by Triton in partnership with the Solana Foundation, alongside Helius, Jupiter, and Anza.

Why this was necessary — the structural problems with the bundled RPC (call it RPCv1):

• Monolithic. Accounts, history, and streaming live in one process, so you can't scale the read path independently of the validator that's busy doing consensus.
• Reads dominate. The overwhelming majority of node traffic is reads, not writes — Syndica's data has put it around ~96%. The validator was never designed as a read-optimised database.
• Provider lock-in. Because vanilla RPC doesn't scale cheaply, serious read workloads run on proprietary provider stacks. The performant read layer ended up closed and fragmented.

The two modules: Cloudbreak and Superbank

The Foundation's RFP organised the work into three domains — Accounts, Historical, and Streaming. The shipping RPC 2.0 build centres on two purpose-built, separately named modules, with streaming served through the existing Yellowstone gRPC path:

• Cloudbreak — account reads. It serves account queries from tailored PostgreSQL indexes instead of Agave's key-value store. A standalone query tracker watches your traffic and counts how often each filter pattern appears; once a pattern crosses a threshold it auto-builds a matching index, and queries skip raw scans from then on. It serves getProgramAccounts (with memcmp and dataSize filters), getTokenAccountsByOwner, and getTokenAccountsByDelegate, with Token and Token-2022 paths optimised via denormalised columns.
• Superbank — the full ledger. A new Rust backend that ingests Solana's entire ~400 TB+ ledger into ClickHouse (sorted columnar storage + materialised views) and serves it as spec-compliant JSON-RPC, replacing the old Bigtable-based system. getTransaction, getSignaturesForAddress, and getSignatureStatuses are already live, and every epoch from genesis is priced the same — no premium for old data.

The benchmarks

Both modules published numbers against public RPC. Superbank, at p50:

• getSignatureStatuses — 38× faster (1,885 ms → 49 ms)
• getSignaturesForAddress — 5× faster (245 ms → 50 ms)
• getTransaction — 3.3× faster (460 ms → 138 ms)

Cloudbreak claims up to 20× faster account reads — getProgramAccounts averaging 205 ms vs ~2,488 ms on Agave (P90 278 ms vs ~6,583 ms).

The Working Group and governance

The RPC Working Group is the coordination layer around the rebuild. Rather than expecting each operator to solve indexing and historical storage in isolation, it brings RPC operators, application developers, and grant recipients together under shared governance, with the Solana Foundation steering a small core to keep direction aligned without design-by-committee.

The governance and funding model has three notable features:

• AGPL, neutral org. Everything ships open-source under AGPL, managed through a neutral RPC organisation run by the Solana Foundation. The bet: core infrastructure should be open, auditable, and community-owned rather than a vendor moat.
• Maintenance grants. Teams selected through the RFP get initial funding and one-year maintenance grants after hitting milestones — infrastructure needs ongoing support, not one-off bounties.
• Self-hostable. Institutions, enterprises, and funds get a standardised read layer they can audit and deploy internally, not just rent.

Why it matters

This is to RPC what client diversity was to the validator. Just as Firedancer and Sig broke single-client risk on the write side, RPC 2.0 gives the read side an open, modular foundation. Concretely:

1. Cheaper to operate. Pluggable storage and decoupled services mean operators pay for what they run, instead of one heavyweight process bolted to a validator.
2. Competition moves up the stack. Providers share an open base instead of each re-engineering indexing and history — so they compete on the products on top, and ship faster.
3. Less lock-in. An open, performant read layer closes the gap between vanilla RPC and the proprietary stacks that read-heavy apps depend on today.

What it means for you

If you build apps: nothing breaks today — existing RPC and providers keep working. Over time you get faster account reads (Cloudbreak builds indexes matched to your query patterns automatically), cheaper history via Superbank, and an open implementation you can self-host or choose between. Watch Cloudbreak if you lean on getProgramAccounts or token-account queries.

If you run infrastructure: this is the path to a competitive read layer without a proprietary stack. Superbank is AGPL today; Cloudbreak is set to open-source under AGPL as part of Yellowstone, and a self-hosted Cloudbreak runs on commodity PostgreSQL — roughly 700 GB of storage for under $400/month. RPC 2.0 is an ongoing project shipping in stages through 2026, with Superbank and Cloudbreak landing in June 2026.

For the provider landscape RPC 2.0 is reshaping, see the Solana RPC providers comparison.

References

• Triton — Announcing RPC 2.0 with the Solana Foundation
• Triton — Introducing Cloudbreak (indexed account reads)
• Triton — Introducing Superbank (full ledger in milliseconds)
• pkxro — "Introducing RPCv2 and the Solana RPC Working Group"
• Solana — "RPC 2.0 is here"