First-detection share
The percentage of matched transactions where a provider delivered the first valid update. This is the headline metric for latency-sensitive systems because it shows who sees the same transaction first most often.
// Geyser gRPC benchmark
A head-to-head benchmark comparing Shreder Fastlane and Quicknode Geyser gRPC for Solana Yellowstone-compatible streaming in Frankfurt.
In this 50,000-transaction Frankfurt run, Shreder Fastlane delivered 100% of matched transactions first. Quicknode Geyser gRPC delivered 0% first. Published Quicknode latency deltas were p50 20.61 ms, p95 122.75 ms, and p99 255.74 ms.
// Published run
| Benchmark | Shreder Fastlane vs Quicknode Geyser gRPC |
|---|---|
| Product class | Yellowstone-compatible Solana Geyser gRPC |
| Shreder endpoint | Shreder Fastlane Frankfurt |
| Comparison endpoint | Quicknode Geyser gRPC |
| Test location | Frankfurt, Teraswitch FRA2 |
| Sample size | 50,000 valid matched transactions |
| First detections | Shreder Fastlane 50,000 · Quicknode 0 · Backfill 0 |
| RTT min / avg / max / mdev | 0.472 / 0.490 / 0.503 / 0.013 ms |
| Benchmark tool | GeyserBench |
| Commitment level | processed (typical for low-latency Geyser benchmarks) |
// First detection and latency
| Provider | First-detection share | p50 latency delta | p95 latency delta | p99 latency delta |
|---|---|---|---|---|
| Shreder Fastlane Frankfurt | 100.00% | 0.00 ms | 0.00 ms | 0.00 ms |
| Quicknode Geyser gRPC | 0.00% | 20.61 ms | 122.75 ms | 255.74 ms |
First-detection share shows which provider 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.
Shreder 0.00 ms does not mean literal zero network latency. It is the published latency-delta result in this benchmark table. End-to-end latency always includes network transport, stream processing, and downstream application logic.
// Latency distribution
This run published a full percentile curve for Quicknode relative to Fastlane. The median gap is already material, and the right tail widens sharply — important for trading, searchers, and alerting systems that care about worst-case freshness.
| Endpoint | p10 | p20 | p30 | p40 | p50 | p60 | p70 | p80 | p90 | p95 | p99 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Shreder Fastlane | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| Quicknode Geyser gRPC | 7.82 | 10.48 | 13.14 | 16.25 | 20.61 | 27.43 | 37.94 | 54.58 | 83.84 | 122.75 | 255.74 |
Reading the curve: even the faster Quicknode observations (p10 7.82 ms) arrived after Fastlane. By p90 the gap is 83.84 ms; by p99 it reaches 255.74 ms. Both endpoints completed the same 50,000 valid transactions with zero backfill events in this run.
// Interpretation
This benchmark is a race between two Solana Geyser-class data streams. For each matched transaction observed by both endpoints, the benchmark records which provider delivered the first valid update to the benchmark client.
In this run, Fastlane won every race. That does not mean Quicknode failed to deliver data — both sides processed 50,000 valid transactions. It means Quicknode’s updates arrived later on every matched event in the sample window.
The metrics in this report are defined as follows.
The percentage of matched transactions where a provider delivered the first valid update. This is the headline metric for latency-sensitive systems because it shows who sees the same transaction first most often.
The median observed delivery-time delta. For Quicknode in this run, the typical matched update arrived 20.61 ms after Fastlane.
The 95th percentile delivery-time delta. Here Quicknode reached 122.75 ms — useful for understanding common tail lag beyond the median.
The 99th percentile delivery-time delta. At 255.74 ms for Quicknode, rare slow updates can still matter for trading, searchers, and alerting.
50,000 matched transactions — larger than many published Geyser head-to-heads on this site, which reduces the chance that a short burst dominates the scoreboard.
Round-trip time from the benchmark environment. Sub-millisecond RTT with low mdev frames the result: the measured gaps are delivery delays, not ping jitter.
Takeaway: in this Frankfurt benchmark, Shreder Fastlane won first delivery for 100% of 50,000 matched transactions while preserving a Yellowstone-compatible Geyser gRPC interface.
// Provider comparison
Quicknode Geyser gRPC and Shreder Fastlane both serve teams that need Yellowstone-compatible Solana streams. The main difference in this report is observed delivery latency: Fastlane arrived first on every matched transaction, while Quicknode’s lag grew from single-digit milliseconds at p10 into hundreds of milliseconds at p99.
| Category | Quicknode Geyser gRPC | Shreder Fastlane |
|---|---|---|
| Interface | Yellowstone Geyser gRPC | Yellowstone Geyser gRPC |
| Migration | Endpoint change | Endpoint change |
| Benchmark result | 0.00% first-detection share in this run | 100.00% first-detection share in this run |
| Median lag vs Fastlane | 20.61 ms (p50) | Baseline in this table |
| Tail lag vs Fastlane | 122.75 ms p95 · 255.74 ms p99 | Baseline in this table |
| Best for | Teams already on Quicknode for broader infra | Teams optimizing for lower Geyser latency |
| Trial path | Provider-specific | Start Geyser trial from Shreder console |
// Comparison context
Quicknode is a common choice for Solana RPC and streaming infrastructure. Many production stacks already use Yellowstone-compatible Geyser gRPC clients pointed at a Quicknode endpoint for accounts, transactions, slots, and blocks.
Shreder Fastlane sits in the same Yellowstone-compatible Geyser gRPC category. This Frankfurt run is most relevant for teams that already consume Quicknode Geyser — or are evaluating Quicknode against a latency-focused alternative — and want measured first-detection and percentile gaps instead of marketing claims.
Fastlane changes the delivery implementation, not the client model. Existing Yellowstone-compatible clients keep the same subscription patterns and stream handling — you update the endpoint and token while Shreder’s accelerated path reduces time-to-data.
Compared with other published Fastlane Geyser runs on this site, Quicknode’s median (~20.61 ms) is in a similar band to Alchemy in Frankfurt, while the p95/p99 tail in this 50k-transaction sample is especially heavy. Always re-benchmark against your own filters and region before changing production routing.
Use the same Yellowstone-compatible stream model, clients, filters, and update handling.
Fastlane uses Shreder’s custom implementation to reduce delivery time while keeping the interface stable.
Shreder guarantees data consistency and accuracy while optimizing for the fastest possible Geyser-compatible delivery.
// Run your own test
To compare your current Quicknode Geyser endpoint with Shreder Fastlane, run both endpoints from the same machine, region, commitment level, and subscription filter. Track first-detection share, p50, p95, p99 latency deltas, missed updates, duplicate updates, reconnects, and stream errors — and inspect the full percentile curve if your workload is sensitive to tails.
Run both endpoints from the same benchmark machine, same region, and same measurement window. Publish RTT so readers can separate network path from stream lag.
Use the same commitment level, the same account or transaction filters, and the same timestamping method on both Quicknode and Fastlane.
Track first-detection share, p50, p95, p99 latency deltas, missed updates, duplicates, reconnects, stream errors, and correctness.
// Who this matters for
A few milliseconds — and especially a heavy p95/p99 tail — can matter more in some Solana workloads than others. Use this benchmark as a signal when first visibility affects downstream decisions.
Earlier transaction and account updates can improve reaction time for quoting, hedging, routing, and risk checks.
First-detection share matters when the system needs to observe relevant on-chain events before competitors.
Pools, vaults, and feeds can be streamed through Yellowstone-compatible filters when freshness matters.
If you already use Quicknode for RPC or Geyser, this run quantifies what a Fastlane endpoint swap may buy in first-detection consistency and lag.
It measures which provider delivered the same matched Solana transaction first to the benchmark client. The page reports first-detection share and latency-delta percentiles for Shreder Fastlane and Quicknode Geyser gRPC across 50,000 valid matched transactions.
In the published Frankfurt run, Shreder Fastlane delivered 100% of matched transactions first (50,000 of 50,000). Quicknode Geyser gRPC delivered 0% first. Published Quicknode latency deltas were p50 20.61 ms, p95 122.75 ms, and p99 255.74 ms.
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, decoding, and application latency. The table is reporting relative delivery-time deltas for the benchmark.
First-detection share is the percentage of matched transactions where a provider delivered the first valid update among the tested providers. For latency-sensitive systems, it is often more useful than a simple average because it shows who wins the data-delivery race most often.
Quicknode is a widely used Solana infrastructure provider, and many teams already consume Yellowstone-compatible Geyser gRPC from Quicknode. Shreder Fastlane is an accelerated Yellowstone-compatible Geyser mode, so this comparison helps teams decide whether switching endpoints can reduce time-to-data without rewriting client logic.
Yes. Fastlane is designed to be 100% compatible with Yellowstone gRPC. Existing Yellowstone-compatible clients can keep the same general subscription model, protobuf update handling, and stream logic while changing the endpoint and token to Shreder.
You can run a similar benchmark using GeyserBench: configure Shreder Fastlane and the Quicknode Geyser endpoint, use the same account or transaction filter, run both endpoints from the same machine, and compare first-detection share plus latency percentiles.
Use Regular Geyser when you want reliable Yellowstone-compatible delivery and cost efficiency. Use Fastlane when your workload is latency-sensitive and you want Shreder’s fastest Geyser-compatible stream.
Yes for teams that need Yellowstone-compatible Solana Geyser gRPC with lower observed delivery latency. The best validation is a side-by-side benchmark from the same machine, region, commitment level, and filters.
If your current integration uses a Yellowstone-compatible Geyser gRPC client, migration usually means changing the endpoint and token.
// Test your own workload
The published Frankfurt run shows Fastlane ahead of Quicknode Geyser gRPC on every matched transaction in a 50,000-tx sample. The next step is to test your own filters, region, and production workload.