First-detection share
The percentage of matched transactions where a provider or workflow delivered the first usable update. For latency-sensitive transaction systems, this shows who wins the data-delivery race most often.
// Shred benchmark
Shreder Binary vs DoubleZero Edge: Solana Shred Latency Benchmark
A Frankfurt benchmark comparing Shreder Binary with a DoubleZero Edge raw-shred workflow for first delivery of usable Solana transaction data.
In this 100,000-transaction Frankfurt run, Shreder Binary delivered 81.48% of matched transactions first, compared with 18.52% for the DoubleZero raw-shred workflow. The published latency deltas for DoubleZero were p50 1.69 ms, p95 15.06 ms, and p99 24.45 ms.
Shreder Binary Frankfurt81.48% firstp50 / p95 / p99: 0.00 / 0.94 / 3.70 ms
DoubleZero Frankfurt18.52% firstp50 / p95 / p99: 1.69 / 15.06 / 24.45 ms
Sample100,000 matched transactions
LocationFrankfurt · Teraswitch FRA2
// Published run
Shreder Binary vs DoubleZero Edge: published benchmark details
| Benchmark | Shreder Binary vs DoubleZero Edge |
|---|---|
| Product class | Shred-derived transaction stream vs raw-shred workflow |
| Shreder endpoint | Shreder Binary Frankfurt |
| Comparison endpoint | DoubleZero Frankfurt raw-shred workflow |
| Coverage setup | Jito shreds were added to DoubleZero Edge shreds to create a continuous raw-shred stream for full-spectrum transaction comparison. |
| Test location | Frankfurt, Teraswitch FRA2 |
| Sample size | 100,000 transactions |
| Benchmark tool | GeyserBench |
| Measurement target | First delivery of matched usable transaction data |
Derived stat: Shreder Binary delivered the first usable transaction update about 4.4× more often than the DoubleZero raw-shred workflow in this published run.
// First detection and latency
First-detection share and latency percentiles
| Provider / workflow | First-detection share | p50 latency delta | p95 latency delta | p99 latency delta |
|---|---|---|---|---|
| Shreder Binary Frankfurt | 81.48% | 0.00 ms | 0.94 ms | 3.70 ms |
| DoubleZero Edge Frankfurt | 18.52% | 1.69 ms | 15.06 ms | 24.45 ms |
First-detection share shows which side delivered the same matched transaction first. Latency percentiles summarize the reported delivery-time delta distribution for this benchmark. p50 is the median case, while p95 and p99 show tail behavior.
The Shreder p50 value of 0.00 ms does not mean literal zero network latency. It is the published relative latency-delta result for this benchmark table. End-to-end latency always includes network transport, processing, serialization, stream handling, and downstream application logic.
// Interpretation
What this result means
This benchmark compares the time to usable Solana transaction data. DoubleZero Edge delivers raw shreds; Shreder Binary delivers compact serialized transactions already extracted from Shreder's raw-shred pipeline.
In this run, Shreder Binary delivered the first usable transaction update for 81.48% of matched transactions. The DoubleZero raw-shred workflow delivered first for 18.52% of matched transactions.
p50 latency delta
The median observed delivery-time delta in the benchmark. This shows the typical difference for matched events in the run.
p95 latency delta
The 95th percentile delivery-time delta. Useful for understanding tail behavior beyond the median.
p99 latency delta
The 99th percentile delivery-time delta. Important for searchers, trading systems, alerts, and infrastructure where rare slow updates can still be costly.
Sample size
The number of matched transactions included in the comparison. This run used 100,000 transactions, giving a broader view than a smaller spot check.
Usable data
Raw shreds still need to be processed before an application can act on transactions. Binary moves that processing into Shreder's optimized pipeline.
Takeaway: in this Frankfurt benchmark, Shreder Binary delivered usable transaction data first for most matched transactions while removing the need for teams to build and maintain their own raw-shred processing stack.
// Fair comparison
Why compare Shreder Binary with DoubleZero raw shreds?
On the surface, Shreder Binary and DoubleZero Edge are different product types. DoubleZero Edge gives users raw Solana shreds. Shreder Binary gives users serialized transaction bytes extracted from shreds.
The comparison still makes sense because most latency-sensitive applications do not act on raw packets directly. They act on transactions. A raw-shred feed still requires receiving packets, deduplicating them, reconstructing data, extracting transactions, serializing or deserializing the result, and routing it into the application.
Shreder Binary is designed to do that processing efficiently inside Shreder's pipeline, so users get the transaction-level output directly. The benchmark therefore compares a practical outcome: how quickly each path can produce usable transaction data for the customer.
The output is what matters
Raw shreds are an input. For many trading, searcher, and infrastructure workloads, the useful output is a transaction update that the application can parse and act on.
Processing is not free
Raw-shred pipelines need packet handling, deduplication, reconstruction, decoding and extraction. Those steps add engineering work and runtime latency.
Binary includes the hard part
Binary is based on Shreder's raw-shred data path and performs highly optimized data extraction before delivering compact serialized transaction bytes to the user.
// Coverage setup
Why Jito shreds were added to the DoubleZero side
During testing, Jito shreds were added to DoubleZero Edge shreds so the raw-shred side had a continuous stream across the full transaction set. This avoided a benchmark where skipped coverage, rather than delivery speed, would dominate the result.
That setup makes the comparison more conservative and more useful.
The goal was to test the practical path a low-latency team would build: combine raw-shred sources, process them continuously, and compare when usable transaction data becomes available.
// Product context
Raw shreds are early. Binary is already usable.
Raw-shred feeds and Shreder Binary serve different engineering preferences. The right choice depends on whether you want maximum packet-level control or the fastest path to usable transaction data. See also Raw Shreds and Shreder Binary.
| Dimension | Raw shreds | Shreder Binary |
|---|---|---|
| Data level | Raw Solana shreds / packets. | Serialized Solana transactions extracted from shreds. |
| Customer work required | Build and maintain packet receive, dedupe, reconstruction, deshredding, extraction, and downstream routing. | Consume a compact transaction stream without maintaining your own raw-shred processing stack. |
| Control | Maximum low-level control over the pipeline. | Less packet-level control, but much simpler and faster to use. |
| Best for | Teams that specifically need raw packets and have deep Solana shred-processing infrastructure. | Teams that want fast transaction visibility with less engineering overhead. |
| Operational risk | Higher: packet loss handling, duplication, coverage, CPU load, backpressure, and parser maintenance are your responsibility. | Lower: Shreder handles the optimized extraction path and delivers transaction bytes directly. |
Practical recommendation: choose raw shreds when your team needs custom packet-level processing. Choose Binary when your goal is fast transaction data and you do not want to own deshredding, reconstruction, and extraction.
// Correctness
Speed only matters if transaction coverage stays correct
A raw-shred benchmark should not only measure arrival time. It should also check whether both sides are observing the same transaction universe.
That is why this benchmark used a continuous raw-shred setup on the DoubleZero side and compared matched transaction delivery rather than isolated packet arrival.
- Compare transaction signatures across both sides.
- Track missing transactions and unmatched transactions.
- Track duplicate transaction updates.
- Log raw-shred packet loss or reconstruction failures where available.
- Repeat the benchmark with production environment.
// Who this matters for
Where this benchmark matters most
This run compared Shreder Binary Frankfurt with a DoubleZero Edge workflow on the same matched transactions. Both sides ultimately need usable transaction data—the difference is whether you process DoubleZero shreds yourself or consume Binary's extracted bytes directly.
Trading and market making
Fast transaction visibility can improve reaction time for routing, quoting, hedging, and risk checks without adding custom shred-processing infrastructure.
Searchers and execution
First-detection share matters when the system needs to observe relevant transactions before competitors and turn them into decisions quickly.
Low-latency indexing
Binary can feed indexing and monitoring systems with compact transaction bytes without the overhead of maintaining a full raw-shred parser.
Alerting and automation
Apps that trigger alerts, automation, or strategy logic from transaction visibility can benefit from getting usable transaction data directly.
Shreder Binary vs DoubleZero Edge FAQ
What does this benchmark measure?
It measures which side delivered the same matched Solana transaction first as usable transaction data. The page reports first-detection share and p50, p95, and p99 latency deltas for Shreder Binary Frankfurt and a DoubleZero raw-shred workflow in a 100,000-transaction Frankfurt run.
Why compare Shreder Binary with DoubleZero Edge if DoubleZero delivers raw shreds?
Because many low-latency teams ultimately need usable transaction data, not just raw packets. Raw shreds still need packet handling, deduplication, reconstruction, decoding, and transaction extraction. Shreder Binary performs that processing inside Shreder's optimized pipeline and delivers compact serialized transaction bytes directly.
Why were Jito shreds added to the DoubleZero side?
Jito shreds were added to DoubleZero Edge shreds to create a continuous raw-shred stream across the full transaction set. This helps avoid a benchmark where missing coverage decides the result. The goal was to compare time-to-usable-transactions across a broad transaction spectrum.
Does this mean DoubleZero missed transactions?
No. This page should not be read as a missing-data claim against DoubleZero. The coverage setup explains that additional Jito shreds were used on the raw-shred side so the benchmark could focus on delivery timing and processing outcome rather than feed coverage.
Does this benchmark measure raw packet arrival?
No. The benchmark measures when usable transaction data became available for matched transactions. That is different from measuring the arrival time of individual raw shred packets.
When should I choose Raw Shreds instead of Binary?
Choose Raw Shreds when your team specifically needs packet-level control and has the engineering depth to operate a custom shred-processing pipeline. Choose Binary when you want the speed benefit of Shreder's raw-shred infrastructure but prefer to consume ready-to-use transaction data.
Why does the table show 0.00 ms p50 for Shreder Binary?
The Shreder row shows the published latency-delta output for this benchmark table. Do not interpret it as literal zero network latency. Every real stream has transport, processing, serialization, and application latency.
Can Shreder benchmark against my current raw-shred provider?
Yes. Please contact us if you need help running a benchmark.
// Test your own raw-shred stack
Benchmark Binary against your current Solana raw-shred workflow
The published Frankfurt run shows Shreder Binary ahead for most matched transactions. The next step is to test your own sources, region, filters, and processing pipeline.