Before the Block: What Solana Shreds Are and Why You Want Them First

TL;DR: Every transaction on Solana gets chopped broken down ~1,228-byte fragments called shreds before it reaches a single validator. Shreds, not blocks, are the actual unit of data propagation. They travel through Turbine, a fanout tree that prioritizes high-stake validators, creating a measurable information hierarchy. By the time your RPC endpoint returns a response, shred-level observers have already seen the data, parsed it, and acted on it. The gap between seeing a shred and seeing a confirmed block is where serious edge lives. OrbitFlare Shredstream delivers raw Turbine shreds over UDP directly to your servers, putting you at the top of that hierarchy.

You send a transaction, and a few hundred milliseconds later your RPC confirms it showed up in a block. On your end it looks clean and simple, just a nice JSON response telling you the transaction landed.

What actually happened in between is significantly less clean. Your transaction was serialized into entries, broken down into roughly 1,228-byte fragments, wrapped with erasure coding metadata, signed by the leader, scattered across a tree of validators in a specific stake-weighted order, reassembled on the other end, verified, and only then packed into the block your RPC told you about. This article aims to explain that 'less clean' part in a cleaner way.

The broken down fragments are called shreds, and they are the lowest-level unit of data propagation on Solana. Almost nobody building on the network thinks about them, which is perfectly fine if you're building a to-do list dApp. But it's totally not fine if your revenue depends on seeing state changes before other people do.

The Smallest Unit on Solana

When a leader validator produces a block, it doesn't wait until the block is finished and then broadcast the whole thing. It starts streaming data out immediately, as transactions are processed, in small fragments sized to fit inside a single UDP packet. Each of these fragments is called a shred, and at 1,228 bytes it sits just under the standard network MTU so it can travel across the internet without being split apart by routers along the way.

A block might produce hundreds or thousands of shreds, and each one is stamped with a slot number, an index, and a 64-byte Ed25519 signature from the leader. That's how validators on the receiving end know which block a shred belongs to, where it fits in the sequence, and that it actually came from the leader who's supposed to be producing that slot.

Now, there's an obvious problem with this design. Solana sends shreds over UDP, which is a "fire and forget" protocol. Packets get dropped, they arrive out of order, and some never show up at all. If you needed every single shred to reconstruct a block, the system would fall apart on any real network.

This is where the two types of shreds come in. Data shreds carry the actual transaction payloads, sliced up from serialized entry batches, and these are the ones with the content you care about: token transfers, swaps, program invocations. Coding shreds don't carry transaction data at all. Instead, they carry parity information generated using Reed-Solomon erasure coding, which lets validators reconstruct missing data shreds without needing to request retransmissions.

The leader groups data and coding shreds into FEC (Forward Error Correction) sets, typically 32 of each. The math works out so that a validator can lose up to half the shreds in a set and still reconstruct the complete original data. That means the network can tolerate fifty percent packet loss on any given batch and the block still comes through clean.

Turbine: How Shreds Actually Travel

Solana doesn't broadcast shreds to every validator simultaneously. That would be a bandwidth catastrophe. Instead, it uses Turbine, a multi-layer fanout propagation tree designed to scale to tens of thousands of nodes.

The leader sends shreds to a root node, which fans them out to the first layer of up to 200 validators. Each of those validators forwards to another set of nodes in Layer 2, which can theoretically hold up to 40,000 validators (200 x 200). Within two or three hops, the entire network has the data.

Here's the part that matters: the tree isn't random. Validators are sorted by stake weight. High-stake validators sit closer to the root and receive shreds first. Low-stake validators sit further down and receive them later. Unstaked nodes are last in line, if they receive shreds through Turbine at all.

This creates a real, measurable latency hierarchy. A validator with significant stake might see a shred 50-200ms before a node at the edge of the tree. That delta is invisible to someone checking their wallet balance. But for anyone in the business of acting fast on on-chain data, latency is the entire game.

The Stack Between a Shred and Your API Call

Most Solana developers interact with the network through RPC or gRPC. Both sit several layers above the raw data.

When a validator receives shreds, it first reassembles them into entries using shred indices and, if needed, reconstructs missing pieces from the coding shreds. Then it deserializes entries into transactions, groups transactions into a block, and marks the block as confirmed (or finalized, one or two slots later). Only then does the data surface through an RPC call or a Geyser gRPC stream.

Every one of those steps adds time. Not a lot individually, but they compound. Shred reassembly, entry deserialization, block construction, database writes, API serialization. By the time getBlock or a Yellowstone subscription hands you data, it's already history in shred terms.

The hierarchy looks roughly like this:

If you're querying RPC, you're reading the morning paper. If you're consuming gRPC, you're watching live television. If you're receiving raw shreds, you're staring at the anchor directly.

For most applications, this hierarchy doesn't matter at all. A DeFi dashboard refreshing every few seconds has zero use for shred-level data. But for HFT desks, MEV searchers, liquidation engines, and market makers, the gap between shred-time and block-time is the gap between capturing an opportunity and watching someone else take it.

OrbitFlare Shredstream

This is the problem Shredstream solves.

OrbitFlare maintains partnerships with high-stake validators positioned near the root of Solana's Turbine tree. When those validators receive shreds from the leader, Shredstream forwards them directly to your server over UDP. Raw packets, no middleware, no reassembly and no aggregation layer sitting between you and the data. Your server gets the same Turbine fragments that top-of-tree validators see, delivered to an IP and port you configure, with under 1ms of forwarding overhead.

That's it. There's no SDK to install. No WebSocket connection to keep alive. No authentication handshake on every request. You give Shredstream a public IP and a UDP port through the dashboard, and shreds start arriving within seconds. Your job is to listen, parse, and act on them.

Nine Regions, Flat Pricing

Shredstream runs across nine global regions: Frankfurt, Amsterdam, London, New York, Singapore, Dublin, Siauliai, Salt Lake City, and Tokyo. You pick the one closest to your infrastructure and the shreds take the shortest possible network path to get there.

Premium regions (Frankfurt, Amsterdam, New York, London) sit in the highest validator density locations, right where the Turbine tree is thickest. Standard regions provide geographic coverage for multi-region deployments or redundancy setups.

Pricing is flat and public. $1,000/month for a premium region, $500/month for standard. No credit systems, no usage metering, no invoices that mysteriously triple when volume spikes. Quarterly, semi-annual, and annual commitments get up to 15% off. Pay with a card or with SOL. If you hold an OrbitFlare NFT Pass, you get one free slot.

Compared to alternatives in this space: more regions, lower entry price, a fully self-service dashboard, and a free 60-minute trial you can start without scheduling a call with anyone.

[Benchmark from a customer (comparing OrbitFlare to Helius Shreds)]

Who Actually Needs This

Not everyone, and that's an honest answer. If you're building a wallet, a block explorer, or an NFT marketplace, you don't need shred-level data. RPC and gRPC serve those use cases perfectly well.

But if your system falls into any of these categories, the latency advantage compounds directly into revenue:

• HFT desks treat the data pipeline as the product. Shaving a few milliseconds off ingestion changes which opportunities are capturable and which have already been taken. Raw shreds skip the entire RPC assembly stack.

• MEV searchers construct bundles based on pending state transitions. Observing those transitions at the Turbine layer, before they're packaged into blocks, creates an information edge that no processed feed can replicate.

• Liquidation engines monitor collateral ratios across lending protocols. A position that's underwater at shred-time still looks healthy on most gRPC feeds. The engine that sees the shred first sends the liquidation transaction first.

• Market makers adjust quotes based on order flow. Earlier data means tighter spreads, which means more volume, which means more revenue. The feedback loop starts with how early you see the flow.

• Memecoin snipers hunt for new token deployments and liquidity events. By the time these surface through conventional WebSocket or gRPC streams, the shred-level observers have already acted.

What Arrives at Your Server

From a technical standpoint, each packet landing on your UDP port is a raw Solana shred. It starts with the 64-byte Ed25519 signature, followed by the common header: a variant byte encoding the shred type and authentication scheme, the slot as a little-endian u64, the shred index as a u32, the protocol version, and the FEC set index. After the common header comes the type-specific header and the payload itself.

You parse these the same way validators do. The solana_ledger::shred crate handles it, or you can write your own parser if you want to avoid the dependency. A minimal listener that binds a UDP socket, reads raw shreds, and prints header fields is about 25 lines of Rust.

Standing in the Right Place

Shreds are the foundation layer of Solana's data architecture. Everything else, entries, blocks, confirmed transactions, RPC responses, derives from them. Most developers never need to think at this level, and the abstractions exist for good reason.

But if you're building systems where milliseconds carry direct economic weight, every abstraction layer between you and the raw data is a cost. Not a bug, not a limitation, just a cost. And costs add up when two competing systems spot the same opportunity at different times.

OrbitFlare Shredstream removes those layers. Raw Turbine data, forwarded over UDP, to your infrastructure, in the region closest to you. No middleware. No block finalization delay. No sitting at the bottom of the Turbine tree hoping gossip gets around to you.

The data is already moving. The question is where in the pipeline you choose to stand.

---

OrbitFlare builds Solana infrastructure for teams that need speed: RPC nodes, Jetstream gRPC streaming, trading APIs, and Shredstream. Start a free 60-minute trial from your dashboard, or get in touch if you want to talk architecture.