Solana ShredStream, explained properly

What is a shred?

When a Solana validator is elected leader it does not build a block, finish it, and then announce it. That would waste most of the slot. Instead it packs transactions into entries continuously, slices those entries into fragments of roughly 1,200 bytes called shreds, signs each one, and broadcasts them across the validator network as they are produced.

Shreds come in two kinds. Data shreds carry the actual entry bytes. Coding shreds are Reed–Solomon parity, grouped with their data shreds into an FEC set, so a receiver that misses some fragments can reconstruct them without asking anyone to retransmit. That design is what lets Solana push blocks over unreliable UDP at high speed.

The practical consequence is the interesting part: the contents of a block are on the wire, in fragments, long before the block is complete — and much longer before any RPC node will admit that a transaction exists.

What is a shredstream?

A shredstream is a service that receives those shreds at a well-connected, peered node and forwards them to a subscriber over UDP. The subscriber supplies an IP address and a port; the proxy fires packets at it. There is no request, no subscription handshake in the hot path, and no acknowledgement — just a one-way firehose.

This matters because every alternative introduces a processing step first. A Geyser plugin emits events after the validator has processed an entry. An RPC websocket emits after processing, serialisation, and JSON encoding. A polling client emits whenever it next asks. Each layer is measured in tens or hundreds of milliseconds. A shred forwarder adds one network hop.

Why you cannot simply subscribe to shreds yourself

Shreds are gossiped between validators, not published on a public endpoint. To receive them directly you need a node that is genuinely part of the cluster: stake so peers propagate to you, hardware that can keep up with the ingest, a datacenter presence close enough to the leader schedule for the latency to be worth having, and someone to keep all of it running at three in the morning.

That is a real infrastructure programme, not a weekend project. Buying access to somebody else's proxy is the same trade every trading firm makes when it leases an exchange cross-connect instead of building an exchange.

What receiving the stream looks like

There is no SDK. You bind a UDP socket, you read datagrams, and each datagram is one raw shred exactly as the leader broadcast it. Parse it with Agave's shred crate, Jito's open-source deshredder, or your own header reader if you only need slot and index.

let sock = UdpSocket::bind("0.0.0.0:20000")?;
let mut buf = [0u8; 1500];

loop {
    let (len, _src) = sock.recv_from(&mut buf)?;
    handle_shred(&buf[..len]);   // ~0.9 ms after the wire
}

Where we fit

We run shred proxies in New York and Frankfurt — the two metros carrying the densest concentration of Solana stake — and forward the full stream to a socket you control. Both regions push simultaneously, so you take whichever copy arrives first and discard the twin.

Pricing is a flat 0.3 SOL per day with no metering, because congested slots are exactly when you need the feed most and we do not want our incentives pointing the other way. A 24-hour term exists so you can measure it against your own infrastructure before committing.