How to Make Solana Transaction 10ms Faster

Without a Powerful Server Using Shreds

WEB3 ENGINEERING

Without a Powerful Server Using Shreds

Shreds are essential to Solana's efficiency. By utilizing raw shreds directly without conversion, performance can improve particularly for transactions that don’t require immediate state changes. This enhances responsiveness and user experience on the Solana network.

What exactly are shreds in Solana

On Solana shreds are a way of breaking down data into smaller, manageable pieces to speed up the process of validating and adding information to the blockchain.

Imagine that instead of processing an entire book page by page, you tear each page into strips (or shreds) and work on those smaller sections simultaneously.

When a small subset of transaction (like a payment) happens on Solana, it gets divided into these shreds before being sent to the network. Each shred contains part of the transaction data. These shreds get distributed across different nodes, which verify them independently and then send back confirmations. Once all the shreds are verified, they’re pieced back together to form the full transaction, which can then be permanently added to the blockchain.

This approach helps Solana achieve its high speed and low cost

Many nodes can process parts of different transactions at once. Instead of each node doing all the work for every transaction, they’re only responsible for a portion, which they can complete faster. This makes the whole system much more efficient and scalable, even when many people are using it at the same time.

How it works

The leader, during the process of creating a block, sends only a part of the block, called shreds, to other network participants without waiting for the entire block to be fully formed.

Most solutions work as follows: they receive these shreds, convert them into a more convenient format, and pass them on to subscribers, such as trading strategies. This is the standard approach everybody uses, but it requires significant resources.

We discovered a method to enable the trading strategy to use raw shreds directly without conversion obtaining information 10ms faster

Assuming that certain conditions are met.

Advantages of this approach

Some transactions modify the blockchain state, and the “relevance” of a transaction depends on “new state = old state + transaction.” In this case shreds are not useful as full processing of the state is required.

However, there are transactions that determine the state independently: market opening messages, start of sales, completion of pump fun migration. In such cases, we don’t need to wait for the transaction to be processed by a node, allowing us to act instantly.

We were able to connect to shreds without using a node which is significant as it saves time considerably. We measured the performance gain and achieved an acceleration of approximately 10ms compared to Yellowstone gRPC Geyser.

Research on Solana shreds

Below is the practical addendum to the shreds theory you just read. We move from concepts to measurements: how provider choices translate into measurable millisecond advantages, how to validate them yourself, and what we built on top of this research.

Direct shred-to-shred benchmarking
We compared 4 shred providers head-to-head with a single script that listens to two streams in parallel and logs which one delivers each shred first. We then parsed the logs, computed summary statistics, and built histograms of the time-difference distribution.

Receive server: Frankfurt
Shred sources: also Frankfurt
Methodology: dual-stream listener → single log → post-processing
Sample size per pair: from hundreds of thousands to millions of events
Reproducibility: sample code to test and compare any two shred sources

Notes on latency and pings:

This is not gRPC; you cannot reliably “ping” a shred feed directly. In some cases, providers can expose their own ping data, but you cannot measure it precisely from the outside.
Network routes, validator/provider load, and software updates change the picture quickly. Results can shift in a week; always retest against your own KPIs.

Which shreds did we test?
Jito
Corvus
Everstake
Helius

Benchmark results

1) How many milliseconds is Corvus faster than Jito?
500,000 measurements (≈5 minutes)

Average difference: 5.051 ms
Median: 3.051 ms
Corvus first: 94.08%
Jito first: 5.92%

2) How many milliseconds is Everstake faster than Jito?
500,000 measurements (≈5 minutes)

Average difference: 2.091 ms
Median: 0.648 ms
Everstake first: 68.25%
Jito first: 31.75%

3) How many milliseconds is Helius earlier than Jito?
500,000 measurements (≈5 minutes)

Average difference: 3.067 ms
Median: 1.881 ms
Helius first: 87.26%
Jito first: 12.74%

4) How many milliseconds is Helius faster than Corvus (or vice versa?) 6,500,000 measurements (≈30–60 minutes)

Average difference: –1.071 ms (on average Helius is later)
Median: 0.179 ms (on median Helius is earlier)
Helius first: 60.61%
Corvus first: 39.39%

Conclusions

Corvus and Helius are the leaders overall. Which one is “better” depends on the metric that matters more to you.

❗️And a note on pings: this isn’t gRPC — you can’t just ping it directly. Sometimes, you need to request ping data from the provider, so we cannot measure it precisely ourselves.

⚠️ Do not anchor on a single snapshot; re-benchmark as routes and loads evolve.

We also run our own high‑performance shred feeds that are fast, efficient, and budget‑friendly.

Characteristics

$300–450/month, with a trial available (contact us for exact pricing)
Performance: significantly faster than JitoStream; yet slightly behind Helius
Unique advantage: 3× less traffic with zero data loss
Lower load on your node/network and faster decoding
Ideal for: arbitrage, sniping, and HFT-style pipelines where cost matters

Contact @inventandchill on Telegram for access.

Other infrastructure solutions

Ready to take your business to the next level? Let's talk

I agree to the Terms of Service