Solana Shreds and Turbine: How Shred Streams Work

Last updated: October 25, 2026

Endpoint and plans: Solana RPC endpoint.

At a glance

What you see

A shred receiver can expose a transaction while a block-oriented API still has no complete block to return. A decoded message contains a signature and instructions, yet no execution logs or balance changes. These observations describe different stages of the same ledger pipeline. In the Agave entry representation, an entry holds a hash, a hash-count field and a collection of versioned transactions; a tick entry can have no transactions. Entry boundaries and network packet boundaries serve different purposes. A shred is therefore neither a transaction envelope nor a small confirmed block. Serialized entries can span data shreds, and a receiver needs a complete relevant data range before it can decode the transactions inside. Agave v3.0.0 entry.rs and shred.rs, read 2026-10-25, are the implementation references for these distinctions. The useful question is which stage your application observes, rather than whether the transport happens to be UDP, WebSocket or gRPC.

Why this happens

Entries become shreds because validators need to distribute ledger data in network-sized pieces. Agave's shred module describes MTU-sized frames: data shreds carry entry bytes, while coding shreds carry erasure-recovery information. Packet size includes headers and verification material, so it is not the amount of transaction data available to an application. FEC means forward error correction. A FEC set groups related data and coding fragments; Reed-Solomon recovery can restore missing data when enough valid fragments of that set remain. Agave v3.0.0 shred.rs defines a target of 32 data shreds and 32 coding shreds per FEC block, while explicitly noting that the actual data count depends on the serialized entries. Treat 32:32 as the referenced implementation's target, not a universal rule for every batch or future release. Recovery works within the matching set; packets from unrelated slots cannot fill its holes. Turbine distributes these fragments through a tree so the leader does not need a separate direct transmission to every validator. Fanout bounds each node's downstream recipients, and additional layers extend the tree. Anza's Turbine documentation, read 2026-10-25, describes a deterministic shuffle weighted by stake and regenerated for each shred. Higher stake biases a node toward earlier positions; it does not promise an arrival time for every packet. Network paths and losses still matter. If a receiver cannot reconstruct a group, validator repair is a separate recovery path. This is a distribution mechanism, not an application replay service. Once sufficient data is assembled, a receiver can deserialize entries and inspect their transactions before replaying them in its own runtime. That is the sense in which a feed can be pre-execution. It does not mean the leader has never executed the transaction, and it does not turn shreds into a public queue of every submitted transaction.

Where each stream sits in the slot

What to do

1. Follow the reconstruction boundary: group raw packets by slot and FEC identity, validate them, recover missing data where possible, and assemble the ordered data range. Only then deserialize entries and extract transactions. A coding shred is recovery input, not an additional transaction. Do not interpret every received packet as an independent trading signal. A FEC batch boundary and a complete serialized entry range need not be the same boundary. If data is missing, record the gap instead of treating an undecodable range as an empty range. A raw feed is appropriate when you need to own this pipeline or supply packets to a node.
2. Separate transaction contents from execution metadata. Solana's RPC JSON structures reference, read 2026-10-25, separates the transaction from its meta object: errors, inner instructions, log messages, balances and compute consumption describe execution. Deserializing an instruction tells you what it requests, not what the runtime actually did. A deshredded feed cannot derive those results from ledger bytes alone. Build a pending observation first, then attach the observed outcome from a commitment-aware channel. Keep failed execution distinct from a transaction that was never observed at your required commitment; absence of a notification is not evidence of success.
3. Choose the observation stage before choosing the transport. A raw UDP receiver gives you fragments and responsibility for reconstruction; a deshredded feed gives you transactions after someone else has assembled entries. A conventional Geyser transaction notification describes an executed transaction with status metadata, as documented in Anza's Geyser plugin reference, read 2026-10-25. A gRPC transaction subscription built on those notifications is useful when you need that result. The protocol name on the socket does not itself prove the data is pre-execution. Ask what event generates the message and which commitment the subscription represents.
4. Use commitment to decide when an observation can change durable application state. Solana's RPC overview distinguishes processed, confirmed and finalized; processed is a node's view and can roll back. For Tower BFT, Anza's commitment reference distinguishes confirmation votes from finality. Its Alpenglow section describes confirmed and finalized as equivalent under that consensus. The table above names the interfaces an application checks, rather than promising separate waiting periods on every cluster. Match the signature and slot across your early feed and outcome channel, and account for discarded forks. A signature appearing early does not make a later successful result inevitable.
5. Measure arrival order at your own consumer if it affects a decision. Pair the same signatures across the feeds, record receive timestamps using the same local clock, and retain missing observations as well as matches. Keep region, subscription filters and decoding work consistent enough to interpret the result. Server timestamps and client receive timestamps describe different events. Reconstructing packets is extra work on a given path, but that fact alone cannot rank two providers using different paths. This article has no timing dataset and gives no measured lead. Use protocol stage as a semantic distinction, then validate delivery in your deployment.
6. Keep protocol changes separate from activation claims. Anza's Alpenglow introduction, published 2025-05-19 and read 2026-10-25, describes Votor for voting and finalization and Rotor for data dissemination. Rotor retains erasure-coded distribution while changing Turbine's relay arrangement. That is a design reference, not evidence that a particular cluster, validator or commercial feed has activated it. Check the network and client release you consume before applying implementation details. Even when dissemination or consensus changes, reconstructing transaction contents and observing execution results remain different jobs. A transport upgrade does not make a decoded instruction an execution receipt.

When this is not our problem

When Triport is the wrong choice: you need raw shreds for a validator, application replay after a disconnect, or logs and balances from the early feed itself. Triport Shred stream supplies deshredded transactions over WebSocket, not raw packets, and has no replay buffer. It is a short path to inspecting reconstructed transactions; confirm their outcome separately. See the related deshredded stream over WebSocket product page for delivery details and the raw shred providers comparison for packet delivery options. Neither a streaming provider nor a deshredder can promise that an observed transaction becomes finalized.