What is Turbine
Turbine is Solana's block propagation protocol, a distributed protocol that is responsible for delivering new blocks to the whole validator network. Turbine doesn't send full blocks to every validator. Instead, Turbine divides blocks into chunks, and these chunks are called shreds and distributed via a tree structure with layers based on stake weights. With this, a single block producer can transmit data from a single block to 1,000 validators across the world in just a few hundred milliseconds without needing a data center's worth of bandwidth.
Turbine is sort of like a phone tree. A person starts a phone tree by calling 200 people. Then each of those people calls another 200 people. Within a few rounds, everyone in town knows the news, even though nobody ever called more than 200 people. Similarly, with Turbine, the calls are packets via UDP and the town is the validator set spread across the world.
How Turbine Works Technically
Because Solana produces new blocks in 400ms intervals, the network cannot wait for the full block to be ready before distributing it. The leader begins streaming data, splitting it into small chunks. Each chunk, or shred, is small enough to fit into a single network frame of around 1,200 bytes.
There are two types of shreds: data shreds, which carry data for transactions, and coding shreds, which contain redundant data. The redundant data is created using Reed-Solomon erasure coding, a mathematical tool that allows you to reconstruct any part of your data even if you miss receiving part of your data. For example, the leader could send one coding shred for every two data shreds to enable recovering data from shreds that got dropped. The reason this is relevant to Turbine's design is that the protocol uses UDP, a network layer protocol that prioritizes speed and does not guarantee packet delivery.
The shreds then flow through a tree structure in which validators are organized based on their stake weight. First, validators are weighted by stake and randomly shuffled using a seed based on the slot number and the shred index (the position of a shred in the block). The validators are then grouped into layers based on their position in the list, with a fanout of 200 nodes per node. Validators at the top of the list are those with the largest stakes, meaning the validators that have the greatest weight in the consensus process receive the blocks most quickly. Each shred is then passed through a newly generated tree so that no single path can be targeted by malicious actors.
How Turbine Compares to Ethereum and Bitcoin
Both Bitcoin and Ethereum propagate blocks in a gossip style, where each node sends the block (or parts of the block) to its connected peers and peers forward to their own peers. While effective in practice and simple to implement, gossip is bandwidth intensive, and both Ethereum and Bitcoin have plenty of time in which to transmit their blocks (12 seconds and 10 minutes respectively). Solana, however, has only 400 milliseconds in which to do so.
By using a split-and-relay tree model, Turbine is able to spend significantly less bandwidth per node than a gossip model does. This efficiency is a key driver in Solana's ability to process multiple thousands of transactions per second (TPS), and its average transaction fee of $0.00025, which makes up more than 150x the TPS of Ethereum's mainnet for one third the base fee.
In practice, you can see that Turbine is effective. For example, during a popular NFT launch on Magic Eden, you can often see 1,000 or more mint transactions go through in a block, and each transaction completes in less than 2 seconds, simply because Turbine streams transactions through the network so fast. Furthermore, companies that support high-frequency trading, like Jito and Helius, offer shredding services that stream transactions before the block has even finished assembling to give traders a millisecond head start.
There are, however, downsides to this model, and those include the extra latency of multiple hops to get to each validator, meaning a slow or offline relay can negatively affect performance across multiple nodes downstream, as well as the heavy hardware that is required by most validators to support 1Gbps+ network speeds. This has been one of the points of contention with Ethereum vs Solana, the latter of which generally favors validators, and the former of which tends to focus on the ability for home users to become validators.
Why Turbine Matters
Ultimately, Turbine enables higher block throughput on Solana and allows for the network to process data faster and in less space, by solving the problem of distributing data across many nodes. In other words, in most blockchains, block propagation is the bottleneck, not computation, and Turbine lets Solana add more nodes without making its block delivery slower, making bandwidth costs increase with the log of the number of nodes rather than the number of nodes. For the average user, this is why you see a Jupiter swap confirm in a second for a fraction of a cent, and for the developer, this is why latency sensitive apps like on-chain order books work well on Solana but not as well on other networks.
Turbine is a legacy protocol, however, and its time has come. The proposed Alpenglow upgrade passed with over 98% of the validator stake last September 2025, has already passed community testing since last May 2026 and plans on fully implementing it at some point in 2027. When the new implementation, called Rotor, is fully deployed, Solana will have significantly faster delivery of data by removing the multi-hop tree architecture, as this will result in approximately a 20-30% faster propagation of new blocks.
Does Turbine still run on Solana today?
Turbine currently still runs on the Solana mainnet, and continues to do so until Alpenglow is released on Solana at some point in late 2026, but until then any blocks you see being confirmed on Solana went through the Turbine protocol.
