First-detection share
The percentage of matched transactions where a provider delivered the first valid update. In this run, Shreder Fastlane delivered first for 100.0% of the matched sample.
// Geyser gRPC benchmark
Shreder Fastlane vs Triton Geyser: Solana Yellowstone gRPC Latency Benchmark
A Frankfurt benchmark comparing Shreder Fastlane with Triton Geyser for first delivery of matched Solana transactions over a Yellowstone-compatible Geyser gRPC stream.
In this 10,000-transaction Frankfurt run, Shreder Fastlane delivered the first valid update for 100.0% of matched transactions, while Triton Geyser delivered 0.0% first. Triton's published latency deltas were p50 160.50 ms, p95 270.05 ms, and p99 338.96 ms in this benchmark.
Shreder Fastlane Frankfurt100.0% firstp50 / p95 / p99: 0.00 / 0.00 / 0.00 ms
Triton Geyser Frankfurt0.0% firstp50 / p95 / p99: 160.50 / 270.05 / 338.96 ms
Sample10,000 matched transactions
LocationFrankfurt · Teraswitch FRA2
// Published run
Shreder Fastlane vs Triton Geyser: published benchmark details
| Benchmark | Shreder Fastlane vs Triton Geyser |
|---|---|
| Product class | Yellowstone-compatible Solana Geyser gRPC |
| Shreder endpoint | Shreder Fastlane Frankfurt |
| Comparison endpoint | Triton Geyser Frankfurt |
| Test location | Frankfurt, Teraswitch FRA2 |
| Sample size | 10,000 transactions |
| RTT min / avg / max / mdev | 0.097 / 0.112 / 0.122 / 0.008 ms |
| Benchmark tool | GeyserBench |
| Subscription filter | High-activity transaction filter |
| Commitment level | processed for low-latency delivery comparison |
Derived stat: Shreder Fastlane delivered the first update for every matched transaction in this published run.
// First detection and latency
First-detection share and latency percentiles
| Provider | First-detection share | p50 latency delta | p95 latency delta | p99 latency delta |
|---|---|---|---|---|
| Shreder Fastlane Frankfurt | 100.0% | 0.00 ms | 0.00 ms | 0.00 ms |
| Triton Geyser Frankfurt | 0.0% | 160.50 ms | 270.05 ms | 338.96 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's 0.00 ms row 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.
// Interpretation
What 100.0% vs 0.0% first-detection share means
This benchmark compares two Solana Geyser-class streams from the same Frankfurt test environment. For each matched transaction observed by both endpoints, the benchmark records which provider delivered the first valid update to the benchmark client.
In this published run, Shreder Fastlane delivered the first update for every matched transaction in the 10,000-transaction sample. Triton Geyser still delivered data, but it did not deliver any matched transaction first in this benchmark.
That distinction matters. A 0.0% first-detection share does not mean the comparison endpoint missed every transaction. It means that, within the matched set used for this benchmark, Shreder Fastlane arrived first every time.
p50 latency delta
The median observed delivery-time delta. Triton's published p50 delta was 160.50 ms in this Frankfurt run.
p95 latency delta
The 95th percentile delivery-time delta. Triton's published p95 delta was 270.05 ms, showing the slower tail beyond the median.
p99 latency delta
The 99th percentile delivery-time delta. Triton's published p99 delta was 338.96 ms in this sample.
Sample size
The number of matched transactions included in the comparison. This published run used 10,000 matched transactions.
RTT
Round-trip time from the benchmark environment to the measured network path. This run reported RTT min / avg / max / mdev of 0.097 / 0.112 / 0.122 / 0.008 ms.
Takeaway: in this Frankfurt benchmark, Shreder Fastlane delivered the first valid update for every matched transaction while preserving a Yellowstone-compatible Geyser gRPC interface.
// Comparison context
Triton Geyser, Yellowstone gRPC, and what Fastlane changes
Triton One built much of the Yellowstone stack teams know today, including Dragon's Mouth: a Geyser-fed gRPC stream for accounts, transactions, slots, blocks, and related Solana updates.
This page compares two streams in Frankfurt. The question is not whether an update arrives, but who delivers the same matched transaction first—often the difference between reacting in time and reacting too late.
Fastlane speaks the same protocol your Yellowstone client already uses: subscriptions and stream handling stay as they are. You change endpoint and token; the consumer does not need a redesign.
What changes is delivery behind the interface. Shreder runs a custom accelerated path aimed at up to 2× lower time-to-data, with the same Yellowstone compatibility and Shreder's guarantee on data consistency and accuracy.
Drop-in for Yellowstone clients
Keep your existing Geyser gRPC consumer and filters; point it at Fastlane to test a faster path without a migration project.
First delivery, not averages
The benchmark tracks who wins the race on matched transactions—the metric trading, search, and live backends usually care about most.
Fast without cutting corners
Speed is the goal, but the stream still has to be correct. Shreder guarantees consistency and accuracy on its fastest Geyser-compatible delivery.
// Correctness
Speed only matters if the matched data stays correct
A 100.0% first-detection result is only useful if the benchmark is comparing the same matched transactions and the delivered updates are valid. When evaluating any Geyser gRPC provider, check both arrival time and data correctness.
Fastlane is built for low latency while preserving data consistency and accuracy. For your own benchmark, validate signatures, slots, account keys, update counts, duplicates, missing updates, commitment behavior, and reconnect behavior.
- Compare transaction signatures across endpoints.
- Confirm that matched transactions are being compared like-for-like.
- Compare slots and commitment levels.
- Track duplicate updates and missing updates.
- Log reconnects and stream errors.
- Confirm account update counts for the same filter.
// Who this matters for
When this benchmark matters
This benchmark is most useful for teams already using, or actively evaluating, Yellowstone-compatible Solana streams where first visibility affects downstream decisions.
Trading and market making
Earlier transaction and account updates can improve reaction time for quoting, hedging, routing, and risk checks.
Searchers and execution systems
First-detection share matters when the system needs to observe relevant on-chain activity before competitors.
Teams using Geyser gRPC today
If your stack already consumes Yellowstone-compatible streams, Fastlane can be evaluated as a faster endpoint without changing your core client model.
Real-time DeFi infrastructure
Pools, vaults, positions, and risk systems benefit when account and transaction updates arrive earlier and remain accurate.
Shreder Fastlane vs Triton Geyser FAQ
What does this benchmark measure?
It measures which provider delivered the same matched Solana transaction first to the benchmark client. The page reports first-detection share and p50, p95, and p99 latency deltas for Shreder Fastlane Frankfurt and Triton Geyser Frankfurt in a 10,000-transaction run.
What is Triton Geyser?
Triton Geyser refers to Triton's Geyser gRPC-style Solana streaming endpoint used in this benchmark. Triton One is also associated with Yellowstone and Dragon's Mouth, a Geyser-fed gRPC interface for streaming Solana account, transaction, slot, block, and related updates.
Does 0.0% first-detection share mean Triton missed transactions?
No. A 0.0% first-detection share means Triton did not deliver any matched transaction first in this published sample. It does not mean Triton failed to deliver every transaction. The benchmark compares matched transactions observed by both endpoints and records which endpoint arrived first.
Why does the table show 0.00 ms for Shreder Fastlane?
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.
Is Fastlane compatible with Yellowstone gRPC?
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.
How can Fastlane be faster if it is still Yellowstone-compatible?
Compatibility describes the interface. Speed depends on the delivery implementation. Fastlane keeps the Yellowstone-compatible interface but uses Shreder's custom accelerated implementation to reduce time-to-data while preserving data consistency and accuracy.
Should I use Fastlane or Regular Geyser?
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.
Should I use Fastlane or Shreder Binary?
Use Fastlane when you need Yellowstone-compatible Geyser data such as accounts, slots, blocks, transaction statuses, and standard Geyser semantics. Use Binary when your workload is focused on compact serialized transaction bytes extracted from shreds.
// Test your own endpoint
Benchmark Fastlane against your current Geyser setup
The published Frankfurt run shows Fastlane ahead of Triton Geyser for every matched transaction in the sample. The next step is to test your own endpoint, region, filters, and production workload.