In the original design of the Solana network, validators exchange the earliest pieces of block data (shreds) through Turbine. The first layer of innovation was establishing direct connections to multiple leaders and getting those shreds from them while bypassing the standard Turbine path. That’s what we have been doing for the last year.
However, as we kept pushing latency further down, we started asking a different question: why wait for shreds at all if the data can be captured inside the validator first?
Now we’re introducing faster access to Solana transactions via preconfs.
Why preconfs
Latency-sensitive applications that need early signals from Solana now have multiple options for getting data. There are three major ways:
- Raw shreds — UDP Solana shreds sourced from validators.
- Decoded shreds — a gRPC stream of Solana transactions decoded from raw shreds and sent to subscribers with specific filters.
- Binary — the fastest gRPC stream of data efficiently extracted from shreds, a new concept we recently introduced.
We can’t get lower latency from raw UDP shreds because of the nature of shreds: the earliest moment they can be collected is when the validator emits them to the network. We can shorten the path to the validator by connecting directly and avoiding Turbine, but we can’t make the validator emit shreds earlier.
As you can see, both Decoded Shreds and Binary rely on raw shreds, because raw shreds feed both pipelines. Since raw shreds themselves can’t arrive earlier, to make Binary faster we had to shift the source — or rather, the moment — from which we get the data. That’s how the concept of pre-shred data came up.
On Solana, when a validator builds a block, there is a gap between the moment transactions are executed and marked for inclusion and the moment the corresponding shreds are sent out to the network. Transactions still need to be shredded and transmitted. For latency-sensitive use cases, this gap is an eternity.
While latency-sensitive searchers chase 0.05 ms improvements, we can cut 10–50 milliseconds by changing the data source.
The gap is so large that a transaction can travel from Frankfurt to Amsterdam or London and still be faster than a local leader shred, not to mention retransmission.
While testing, we compared performance across a number of validators. Our benchmarks measured the speed of leader shreds versus preconfs from the same leaders.
Here’s what you can expect from preconfs:
- P10: 1–3 ms lead.
- P50: 5–10 ms lead.
- P90: 20–50 ms lead.
And again, this is performance against the leader shreds of those validators. That means preconfs can be 60 ms faster than Jito ShredStream and around 100 ms faster than standard Turbine.
Most importantly, even though preconfs give a large boost compared to shreds, they are safe for validators and the network. Transactions streamed via preconfs are already included in the block by the time they are sent out. That means preconfs do not expose transactions before inclusion decisions are made or create an opportunity to influence the current block. We are simply removing steps that are not necessary for low-latency use cases.
How to use preconfs
We’re sure you’ll find the best use of preconfs for your low-latency strategies, so we won’t dive too deeply into the use cases today. However, it’s important to understand how we’ll ship preconfs so you can plan the integration into your pipeline.
Here are the key principles to note:
- The first and most important one: preconfs are streamed only from current leaders. That means not every transaction gets the boost. Only transactions from connected leaders will be accelerated. The more leaders we add, the more coverage we’ll have.
- Preconfs are local. For example, we won’t include Tokyo preconfs in the Frankfurt stream, because it simply won’t make sense. To catch a Tokyo transaction faster, it is better to have a local server. So the Frankfurt stream will include only transactions within a meaningful distance from Frankfurt.
- The data inside preconfs is exactly the same transaction data you get from Binary or Decoded Shreds. It just arrives faster.
To make the most of preconfs, we’re going to provide them as a continuous stream on top of Binary: a mix of the fastest shreds and pre-shred data (preconfs).
Here’s why it makes sense:
- Binary is the fastest way to work with transaction data on Solana. As we wrote earlier, it outperforms the vast majority of raw shred setups. By default, Binary gets shreds from top-tier validators and efficiently extracts the data. This way, customers get the earliest signals without spending months on decoder optimisations.
- You get a continuous stream of all transactions without interruptions. Some transactions arrive from the earliest shreds, some from preconfs. Whichever source delivers a transaction first gets sent straight to you. That makes the integration seamless.
- Preconfs are provided as an add-on, making them a flexible option for Binary users.
We already have a large amount of stake connected to preconfs. The more stake we connect, the more transactions will be delivered faster than regular shreds.
We’re starting with the Frankfurt region, as it’s the main competitive region for Solana traders.
Binary preconfs are strategically provided on a new endpoint to give our users an additional optimisation venue. As we get shreds from different parts of the region, having more than one location in highly competitive regions such as Frankfurt significantly increases your chances of landing your transaction faster.
For this new location, we’ve chosen Allnodes servers, as their data centres have great connectivity within the region. While being just 0.3 ms away from our original Teraswitch FRA2 endpoint, it creates a second optimisation point for additional shred access and TPU landing. We suggest setting up a second location close to the new endpoint to get the most out of it.
What’s next and how to get started
Preconfs are currently available to qualified customers of Shreder Binary. Please get in touch with the team to discuss your use case for preconfs.
We’re excited about this launch and the opportunities that preconfs open for low-latency Solana applications. This edge can make new strategies possible and shift the frontier for trading on Solana.
We’re looking forward to hearing your feedback.