Quark: RPC Fast’s DeFi Query Accelerator for Solana

Quark is RPC Fast’s in-house Solana query accelerator for traders, searchers, routing engines, and DeFi backends whose critical path includes filtered getProgramAccounts calls.

Instead of handling every eligible request as a broad program-account scan, RPC Fast routes matching Mainnet Beta queries through a custom accounts engine backed by bounded account-type or mint indexes. Your application keeps the same RPC endpoint and standard Solana response shape.

The latest RPC Fast benchmark, published on September 11, tests nine DeFi pool-discovery workloads under the same filters and commitment on Quark and Agave. In the confirmed, warm-repeat, full-data comparison, Quark recorded median latency between 0.366 ms and 0.856 ms, while the matching Agave requests ranged from 1.86 seconds to 38.26 seconds.

TL;DR

• Quark accelerates eligible filtered getProgramAccounts and getProgramAccountsPaginated request shapes rather than Solana RPC in general.
• Matching requests use RPC Fast’s indexed accounts engine; unsupported request shapes remain on the normal RPC path.
• The latest benchmark covers nine DeFi discovery workloads across Pump AMM, Orca Whirlpools, Meteora DAMM v2, Meteora DLMM, Meteora DBC, Raydium v4, Raydium CLMM, Raydium CPMM, and Raydium LaunchLab.
• For confirmed, warm-repeat, full-data requests, all nine Quark median measurements were below 1 ms. Agave medians for the same requests ranged from 1.86 to 38.26 seconds.
• Relative latency differences in that view range from about 2,172× for Raydium CPMM to 104,595× for Pump AMM.
• The useful benchmark is still your production query shape: protocol, filters, commitment, payload, cache state, concurrency, and network path all affect end-to-end latency.

Benchmark note: What the latest test measures

RPC Fast sends the same filters and commitment to Quark and Agave and reports results across three dimensions:

• processed, confirmed, and finalized commitment;
• full data, returning complete account data, and keys only, using dataSlice: {offset: 0, length: 0};
• first pass and warm repeats.

“First pass” is the first observation in the run; caches were not explicitly cleared. “Warm repeats” combines the next three observations. Requests that fail to complete within 60 seconds are recorded as ≥60 s. Measurements use live account state, so slots and payload sizes differ between requests.

The numbers below therefore describe a controlled RPC Fast benchmark, not a universal latency guarantee or SLA.

Why DeFi getProgramAccounts becomes a different RPC problem

Solana's getProgramAccounts returns accounts owned by a specified program and supports filters such as dataSize and memcmp. For DeFi applications, that often translates into pool discovery, market lookup, obligation discovery, or filtering state by one or more token mints.

That workload differs from reading a known account address.

A trading engine often knows what state it wants, such as a Whirlpool for a specific mint pair, but not the account address containing that state. The infrastructure first has to identify the matching account set.

Quark targets this discovery step. RPC Fast describes the architecture as replacing broad program scans with bounded mint or account-type indexes for eligible queries.

How Quark works

There is no separate Quark API for your application to integrate. Your client sends an eligible getProgramAccounts or getProgramAccountsPaginated request to the usual RPC Fast endpoint. The gateway identifies the program, commitment, and filter shape. Matching requests go through Quark's accounts engine; requests outside the supported shapes remain on the normal RPC path.

That gives Quark an important distinction: It is an acceleration layer behind standard Solana RPC semantics, not a protocol-specific data API.

Your trading system does not need one API for PumpSwap, another for Meteora, and another for Raydium merely to use the acceleration path.

Which DeFi workloads Quark accelerates

We list the following eligible account layouts. All listed entries support processed, confirmed, and finalized commitments. 

Latest benchmark coverage

The current Quark benchmark does not test every supported account layout. Instead, it concentrates on nine pool-discovery query shapes:

• Pump AMM—pool by base + quote mint;
• Orca Whirlpools—pool by token pair;
• Meteora DAMM v2—pool by token pair;
• Meteora DLMM—LB pair by token pair;
• Meteora DBC—pool by mint;
• Raydium v4—pool by token pair;
• Raydium CLMM—pool by token pair;
• Raydium CPMM—pool by token pair;
• Raydium LaunchLab—pool by base mint.

Quark request requirements

A Quark-eligible request uses a documented program ID, explicitly sets base64 encoding, includes a non-empty filters array, and uses standard dataSize or memcmp filters. Mint filters must resolve to exactly 32 bytes. dataSlice and withContext remain supported.

For mint-indexed protocols, the required offsets are protocol-specific. PumpSwap, Raydium AMM v4, CLMM, and CPMM accept one or both documented mint filters. Orca and both Meteora layouts require both mint filters.

Quark also supports eligible getProgramAccountsPaginated requests. Current documentation limits compact mint-index queries to 1,000 accounts per page and other accelerated layouts to 10,000 accounts per page.

Latest Quark benchmark results

The September 11 benchmark provides a cleaner way to compare the two execution paths because it separates commitment, cache state, and payload type.

For the table below, we use confirmed commitment, warm repeats, and full account data.

All nine Quark medians in this comparison stay below 1 ms. The Agave side ranges from roughly 1.9 seconds for Raydium CPMM to more than 38 seconds for Pump AMM.

One method, very different amounts of work

Even inside the Quark path, confirmed warm full-data latency ranges from 0.366 ms for Pump AMM to 0.856 ms for Raydium CPMM. On Agave, the same query class ranges from 1.86 seconds to 38.26 seconds. 

Depending on your project’s needs, tasks, and functions, you may decide which path getProgramAccounts takes and how much time it’ll cost. Program layout, filter offsets, candidate account set, result cardinality, payload size, and backend indexing all change the amount of work required.

So benchmark the query shape, not the method name.

Example: What the Pump AMM result means

For confirmed, warm-repeat, full-data requests, Quark reports a 0.366 ms median versus 38.26 seconds for Agave—roughly a 104,595× latency difference. The first-pass confirmed measurement was 0.217 ms for Quark versus 38.63 seconds for Agave.

A 38-second program scan is unusable inside an HFT decision loop. A sub-millisecond indexed lookup keeps account discovery small enough to leave the remaining time budget for strategy evaluation, transaction construction, simulation, fee logic, submission, and confirmation.

Quark changes the amount of backend work required to locate matching accounts. It does not accelerate Solana consensus or transaction propagation.

Quark performance is not dependent on one warm-cache result

Warm-cache benchmarks often deserve skepticism, so the first-pass numbers are useful. For confirmed full-data requests, Quark’s first observations ranged from:

• 0.217 ms—Pump AMM;
• 0.429 ms—Meteora DLMM;
• 0.530 ms—Meteora DAMM v2;
• 0.617 ms—Raydium CPMM;
• 0.704 ms—Raydium CLMM;
• 0.725 ms—Raydium v4;
• 0.666 ms—Meteora DBC;
• 1.028 ms—Raydium LaunchLab;
• 1.661 ms—Orca Whirlpools.

Seven of nine first-pass confirmed full-data measurements therefore stayed below 1 ms, while every warm-repeat median did.

The integration trap: Your SDK call is not your RPC call

Protocol SDKs often hide the underlying RPC request. That matters because Quark evaluates the actual RPC shape, not the high-level SDK function name.

For example, RPC Fast's current documentation notes that Orca's fetchWhirlpoolsByTokenPair helper first reads FeeTier accounts, derives pool addresses, and then uses getMultipleAccounts. The accelerated Whirlpool GPA path instead requires a raw getProgramAccounts request containing both mint filters at offsets 101 and 181.

Raydium presents another example. Its documented all-pools flow uses size-only GPA requests, while Quark acceleration requires the documented mint filters. Size-only all-pool scans do not match the acceleration path.

Inspect the RPC your SDK emits before assuming a supported protocol automatically means an accelerated workload.

Where Quark fits

Quark is strongest when account discovery itself sits on the critical path.

For HFT and arbitrage systems, that means resolving the pool or market state required to evaluate an opportunity. For routers and pricing services, it means repeated filtered discovery across structured DeFi account sets.

The business effect is not “faster Solana.” It is narrower: less of your strategy window is consumed by account discovery before the execution logic starts.

Quark remains less relevant when your application already knows the exact account addresses and performs direct point reads.

What Quark does not accelerate

Quark is not a universal RPC fast path. We explicitly state that getAccountInfo and getMultipleAccounts do not use this GPA acceleration path. Requests with unsupported programs or filter shapes also continue through the normal RPC route.

It also does not change leader scheduling, transaction propagation, priority-fee economics, or confirmation semantics.

This distinction prevents the wrong benchmark question. The right one is—“How much time does Quark remove from this exact filtered account-discovery operation?”

Benchmark the query shape, not the method name

• The same test page shows results changing with: program × filters × commitment × full-data/keys-only × first/warm state
• Production testing should add: concurrency × client region × network RTT × result cardinality

Track p50, p95, and p99 together with state freshness, success rate, response size, and behavior under account churn. Then measure how much of that improvement survives inside the end-to-end strategy loop.

A 0.5 ms backend lookup has little value if network RTT or downstream processing dominates the decision path.

Ready to use Quark?

Use Quark where filtered getProgramAccounts queries already consume measurable time in your DeFi critical path: pool discovery, market lookup, token-ledger queries, or obligation discovery.

Start with the request your application already sends:

1. Identify expensive filtered getProgramAccounts calls.
2. Check whether the program and filter shape match a Quark-accelerated layout.
3. Send the eligible request through your existing RPC Fast endpoint—there is no separate Quark API.
4. Compare the exact production query across commitment levels and payload shapes.
5. Measure client-side p50/p95/p99 and state freshness before moving the optimized path into your strategy loop.