The Wall of Speed: I Cut Five Seconds to One, And It Still Wasn't Enough

The Number That Stopped Me

I ran the benchmark three times because I did not want to believe it the first two.

The rewrite is working. The pipeline that used to spend roughly five seconds dragging a transaction across the finish line now does the same job in under a second. On paper that is a five-fold improvement, the kind of number you screenshot and stare at for a minute because progress in this project has been measured in inches for weeks. Pre-build the transaction skeleton up front, drop the round-trip simulation calls, fold the math into local computation, and the wall clock collapses. I have the before-and-after right here in the log.

Then I open the latest infrastructure write-up I have been reading and the line that ends my celebration is right there: capture rate at sub-thirty-millisecond P95 latency is 80 to 90 percent; capture rate at over two hundred milliseconds is under 10 percent. My new number, the one I was about to celebrate, is roughly one thousand milliseconds. According to an MEV infrastructure analysis, that puts me in the bucket where most attempts simply do not land.

The gap I closed is real. The gap that remains is roughly an order of magnitude larger than the one I just spent two weeks closing.

The Game Is Played on a 400-Millisecond Clock

To understand why this is so brutal I need to step back to the structure of the game itself. Solana produces blocks in slots that are roughly four hundred milliseconds long. A designated validator (the leader) gets four consecutive slots before rotation, and the leader schedule is published a full epoch in advance, which means roughly two days of public knowledge about who will be at the front of the line and when. This is per a slot time breakdown, which walks through the TPU pipeline stage by stage.

That slot is not a polite suggestion. It is a hard physical clock enforced by the chain's Proof of History construction. Inside those four hundred milliseconds the leader has to fetch incoming transactions, verify their signatures, run them through parallel execution, generate shreds, and propagate the resulting block. The breakdown lays it out: fetch takes one to five milliseconds, signature verification five to fifteen, banking fifty to one fifty, broadcast thirty to one hundred, vote propagation another fifty to one hundred. Add it up and almost the entire budget is spoken for before anyone outside the leader has even shown up.

That leaves an extremely narrow window where my transaction can arrive, be acknowledged, and be included. Miss the window and the opportunity is not delayed — it is gone. The next slot belongs to a new leader, the on-chain prices have shifted, the arbitrage triangle I was about to capture has either been taken by someone else or evaporated entirely.

This is the part that took me a while to internalize. In most software performance work, being slow means being slow. A user waits a few extra seconds for a page to load. In MEV, being slow means being absent. The work executes, but it does not count.

What Pre-Building Was Supposed to Do

The optimization I just shipped is called transaction pre-building, and the logic behind it is sound. In the naive version of my pipeline, the bot waited for a trigger signal, then went to work: query state, compute the trade size, construct the transaction, sign it, serialize it, and finally hand it to the network. Every one of those steps sits between the moment the opportunity becomes visible and the moment my signed bytes hit a validator.

The pre-built version moves most of that work earlier in the timeline. The transaction skeleton is constructed in advance, parameters templated, accounts pre-resolved, and the signing key warmed up. When the trigger fires, only the final values need to be plugged in. The critical path between "I see it" and "I sent it" gets dramatically shorter.

This is essentially the NASCAR pit crew strategy: every wrench is pre-positioned, every motion rehearsed, the tire iron lives in the same spot on every stop. The driver does not show up to a toolbox and start hunting for a tool. Each second saved during a pit stop comes from work that was done before the car ever pulled in.

An infrastructure analysis documents the technique in concrete numbers: "Use local simulation...instead of network calls to verify profitability. This reduces RPC calls from 100 to 36 in typical arbitrage scenarios, improving execution time from 5s to under 1s." That is the source of my own benchmark improvement. The change is genuinely large. In a different domain — building a backend service, a data pipeline, a batch job — going from five seconds to under one second would be the headline of a quarterly review. Engineers would get bonuses.

In this domain, it is the price of admission to the room where the actual race happens.

Where the Winners Actually Live

The capture-rate table is uncomfortable to read carefully. At P95 latency under thirty milliseconds, capture rate sits at 80 to 90 percent. At thirty to one hundred milliseconds, 50 to 70 percent. At one hundred to two hundred milliseconds, 20 to 40 percent. Above two hundred milliseconds, under 10 percent. The case study cited alongside the table is even sharper: a quantitative trading operation found that four hundred milliseconds of node latency was costing them roughly 40 percent of potential arbitrage captures, and reducing that latency moved their success rate from sixty profitable trades per hundred attempts up to eighty-five.

My one-second number is not in that table. It is past the right edge of the table.

The number that compounds the discomfort comes from an analysis on Medium. Across roughly 1.3 billion MEV transactions on Solana over a recent twelve-month window, the success rate was only 3.31 percent. Average profit per block was about twenty-three cents. Total accumulated profit across that entire ocean of activity came out to over $14.8 million. The vast majority of attempts simply do not land, and the value that does get extracted concentrates in a small number of operators: the top 10 percent of extractors capture roughly half of all MEV value.

A separate cross-chain analysis sharpens this further. It reports top-three bot concentration controlling more than 60 percent of Solana market share, with annual ecosystem profits of roughly $143 million. Most of that is captured by a small set of operators whose infrastructure puts them in the sub-thirty-millisecond bracket.

This is what "winner-take-all" actually means in practice. It is not a metaphor about competition being tough. It is the literal observation that Solana's transaction processing is first-in-first-out at the slot level, and the first transaction to land claims the opportunity. The second-place transaction does not get second place — it gets nothing, and it pays the fee anyway. The closest American comparison I can find is the New York City taxi business before the apps showed up: whoever's hand was up first got the cab, the second-in-line passenger just kept waiting on the curb. There was no consolation fare.

Computation Was Never the Bottleneck

Here is the part that took me longest to accept, and it is the part that explains why my five-second-to-one-second win does not move me up the leaderboard.

A writeup from a developer working on a multi-chain arbitrage engine makes the point bluntly: "computation time has not been a bottleneck for competing for latency compared to network transmission time, which is usually tens or even hundreds of times longer than the computation time."

Read that twice. The work I just spent two weeks doing — making computation faster — was attacking the part of the problem that was not the bottleneck. Pre-building moves the compute step off the critical path. But the critical path is dominated by network round-trips, not by compute. A co-location analysis puts hard numbers on this: from Frankfurt to a Solana node co-located in Frankfurt, round-trip latency is 1.5 to 2.5 milliseconds. From a Singapore cloud region to a European Solana cluster, it is 190 to 220 milliseconds. The same data, the same protocol, the same code — but the physical distance between machines multiplies latency by roughly a hundred times.

The same write-up adds the brutal corollary: a 100 to 150 millisecond round-trip "can eat 25–35% of the slot time — before the RPC even forwards the transaction." My transaction can be perfectly constructed, perfectly signed, perfectly priced — and still arrive at the leader after the slot has closed because of where my machine happens to sit on the planet.

This is not a software problem. It is a problem of geography, fiber routes, and the speed of light. A Medium essay on the topic titled "The Zero-Latency Dream" puts it as plainly as possible: "Absolute zero latency...defies the laws of physics. Light travel time between geographic locations creates irreducible minimum delays." Even photons traveling in straight lines through perfect fiber take measurable time, and real fiber is neither straight nor perfect.

The American Trucker Analogy

The best way I can describe this to myself is to think about overnight package delivery. Imagine I run a small fulfillment shop in rural Montana, and I want to compete with someone running an identical shop literally across the street from a major shipping hub in Memphis.

We can both pack a box equally fast. We can both print a label in the same number of seconds. If I optimize my packing station I can get my preparation time down from five minutes to one. That is a real, measurable improvement and my customers will notice.

But the moment the box leaves my dock, the package next to me at the Memphis hub is already on a plane. Mine has to be driven to the nearest regional hub, flown to Memphis, sorted, then flown to its destination. The competitor's package skips the first three legs of that journey entirely. No amount of packing-station optimization on my end will close that gap, because the gap is not in the packing station. It is in the routing.

That is exactly the shape of the MEV problem. Pre-building is packing-station optimization. The thirty-millisecond winners are not pre-building harder than I am — they are sitting in Memphis.

Two Walls, Not One

When I lay it out for myself I see that the latency budget is actually two separable problems stacked together.

The first wall is the one I can climb. Compute, transaction construction, signing, local simulation, RPC call reduction — all of these are software problems. I can pre-build. I can cache. I can write tighter code. I can choose protocols that move data faster. The published benchmark showing five seconds to under one second comes from this kind of work, and it is the kind of work that rewards effort.

The second wall is the one I cannot climb without changing the physical address of my computer. Network round-trip time across continents. The cross-region penalty of one to two hundred milliseconds. The speed-of-light floor between geographically distant data centers. Co-location with validators. A co-location guide describes well-architected stacks reaching twenty to thirty-five millisecond end-to-end transaction submission, but only when the bot is physically in the right building. From the wrong building, no software change reaches that number.

The uncomfortable truth is that the second wall is the dominant cost. Cross-chain analysis consistently points to infrastructure speed — not transaction fees — as the dominant cost for Solana arbitrageurs. Not the speed of your code. The speed of your infrastructure.

The Slot Clock Doesn't Negotiate

There is one line from the slot time breakdown I keep coming back to: "The 400 ms slot is not a tunable parameter on your side of the keyboard. It's a physical constraint that defines the game." Inside that four-hundred-millisecond envelope, the writer continues, every type of opportunity — cross-DEX arbitrage, liquidations, sandwiches, back-runs — is won by whoever lands their transaction first. The framing they land on is binary: either you compete, or you watch.

That phrase has been rattling around in my head all week. The optimization I shipped does not move me from watching to competing. It moves me from one part of watching to another part of watching. The arbitrage opportunities are visible in my data feed. The math is correct. The transaction is well-formed. The system works in the sense that it produces correctly signed bytes pointing at correctly identified opportunities. But on the wall clock that actually matters, those bytes arrive after the door has closed.

The fact that it is closer to closing than it used to be does not change which side of the door I am on.

What Happens When the Clock Gets Faster

There is a future development that will make this gap worse before it gets better. The Solana roadmap includes an upgrade called Alpenglow, which according to the same slot time analysis is expected to reduce finality from the current 12.8 seconds (which takes 32 confirmation rounds under Tower BFT) down to 100 to 150 milliseconds under a new construction called Votor. A future release is targeted at reducing slot length from 400 milliseconds to 200 milliseconds.

The author draws the implication out: every latency optimization that matters at 400 ms matters disproportionately more at 100–150 ms, where slow infrastructure becomes lethal rather than merely suboptimal.

In other words, the gap between fast bots and slow bots is about to widen, not narrow. The winners get faster. The losers do not get more time. The threshold of competitiveness moves toward shorter and shorter windows, and operators whose hardware and geography already place them inside that window will widen their lead.

This is the part where I would normally write something hopeful about how the smaller player still has a path forward. I am not going to do that, because right now I do not see one clearly. What I see is a market where the winners are increasingly defined by their physical proximity to the network they trade on, where the software differences between operators have largely been competed away, and where new chain upgrades make those physical advantages more valuable rather than less.

What I Did Not Get From Pre-Building

Let me be precise about what the optimization actually delivered, because being precise about what changed and what did not is the only way to think about what to do next.

What pre-building reduced: the compute portion of the critical path. Transaction construction time, in the framing from the slot time breakdown, dropped from the thirty-to-one-hundred-millisecond degraded band toward the sub-ten-millisecond healthy band. Local simulation replaced network round-trips for profitability verification. The full pipeline's wall-clock time dropped roughly five-fold.

What pre-building did not reduce: data feed latency, RPC round-trip time, submission propagation time, and validator-side processing time. None of those depend on whether my transaction skeleton was assembled before or after the trigger signal. They depend on where my server sits, what kind of connection it has to the validator network, and whether I am inside or outside the geographic cluster where the leaders actually run.

If I draw a picture of the latency budget with all components added together, the slice I shrank is real but is not the largest slice. The largest slices are the network slices, and those are not slices I can shrink with code. It is the same lesson a small restaurant learns the hard way about same-day grocery delivery: the chef can chop faster, the kitchen can be tidier, the recipe can be drilled until it is second nature, but the delivery driver still has to make the drive. The driving time is most of the customer's wait, and no amount of kitchen polish changes that.

The Honest Read

I started this stretch of work expecting that a clean pre-building implementation would put me meaningfully closer to landing real trades. The result of the benchmark says that I did the engineering work correctly, but the gap to competitiveness was never primarily a code problem. The five-second-to-one-second improvement is real and worth keeping. It also does not, by itself, do the thing I wanted it to do.

There are not many cleanly-shaped lessons here yet. The data tells me the floor of competitive latency is roughly thirty milliseconds at the P95 level, that capture rates fall off a cliff above that, that computation is rarely the bottleneck for latency, that the physical-network portion of the budget tends to dominate, and that the winner-take-all structure of slot-FIFO transaction processing means partial improvements toward the leaders accomplish very little if I do not actually reach the leaders.

The gap I tried to close is partially closed. The gap that remains has a different shape than the one I started with, and I am still working out what kind of move addresses it without changing the fundamental economics of the project. The optimization shipped. The wall is still there.

What This Means Going Forward

For now I am going to leave the pre-built pipeline in place. It is better than the previous version on every measurable axis, and the work was not wasted — it just did not accomplish what I had assumed it would accomplish. The question that comes next is not really about another round of code optimization. It is a question about whether the kind of bot I am building can ever be competitive against operators whose primary advantage is physical infrastructure rather than software.

I do not have a clear answer to that question yet. What I have is a clearer picture of where the wall sits, what its shape is, and which kinds of moves do and do not reach it. The honest read of the data is that the gap between my latency budget and the competitive threshold is dominated by costs I cannot easily change, and that the upcoming chain upgrades are likely to make that gap matter more rather than less.

Sometimes the most useful thing a benchmark can tell you is that the problem you were solving was not the problem you needed to solve. That is the message I am taking out of this week.

Key Takeaways

• Pre-building transactions delivered the documented five-seconds-to-under-one-second improvement that infrastructure analyses describe, but the competitive threshold for high MEV capture rates sits roughly an order of magnitude tighter than that
• Solana's four-hundred-millisecond slot defines a binary outcome where transactions either land or do not land within the window; partial improvements that do not reach the threshold accomplish very little
• Computation is rarely the bottleneck in MEV latency; network transmission time across geography tends to dominate the budget by a wide margin
• Cross-region penalties of one hundred to two hundred milliseconds can consume a quarter to a third of an entire slot before the RPC even forwards the transaction
• The upcoming reduction of Solana finality from roughly thirteen seconds down to the hundred-millisecond range will widen the advantage of operators whose infrastructure already sits inside the competitive window