RPC Fast August roundup: Faster account reads, Quark, and better observability

At RPC Fast, we spent August focused on one of the less glamorous but expensive parts of Solana infrastructure: moving large amounts of account data without turning RPC into a bottleneck.

RPC Fast separated account-reading workloads from the rest of its Solana RPC processes, introduced Quark for accelerated DeFi queries, sped up all three low-latency streaming products, expanded dashboard analytics, and added project-level IP whitelisting. The Solana RPC documentation also gained a pagination extension for account queries that are too large for a safe single response.

For DeFi backends, indexers, trading systems, wallets, and other account-heavy applications, the common pain is isolation: expensive reads should not compete with routine RPC traffic, stream processing, or transaction delivery for the same infrastructure resources.

TL;DR

• Common Solana account requests on RPC Fast are now 3–8× faster after we separated account-reading workloads from other RPC processes.
• Meet Quark, RPC Fast’s custom accounts engine, that accelerates eligible getProgramAccounts queries for protocols including PumpSwap, Orca, Meteora, Raydium, HumidiFi, and Kamino.
• TxStream, Shredstream gRPC, and Yellowstone gRPC received performance improvements plus a new raw-shreds source, Raiden.
• Dashboard analytics now support method comparison, filtering, zooming, and more granular latency analysis, while IP whitelisting restricts project tokens across RPC/WS, gRPC, and Beam.
• getProgramAccountsPaginated provides bounded pages and continuation keys for result sets too large or expensive for a single standard response.

Solana account reads moved onto a separate performance path

A large Solana account query behaves differently from a normal RPC request.

A filtered lookup against a popular program might return a large result set, hold significant memory during processing, and run for tens of seconds. On shared infrastructure, one such request risks consuming resources that would otherwise serve blockhash reads, account lookups, transaction queries, or other users.

RPC Fast changed that architecture in August by separating account reading from the rest of the Solana RPC processes. The resulting infrastructure now responds to common account requests 3–8× faster than standard Solana RPC, according to the August update.

The architectural benefit extends beyond the individual query. Separating the account path reduces contention between memory-heavy account scans and latency-sensitive routine RPC workloads.

This distinction matters for systems built around:

• Wallet and portfolio state,
• DEX pool discovery,
• Lending markets,
• Token analytics,
• Indexing,
• Trading strategy state.

The key metric sits beyond the fastest account request. A production RPC service also needs predictable latency while expensive queries run alongside ordinary traffic.

Quark brings accelerated DeFi queries into RPC Fast SaaS

Quark targets specific combinations of program, commitment, and filter shape. Initial use cases listed in the August update include Pump.fun PumpSwap, Orca Whirlpools, Meteora, Raydium, HumidiFi pool accounts, and Kamino Lending.

This is narrower than saying “every getProgramAccounts call is thousands of times faster.” Here’s what we found in numbers.

Quark benchmark: Filtered DeFi getProgramAccounts

We compared the RPC Fast Quark path against Agave for eight DeFi account-query cases. The displayed configuration uses confirmed commitment and P90 latency.

The results below show why account-query benchmarks need workload-level detail. The Jupiter case improves by 2.18×, while several pool-account queries differ by four to six orders of magnitude. Method name alone does not describe the cost profile; program size, filters, result shape, commitment, and backend architecture—all matter.

For a production DeFi backend, the right test is your exact program IDs and filters, not an unfiltered synthetic RPC latency check.

TxStream, Shredstream gRPC, and Yellowstone gRPC got faster

RPC Fast accelerated Aperture TxStream, Shredstream gRPC, and Yellowstone gRPC and added another raw-shreds integration. Check out the August gRPС performance comparison here.

You might have seen a recent announcement—we'll cover it in more detail in the next roundup.

Architecturally, the additional source matters because the three feeds occupy different places in the latency stack. Yellowstone provides structured Solana events, Shredstream exposes reconstructed shred-level data, while TxStream is designed around earlier decoded transaction delivery and execution-sensitive processing.

A new raw source therefore affects more than peak speed. Source diversity also matters for coverage, regional performance, failover, and latency variance.

The right post-update test is a feed race from the same consumer host: record first arrival, complete-message arrival, missing transactions, duplicates, reconnects, and p95/p99 rather than comparing one average.

Dashboard analytics now exposes method-level behavior

A RPC Fast dashboard becomes useful when it answers which workload produced the latency, rather than showing one blended RPC number.

Our August’s analytics update adds method selection for side-by-side comparison, method filtering, a zoom-range tool, and more precise latency inspection. 

That changes the operational workflow.

Suppose total RPC latency spikes while request volume remains stable. A blended average gives little direction. Method-level analytics lets an SRE separate a slow account query from normal getBalance, transaction, or block requests and correlate the spike with the request mix.

The same view is useful before optimization. Measure latency by method, identify the expensive path, move or redesign that path, then compare the same metric after the change.

IP whitelisting adds project-level access control

RPC Fast also added IP whitelisting per project and per token. Once configured, the restriction applies across the products inside that project: Beam, gRPC, RPC, and WebSocket access.

This is particularly relevant for backend-only infrastructure. An API token restricted to the known egress IPs of a trading cluster, indexer, or application backend has a smaller exposure surface than a credential accepted from arbitrary networks.

It does not replace proper secret storage, credential rotation, or application-level authorization. It adds another control at the infrastructure boundary.

For teams operating separate production, staging, and development environments, project-level restrictions also make access policy easier to align with the environment that owns each token.

getProgramAccountsPaginated addresses oversized result sets

The more interesting addition for account-heavy applications is getProgramAccountsPaginated, an RPC Fast extension for requests whose result sets are too large or expensive to return safely in a single getProgramAccounts response.

The extension preserves standard Solana account encoding and filter shapes, but returns:

• A bounded page of results, and
• An opaque continuation key for the next page.

That is an operationally cleaner failure mode than treating every program scan as one unbounded response. Large payloads increase memory pressure, transfer size, response time, and retry cost. Pagination bounds each unit of work while retaining the familiar account-query model.

Standard vs paginated account reads

These approaches solve different problems. Quark reduces query execution time for supported workloads. Pagination controls response size. The underlying account-path separation protects the rest of the RPC workload from expensive reads.

What the August updates mean for production architecture

The August release set is more coherent when viewed as one account-and-data pipeline:

Heavy account queries get a specialized execution path. Oversized responses get pagination. Streaming workloads stay on dedicated real-time interfaces. Access policies apply at project level. The dashboard then exposes enough per-method data to measure whether those choices work.

That is more useful than treating every Solana workload as interchangeable RPC traffic.

Looking forward: September discounts and more integrations

Two August items point directly into September. RPC Fast plans the future integrations,more benchmarks, and performance tuning. We launch new promotion for quarterly subscriptions and plan to support the next Colloseum edition in September.

The Summer Sale itself has ended. Yet, the RPC Fast community still has promo codes to offer; check the Telegram and Discord communities for current codes before subscribing.

For engineering teams, the more important next step is continuous measurement. Re-run account queries after the August architecture changes, test Quark against your exact DeFi filters, compare streaming p95/p99 from your production region, and use the expanded dashboard to identify where the remaining latency budget sits.