Winning the Millisecond Game: Shreds, LaserStream, and the Edge of Solana

What would you do if you had a time machine that was perpetually 10 milliseconds into the future? What trades would you make? What accounts would you monitor? How much more money would you make? 

LaserStream is Helius’ next-generation gRPC streaming service, which consistently outperforms other data-streaming services across all regions around the world without the burden of needing to maintain dedicated nodes. 

Streaming data as fast as possible is crucial for the detection of on-chain events (e.g., swaps, liquidations, price updates) and submitting transactions that react to those events. The difference between a couple of milliseconds for RFQ desks, liquidation bots, and high-frequency trading is the difference between winning and missing an opportunity.

LaserStream’s best-in-class performance for latency-sensitive operations is largely because it builds upon low-latency shreds. That is, LaserStream receives propagated block data as soon as it becomes available, giving users earlier visibility into Solana state updates. With its globally distributed pipeline, automatic replay, automatic failover, and client SDKs, LaserStream is, undoubtedly, the easiest and fastest way to stream real-time data on Solana. These advantages make LaserStream’s integration crucial for exchanges, trading apps, MEV bots, and anyone serious about latency-sensitive operations.

This article explores shreds, the smallest units of blocks on Solana, why they matter, and how LaserStream uses them to power the fastest data streaming solution possible. The article is designed so that each section can be read in isolation. However, readers new to shreds and streaming data on Solana would benefit from reading each section sequentially.

What are shreds?

Shreds are the foundational unit that enables Solana’s high-performance data propagation, offering early access to on-chain state changes.

Solana is designed for maximum speed and throughput. To achieve this, it cannot transmit blocks as a single, large unit across the network. Instead, blocks are divided into smaller packets known as shreds—the atomic units of data propagation in Solana. 

These shreds represent portions of transaction data before they are assembled into a block. Each shred is approximately 1.2 KB in size, optimized to fit within the Maximum Transmission Unit (MTU) of standard network packets to ensure lightning-fast delivery without fragmentation. 

There are two types of shreds:

Data Shreds

Data shreds encapsulate the core transaction data from a block, divided into fixed-size pieces. They include serialized entry batches, which are groups of transactions prefixed by a count for efficient processing.

Coding Shreds

Coding shreds provide redundancy using Reed-Solomon erasure coding, a forward error correction technique that generates parity data. This allows for missing or corrupted shreds to be reconstructed. Coding shreds are organized into Forward Error Correction (FEC) sets alongside data shreds, typically in balanced ratios (e.g., 32 data to 32 coding shreds) to tolerate up to 50% of packet loss. Leaders can adjust this ratio based on network conditions to maintain high reliability.

How are shreds propagated on Solana?

The process starts with the leader (i.e., the validator currently responsible for producing blocks) batching and serializing transactions into entries. These entries are then divided, or shredded, into smaller segments referred to as shreds. All shreds are signed by the leader using either a legacy system (i.e., signing each shred individually) or a Merkle-based scheme (i.e., signing the Merkle root of the entire FEC set) as defined by Solana’s shred specification. This ensures authenticity and data integrity. 

Shreds are sent to other validators using Turbine, Solana’s multi-layer, fanout-based propagation system. Under Turbine, the leader transmits shreds to a root node, which distributes them to subsequent layers of validators in a tree-like structure. Each layer forwards to the next with a fanout of 200 nodes per layer, typically spanning 2 to 3 hops depending on the number of active validators. This tree structure minimizes bandwidth while achieving the network-wide distribution of transactions in milliseconds.

Stake-weighted shuffling prioritizes delivery to higher-staked validators. Turbine first sorts validators by the amount of stake they hold (i.e., their stake weight). Validators with higher stake are placed earlier in this list, and after a deterministic shuffle, they tend to end up in earlier layers of the tree closer to the leader. Thus, fewer hops means lower latency. So, validators with more stake receive shreds sooner.   

Note: Turbine will be replaced by Rotor in the future once Alpenglow is implemented. Even with these changes, a validator’s stake will still influence which peers validators will broadcast to.

How are shreds reassembled into blocks?

Once received by a validator, shreds are reassembled by first verifying their signatures for authenticity and using Reed-Solomon erasure coding to reconstruct any missing or corrupted data shreds from the available coding shreds in the FEC set. 

The reconstructed data shreds are then deshredded. That is, their payloads are concatenated in order using shred indices to reform serialized entry batches. 

These batches are then deserialized into individual transactions and entries, which can be assembled into a complete block.

Why do shreds matter? 

Shreds matter because they compress the reaction window in a network where timing is paramount. 

Shreds are crucial for unlocking Solana’s high-performance advantages, particularly in latency-sensitive applications such as high-frequency trading, request-for-quote (RFQ) desks, liquidation engines, and oracle updates. 

Shreds provide the earliest visibility into emerging on-chain events, unlike most other blockchains, where applications must wait until complete block production and confirmation, which can add delays of hundreds of milliseconds to several seconds. 

Raw shreds can be awkward to work with since the receiver must verify their authenticity, reconstruct any missing data shreds, deshred and deserialize them into transactions and entries, and, finally, parse them for actionable events like swaps or account changes.

However, this “early peek” into pending transactions and account updates offers an unparalleled advantage, directly translating into higher success ratios in competitive scenarios.

For example, a liquidation bot monitoring collateral ratios could detect and act on a vulnerable position using shreds well before their competitors using slower methods like WebSockets, thus winning the liquidation. 

Similarly, arbitrage traders identifying market inefficiencies and low-latency DEX aggregators quoting prices can benefit from this latency edge, as milliseconds determine profitability.

The Shred Latency Hierarchy

It is important to note that shred latency is not uniform across all sources.

High-Staked Validators

Validators with a significant amount of stake receive the highest priority in Turbine’s propagation tree. They often ingest shreds directly from the leader or in earlier fanout layers, benefiting from Stake-Weighted Quality of Service (SWQoS).

Staked Validators

Validators with a modest amount of stake experience moderate delays due to their lower priority in the propagation queue, since shreds need to make additional hops. Their involvement in consensus ensures reliable access, though latency can vary slightly based on network position and current stake distribution. Low-staked validators are less than ideal for ultra-competitive, time-sensitive operations compared to high-staked validators.

Unstaked Validators

Validators with no stake lack the quality of service advantages of staked nodes and are not suitable for streaming real-time Solana data for latency-critical operations. They are the last in Turbine’s fanout to receive shreds.

The earlier in the tree, the more time you have to react before the rest of the network catches up. 

Global Variability 

Importantly, Turbine is location agnostic. Global propagation can magnify the latency variability, as physical distance and network conditions introduce delays beyond Turbine’s hops. 

For instance, shreds travelling inter-regionally (e.g., from a US-based leader to Asia-Pacific validators) can experience delays due to cross-continental routing, packet retransmissions, or even peering issues—even for high-staked validators in Turbine’s early layers.

This geographic spread creates opportunities for optimization. While a single, high-stake validator might excel locally, it could lag globally if not positioned optimally. This could be mitigated by a distributed shred network to aggregate the fastest possible shreds from various sources, thereby reducing variance and achieving consistent ingestion speeds. Such a system could consistently outperform a top-staked validator in global scenarios.

Accessing shreds reliably from optimized sources is essential to maintaining a competitive edge for developers building latency-critical systems. However, this requires robust infrastructure to effectively handle recovery, verification, and global distribution. Plus, most of Solana’s popular real-time data streaming tools do not currently leverage shreds.

Streaming Data on Solana

On Solana, developers looking to stream real-time data have a few options that each come with their own tradeoffs in terms of latency, reliability, and complexity:

Webhooks

Webhooks enable event-driven updates, pushing data to your application when changes to a specific account or program occur. They are simple to integrate programmatically, and can even be set up without any coding directly in the Helius Dashboard. Developers can stream human-readable, parsed data for specific transaction types, raw transaction payloads, and even stream these updates directly into a specific Discord channel as a formatted message.

Although webhooks are highly reliable and used by many high-profile companies on Solana, they send notifications after a transaction is confirmed. This means that webhooks may be hundreds of milliseconds behind shred-level data, making them too slow for latency-critical operations like high-frequency trading or liquidations.

Standard WebSockets

Solana’s JSON RPC API supports WebSocket subscriptions, such as accountSubscribe for account changes, logSubscribe for transaction logs, and programSubscribe for program events. WebSockets maintain a persistent connection between a client and an RPC provider, streaming updates as soon as transactions and account changes are processed. WebSockets are bidirectional and suitable for monitoring specific accounts or events in real-time while reducing polling overhead.

However, like webhooks, WebSockets deliver data post-shred reassembly (i.e., at the processed, confirmed, or finalized commitment levels), adding anywhere from 400ms to 30s of latency, depending on the commitment level. 

WebSockets are also considered a fragile connection type, meaning connections can drop for a whole range of issues requiring custom retry logic. Disconnections can mean permanent data loss unless supplemented with polling, which undermines real-time reliability. 

Enhanced WebSockets

Enhanced WebSockets are a significant improvement compared to standard WebSockets, offering several performance optimizations and enhanced filtering capabilities. Namely, better event parsing and reduced noise make them more developer-friendly for production use.

Enhanced WebSockets can reduce latency compared to standard WebSockets and are excellent for general streaming applications. For example, there is a noticeable performance difference when streaming Pump AMM data with Enhanced WebSockets compared to both standard WebSockets and webhooks. 

However, Enhanced WebSockets still fundamentally deliver data post-shred reassembly. Again, this limits their usefulness for applications where every millisecond counts. Moreover, while enhanced, they lack automatic replay or failover, requiring manual gap handling. 

Yellowstone gRPC

Yellowstone gRPC is a low-latency, validator-to-client streaming protocol that can provide access to data at the shred level. This makes it significantly faster than WebSockets and webhooks since it can deliver updates faster for the respective commitment level. 

Yellowstone offers bidirectional streaming with immediate subscription creations and cancellations, as well as advanced filtering capabilities to precisely control what data you receive in response to specific transaction, account, or program updates.

Yellowstone is ideal for users who want no rate limits, no credits, and guaranteed isolated hardware for custom node configurations. However, there are several major trade-offs:

1. Infrastructural Burden

You need to have your own dedicated node to use Yellowstone gRPC at its full potential. This requires access to hardware, the proper configuration, continued management of said hardware, and vertical expertise to debug any hardware-related issues.

2. Latency Variability

Just because Yellowstone gRPC can deliver data at the shred level, it doesn’t mean it will in the most optimal way. Latency can vary depending on your provider as well as whether your dedicated node is paired with shred-optimized sources (i.e., high-staked validators). Pairing with staked to low-staked validators means they won’t consistently land in the first Turbine layer, meaning you’ll still be downstream for many shreds.

3. Failure Risks

Relying on a single dedicated node creates a single point of failure, exacerbated by the fact that Yellowstone gRPC does not have any native replay capabilities.

4. Resource Demands

Overloading a dedicated node with intensive RPC calls while streaming data via Yellowstone can result in degraded performance. 

For a long time, and for many teams, Yellowstone gRPC has been the go-to streaming service for real-time data on Solana. It’s fast and suits advanced users, but it’s hard to operationalize for consistent, global, low-latency coverage without having access to a fleet of dedicated nodes around the world.

LaserStream

LaserStream combines the speed of shred-level ingestion with the reliability and reach of a globally distributed service, without the cost or operational headache of running multiple dedicated nodes. 

LaserStream achieves this through:

• Multi-source Ingestion: LaserStream ingests the lowest latency shreds, consistently beating competitors worldwide.
• Global Coverage: LaserStream is available in multiple regions worldwide, allowing developers to use the endpoint closest to their infrastructure. Each region runs multiple servers for redundancy, with an automatic failover.
• Zero Gaps:  LaserStream’s historical replay allows developers to replay recent blockchain data from up to 3000 slots in the past (i.e., approximately 20 minutes). This is useful for handling disconnects and ensuring data continuity. 
• A Developer-friendly Experience: LaserStream is a drop-in replacement for Yellowstone gRPC—no migrations, no new syntax, no headaches.

In a nutshell, LaserStream is a scalable, low-latency, and fault-tolerant improvement to Yellowstone gRPC and WebSockets. It consistently provides on-chain events as soon as they happen on the network, without requiring millions in stake or operating high-performance infrastructure yourself. 

LaserStream is the easiest way to harness the power of shreds for ultra-low-latency data streaming on Solana.

Clients and Performance

LaserStream has clients available in Go, Rust, and JavaScript/TypeScript. These clients handle automatic replay on disconnects as they continuously track which slot has been streamed. If a disconnection occurs, for whatever reason, the client will automatically reconnect and resume streaming at the last processed slot.

LaserStream’s JavaScript client is particularly interesting because it uses native Rust bindings. Because of this, the client boasts 1.3 GB/s throughput. This is a 40x improvement over the current Yellowstone gRPC JavaScript client, which maxes out at 30 MB/s. 

As Solana continues to scale, the Yellowstone gRPC JavaScript client will struggle to keep up. LaserStream’s JavaScript client performance headroom ensures your application can safely scale with the network as demand increases. 

Real-World Wins

DFlow, a low-latency DEX aggregator, recently integrated LaserStream to feed its price engine. Their decision to integrate came down to the ability to scale globally without having to worry about dedicated nodes and saving engineering bandwidth to focus on routing and business code. 

Since their integration, DFlow has reportedly saved over eight hours of recurring engineering overhead, maintained 100% uptime with uninterrupted data streaming, and improved quote speeds with faster transaction confirmations. 

xFractal also recently integrated LaserStream, citing its quick and easy setup and robust message and error handling, which makes it feasible for them to use without the overhead of managing dedicated Geyser nodes themselves. 

Faster Streaming, Today.

Milliseconds aren’t just latency—they’re opportunity. With LaserStream, you don’t just keep up with the network. You stay ahead of it. 

Want sub-second data for trading, liquidations, or oracles? Get the LaserStream—get access to the fastest Solana data available. 

Alternatively, for our power users, if you’re interested in raw shred delivery, reach out to us here by filling out the following Typeform.

Further Resources

• LaserStream
• Agave’s Shred Module
• Solana’s Shred Specification