Infrastructure > Strategy > Execution: The Priority I Had Backwards

The Moment I Realize I've Been Optimizing the Wrong Thing

For weeks now I've been deep in the weeds of strategy and execution. Cycle search algorithms. AMM math overpredictions. Custom error decoding. ALT compression. Bundle land rates. Every one of those felt urgent, and each one was a real bug.

But something nags at me as I look back across the last few dozen entries in this series. Every fix shaves a millisecond here, a percentage point there — and yet my landing rate is still essentially flat. Profitable opportunities are still being missed. The model is correct, the math is correct, the bundle is correct. And the trade still doesn't land.

That's when I start to suspect the priority order I've been working from is wrong. I've been treating Solana MEV as a coding problem with an infrastructure tax. What if it's actually an infrastructure problem with a coding tax? What if I've been tuning the engine when the real problem is how far my car is from the racetrack?

The Series So Far — A Map of What I've Been Fighting

If I lay out everything I've worked on, a pattern becomes uncomfortable.

• DEX integration, swap-direction bugs, error-code conflicts, custom programs, CPI audits, PDA layouts — that's execution.
• Cycle exploration, weighted scanning, dynamic trade caps, circuit breakers, profit thresholds — that's strategy.
• An RPC subscription somewhere, a Yellowstone-compatible gRPC stream somewhere else, a leader-schedule peek, a bundle send to a block engine — that's the infrastructure layer I treated as a commodity.

Three categories. Three priorities. And almost all of my time has gone into the first two, with infrastructure pulled off a shelf like it's a default setting.

The Solana MEV writers I'm reading right now keep telling me, in different words, that this is the wrong way around. Daniel Yavorovych puts it most bluntly in his Medium piece: "Solana MEV is not won by smarter code alone — it's won by being closer to the current leader, receiving state updates faster, and submitting bundles before anyone else." RPCFast, in their Solana MEV infrastructure write-up, says the searchers who captured the bulk of last year's MEV "weren't running the most sophisticated strategies. They were running the best infrastructure."

That's a harder pill than it sounds. It means most of my recent battles were skirmishes on the second-most-important front.

The Stakes — What's Actually on the Table

Let me ground this in scale, because it's tempting to wave off infrastructure investment as "premature optimization" until you see the size of the prize.

For 2025, Solana MEV revenue lands at around $720 million for the year, according to RPCFast's overview and Yavorovych's analysis. In Q2 alone, Solana pulled in roughly $271 million in MEV versus about $129 million on Ethereum — Solana captured the larger share of the cross-chain MEV pie that quarter.

The single-hour records show how concentrated the action can get. During the TrumpCoin launch on January 20, 2025, bots paid out 8,584 SOL — roughly $1.5 million in a single hour — in tips and priority fees, per Pine Analytics and RPCFast. That's not a daily total. That's an hour.

Dwellir notes that across all chains since 2020, roughly $7.2 billion in MEV has been extracted, with Ethereum contributing about $600 million annually. Solana is now the bigger pot, and the data is converging on the same conclusion from every angle: this is a market worth competing in, but the bar to compete is set by infrastructure, not cleverness.

For a small operator like me — and let's be honest, I'm not a Wall Street firm with a co-lo cage in Mahwah, New Jersey — even capturing a sliver of a market this size is meaningful. But "a sliver" still requires being in the game. And being in the game, as the data is about to show, is mostly an infrastructure question.

What the Latency Data Actually Says

Here's the part where it stops being philosophy and becomes physics.

Solana's block time is 400 milliseconds. Paul Timofeev makes the consequence explicit in his latency piece: the decision window for MEV is measured in single-digit milliseconds. Hivelocity puts it in a sentence that took me a minute to absorb: a 100 ms delay is a quarter of the entire block interval (Hivelocity blog). I can spend 100 ms doing absolutely nothing and I've already burned 25% of the time I had to act.

Dwellir publishes a table that crystallizes the relationship between latency and capture rate — and reading it changed how I think about my own setup. From their MEV infrastructure piece:

• Under 30 ms P95 latency: 80–90% capture rate — highly competitive.
• 30–100 ms: 50–70% capture rate — still competitive.
• 100–200 ms: 20–40% capture rate — marginal.
• Over 200 ms: under 10% capture rate — non-competitive.

The gap between the top and bottom bands is not 2x. It's not 3x. Moving from above 200 ms to below 30 ms takes capture rate from under 10% to 80–90%. That's nearly an order of magnitude in opportunity capture, with the exact same strategy code running on top. Same algorithms. Same scanner. Same execution path. Different physical proximity to the network. Different result by almost ten to one.

Dwellir also documents a real-world case I keep returning to: one quantitative trading operation found that 400 ms of node latency was costing them 40% of potential arbitrage captures. After switching to faster infrastructure, their success rate jumped from 60 to 85 profitable trades per hundred attempts. They didn't rewrite their strategy. They didn't refactor their bot. They moved the box closer to the network and watched a quarter of their lost trades come back.

If I had to pick the single statistic that recalibrates how I'm thinking about priorities, it's that one.

The 200 ms Cliff and Why It's a Cliff, Not a Slope

Dwellir explicitly frames the 200 ms total-execution threshold as the line between competitive and non-competitive MEV. Their description, summarized: spotting opportunities, calculating profitability, and submitting transactions all need to happen inside that 200 ms budget. Bots that breach it capture significantly fewer opportunities.

The word "significantly" is doing a lot of work there. Look at the capture-rate table again. Between the 100–200 ms band and the over-200 ms band, capture rate drops from 20–40% to under 10%. That's a step change, not a gradient. It's a cliff.

This maps to a useful mental picture. Imagine the Indianapolis 500. You can finely tune your engine, your tires, your aerodynamics — but if your car is parked in a garage two miles from the track when the green flag drops, none of it matters. You won't even hear the starting horn until everyone else is on lap two.

That's what >200 ms latency looks like in Solana MEV. The strategy is in the garage. The race is already happening on the track. The Dwellir cliff isn't punishing slow code; it's punishing geographic and architectural distance from the validators where decisions get made.

The sub-200 ms world is also where the FIFO mechanic kicks in. As Paul Timofeev notes, Solana's transaction processing rewards order of arrival more than fee size — unlike Ethereum, where you can outbid your way to the front. On Solana, the searcher who shows up first eats first, and "first" is a function of network proximity, not wallet size.

This is also where the slot leader rotation matters. Leaders rotate every 1.6 seconds (about four slots), per Yavorovych. The validator that includes your transaction changes constantly throughout the trading day. So "being close to the leader" isn't a one-time setup — it's an ongoing geometry problem. A bot colocated in Frankfurt has a very different latency profile to a leader in Ashburn, Virginia than to one in Tokyo. And the leader keeps moving.

What Co-location Actually Buys

The second time I read RPCFast's co-location piece is the time it stops being abstract.

From their data table:

• Frankfurt → Solana Frankfurt cluster: 1.5–2.5 ms — optimal.
• Hetzner Falkenstein → Solana Frankfurt: 1.2 ms on bare metal — excellent.
• GCP Amsterdam → Solana Amsterdam cluster: 3.5 ms — acceptable.
• AWS Ashburn → Solana New Jersey: 60–75 ms — OK for US bots.
• AWS Singapore → EU Solana clusters: 190–220 ms — "unsuitable for slot-level trading."

Look at that bottom row. AWS Singapore to EU clusters is roughly the same range as Dwellir's >200 ms non-competitive band. If you spin up a Solana MEV bot in Singapore expecting to trade against European validators, you're already on the wrong side of the cliff before you write a single line of strategy code.

This is where the metaphor of NYSE co-location in Mahwah becomes useful, because Americans who follow finance know exactly what this is. Wall Street firms pay for rack space inside the NYSE data center precisely because microseconds of latency separate winning and losing trades. The cable lengths matter. The fiber path matters. The HVAC matters. Solana MEV has imported this discipline whole, just with millisecond units instead of microseconds.

RPCFast claims that co-locating a bot and an RPC node in the same physical data center as a high-stake validator yields a 5–10× latency reduction versus a remote cloud setup. They also describe LAN-local RPC access pulling request latency from 20–100 ms down to sub-1 ms. That's a vendor self-reported figure, so I'm taking the magnitude as directional rather than precise — but even a fraction of that improvement is enough to move from one Dwellir band to another, which (per the capture-rate table) is what matters.

For a US-based operation, the East Coast clusters around Ashburn, Virginia and the New York metro area are the gravitational centers. For a European operation, Frankfurt and Amsterdam. For Asia, Tokyo and Seoul. The validator map isn't uniform across the globe, and where you sit on it determines which leaders you can actually reach inside the competitive latency budget.

The punchline from Dwellir: searchers "looking to stay competitive have been forced to run their own validator nodes to reduce latency and co-locate their nodes in data centers near the Solana clusters." That word "forced" is doing a lot of work. It's not an option you take if you want extra returns. It's the price of admission.

Why Public RPC Is a Trap I Didn't Realize I Was In

This is the part that lands hardest, because it's where I am right now.

Cherry Servers contrasts a local node response of about 5 ms with public RPC providers at 50–200 ms of overhead (Cherry Servers blog). Dwellir, in their plainest line on the subject, writes: "Public RPC providers are rarely fast or reliable enough for competitive MEV."

I've been operating with a paid RPC subscription and treating that as the infrastructure question solved. But the data is saying that subscription RPC, no matter the tier, sits at exactly the latency band Dwellir labels marginal-to-non-competitive. Even the best paid endpoints are still on the wrong side of the network from the validators when the leader is in Ashburn and I'm not.

This is the Domino's pizza distribution model problem, in reverse. Domino's puts its stores close to its customers so the pizza arrives hot. If MEV opportunities are the pizza, then a public RPC endpoint is like ordering from a store across the country and being surprised the pizza is cold. The architecture of "some endpoint, somewhere" guarantees a latency ceiling I can't punch through with better code.

Dwellir's monthly infrastructure cost guide is sobering and clarifying at the same time:

• Self-hosted full node: $150–$500/month.
• Self-hosted archive storage: $500–$2,000/month.
• Bandwidth and networking: $100–$300/month.
• Dwellir dedicated node: around $2,000/month.
• Chainstack dedicated node: around $2,774/month, per their published figures.

Numbers like these used to feel disproportionate to a small operation. Now I look at them through the lens of the capture-rate table and they feel proportionate to the cliff. The cost of competitive infrastructure is not the cost of running a bot — it's the cost of being allowed on the track. There's an actual price for being in the under-30 ms band, and it's not zero, but it's also not the kind of money that puts a serious project out of reach.

Jito's Role and Why It Doesn't Replace the Latency Game

One objection I keep arguing with myself about: "OK, but Jito introduced a bundle marketplace. Now I can buy my way in with tips instead of racing on latency."

The data says: only partially.

Jito has restructured Solana MEV in significant ways. By late 2024, over 90% of Solana stake was running the Jito-Solana client, per Jung-Hua Liu's economic analysis, with RPCFast and Yavorovych reporting around 92% validator adoption by stake weight as of 2025. Jito tips climbed from about 10% of priority-fee volume in April 2023 to over 60% by early 2025, according to Pine Analytics. Daily tip activity reaches roughly 13 million tip transactions and 12,500 SOL spent on tips per day in Pine Analytics' data. By Q2 2025, Jito MEV infrastructure accounted for 13–15% of total staking rewards, per AIinvest's January 2026 report, which also notes that Jito Labs raised $50 million in October 2025, bringing total funding to $62 million.

Chainstack frames the macro shift well in their 2026 infrastructure piece: Jito's block engine "introduced a more structured marketplace for block space," moving MEV "beyond a pure speed race and toward a more explicit market for transaction ordering."

So yes — there's now a tip-based competition layer on top of pure latency. But the same Chainstack piece, alongside Hivelocity and Yavorovych, makes the qualifier brutal: bundles still need to reach Jito block engines within tight latency budgets. Hivelocity notes that ShredStream requires round-trip latency under 50 ms to block engines for guaranteed bundle inclusion. The auction happens every 200 ms (twice per slot), per Jung-Hua Liu. If my bundle doesn't reach the engine in time for the relevant auction window, my tip never gets a chance to compete.

In other words, Jito turned a pure speed race into a speed-plus-tip race. The tip lets me out-bid for a given auction slot, but the speed determines which auctions I can even enter. Infrastructure remains the gatekeeper. Tips are how you outcompete inside the gate.

There's also a sobering pre-Jito data point worth holding onto. In epoch 414, per Jung-Hua Liu, 60% of block compute units were consumed by arbitrage transactions, and over 98% of those arbitrage attempts failed. Validators were effectively burning more than half their block space on failed trades. Jito's bundle system, which requires atomic execution and discards failed bundles before they hit the chain, exists in large part to clean up that infrastructure-driven waste. The lesson I take from that: when infrastructure is bad, even good strategies look terrible.

What Strategy Actually Buys Me — And What Execution Actually Buys Me

None of this is an argument for ignoring strategy or execution. It's an argument for sequencing.

Strategy — the cycle search, the AMM modeling, the threshold logic — is what determines what I do inside the latency budget I'm allowed. If I can spot a real arbitrage opportunity that other bots can't, that's worth real money. But only after I've built the infrastructure that lets me see the opportunity in the first place.

Execution — bundle construction, ALT compression, tip calculation, instruction packing — is what determines whether the trade I want to make actually makes it on chain. This is the part where the last 40 episodes of this series have lived. It matters. A perfect strategy with broken execution lands nothing.

The correct mental hierarchy, I'm starting to think, looks like this:

1. Infrastructure floor. Be inside the sub-100 ms latency band. Be in the right region for the validators I want to reach. Don't depend on public RPC for the hot path. This is the price of admission.
2. Strategy ceiling. Inside that floor, build the smartest opportunity detector I can. More cycles, better math, fewer false positives.
3. Execution discipline. Inside the strategy, ship clean transactions. Compact bundles, accurate tips, atomic safety. Without this, the strategy doesn't realize.

For most of this series I've been working on items 2 and 3 with item 1 set to a default value. That's like a sprinter training for the 100-meter dash by perfecting their stride mechanics while running on a treadmill set to walking pace. The mechanics are real, but they're not going to translate into a finish-line time until the treadmill problem gets solved.

The academic literature on Ethereum block-building hints at the same dynamic. A 2024 paper on the Ethereum PBS oligopoly describes how "a small number of builders with superior latency or access to order flow came to dominate the market." Different chain, different mechanism, same gravity. Latency and order-flow access concentrate power in whoever has the best infrastructure, and the long tail finds it nearly impossible to break in without matching the floor.

What This Changes for Me, Right Now

I'm not making any rash moves. I'm not going to swipe a credit card and rent a bare-metal cage in a Frankfurt data center this week. But the priority order in my head is shifting, and that changes which problems get my attention next.

Where I'm landing:

• The infrastructure layer needs to move from "shelf item" to first-class engineering problem. I need to actually measure my P95 latency to the relevant block engines and the relevant validators, and benchmark that number against the Dwellir bands. If I'm above 100 ms, no amount of cycle-search optimization is going to save me.
• Public RPC for the hot path is a structural ceiling I've been ignoring. The data is unambiguous: 50–200 ms of public RPC overhead, per Cherry Servers, plus whatever overhead my own stack adds, plus serialization, plus bundle submission — adds up to a budget that's almost guaranteed to exceed the 200 ms cliff before I've even spotted the opportunity.
• Tips are a layer on top of latency, not a substitute for it. Jito has changed the shape of the competition, but it has not eliminated the geographic and architectural game. If anything, it has raised the stakes for the operators who already had infrastructure.
• Most importantly, I need to stop treating each new strategy refinement as my next priority. The marginal return on better algorithms is real but bounded. The marginal return on closing 100 ms of latency, if Dwellir's data is even approximately right, is potentially a step change in capture rate.

This doesn't mean abandoning the work I've done. The DEX integrations, the AMM math, the custom programs, the bundle construction — that's all the substrate the infrastructure stack is going to deliver value through. None of it gets thrown away. It just gets reordered behind the thing it depends on.

I suspect the next round of work on this project is going to look very different from the last several rounds. Less time in source code, more time staring at network topology diagrams and ping tests. Less arguing with the AMM model, more measuring round-trip times to block engines. The bot doesn't change. The ground it stands on does.

And that's what I'm trying to figure out next — not as a plan I'm executing, but as a question I'm working through. Where exactly am I on the latency map right now, and what's the cheapest first move that closes the biggest gap?

Key Takeaways

• Solana MEV is an infrastructure game first, per multiple independent sources (RPCFast, Yavorovych, Chainstack, Dwellir, Cherry Servers). The thesis is consistent: the searchers capturing the most value run the best infrastructure, not the most sophisticated strategies.
• Latency tiers map directly to capture rates. Per Dwellir's published table, sub-30 ms P95 latency yields 80–90% capture, while over-200 ms latency yields under 10% — a near order-of-magnitude swing with the same strategy code.
• The 200 ms threshold is a cliff, not a slope. The drop from 20–40% (100–200 ms band) to under 10% (>200 ms band) makes this a step-change competitive boundary.
• Co-location with validators is the structural answer. RPCFast's regional latency data shows the range from 1.2 ms (Hetzner-Frankfurt to Solana Frankfurt) to 190–220 ms (AWS Singapore to EU clusters) — geography sets a ceiling no amount of code can pierce.
• Jito has restructured but not replaced the latency game. Tip-based bundle auctions sit on top of infrastructure access; bundles still need to reach block engines within tight latency budgets to compete inside the every-200 ms auction window.
• The priority order is infrastructure → strategy → execution. Strategy and execution work multiply the value of the infrastructure floor; they don't substitute for it. Optimizing the upper layers without securing the foundation is, as the metaphor goes, tuning the car engine while parked two miles from the track.