Cut 10x, Still Zero: The Hard Limit of Arbitrage Prediction

A Win That Was Also a Zero

I've spent weeks chasing one number down. The first time I ran the route detector on real on-chain data, the predicted profits it spat out were roughly six to seven times what those same trades would have actually earned if simulated against fresher state. Each round of fixes — better reserve reads, accounting for fees I'd missed, correcting the math for concentrated liquidity ticks, handling each DEX type's specific quirks — chipped away at that gap. I'm now hovering somewhere near a tenth of the original overestimate. By any internal measure, that's a real result.

Then I pointed the bot at mainnet with real SOL behind it. The result so far: not one profitable landing.

Not a small loss. Not a near-miss. Zero successful trades. When a bundle does make it into a block, it reverts on the on-chain profit check — the wallet ends where it started, minus fees. The math said "this is a real opportunity." The market said "no."

This article is about why both of those statements can be true at the same time — and why closing the prediction gap further may not even be the right problem to keep attacking.

What "Cut by 10x" Actually Means

When I say I shrank overestimation by an order of magnitude, what I mean is narrower than it sounds. The bot is calculating two things, and one of them I can do almost perfectly. The other I cannot do at all, in any general sense, and I'm only now starting to understand why.

The first calculation is the static AMM math: given a frozen snapshot of a pool's reserves, what would my profit be if I executed a particular swap path right now, this instant, against this exact state? For a constant-product pool, that's the textbook x * y = k formula. For a tick-based concentrated-liquidity pool, it's more involved, but still deterministic — there's no randomness in it, just bookkeeping over the active tick range. For bin-based liquidity, the same story. The formulas have been formalized and published; an academic paper on AMM dynamics lays out closed-form conditions for when arbitrage is profitable down to the fee parameter γ.

I can compute that number to as many decimal places as I want. Given the input state, the output is exact.

The second thing I'm trying to do is the actual job: predict the profit I will earn when my transaction actually executes, some number of slots in the future, against a state I haven't seen yet. That's the number I was off by 6–7x at first. That's the number I've narrowed to roughly a tenth of the original error.

And that's also the number that hit zero on the first real attempt.

The distinction matters, because it tells me whether to keep grinding on the same lever or look somewhere else entirely.

The Frozen Lake Versus the Moving River

Think of it this way. Static AMM math is like calculating the area of a frozen lake. You can walk the shoreline with a tape measure, take however long you need, and arrive at a number that is exactly, provably correct. If two people use the same formula on the same lake, they get the same answer. There's no skill in it beyond knowing how to read the tape.

Dynamic market prediction is like predicting where a leaf will be after floating down a river for thirty seconds. You know the current at the upstream point. You know the leaf's starting position. You know roughly how fast water moves. And yet — eddies, branches, a fish flipping under the surface — the leaf can end up anywhere within a wide arc, and sometimes nowhere near where the steady-state math said it would.

The bot is the person trying to predict where the leaf goes. The math is the upstream measurement. The river is everything that happens between the moment I read the pool state and the moment my transaction lands in the leader's block.

Or try a more American version: it's the difference between knowing the line on a football game and knowing the final score. The pre-game stats are computed exactly. They're publicly available, agreed upon, audited by every sportsbook in Vegas. None of that tells you who covers.

What "Committed State" Means and Why It's the Ceiling

The way Flashbots research describes it, "An offchain query can fetch the state of the last-committed block, but this lags behind the MEV opportunities being created by transactions within the block currently being built." Read that twice. The whole problem is sitting in one sentence.

Every reserve number I read is a snapshot from a block that's already done. The transactions I'm reacting to — the swap that opened the arbitrage gap — are already history when I see them. The transactions that will close that gap before mine lands have not been broadcast yet, or have been broadcast and not yet committed. They're in flight. They're invisible.

On Ethereum, you can at least watch the public mempool — pending transactions that haven't been included yet but are visible to anyone running a full node. Bots there can try to incorporate those pending swaps into their estimates. Solana, unlike Ethereum, has no public mempool to watch. There is no equivalent here. Every Solana bot is reasoning entirely from committed state, and committed state is, by definition, the past.

This is not a bug in my code. It's not something I can fix by reading reserves faster or doing the math more carefully. It's a property of the system itself: the information I'd need to predict perfectly does not exist anywhere I'm allowed to look.

Solana's 400ms Blocks Compress the Window

The other constraint is timing. Solana produces a new block roughly every 400 milliseconds. That's faster than twice per second. Ethereum, by comparison, produces a block roughly every twelve seconds — so a Solana bot has to deal with state changes happening at an order-of-magnitude higher rate than an Ethereum bot.

What does that mean concretely? Suppose I see an opportunity appear in slot N. By the time my construction pipeline assembles the transaction, signs it, and submits it through a network connection, the chain has often already moved on to slot N+1 or N+2. If the opportunity was created in slot N by a swap that someone executed against the pool, and my response only lands at slot N+3, three rounds of competing bots have had the chance to close that gap. On a chain where the marginal cost of submitting a transaction is small, several of them probably already did.

The faster the chain, the shorter the window between detection and execution, the wider the gap between "what I saw" and "what's there now." This is why latency matters disproportionately on Solana. As Umbra Research puts it, latency is more important for searchers on Solana because state updates are so frequent.

This is the closest thing to physics in this game. I can't make Solana slower. I can only react faster, and reacting faster has its own hard floor.

Why the Math Being Right Doesn't Save You

Here's the painful part. Even if my prediction were perfect — even if I could calculate the exact profit that would exist at the moment my transaction executes — that wouldn't guarantee I'd capture it. The question isn't "does the profit exist?" The question is "am I the first one to take it?"

Umbra Research reports that approximately 96% of atomic arbitrage attempts on Solana fail outright. An infrastructure provider, in its annual Solana MEV report, recorded a peak month where 75.7% of all non-vote transactions on the chain reverted — and the majority of those were failed arbitrage bots burning small amounts of SOL on attempts that didn't pan out. Flashbots research on Ethereum quantifies the same pattern from the other end: for every successful arbitrage, bots send approximately 350 failed transactions, and one searcher consumed roughly 132 million gas — the equivalent of nearly four Ethereum blocks — to land a single successful arbitrage.

These numbers are not failures of prediction in the narrow sense. The math, when each of those 350 transactions was constructed, said "profit exists." The bots that sent them weren't running broken formulas. They were losing a race.

On Solana, the way bots compete for inclusion inside a tip-priority competition is by offering a tip — a payment to the validator or block-building infrastructure on top of standard fees. According to a cross-chain analysis firm tracing the share of expected arbitrage profit that ends up in tips, the share rose from around 10% of expected profit in early 2023 to roughly 60% by early 2025. Same gross opportunity, dramatically lower net take, because the competition for inclusion has intensified.

So the picture, by the time you compose it honestly, looks like this: I might predict a profit of $X. The actual realized gross profit, even if I land, is something less than $X because the pool moved between detection and execution. Then I pay a tip that's a substantial fraction of what's left to outbid other bots. Then there's fee overhead. And then — most of the time — I don't land at all, because someone else's tip cleared the bar before mine and their transaction took the opportunity.

The Second-Place Trap

There's a special version of this worth naming, because it's one of the structural reasons a technically-correct opportunity still returns zero. On Solana, being second often means earning nothing. Not "earning less." Not "earning a smaller residual." Nothing.

The reason is simple. The arbitrage I detected was a price gap between two pools. When the first bot's transaction lands, it executes the arbitrage by swapping through both pools in the profitable direction. That swap moves both pools' prices, closing the gap. When my transaction lands second, the swap path is the same path, but the pools no longer reflect the imbalance. The state at execution looks like "two pools at parity, with my swap going through both of them and paying fees on each side." Net profit: zero, or close enough to zero that I cannot tell the difference.

The math, at the moment I composed my transaction, said the profit existed. The math, at the moment my transaction landed, said the profit was gone. Both statements are true. There's no contradiction in the formulas. The variable that changed was the world.

This is the part of MEV that doesn't reduce to a better model. There's no smarter calculation that tells me whether I'll be first or second. Being first is a function of infrastructure, geography, tip strategy, and luck — none of which are inputs the AMM formula knows about.

It's a little like getting in line at a Black Friday doorbuster. The store really does have the TV at the advertised price. The price is real, the inventory is real, the deal exists. But by the time you're at the front of the line, the TV is gone, and what's left for you is the privilege of having driven across town in the dark. The advertised price wasn't a lie. It just didn't apply to you.

Where Latency Actually Lives

If the prediction problem doesn't reduce to better math, the natural next question is: can it reduce to better infrastructure? The honest answer is partially, and with diminishing returns.

The largest gains come from getting closer to the leader — both physically (running in data centers near where upcoming block leaders are geographically located) and in terms of the data feed (subscribing to state updates over a low-overhead streaming protocol rather than polling at a slower cadence). The pattern that surfaces consistently in practitioner write-ups is this: according to one infrastructure analysis, a poorly tuned setup can see hundreds of milliseconds of state lag, while a well-tuned setup pulls it down to tens of milliseconds. That's a meaningful difference when blocks are 400ms apart — you're changing the ratio of "I saw the world this slot" to "I saw the world last slot."

But notice what this does and doesn't fix. It moves the snapshot closer to "now." It does not give me a snapshot of "after my transaction lands." The state I'm reasoning from is still committed state; it's just less stale committed state. The fundamental gap — between what I see and what will be — gets smaller, but it doesn't go to zero.

The pattern I've seen in practitioner write-ups is consistent: past a certain point the bottleneck stops being the math and starts being how quickly you can see the state and how quickly your transaction reaches the leader. Strategy is the entry ticket; execution speed is what determines whether you get to play in the top tier.

This is humbling to read as someone whose project so far has been mostly about strategy. It reframes "cut the prediction error by 10x" as the right work in absolute terms but not necessarily the rate-limiting work in competitive terms.

The Macro Picture: Other Bots Are the Noise

The other thing I keep coming back to: this gets harder, not easier, over time. Not because the protocols get harder, but because the competition gets denser.

The same cross-chain analysis that traces tip share rising from 10% to 60% of expected profit also documents that cyclic arbitrage activity on Solana climbed from a small fraction of aggregator-executed DEX volume in mid-2024 to a substantial share of certain DEX aggregator volume by late 2025. The bots are no longer the side characters in the market. The bots are increasingly the market, at least for routine flows. That's not a niche participating in an exchange. That's a substantial chunk of price discovery happening between bots that are watching each other.

For any given pool, the noise on its reserves between two committed blocks is increasingly other bots executing arbitrages. The world I'm trying to predict is itself populated by entities trying to predict me. There's a research paper, The Origins of MEV, that uses a 5% profit-threshold rule to identify when an arbitrage opportunity has gone stale — and reports that 99.3% of attributable opportunities are claimed within seven blocks of when they're created. The window is tiny by human standards and enormous in machine time.

The lesson I'm drawing is that the math is necessary but the game is no longer about math. Or more precisely: the part of the game I have the most control over is the math, but the math, by itself, doesn't determine who wins.

What This Means for the Next Hundred Trades

These first real attempts earning zero are not, in themselves, a signal that the bot is broken. They signal that the bot is now playing in the real game. In the real game, the question isn't "can the math identify an opportunity" — the math can, and that part is working. The question is "of the opportunities the math identifies, what fraction can I actually capture?"

The empirical answer from the wider ecosystem, given that roughly 96% of attempted atomic arbitrages on Solana fail, is that most opportunities, by the time I get there, are already gone. The fraction that do land are the ones where I happened to be first, or where the opportunity was deep enough that even after several bots took bites there was still meat left.

So the operational question I'm staring at now is not "how do I get the prediction error down further?" The prediction error, in the narrow sense of static-math accuracy, is already in a range where further gains have small marginal impact on outcomes. The real questions feel different:

How do I get the detect-to-submit pipeline tighter, so that fewer of my predicted opportunities are stolen between detection and landing? How do I size tips so that I outbid the median competitor on opportunities worth winning, and walk away from opportunities that aren't? How do I avoid spending SOL on transactions that have no realistic chance of landing first?

None of those are math problems. They're systems problems, market-strategy problems, and — perhaps most uncomfortably — problems where the answer depends on what other people are doing, which I cannot see and cannot fully predict.

The Honest Frame

I want to write down what I think I've learned, because it's the kind of thing that's easy to forget once the bot lands a few trades and starts looking like it works.

The math is necessary but not sufficient. Cutting overestimation by 10x was real progress. Without it, even the trades I do land would be priced wrong, and I'd be tipping inefficiently or chasing opportunities that don't exist. So this work mattered. But it does not, by itself, produce profit. Nothing in the formulas tells me how often I'll actually be the bot that lands.

Static and dynamic are different categories. I had been treating "predict the profit" as one problem. It's two problems wearing the same name. Calculating the profit at a given state is a math problem and it's mostly solved. Predicting the state at execution is a forecasting problem under partial information, and it is not solved — not for me, not for the people who've been at this for years, not in any general sense.

Zero is data. An attempt that identifies a real gap but returns zero — whether it reverts on the profit check or loses the race to another bot — tells me I was in the right neighborhood. That's a different failure mode than "the math hallucinated an opportunity that didn't exist." The first is fixable by being faster or more selective. The second would be fixable only by being more careful with the formula. Knowing which kind of zero this is changes what I do next.

The market is not standing still. While I'm narrowing my prediction error, the rest of the ecosystem is also getting better at this. Same cross-chain analysis documenting tips at 60% of expected profit also documents the rapid growth of bot-driven volume. There are more bots, fighting harder, for thinner margins. Whatever lead I build in static math can be eroded by everyone else building the same lead.

Where I Sit Right Now

I'm going to keep refining the math because the math is leverage — every percentage point of overestimation I eliminate is a percentage point fewer fake opportunities I chase and a percentage point closer to right when I size tips. But I am no longer expecting that "fixing the prediction" will produce a profitable bot.

The bot is now in the part of the work where the real adversary is other people running the same kind of system, watching the same pools, racing the same blocks. The static math is a prerequisite for showing up. It is not the thing that wins.

These first zero-profit attempts are, in that frame, neither failure nor success. They're the first evidence from the actual environment I'm trying to operate in. It tells me roughly where I sit relative to the competitive frontier — close enough to identify the same opportunities they identify, not yet close enough to land them first. That gap is the next problem.

I don't know what closing it looks like yet. I have guesses about where to push — pipeline latency, tip strategy, selectivity about which opportunities are even worth attempting — but those are conjectures, not a plan. I'll find out by trying.

Key Takeaways

• Static AMM math can be computed almost perfectly; dynamic market prediction is fundamentally hard. The formulas are exact; the world doesn't stand still long enough for the formulas to be the whole answer.
• "Committed state" is a ceiling, not a floor. Bots can only read state from blocks already in the past, while the opportunity-generating transactions happen in the block currently being built. That gap is structural, not a bug to be fixed.
• Solana's 400ms blocks compress every prediction window. State changes happen multiple times per second; the cost of being slow is paid in lost opportunities, not just in lower profit per opportunity.
• Being second in a block often means earning zero. The first arbitrageur closes the gap, leaving subsequent bots with no opportunity at all — even though their static math was correct.
• Prediction-accuracy gains have diminishing returns past a certain point. Once the math is roughly right, further improvement competes for impact with infrastructure, tip strategy, and selectivity — which are the levers that actually determine whether you land.