What is Solana Turbine?
Turbine is Solana's block propagation protocol. A leader divides its block into shreds and sends each shred to a packet-specific root selected by a stake-weighted ordering. The root and later validators relay it through a tree, distributing transmission work across the network while coding shreds let receivers recover some packets lost in transit.
network desk · updated 2026-08-31
The short version
Turbine moves a block while the block is still being produced.
The slot leader emits data shreds as entries become available. It also produces coding shreds that carry erasure information. Instead of sending every shred separately to every validator, the leader sends each packet to a selected root. That root and later validators retransmit to peers below them. Each participant performs a bounded share of the distribution work.
The result is a broadcast system built from ordinary point-to-point packets. There is no network primitive that delivers one UDP datagram to the entire cluster. Turbine creates that effect through coordinated forwarding.
Three properties matter to an engineer consuming the output. The topology is computed, not negotiated for each packet. Stake influences where validators tend to appear in the ordering. Arrival time depends on the number and quality of relay hops between the leader and the receiver. Those properties explain both Turbine's scale and the market for feeds taken from favorable network positions.
The problem Turbine solves
A leader has a fixed amount of time and a finite network interface. Directly sending every packet to every validator makes the leader's outbound work proportional to cluster size. A larger validator set would then increase leader load at precisely the point where the leader is also executing transactions, recording proof of history, generating shreds, and protecting its slot from overload.
Assume a slot produces 8,000 packets after data and coding shreds are counted. Sending those packets to 2,000 peers would require 16 million packet transmissions from one machine. At roughly 1,200 bytes per packet, protocol overhead excluded, that is about 19.2 GB of outbound data for one slot. The arithmetic is incompatible with a subsecond production target.
Turbine changes the scaling shape. The leader sends each shred to one selected root. That validator feeds the first layer, later nodes feed deeper layers, and distribution expands across the cluster. Total traffic remains substantial, but transmission work is shared instead of concentrated on one leader.
A block is streamed, not released
Turbine is often drawn as if a finished block enters the top of a tree. The drawing is useful, but the timing is wrong.
The leader records transactions into proof-of-history entries during its slot. Completed entry data is serialized into shreds. Those shreds can enter Turbine before later entries exist. Early shreds are already crossing relay layers while the leader is still executing transactions that will appear near the end of the block.
This overlap removes a block-sized wait from the critical path. Validators can receive, recover, and insert early portions of the ledger before the slot closes. A raw consumer can begin decoding those portions on the same schedule.
Streaming also means there is no single block arrival time. Each shred has its own production time, route, loss history, and arrival time. A measurement that assigns one timestamp to a slot hides the behavior a trading system cares about. Packet-level timestamps show the actual propagation distribution.
A tree made from unicast packets
The Turbine tree is a logical topology. It is not a persistent set of tunnels and it is not IP multicast.
Validators derive an ordered view of eligible peers from cluster information and protocol inputs. The ordering is divided into positions that imply forwarding responsibilities. A node can determine which peers are in its local neighborhood and which positions below it should receive retransmissions. Other honest nodes performing the same calculation reach compatible results.
Packets still travel as individual datagrams between concrete socket addresses. A parent may send the same shred to several destinations. Each child then repeats the process for its assigned destinations. The tree describes responsibility, while UDP carries the bytes.
The topology can differ between shreds because the shuffle seed includes shred-specific context. That rotation spreads favorable and unfavorable positions across traffic and makes a static interception point less useful. It also means a receiver should describe its position statistically, across many shreds, rather than claim one permanent rank.
The leader precedes the root
The scheduled leader originates valid shreds for its slot and sends each one to the root selected for that packet. The leader is excluded from the shuffled validator list. Position zero in that list is the root, which retransmits to the first layer. The leader's signature still binds every shred to the expected producer.
The leader does not maintain a session with every descendant. It needs current peer information and enough outbound capacity to reach each selected root. From there, the root and later retransmit nodes carry the fanout burden.
The leader's network still matters. Slow serialization, an overloaded interface, a poor route to the selected root, or late shred creation moves the entire downstream distribution later. Tree efficiency cannot recover time lost before the packet reaches position zero.
For that reason, arrival analysis separates production delay from propagation delay. The former begins inside the leader. The latter begins when a packet is emitted. External consumers normally observe only the combined result unless they control a timestamp close to the leader.
Deterministic does not mean static
Validators need compatible forwarding decisions without running a coordination round for every shred. Turbine obtains that property from deterministic inputs.
The current peer set, stake information, leader identity, slot, and shred-specific values contribute to the derived ordering in the relevant client implementation. The exact seed construction is an implementation detail that can change. The important invariant is that nodes with the same inputs can reproduce the same placement.
The inputs change over time. Gossip updates contact information. Epoch boundaries change effective stake and leader assignments. Validators appear, disappear, restart, or advertise new addresses. Shred-specific seeding also rotates the ordering within a slot. A tree calculation is therefore a reproducible snapshot, not a permanent hierarchy.
Receivers outside consensus do not have to recreate the tree to parse shreds. They do need tree context when explaining latency or choosing an ingest location. A feed captured near an early relay observes a different packet distribution from a socket attached to an ordinary late recipient.
Stake changes expected placement
Turbine uses stake when shuffling eligible validators. Higher-staked validators receive more weight and therefore have a greater probability of appearing earlier in the ordering. Earlier positions tend to carry more retransmit responsibility and tend to see packets after fewer hops.
The statement is probabilistic. Stake does not purchase a fixed root or first-layer seat for every shred. A weighted shuffle samples without replacement, and shred-specific inputs rotate results. A lower-staked validator can appear early for a particular packet, while a higher-staked validator can appear later.
Over a large sample, however, the distribution matters. High stake shifts the receiver's expected position upward. That reduces expected hop count and creates more opportunities to observe packets before the broad cluster does.
Hardware spending cannot directly change that protocol weight. Faster interfaces and better peering reduce delay along an assigned path, but they do not rewrite the ordering. An operator without the required stake can obtain an earlier observation point only through a party that already has one or through a separate direct path from the leader.
Fanout controls depth and work
Fanout is the number of forwarding relationships assigned at a branch of the logical tree. A wider fanout reaches more validators per layer and reduces the number of layers needed for a fixed cluster size. It also makes each transmitting node send more copies.
A narrower fanout reduces per-parent transmission work but creates more layers. Every added layer introduces serialization, queueing, kernel processing, routing, and another opportunity for loss. The useful setting is a compromise between individual node load and end-to-end propagation time.
Solana clients define the operational fanout used by their Turbine implementation. Engineers should consult the client version they run instead of embedding a historical constant into capacity models. The mechanism matters more than one value: breadth grows rapidly, then stops once all eligible positions are covered.
Fanout also shapes failure domains. Losing one early parent can affect a larger descendant region than losing one leaf. Coding shreds and alternative packet arrivals reduce the impact, but they do not make every branch equivalent.
Data shreds and coding shreds travel together
Data shreds carry serialized ledger content. Coding shreds carry parity produced by erasure coding over a fec set. Both use Turbine because both must reach enough validators for the block to be reconstructed under packet loss.
A receiver does not need every original data shred if it obtains enough members of the corresponding recovery set. Missing data can be reconstructed from available data and coding shreds. This is a forward recovery mechanism. It avoids putting a request and response round trip on the normal production path.
Redundancy costs bandwidth. The observed packet stream is materially larger than the serialized transaction content because it includes coding material, headers, votes, and other block data. A raw feed capacity plan based only on application transaction bytes will fail.
Erasure coding also changes the meaning of first arrival. The first copy of a shred is valuable, but completion of a recoverable set can matter more than receipt of every original. Decoders should timestamp packet arrival and recovery readiness separately. They answer different operational questions.
UDP is a deliberate trade
Turbine's data plane favors timely delivery over per-packet guarantees. UDP does not establish a session, wait for acknowledgements, preserve order, or apply receiver backpressure. The sender can continue emitting at slot speed even when one destination is slow.
That choice moves complexity to receivers. Packets can arrive out of order, twice, or not at all. Socket buffers can overflow during bursts. A slower consumer cannot ask the network to pause. The recovery layer must tolerate ordinary loss, and repair handles deficits that remain after the initial broadcast.
TCP would offer ordering and retransmission, but those guarantees can create head-of-line blocking. One missing segment delays later bytes on the same stream. For block propagation, later useful shreds should not wait behind one lost packet.
A commercial raw feed preserves these semantics. shredstream.sh sends raw UDP with no ordering, retransmission, or backpressure. A customer is responsible for receive-buffer sizing, duplicate handling, recovery sets, and downstream queue discipline.
Position becomes latency
Every relay layer adds work. A packet reaches a parent, enters kernel and application processing, is classified, copied or referenced for retransmission, queued on outbound sockets, serialized onto a link, and routed to the next set of recipients. No individual step needs to be slow for the sum to matter.
Suppose one path adds 2 milliseconds of network travel and 0.8 milliseconds of processing at each relay. The root may see the packet after 2 milliseconds. An observer two relay cycles below it may see the packet after 7.6 milliseconds. Real paths are not uniform, so the distribution is wider than the arithmetic.
For a validator, several milliseconds can affect vote timing and repair load. For an HFT system, several milliseconds can determine whether a state transition is detected before competing order flow reaches the next leader.
Turbine position is therefore an economic resource. It is not the only latency variable, but it is upstream of any optimization inside the customer's decoder.
Failure is local until it is not
An unavailable leaf mainly harms itself. An unavailable node near the top can delay or deprive descendants assigned through it for a given shred. Shred-specific rotation prevents one machine from owning the same descendants forever, but a bad early path can still shape one packet's arrival pattern.
Coding shreds cover a bounded amount of loss. Duplicate paths, incidental copies, and later repair can add resilience. None changes the fact that first-wave propagation has a topology. When an early relay misses its deadline, some downstream nodes wait for recovery or repair while others on healthy branches continue.
Operators should analyze loss by fec set, source, slot, and arrival phase. A flat packet-loss percentage merges harmless duplicates, recoverable gaps, and branch-correlated outages into one number. Those events have different consequences.
The relevant service objective is often not zero packet loss. It is a high probability of reconstructing each useful entry before a strategy deadline. That measure incorporates redundancy and time instead of treating every datagram as equally valuable.
Gossip supplies the map
Turbine depends on cluster information learned through Solana gossip. Contact records provide network addresses and identity information. Stake and epoch state provide weights. Leader schedule information identifies the expected producer for a slot.
Gossip is not the block data plane. It does not carry the full stream of shreds. It maintains the distributed control-plane view from which data-plane decisions can be made. Conflating the two leads to bad architecture, such as expecting a gossip connection to provide earliest transaction visibility.
The map is eventually consistent. Two nodes can briefly disagree because they received CRDS updates at different times. Implementations must handle stale or missing peers without pausing the slot. That is another reason the topology should be treated as a derived operational view rather than a centrally issued routing table.
For an external feed consumer, gossip remains useful for context. It explains leader identity, cluster membership, address changes, and some route changes, while the UDP feed supplies the latency-sensitive bytes.
What a receiver must build
A raw receiver needs more than a large socket buffer. It must timestamp packets close to ingress, validate lengths and variants, deduplicate repeated shreds, group them by slot and recovery set, verify leader signatures at the chosen trust boundary, reconstruct missing data, and decode entries in ledger order.
The work is concurrent. One slot can still be completing while the next slot begins. Packets arrive out of order across fec sets. A leader transition changes the expected signing identity. Repair data or a second source can arrive after the first decoder deadline and still be useful for reconciliation.
Backpressure must terminate inside the customer's system because UDP senders will not wait. A bounded queue, explicit drop policy, and per-stage latency histograms are safer than an unbounded buffer that turns fresh data into stale data.
The receiver also needs a confirmed-state path. Shreds describe proposed ledger content at the earliest observable stage. RPC or another executed-state source later establishes whether a transaction succeeded and whether the fork survived.
The operational conclusion
Turbine trades centralized outbound load for distributed forwarding. The trade allows a leader to stream block fragments across a large validator set without maintaining a full-rate connection to every participant.
The same design creates unequal observation times. The leader sees a shred at creation. Early relays see it after one path. Later relays see it after more processing and network hops. Stake changes the expected placement, and network quality changes the cost of each assigned edge.
A feed provider is selling access to an observation point and a delivery path, not a different class of shred. shredstream.sh receives the raw stream and forwards it from Frankfurt to one verified destination over UDP. The downstream packet still has Turbine's uncertainty: it can be duplicated, reordered, lost, or associated with a block that does not survive.
The engineering question is therefore precise. Measure when recoverable transaction data reaches your strategy, relative to alternative sources, across leaders and slots. Brand names and median pings do not answer it.
In practice
Assume a 400 millisecond target slot produces 6,400 total data and coding shreds. The logical fanout in this example is 64, and each relay adds 0.7 milliseconds of processing before transmission.
An early receiver is 2.1 milliseconds of network time from the leader. It observes a selected shred after about 2.8 milliseconds. A later receiver needs two additional relays with network legs of 1.8 and 2.4 milliseconds. It observes the same shred after about 8.4 milliseconds.
Both receivers decode correctly. The later one has excellent hardware, but it starts 5.6 milliseconds behind because its copy crossed more of the tree. Faster parsing can reduce downstream work. It cannot recover time spent before the packet reached the socket.
What this does not cover
This page describes Turbine as a propagation mechanism, not as a promise that every packet follows one stable route. Exact shuffle seeds, peer filtering rules, fanout constants, transport details, and shred variants belong to the specific validator client and release being operated.
The latency examples isolate tree depth so the effect is visible. Production systems also face leader-side delay, physical distance, queueing, packet loss, kernel scheduling, erasure recovery, fork choice, and decoder cost. A favorable Turbine position cannot remove those delays, and raw shreds do not prove that a transaction will execute or finalize.
Related questions
- Is Turbine a separate network from Solana gossip?
- Yes, in function. Gossip distributes cluster metadata through CRDS, including identities and contact information. Turbine is the data-plane mechanism that carries block shreds through a relay tree. The systems interact because Turbine uses the cluster view, but receiving gossip records is not equivalent to receiving the block stream.
- Does every validator receive a shred from the leader?
- No. The leader sends each shred to one packet-specific root selected from the stake-weighted ordering. That root sends to the first layer, and later validators retransmit to assigned peers below them. This shared work prevents the leader's outbound packet count from growing directly with every validator in the cluster.
- Does higher stake guarantee an earlier Turbine position?
- No. Stake weights a deterministic shuffle, so higher stake improves the probability of an earlier position across many shreds. It does not reserve one fixed layer for every packet. Shred-specific inputs rotate placements, and the actual arrival time still depends on leader behavior, routes, relay load, and packet loss.
- Why does Turbine use coding shreds?
- Coding shreds let a receiver reconstruct missing data shreds when enough members of the same recovery set arrived. That forward redundancy fits a time-sensitive UDP broadcast better than waiting for every loss to trigger a request and response. Recovery has limits, so larger deficits still require repair or another source.
- Can a raw shred feed guarantee the first packet?
- No. A raw feed can provide access to a favorable observation point and a measured delivery path, but packet creation, tree placement, internet routing, relay load, and UDP loss still vary. Buyers should compare packet and recoverability timestamps across representative leaders instead of treating one advertised latency number as a universal guarantee.