Why Solana Latency Is Different

We've watched teams overinvest in every part of the stack regardless of whether they actually need each piece.

This is a problem because low latency trading infrastructure on Solana is different and it has more moving parts than what you might be used to. This guide will focus on infrastructure decisions that are specific to Solana's architecture, and how the architecture determines your infrastructure choices. It is meant for traders, bot developers, and infrastructure engineers building systems for trading or bots. We'll focus specifically on end-to-end latency on Solana (from seeing an on-chain event, to getting a transaction into a block). If you are building a wallet or an analytics product, a lot of this will be more than you need, but the first two layers will still save you money.

There are four main layers that we'll cover: placement, observation, submission and routing. The first two are the most applicable for any Solana users. The latter two are applicable for more sophisticated trading bots, and can be deferred as needs arise.

• Placement: refers to the geographic proximity of your servers to Solana's validator network.

• Observation: how you observe the chain, from raw shreds, via the gRPC API, WebSockets or polling.

• Submission: how you submit transactions (with staked TX lanes, via the bundle API or otherwise)

• Routing: determining the optimal region to send transactions to. This is because Solana's current architecture means that the leader (the node that produces blocks) changes every 4 slots, which is approximately 1.4s at the current slot time.

A quick note on the numbers in this article. Solana's mainnet slot time was 400ms for most of the network's life, but it was reduced to 350ms on 21 August 2026 (epoch 1020) as the first stage of SIMD-0525. Further reductions to 300ms, 250ms and eventually 200ms are planned, each behind its own feature gate, and testnet is already on the 250ms to 200ms stage. So a leader window today is 4 x 350ms = 1.4s. We've used the 350ms figure throughout. If you are reading this after another reduction has been activated, just adjust the arithmetic. More on this at the reduced slot times page.

Key Takeaways

• Latency on Solana is relative to the leader, and the leader changes every four slots (about 1.4 seconds at 350ms slots). Whatever is fast in one region will be slow for most of the schedule.

• Reads are more important than writes. Seeing an event earlier makes every decision after it better. A faster submission path only helps once you've already decided.

• Raw shreds are the earliest point where you can observe the chain. Anything that works off processed blocks is at least one processing step behind.

• Unstaked connections are the first to be dropped during congestion. A staked (prioritized) write path is what keeps your transactions flowing in the exact conditions you built the system for.

• Build for the worst hour, not the average hour. Average numbers don't tell you anything about what happens during a token launch.

• Alpenglow is expected to bring finality down to around 150ms (sometimes 100ms). It doesn't remove the geographic component of latency, so placement and routing still matter after it ships.

Layer One: Placement

Placement is the most fundamental aspect of trading infrastructure on Solana. The next three layers are important but they can only go so far to improve the latency if your servers are far from the leader.

Solana's design has three properties that impact your placement.

• Validators are spread globally, and the leader schedule walks through them in proportion to the stake they control. So the more stake there is in a region, the more often the leader is in that region. As of 2026 Europe is the largest cluster by a wide margin and Frankfurt in particular is the single biggest concentration of stake.

• Blocks are produced by a leader who changes every 4 slots (approximately 1.4s), and the schedule is deterministic. The leader schedule for an epoch is calculated from the ledger state at the start of the previous epoch, so it is known ahead of time. An epoch is 432,000 slots, which at 350ms per slot works out to roughly 42 hours.

• While producing a block, the leader splits it up into messages called shreds (erasure coding means that there are extra coding shreds, so any given section of a block can be recovered if some of the data shreds go missing), and broadcasts them via its peer-to-peer network, Turbine, while the block is still being built. Nodes then have to recombine the shreds and replay the transactions to reconstruct the block.

Turbine is a multi-layered tree structure, with a fanout of 200 in each layer, and propagation moves from the root to the leaves. The process is documented in the Turbine docs.

For any given block, a user that is observing raw shreds will observe the block much faster than users via RPC. RPCs will report blocks at processed commitment (which requires replaying the block on the node itself) which introduces another hundreds of milliseconds or potentially an entire slot of latency on top of however long the shreds took to arrive.

These three properties mean that you can expect to see a pattern of fast and slow time, where you will be very fast when the leader is close by, but slower during the rest of the schedule. A tradeoff can be made between costs and this fast/slow time, depending on your strategy.

Some options for placement, in approximate increasing order of cost and complexity:

• Have a server in a single region. Ideally this would be where a lot of stake is (e.g. Frankfurt, Amsterdam, the US east coast). This would mean that your system is slow for a good part of the schedule, but the cost is much lower. If you are using unstaked routes, it would also mean your transactions are dropped first during congestion (which is why we recommend at least one staked connection).

• Have servers in multiple regions. This is the preferred option for latency-sensitive trading systems. By spreading servers closer to each of the leaders, and submitting from whichever one is closest to the current leader, you can minimize the impact of a leader being far away, and the cost is still reasonable given the value. Europe plus one US region covers most of the schedule in practice. This is the part of the infrastructure that is the least obvious on how to build, but also the most important for overall latency. It may not be obvious where to put servers initially, but we've seen where a lot of stake is concentrated, and can advise on it. We also publish per-region pages like Solana RPC in Frankfurt and Solana RPC in New York so you can see where the infrastructure actually is.

• Run your own node next to your bot (colocation). This means a Solana node on the same host or in the same rack as your strategy, near stake, so you remove a network hop on both the read and the write side. It is the fastest option and also the most expensive, since a healthy node needs fast NVMe, 100+ Mbps of Turbine traffic, and somebody on call when it breaks.

Some other important points:

• Reads are more important than writes because being able to see data faster gives you a more substantial edge. It helps you make all other decisions faster (including transaction submission). The best trading strategies have to do with acting faster than other people, so this matters.

• Network latency between continents is a real bottleneck. The current minimum round-trip time between the US east coast and Europe is approximately 70-90 milliseconds over good fiber, and this is impossible to build around. This is why it's so important to have servers in each region.

• Alpenglow, the next major Solana upgrade, is expected to have much lower finality times (around 150ms median, sometimes 100ms). It won't remove the geographic component of latency or obviate the importance of placement and routing.

• The network isn't always under maximum capacity. It is important to build a system that is optimized for times of high congestion because many strategies will make money during that time, and congestion is worst during periods of token launches. You can't build your infrastructure to handle average usage per hour. The system has to be able to hold up during times of launch.

Layer Two: Observing the Chain

There are five different points at which you can observe the chain. They are listed here from earliest to latest. Each of them is the right choice for some use case. The expensive mistake is using one of the later ones for a strategy that is sensitive to latency, and then trying to make up the difference in code.

The difference between raw shreds and Geyser gRPC is the block processing time on the node. In most setups this is the largest delay that can actually be avoided. We have written about this in more detail in our shredstream article.

Some things to know before choosing:

• Shred data is raw. A full shred stream is somewhere in the range of 50-100 Mbps of UDP traffic, and to turn it into transactions you need to do deshredding, Reed-Solomon recovery, and deserialization. This has to happen somewhere, either in your own code or in a service. In our experience it is the biggest single leverage point in the whole stack, and it's what Jetstream gRPC is for: transactions reconstructed from shreds sourced at the top of Turbine, delivered over a normal gRPC stream, with the deshredding done on our side.

• Match the level of detail to the decision. Shred-level streams are faster partly because they leave out inner instructions and full metadata. Yellowstone gives you all of that (inner instructions, account updates and so on) but it arrives one processing step later. Most serious systems use both. The shred-level feed is the hot path that tells you something happened, and Yellowstone is the structured source of truth that you check before acting on state.

• Commitment levels are a choice, not a default. If your logic waits for "confirmed" or "finalized", you are waiting hundreds of milliseconds to whole seconds longer than "processed". Sometimes that fork protection is what you want. It should just be a decision you made and not something you inherited from a code sample.

Layer Three: Submitting Transactions

Seeing an event early is not much use if your transaction doesn't land. During congestion the leader's transaction processing unit (TPU) is saturated, and Solana decides whose connections get served first based on stake. This is the stake-weighted QoS mechanism, which gives stake-weighted priority to 80% of the leader's TPU capacity. There are four ways to get a transaction in, and our comparison covers them in more depth. In short:

• Plain RPC forwarding. The node forwards your transaction to the leader over an unstaked connection. This is fine when the network is quiet and is the first thing to be dropped when it isn't.

• Stake-weighted QoS lane. Your transaction goes over a staked connection and is served before unstaked traffic. This should be the default for anything high volume.

• Jito bundles. A group of up to 5 transactions that execute sequentially and atomically at the top of a Jito-enabled leader's block. Bundles compete with each other on tips. If any transaction in the bundle fails, none of them are committed. This is the tool for multi-leg strategies and for bidding on priority explicitly. See Jito's docs for the details.

• Direct TPU forwarding. Your own forwarder speaks QUIC directly to the leader's TPU. This is the fastest option when you are colocated and staked, and unreliable when you are not.

Priority fees and tips sit above all four of these. A transaction paying the base fee on the best connection will still lose to a worse connection that pays more. Fees are bids in an auction, and it is a mistake to treat them as a cost to be minimized.

The rule we give people is: bundles when you need atomicity, the staked lane for everything else, and direct forwarding only if you are colocated and staked. If you'd rather not build this layer yourself, there are landing services for it. OrbitFlare's Apex, for example, combines Shredstream-routed submission, Jito bundle support, and stake-weighted QoS behind one endpoint, with per-transaction analytics so you can see the landing rate.

Layer Four: Routing Between Regions

Once you have servers in more than one region and you have the leader schedule, the router has one job per transaction, which is to decide which region sends it. It needs three inputs:

• The current slot and the upcoming leaders. These come from the deterministic schedule via getLeaderSchedule.

• A mapping from validator identity to datacenter region. This has to be built by parsing gossip continuously, because validators move and the mapping goes stale.

• The latency from each of your regions to each leader region. This should be measured with your own probes and not taken from a published ping table (those are someone else's numbers from someone else's rack).

The output is something like "submit from region X, and also from region Y if the next leader is there". You cover the slot boundary by targeting the current leader and the next one, and then you stop. Resending from every region for seconds at a time is how bots burn through rate limits, get dropped as duplicates, and land in the wrong slots. It is the most common routing mistake we see, and usually it's someone's idea of being safe.

Routing helps on the read side as well. A feed in Frankfurt sees Frankfurt blocks first, so a strategy that reacts to events globally should consume feeds from several regions and deduplicate by signature. The same shred data arriving twice is redundancy, not two events.

What Alpenglow Changes, and What It Doesn't

Alpenglow is Solana's consensus overhaul and no infrastructure guide written in 2026 can really skip it. The governance vote (SIMD-0326) passed in early September 2025 with 98.27% of the participating stake voting yes. Community validator testing started in May 2026. Anza's Agave v4.3 release schedule has mainnet feature activation targeted for 28 September 2026, with the usual caveat that Anza's schedules are tentative. Two pieces of it matter for this article.

Votor replaces Tower BFT voting. Votes move off chain into lightweight aggregated certificates, and finality drops from about 12.8 seconds to around 150ms median (sometimes as fast as 100ms). Vote transactions also stop taking up block space.

Rotor replaces Turbine's multi-hop tree with a single-hop, stake-weighted relay broadcast. Blocks are still erasure-coded into shreds. In the whitepaper's numbers, with 1 Gb/s of bandwidth, transmitting 1,500 shreds takes about 18ms.

The Alpenglow whitepaper has the full detail. For your infrastructure the effects are fairly specific:

• The read side stays shred-first. Rotor still uses shreds, so the earliest observation point is still the propagation layer and not the processed block. Faster propagation actually makes the node's processing gap a bigger share of the total delay, not smaller.

• Geography still matters. In Anza's simulations the consensus overhead is roughly a 2x multiplier on the raw network latency, so finality is bounded by how far the leader is from the stake supermajority. A leader in New York with most of the stake in Europe is still looking at something like 200ms. Placement and leader-aware routing don't change.

• Congestion moves, it doesn't go away. Freed-up vote capacity adds throughput headroom, and demand has always grown to fill block space. Keep the prioritized write path.

• Block production gets more regular. Alpenglow drops Proof of History timing in favor of fixed slot timeouts, which should make your latency measurements more repeatable.

Plan for Alpenglow as the current model getting faster and not as a replacement for it.

Ultra-Low Latency: What Separates the Top Tier

Everything above gives you a fast stack. The tier where trading firms compete with each other adds three more decisions.

• VPS or bare metal. A Solana VPS near stake is the right starting point (cheap, deployed in minutes, milliseconds from the regional leader). The problem is that virtualized neighbors burn your CPU and add jitter that an average ping never shows. The top tier moves to bare metal or trader nodes, meaning a machine that runs only your strategy, because at that level tail consistency matters more than average speed.

• Temporal submission. Default routing targets the current leader. Because the schedule is deterministic you can instead send to the next leader while it is still building its block, and land at the start of its window rather than the end of the previous one. This is a legitimate use of public information and it is how the fastest bots make the 1.4 second rotation work for them instead of against them.

• Proximity to the block engine, not just the validators. For bundle strategies, distance to the Jito block engine relays matters as much as distance to the leaders. Colocating your submission in a region with block engine presence removes one more hop from the write path that is most sensitive to latency.

The principle at this tier does not change. Each upgrade should remove one identifiable stage from the loop, and if you can't say which milliseconds an upgrade removes, you are buying marketing and not speed.

Putting the Layers Together

The pattern is the same in every row. The read path depends on how early you need to see events. The write path depends on whether you need atomicity. The placement depends on how much of the leader schedule you need to be fast for.

Where the Milliseconds Go

If you walk through one loop from event to landing, the optimization targets pick themselves.

1. The leader builds the block and broadcasts shreds. This is fixed by the protocol, there is nothing to optimize.

2. Shreds reach a node. This is network distance to the leader, so it's a placement problem.

3. The node processes the block and exposes it. You skip this entirely if shreds are your event source. Otherwise you pay the node's processing time. This is your read path choice.

4. Your feed delivers events to your process. Local network plus serialization. Minimal if you are colocated.

5. Decode, decide, build, sign. This is your own code, and it should be under a millisecond.

6. Your transaction reaches the leader. Network distance plus TPU queuing. Placement and write path.

7. The leader includes it. Priority fee, stake, or tip. Write path.

Stages two, three and six dominate, and all three are infrastructure decisions. Stage five is the one that everybody over-optimizes.

How to Benchmark Before You Buy

Vendor numbers are measured from the vendor's rack to their nearest leader. You should measure from wherever your bot is actually going to run. The fastest RPC for trading is not the one with the best number on a landing page, it is the one that wins these four measurements from your own servers.

• Observation lag. Timestamp the same transaction on each feed (shred-derived, Yellowstone, WebSocket) and take the spread. That spread is the value of the earlier feed, in your region, on your traffic.

• Landing rate by leader region. Send a cheap transaction through each write path every few seconds for a week. Record the slot it landed in relative to the slot you sent it in, and bucket the results by the leader's region. Then look at the worst hours (token launches, liquidation cascades) and not the averages.

• Fill quality. For a live strategy, this is the executed price against the price at the time you observed the event. It is the only number that proves the stack is actually early.

• Feed continuity. Count gaps and reconnects per day on each feed. A feed that is 5ms faster but drops twice a day during launches is slower in expectation.

Our benchmarks page is built on exactly this methodology. It is run from multiple regions against the live leader schedule, so the numbers can be reproduced and don't have to be taken on faith.

Common Mistakes

• Optimizing code before infrastructure. A sub-millisecond decoder behind a feed that is 300ms late is a fast bot that is always late.

• One region. You are fast for a minority of the schedule and slow for the rest.

• An unstaked write path in production. It works in testing and then fails during exactly the launches you built the bot for.

• Resending forever. This burns rate limits, causes late landings, and makes your own metrics lie to you.

• A zero priority fee on a fast path. Connection quality and fees multiply. If either one is zero you still lose the auction.

• Measuring averages. The average hides the congested hours, and that is where the edge is. Measure the tail.

• Not reconciling. Without the observed slot, submit time and landed slot for each transaction, you can't tell which layer went slow.

FAQ

What does low-latency network infrastructure for Solana trading look like?

Servers placed near stake concentrations, a data feed that is as early as possible (ideally shred-level), a prioritized submission path, and routing that follows the rotating leader schedule. The whole point is to shrink the loop from an on-chain event to your responding transaction landing in a block.

How many regions do I need to trade on Solana?

One region near stake (Frankfurt, Amsterdam, or the US east coast) is a sensible start. Two or three regions covering Europe and North America will handle most of the leader schedule. Beyond that the returns diminish quickly once the stake-heavy regions are covered.

Are shreds faster than gRPC?

Yes. Shreds stream while the leader is still building the block. Yellowstone gRPC delivers after the node has processed the block, which adds the processing time on top. Shred-based gRPC services reconstruct transactions from shreds and keep almost all of that lead, and you don't have to do the deshredding yourself.

Should I use Jito bundles?

Only if you need atomicity (several transactions that must land together, as in multi-leg arbitrage) or you want to bid for priority explicitly through tips. For everything else a single transaction on a staked lane is the better trade.

Will Alpenglow make low-latency infrastructure obsolete?

No. Finality drops to around 150ms and Rotor speeds up propagation, but both are still bounded by the physical network latency between leaders and stake. Shreds stay the earliest observation point, and placement near stake still decides who sees and lands first.

What should I measure before choosing an RPC provider?

Observation lag between feed types, landing rate bucketed by leader region during congested hours, fill quality against the price at observation, and feed continuity. Measure from your own servers for at least a week and weight the worst hours, because averages hide exactly the conditions you are building for.

Does any of this change for AI trading agents?

No. An agent in the trading loop runs the same event-to-landing loop as a rule-based bot: listen on a feed, decide, submit. The only difference is that the decision step takes longer, which makes the milliseconds saved everywhere else more valuable, not less.

Four Decisions

Where do you sit relative to a leader that moves every four slots? How early do you observe the chain? How does your transaction get into a saturated leader? And which region submits as the schedule rotates? Whether you are a solo bot operator or a firm evaluating providers, the framework is the same. Place near stake in more than one region. Read the hot path from shreds or a shred-derived stream. Write through a staked lane, or bundles when you need atomicity. Route by the schedule. Then measure observation lag, landing rate in the worst hour, and fill quality, and let the data decide the next upgrade. Alpenglow will make all of this faster. It won't make any of it optional.

The OrbitFlare stack maps onto the four layers directly: Shredstream and Jetstream gRPC on the read side, staked transaction landing in the RPC plans on the write side, and eleven regions to route across. Start with the measurements, and the rest follows from the data.

---

OrbitFlare builds Solana infrastructure for teams that need speed: RPC nodes, Jetstream gRPC streaming, trading APIs, and Shredstream. Get in touch if you want help designing your stack.

Resources

1. Solana documentation on Turbine
2. Alpenglow: a new consensus for Solana (Anza)
3. Reduced slot times (SIMD-0525)
4. Agave v4.3 release schedule (Anza)
5. What is Shredstream?
6. How to land transactions on Solana
7. Stake-weighted QoS guide
8. Jito bundle documentation
9. Jetstream V2 docs
10. OrbitFlare benchmarks