We ran 40,000+ transactions across Frankfurt and New York. Here’s what the data says.
TL;DR
Multiple benchmark runs. Two regions. Same tool (geyserbench v1.2.2). 10,000+ transactions each. RabbitStream arrived first in both regions tested.
| Region | RabbitStream Win Rate | Jito Win Rate | Jito P50 Behind | Jito P99 Behind |
|---|---|---|---|---|
| Frankfurt (FRA) | 97.77% | 2.23% | 6.72ms | 46.86ms |
| New York (NY) | 97.19% | 2.81% | 5.29ms | 81.50ms |
Frankfurt: RabbitStream arrived first in 9,780 of 10,003 transactions (97.77%). Jito ShredStream’s median lag was 6.72ms; at p99, it trailed by 46.86ms.
New York: RabbitStream won 9,723 of 10,004 transactions (97.19%). Jito ShredStream’s p99 reached 81.50ms — more than 20% of a full 400ms Solana slot.
In both regions: Both feeds received 100% of valid transactions with zero backfill. The difference is not reliability — it is who gets there first.
Results were consistent across multiple runs per region. Full iteration data in the benchmark section below.
Introduction
When a validator produces a block, it doesn’t broadcast it whole. It breaks it into small ~1,228-byte packets called shreds and fans them out across the network via the Turbine protocol. These shreds are the earliest form of transaction data that exists on Solana — they arrive before any RPC node has processed anything, before any program has executed, before any log has been written.
For most applications, that doesn’t matter. For bots, it’s everything.
A sniper bot reading shreds is reacting to a transaction signal that a standard RPC user won’t see for another 100–500ms. On a chain with 400ms slots, that gap isn’t small — it’s often the entire window between a winning trade and a missed one.
In this blog we will explore, two options for consuming shred-level data on Solana: Jito ShredStream and Shyft RabbitStream.
How They Work — And Where They Differ
Both RabbitStream and Jito ShredStream receive data from Solana’s shred layer — before any RPC node is involved, before execution, before logs. However, the architecture behind each is quite different.
Shred Sources
RabbitStream ingests raw UDP shreds from multiple sources simultaneously. Whichever propagation path delivers first, that’s what your client receives. There is no single relay dependency.
Jito ShredStream routes shreds through Jito’s Block Engine network. This gives it tight integration with Jito’s validator relationships, but means all shreds travel through one relay path.
Filtering
RabbitStream supports Yellowstone-style transaction filters — using the exact same SubscribeRequest format. You only receive the transactions your application needs.
Jito ShredStream has no filtering. It is a full firehose — every transaction on Solana, including votes and failures, arrives at your client.
The RPC
Neither puts the RPC in the data path. Both operate independently of RPC nodes. This is what makes shred-layer feeds fundamentally faster than Yellowstone gRPC.
Benchmark — Setup and Methodology
We ran both endpoints side-by-side on the same live stream, in the same region, at the same time — across multiple iterations.
- Tool: geyserbench v1.2.2
- Sample: 10,000–10,008 valid transactions per run
- Iterations: 2 runs per region (4 runs total)
- Regions: Frankfurt (FRA), New York (NY)
- Method: Both endpoints received the same transactions simultaneously — every delivery was tagged with which arrived first
Benchmark Results: Every Run, Every Number
We ran geyserbench v1.2.2 across two regions and multiple iterations. Every run used the same methodology — both endpoints live simultaneously, same transaction stream, tagged by first delivery. No runs were excluded.
Frankfurt (FRA)
Across two runs in Frankfurt, RabbitStream won 97.77% and 97.31% of deliveries respectively. Jito ShredStream’s p99 ranged between 25.74ms and 46.86ms. The results were consistent — the win rate gap did not meaningfully change between runs.
New York (NY)
New York is where Jito’s infrastructure is most concentrated — their strongest region. Across two runs in New York, RabbitStream arrived first in 97.19% and 96.52% of transactions respectively. Jito ShredStream’s p99 held near 80ms in both runs, confirming the tail latency pattern is not an outlier.
Across All Runs
| Region | Run | RabbitStream Win Rate | Jito P50 Behind | Jito P99 Behind |
|---|---|---|---|---|
| Frankfurt | Run 1 | 97.77% | 6.72ms | 46.86ms |
| Frankfurt | Run 2 | 97.31% | 4.19ms | 25.74ms |
| New York | Run 1 | 97.19% | 5.29ms | 81.50ms |
| New York | Run 2 | 96.52% | 3.87ms | 82.06ms |
RabbitStream arrived first in every run, in every region. Jito ShredStream’s p99 never dropped below 25ms across any iteration — and in New York, never below 81ms.
What Explains These Results?
Why RabbitStream wins consistently
The core reason is simple: RabbitStream has no single point of dependency. It ingests raw UDP shreds from multiple sources simultaneously, taking whichever propagation path delivers first. There is no relay to route through, no RPC queue to wait behind. By the time a shred hits your client, the only work that happened server-side was decoding — which adds negligible overhead.
The result is what the numbers show: a consistent, region-independent edge that held across every run we tested.
Why Jito ShredStream still wins sometimes
Jito’s Block Engine maintains direct relationships with Solana leaders. For certain slots, that direct line yields faster delivery — which explains the small share of transactions Jito wins in each region. However, across all four runs and both regions, that share never exceeded 3%, and Jito’s p99 never dropped below 25ms. The pattern suggests Jito’s edge is slot-specific, not structural.
When to Use Each
RabbitStream is the right choice when:
- You want shred-speed data without managing a proxy, keypair, or UDP infrastructure.
- Your team already uses Yellowstone gRPC — it’s a near-zero migration (same
SubscribeRequestformat). - You need transaction-level filtering (by program ID, account involvement) on a shred-speed feed.
- You’re building in FRA, AMS, or any region without heavy Jito infrastructure.
- You want to get started immediately — access is token-based, no approval process, no infrastructure setup required.
Jito ShredStream is the right choice when:
- You operate your own validator or bare-metal RPC and can run the proxy natively.
- You need raw binary shred data for custom downstream processing.
Conclusion — What the Benchmark Establishes
Across two regions, four runs, and 40,000+ transactions, RabbitStream delivered transaction data first more frequently than Jito ShredStream in every single run. The win rate ranged from 96.52% to 97.77% across all runs — a remarkably consistent band that held regardless of region or iteration.
Both feeds received 100% of valid transactions with zero backfill in every run. Reliability is equivalent. Speed is not.
Jito ShredStream’s tail latency was consistently high in New York, with p99 reaching 80.37ms and 81.22ms across two runs — never dropping below 25ms in any region or iteration.
For teams evaluating which shred-layer feed to adopt, here is the practical picture:
| RabbitStream | Jito ShredStream | |
|---|---|---|
| Access | gRPC token, existing Shyft plan | Keypair auth, proxy binary/Docker |
| Port/Network | Standard gRPC, any network setup | UDP 20000 open, direct public IP required |
| Infrastructure | None | Proxy instance per region recommended |
| Approval | None | Jito application required |
| Filtering | Transaction filters (Yellowstone-compatible) | None — full firehose |
| Execution metadata | ❌ | ❌ |
Neither feed provides execution metadata. Applications requiring logs, balance changes, or confirmed results should pair either feed with a Yellowstone gRPC subscription — using the transaction signature to correlate the shred-speed signal with the confirmed result.
