The Fastest Solana Shred Streaming in 2026: Shredline vs eRPC Direct Shreds Benchmark

If you run a Solana MEV bot, a Pump.fun migration sniper, or any trading strategy that depends on sub-20 ms reaction time, your choice of Solana shred streaming provider is the single biggest latency lever in your stack. More than your co-location, more than your signing path, more than your RPC tier.

We benchmarked the two most credible raw-shred-layer products on the market: Shredline RAW, which delivers UDP shreds directly to the client's IP, and eRPC Direct Shreds, which delivers shred-level data over a gRPC channel. Same Frankfurt node, same time window, 16,523 dual-observed slots. Shredline arrived first on 98.84% of them, with a +8.5 ms p50 lead.

This post walks through the results, the methodology, and what the latency gap means for traders competing on Pump.fun migrations and other tight-latency Solana workloads. The full data and reproducible benchmark tool are open-source on GitHub.

Benchmark results

Over 16,523 slots where both endpoints delivered within 30 seconds, Shredline arrived first 16,332 times. eRPC arrived first on 191 slots, typically by less than 10 ms. When Shredline won, it won by 8 to 20 ms on average.

Dashes indicate the fastest endpoint (baseline). Other rows show how far behind they were when they lost, per percentile.

One number kept off the headline table for statistical rigor: 1,700 additional slots where Shredline delivered a UDP shred but eRPC never streamed an entry within 30 seconds. We excluded these from the win-rate calculation because comparing "arrival vs never-arrived" is methodologically weak. Counting them as Shredline wins would push the rate above 99%.

How the benchmark works

For each observed Solana slot S, the benchmark records two monotonic timestamps:

• t_udp(S): the moment the first raw UDP shred carrying slot S arrives at the node, captured via libpcap at the kernel layer.
• t_grpc(S): the moment the first Entry message with slot=S is delivered by ShredstreamClient::subscribe_entries() from eRPC's SDK.

A slot is dual-observed when both timestamps land within a 30-second window. Delta equals t_grpc - t_udp: positive means eRPC arrived later. Slots delivered by only one endpoint within the window are bucketed as udp_only or grpc_only and excluded from the win-rate percentage.

The measurement point is pre-FEC and pre-decode. We timestamp the UDP packet on arrival, before any shred reassembly or entry parsing. This matches exactly what a Shredline RAW tier subscriber receives at their application, minus the network hop from our node to theirs.

Why raw UDP beats gRPC at the shred layer

The architectural reason is pipeline length. Both endpoints receive the same shreds, from the same upstream sources, within microseconds of each other. The difference is what happens between reception and delivery to the client.

When eRPC ships a Direct Shred over gRPC, the shred is parsed, wrapped in a protobuf message, serialized to bytes, framed for HTTP/2, multiplexed onto a shared TCP connection, transmitted with congestion-controlled ack/retransmit semantics, then decoded on the client side. Each step is measured in microseconds on a tuned system, but they stack. And each step adds variance that explodes on the tail.

Shredline's RAW path is two steps: receive UDP, forward UDP. The bytes your application sees are the bytes the validators broadcast. No parse, no serialize, no TCP, no protobuf. If you need to extract slot, you read bytes 65-73 as a little-endian u64. If you need decoded entries, you reassemble on your side.

Shorter pipeline, lower latency, lower variance. Not a framework trick. An architectural truth.

We covered this in detail in our deeper write-up on why raw UDP beats gRPC at the shred layer.

What this means for Pump.fun migrations and MEV snipers

Pump.fun migration sniping is one of the tightest-latency opportunities on Solana. When a token graduates from the bonding curve to Raydium, a narrow window opens where the first wallet to submit a buy captures most of the upside. Competition is measured in milliseconds.

Bots running on a Yellowstone Geyser gRPC stream (via Triton, Chainstack, or the shred-sourced variants Helius Laserstream and Shreder Fastlane) are consuming a processed-entry stream. By the time a message reaches the bot, shreds have been reassembled, FEC-recovered, and protobuf-wrapped. Several milliseconds of pipeline overhead are baked in before the bot can react.

Bots running on raw UDP shreds see the shred bytes as the network sees them. They can detect a migration the moment the first shred of the triggering transaction arrives, parse enough of the raw bytes to extract the signal, and fire their own transaction. No decoded-entry pipeline between them and the event.

In our benchmark, the p50 gap was +8.5 ms. In practice, on a high-competition migration, that is the difference between being the first wallet in the pool or one of the several that land in the same block. Same-block order matters as much as same-slot presence.

For tight backrunning, same principle. For MEV searching on SPL programs, same principle. Anywhere competition is measured in milliseconds, the layer you consume from is architecturally load-bearing.

Shredline, eRPC, and the broader Solana data ecosystem

To situate Shredline in the Solana data infrastructure landscape:

• Shred layer, UDP pass-through: Shredline RAW. Raw UDP packets forwarded to the client's IP. Zero decode, shortest pipeline.
• Shred layer, gRPC-wrapped: eRPC Direct Shreds and Helius Shred Delivery. Same raw shred bytes as Shredline RAW, but shipped inside a gRPC stream. The client still has to deshred and FEC-recover.
• Entry layer, shred-sourced: Helius Laserstream and Shreder Fastlane. Ingest raw shreds server-side, decode and FEC-recover internally, then deliver processed entries through a Yellowstone Geyser gRPC-compatible interface. Drop-in replacements for Yellowstone, but with a server-side decode step in the pipeline.
• Entry layer, Geyser-sourced: Chainstack's Geyser endpoint, Triton's streaming tier, and Yellowstone vanilla. Consume decoded entries from a validator's Geyser plugin. The traditional path, and several milliseconds slower than shred-sourced variants.
• Block / RPC layer: confirmed blocks via JSON-RPC or gRPC. The slowest layer for a trading bot but the easiest to integrate. Helius standard RPC, QuickNode, Alchemy, and every Solana RPC vendor operate here.

A trading bot on the block layer is architecturally hundreds of milliseconds behind a shred-layer bot. A bot on a Geyser-sourced entry stream is 5-20 ms behind. Shred-sourced entry products (Laserstream, Fastlane) narrow that gap but still require server-side decoding that raw UDP pass-through avoids. The gap compounds with every abstraction.

How to reproduce the benchmark

The full benchmark tool is open-source: github.com/shredlinexyz/shredline-benchmarking.

You need a Linux host with libpcap and CAP_NET_RAW, a Shredline RAW trial (request via Telegram), and an eRPC shred endpoint from your own subscription.

git clone https://github.com/shredlinexyz/shredline-benchmarking
cd shredline-benchmarking
cargo build --release
sudo setcap cap_net_raw+ep target/release/bench-layer0

ERPC_SHRED_URL=http://<your-erpc-shred-endpoint>/ \
BENCH_IFACE=<iface> BENCH_PORT=<port> \
  ./target/release/bench-layer0 data/bench_$(date +%Y%m%d).csv

python3 analysis/plot.py data/bench_YYYYMMDD.csv analysis/

The output includes a CSV of raw timestamps, a summary text report in the same format as this post, a histogram of per-slot deltas, and a CDF of Shredline's lead over eRPC. If your numbers disagree with ours, open an issue.

Frequently asked questions