.jpg)
DoubleZero reduces Solana data latency by moving shred delivery away from unpredictable public internet paths and onto dedicated fiber routes and using multicast to distribute data. For RPC Fast users running HFT, MEV, market making, or real-time analytics, the practical benefit is earlier, faster access to the same Solana transactions, not more transactions.
Since the start of our partnership with DoubleZero in early 2026, we’ve been actively integrating DoubleZero shreds into our RPC layer and thoroughly testing their performance. Finally, we’re glad to share the results of our experiments.
In our Frankfurt benchmark, the DoubleZero-enabled feed won 94.72% of same-transaction races against a non-DZ feed. The non-DZ path delivered the same 50,000 valid transactions, but trailed by 1.15 ms at p50, 6.97 ms at p95, and 15.29 ms at p99.
Why Solana latency starts before RPC
Most teams measure Solana performance at the RPC or gRPC layer. That is useful, but it misses the first bottleneck: how fast raw block data reaches your infrastructure.
Solana leaders split blocks into shreds before full block reconstruction. DoubleZero’s whitepaper describes shreds as pieces of a block that are transmitted before the complete block is built, and positions multicast as a way to improve data propagation across a dedicated network path.
That matters for:
- HFT bots reacting to pool updates;
- MEV searchers watching state changes;
- Market makers updating quotes;
- Liquidation systems tracking account health;
- Analytics platforms that need slot-fresh data.
If your feed receives shreds later, your application starts later as well. Faster JSON-RPC responses do not fully compensate for late data ingress.
What DoubleZero Edge adds
DoubleZero Edge is a market data distribution layer for onchain data. Its first feed is raw Solana shreds, delivered over DoubleZero’s high-performance fiber network rather than ordinary and slow public internet routing.

The protocol combines three ideas:
- Dedicated fiber links contributed by network participants;
- Edge routing and filtering for performance-sensitive traffic;
- Multicast distribution, where the network replicates data efficiently instead of forcing every publisher to duplicate packets.
Public launch coverage reported Edge starting with hundreds of validators publishing shreds and roughly 43-45% of Solana stake represented by those publishers. That coverage is important because a shred network is only useful when it sees a meaningful share of leader output.
Edge also changes Solana’s validator economics. Validators that publish shreds gain a new revenue stream from subscriber demand, while subscribers pay for earlier data access. That aligns Solana infrastructure providers, validators, and trading teams around the same performance primitive: fresher block data.
RPC Fast benchmark: With DZ vs without DZ
RPC Fast tested two shred delivery paths from AWS eu-central-1b in Frankfurt using Geyserbench.
Test setup:

Completed test results:
The key point: DoubleZero did not increase delivered transaction count in this test. Both paths saw the same 50,000 valid transactions. The gain came from ordering and arrival time.

In the recent one-hour user-facing comparison, the DZ path won 90.4% of direct same-transaction races. The non-DZ path trailed by:
- +1.0 ms median customer-visible lag;
- +3.6 ms p90 customer-visible lag;
- +1.7 ms p50 latency relative to RPC block time;
- +15.2 ms p90 latency relative to RPC block time.
For latency-sensitive Solana workloads, those numbers are material. A 1 ms median lead is not dramatic for a wallet backend. It is significant for a bot competing on pool state, quote updates, or liquidation windows.
Where RPC Fast SaaS Fits
RPC Fast SaaS packages the Solana data stack that trading and DeFi teams usually assemble by hand: JSON-RPC, WebSocket, Yellowstone gRPC, Shredstream, and RPC Fast’s in-house Aperture gRPC layer. The dedicated node offering also supports low-latency Solana setups with Yellowstone gRPC, shred-level ingestion, custom plugins, and geo placement.
DoubleZero Edge fits into that stack as an upstream data advantage. RPC Fast turns that earlier signal into an operational service:
- Ingest shreds close to the source;
- Decode and normalize data for application use;
- Stream updates over gRPC where needed;
- Keep RPC, WebSocket, and transaction paths observable;
- Place infrastructure in the right region for the strategy.
The buyer does not need to operate every layer of Solana infra. They need measurable freshness, stable streams, and a path to production without losing weeks on validator, Geyser, replay, and failover work.
When DoubleZero helps most
DoubleZero shreds matter most when your application reacts before confirmation.
The tradeoff is complexity. Raw shreds are earlier, but less processed. Your system still needs decoding, deduplication, ordering logic, replay handling, observability, and a confirmation path through standard RPC or gRPC streams.
Practical low-latency architecture example
A production Solana low-latency stack usually looks like this:
.png)
- DoubleZero Edge or another shred source delivers raw Solana shreds.
- A decoding layer reconstructs usable transaction signals.
- Yellowstone gRPC or Aperture gRPC streams structured updates to applications.
- RPC nodes handle reads, transaction simulation, and confirmation.
- Observability tracks slot lag, p95/p99 delivery, reconnects, missed slots, and source races.
The operating rule is simple: use shreds for the earliest signal, and use RPC/gRPC for correctness, state confirmation, and recovery.
Takeaway notes
DoubleZero does not make Solana produce more transactions. It helps your infrastructure see the same transactions earlier.
In RPC Fast’s Frankfurt test, DZ shreds won 94.72% of races across 50,000 valid transactions, with the non-DZ path trailing by 1.15 ms at p50 and 15.29 ms at p99. For teams competing on milliseconds, that is enough to change execution quality.
RPC Fast SaaS brings DoubleZero-style low-latency data into a managed Solana infrastructure stack, so HFT, DeFi, and analytics teams get earlier signals without owning every operational layer themselves.

.jpg)
