Predicted State MEV: The Hardest Puzzle in Solana Arbitrage

The Wall I Am Currently Climbing

I have been staring at the same problem from different angles for weeks, and I am finally willing to call it what it is: the hardest puzzle in on-chain arbitrage. Not the algorithmic side. Not the on-chain execution side. The prediction side.

If I can correctly anticipate what a liquidity pool will look like after a large pending swap executes — token reserves, marginal price, effective liquidity in concentrated ranges — then I can route an arbitrage transaction into the same atomic bundle as that swap and lock in the price gap before anyone else even sees it move. The math says this is possible. The market says many bots already do it. My logs say I am not one of them yet.

This is a snapshot of where I am right now — what I have figured out, what I have not, and why I think this is genuinely the toughest problem in the stack.

What "Predicted State" Actually Means

There is a useful ladder for thinking about arbitrage sophistication, and most beginner content stops two rungs short.

Rung one — reactive arbitrage. Watch the spot price of an asset across multiple DEXes. When SOL/USDC trades at one price on one venue and a different price on another, buy low, sell high. The catch: by the time you can see the gap, dozens of other bots can see it too. The opportunity gets eaten in milliseconds, and the winner is whoever has the fastest reading and the highest tip.

Rung two — backrun arbitrage. Stop watching prices directly. Instead, watch the swaps that move prices. When a large user trade hits a pool, the pool's reserves change. Subscribe to account-write streams that fire the moment those reserves commit, then immediately compute the resulting arbitrage. This is faster than rung one because you are reacting to the cause, not the effect. But you are still reacting. You see the new state, then you compute, then you submit. Other bots see the same state at the same time.

Rung three — predicted state MEV. Stop reacting entirely. Observe the pending swap before it executes. Predict mathematically what the pool will look like once it lands. Compute your arbitrage against the predicted state. Package your transaction into the same atomic bundle as the user's swap, so the two execute back-to-back. When the bundle lands on-chain, your arbitrage is already there — pre-computed, pre-signed, waiting.

This is the version of arbitrage that produces consistent returns at the scale Solana operates at. According to a recent cross-chain MEV analysis, the top three Solana arbitrage bots control more than 60% market share in their categories, and a recent industry MEV report counts more than 90 million successful arbitrage transactions in a single one-year window. You do not get there on rungs one or two.

Why the Math Says This Is Possible

The theoretical case for prediction is airtight, and it is the reason this puzzle is so frustrating. The mechanics of automated market makers are deterministic.

For a constant-product pool — the original Uniswap v2 design, and still the dominant model for many Solana venues — the entire post-swap state can be computed from the current reserves and the swap input. Reserves multiply to a constant k. A swap of size dx produces an output dy = y * dx / (x + dx) (ignoring fees). The new reserves are x + dx and y - dy. The new marginal price falls out from there.

A peer-reviewed paper published in mid-2025 puts it succinctly: "Operators leverage automated market maker (AMM) mechanics to calculate likely token reserves after pending transactions. This mathematical predictability — derived from constant product formulas — enables speculative positioning" (Solmaz et al., arxiv:2506.14768). The paper formally defines this whole tier of activity as "optimistic MEV" — "the practice of executing trades based on predicted future blockchain states before those states are finalized."

Stable-swap curves are flatter near the peg but still mathematically deterministic. So are the piecewise-linear pricing segments inside concentrated liquidity market makers (CLMMs). If I know the current state and the input, I can compute the output exactly.

In a vacuum, prediction reduces to plugging numbers into a formula. The vacuum is the problem.

Five Reasons Reality Disagrees With the Math

My bot's logs read like a tour of every way prediction can break.

1. Concurrent transactions and ordering uncertainty

A Solana slot is roughly 400ms, and inside that window a leader can pack hundreds of transactions. There is no public mempool to inspect — a major MEV relay suspended its mempool in March 2024 over sandwich-attack concerns, and Solana's design has never offered the kind of visible pending-transaction pool that some other chains do.

What that means in practice: even if I correctly predict the state change from the specific swap I am observing, my prediction is conditional on no other swap touching the same pool ahead of mine. In a popular pool during volatile minutes, that is a heroic assumption. The actual post-swap state is determined by whatever ordering the leader chooses, and the leader is not asking me.

2. CLMM tick boundaries break clean formulas

Constant-product pools have one formula that holds across the whole reserve space. Concentrated liquidity pools do not. Liquidity is allocated into discrete price ranges ("ticks"), and the effective formula changes every time a swap crosses a boundary.

A technical analysis from a 2025 arbitrage-routing piece captures it well: "Concentrated liquidity (Uniswap v3): Piecewise linear segments with dramatic price shifts when exhausted." A large swap on Whirlpool-style pools can cross multiple tick boundaries, and accurately predicting the end state requires simulating each crossing step by step. A constant-product prediction takes microseconds. A multi-tick CLMM simulation can take milliseconds — and milliseconds, in this market, are eternity.

3. Compound error in multi-hop routes

The simplest arbitrage is two-legged: swap A → B on one venue, B → A on another. Two predictions, multiplied together. The more interesting opportunities are triangular: A → B → C → A across three pools. Three predictions, multiplied together.

The same arbitrage-routing piece frames it as a constrained optimization problem: "For triangular arbitrage cycles (A → B → C → A), solvers must balance the slippage on each leg of the cycle. The limiting factor is whichever pool exhibits 'very high curvature (steep slippage).'" Errors compound multiplicatively. If each individual prediction is 95% accurate, the product across three hops is closer to 86%. That gap is exactly where my losing transactions live.

4. Competing bots invalidate predictions

Even if my prediction is correct at the moment I compute it, the state may not stay correct long enough for my transaction to land. The same analysis frames the dilemma directly: "Solvers operate with incomplete future knowledge, they estimate outputs and profitability based on the current state of the pools. If the state changes before their transaction mines, the path might no longer be profitable or even valid."

There are two defensive moves: tighten slippage so that a wrong prediction reverts cleanly, or accept worse fills to maximize landing probability. Both cost money. And the cost of a reverting bundle is not zero — the tip stays paid even when the trade does not execute.

5. Partial fills break the assumption

My prediction assumes the user's pending swap executes in full. Sometimes it does not. The user may have set their own slippage tolerance, and if the pool moves enough during the slot, the swap partially fills or fails outright. My arbitrage is now built against a state that never existed. The transaction reverts. The tip is gone.

The Cost of Being Wrong

It is worth pausing on the economics, because this is what makes the prediction problem feel so unforgiving.

Solana arbitrage is a high-frequency, low-margin business. A recent industry analysis pegs the average profit per arbitrage transaction at $1.58, with total arb profits across an entire year at $142.8 million — generated across over 90 million transactions. The largest single arbitrage in that period netted $3.7 million in one shot, but those are outliers. The median is a dollar and change.

Meanwhile, a cross-chain analysis observes that "arbitrage bots pay 50–60% of their profits in tips to validators." So a successful arb that nominally captures three dollars of price gap might net the searcher around a dollar after the tip. Every failed bundle still owes the tip. The minimum bundle tip is 10,000 lamports, and competitive bundles routinely tip orders of magnitude higher than that.

The math is unforgiving in a specific way: a bot with 90% prediction accuracy is not 90% as profitable as a bot with 100% accuracy. It can easily be unprofitable in absolute terms, because the failed 10% drains the tip budget faster than the successful 90% can replenish it.

Which means prediction accuracy is not a nice-to-have. It is the difference between a profitable bot and an expensive hobby.

What the Production Bots Actually Do

There is a publicly available reference implementation of a Solana MEV bot, and it is illuminating to read precisely because of what it does not do.

The reference bot is reactive. It "simulates the transaction and observes the changes in the account balances" after they happen. It subscribes to account-update streams for pool accounts and recomputes opportunities when reserves change. It is not predicting anything. It is reacting to confirmed state changes.

The maintainers themselves note that the repository "is no longer maintained" and "is not intended to be used in production for MEV." The clear implication: production bots have moved past the reactive design.

What have they moved to? The publicly observable pieces fit together. There is a relay layer that introduces a roughly 200ms delay on routed transactions, which creates a window between when a swap enters the system and when it executes. There is a bundle mechanism that lets a searcher attach their own transaction to a target swap, with the guarantee that the entire bundle executes atomically — all-or-nothing — so there is no risk of the user's swap landing without the searcher's arb.

Inside that 200ms window, sophisticated bots:

1. Detect the incoming swap from the relayed transaction.
2. Parse it to identify the pool and trade size.
3. Compute the predicted post-swap state.
4. Search across all monitored pools for arbitrage cycles that would be profitable in the predicted state.
5. Build and submit the bundle, including a competitive tip.

That full pipeline has to finish well inside 200ms, account for compute-unit limits, and produce a tip number high enough to win the competition but low enough to preserve margin. This is the engineering problem I am chewing on.

The Competition Is Won on Infrastructure, Not Cleverness

One of the more sobering reads I have come across this month is a technical post from earlier this year arguing, plainly, that "the searchers who captured the majority of that value weren't running the most sophisticated strategies. They were running the best infrastructure."

The same piece offers a line I cannot get out of my head: "A bot reading prices from a public RPC endpoint is already 200ms behind the bots co-located next to validators." Two hundred milliseconds. On a chain where the entire block time is 400ms, you have spotted yourself half a block before you started.

This is where Solana arbitrage stops resembling any other software-engineering problem I have worked on. The win condition is not "write better code." The win condition is "see the swap before everyone else, predict the state faster than everyone else, and pay the right tip to land before everyone else." Each of those three is its own infrastructure project.

I keep coming back to a sports analogy. In motorsport, the car matters, the driver matters, but the pit crew determines who wins the race. The teams that consistently win are not the ones with the most exotic engineering — they are the ones whose pit stops are half a second faster than everyone else's. Solana MEV is the same. The math is public, the strategies are well documented, the on-chain code is open source. What is not public is who has co-located their hardware where, who has subscription access to which streaming services, and who has spent the months tuning their pipeline to shave milliseconds.

The Speculative Approach: Just Send It

There is one option I keep flirting with and then talking myself out of. An introductory guide to Solana MEV describes the alternative philosophy this way: sandwich bots "create on-chain programs that exploit opportunities even with uncertainty, making speculative calls without knowing if an opportunity is present, but the low transaction fees mean successful ones offset the costs of failures, making these strategies profitable overall."

In other words: stop trying to predict. Build an on-chain program that conditionally executes if conditions are right at execution time. Submit it on every plausible signal. Let the on-chain checks revert the failures. Pay tips on the failures. Hope the successes pay for the failures.

This works for sandwich attacks because the on-chain program can verify the conditions atomically. It is more dangerous for arbitrage because the tip and base fees are not refundable, and at a $1.58 average profit, the failure rate has to stay genuinely low for the math to work.

I keep coming back to the same conclusion: the speculative approach trades engineering complexity for tip burn. It is not the wrong answer for everyone — it might be the right answer for highly sandwich-friendly venues — but for the pure arbitrage problem I am working on, prediction accuracy is the cheaper lever to pull.

Where I Am Stuck Right Now

The open questions I am actively wrestling with, in roughly the order they bother me:

CLMM prediction latency. Constant-product pools predict in microseconds. CLMM pools with multi-tick swaps take much longer. By the time I finish simulating, the window may already be closed. I am trying to find the right cutoff: when does a CLMM swap get "too large to predict in time," and what should the bot do when that happens? Skip it? Use a coarser approximation that admits more error?

Multi-pool consistency. A large swap on one venue changes the optimal arbitrage cycle across many others, because most popular pairs trade on multiple DEXes simultaneously. Predictions for each pool need to be consistent with the predictions for every other pool that shares an asset. The naïve approach — predict each pool independently — produces inconsistent state snapshots. The principled approach — simulate the whole graph simultaneously — is computationally expensive.

The accuracy-vs-coverage trade-off. I can build a bot that only fires on swaps it is highly confident about. That bot will have a high success rate but will miss most opportunities. Or I can build a bot that fires on anything plausible. That bot catches more opportunities but pays more failed-bundle tips. Where the optimum sits is not a question I can answer in the abstract — it depends on the tip distribution, the average opportunity size, and the failure cost. I am still measuring.

The tip auction. Even a perfect prediction loses if the tip is outbid. Bundle selection runs as a tip-priority competition: the block engine ranks bundles by tip-per-compute-unit and selects the top ones. To win, my tip has to exceed every competing bot's tip on the same opportunity. To preserve margin, my tip cannot exceed the prediction's expected value. The intersection of those two constraints is narrow and dynamic.

Information asymmetry. Some participants see swaps earlier than others. Co-located searchers running validator-adjacent streaming pipelines have a structural latency advantage over anyone running on public endpoints. Closing that gap is not a software problem — it is a hardware and network-topology problem.

What This Looks Like From the Outside

From outside, the Solana MEV market looks like a healthy, mature ecosystem. A recent analysis notes that MEV-related rewards now contribute somewhere between 13% and 15% of total staking rewards by Q2 2025, and that the leading block-engine operator generated roughly $4.7 million in fees in Q3 2025 alone. A block-assembly marketplace (BAM) launched in July 2025 to support more sophisticated bundle sequencing. A real-time leader-scoring tool now ships data that helps bots adjust submission timing based on validator behavior. Total Solana MEV revenue for full-year 2025 ran around $720 million, the first year MEV revenue exceeded priority fees.

From the inside — by which I mean from a project that does not yet have a working predicted-state engine — the same ecosystem looks like a fortress. The market is highly concentrated. The infrastructure requirements are heavy. The margin per transaction is tiny. The cost of being wrong is real.

None of which means it is impossible. Predicted-state MEV is solvable for someone who can pair the math with the infrastructure with the engineering discipline to keep all three sides working together. It is just that "solvable" is doing a lot of work in that sentence.

Key Takeaways

• Predicted state MEV sits at the top of the arbitrage sophistication ladder. Reactive and backrun strategies are well-understood; predicting future pool state and bundling the arb with the causing swap is the difficult next step.
• The math is exact for constant-product pools, painful for concentrated liquidity. AMM mechanics are deterministic given current reserves and swap inputs, but CLMM tick boundaries break clean closed-form prediction.
• Five practical failure modes erase the theoretical guarantee. Concurrent transactions, tick crossings, multi-hop error compounding, prediction invalidation by competitors, and partial fills each produce reverted bundles with non-refundable tips.
• At $1.58 average profit per arb, prediction accuracy is the difference between profit and loss. Failed bundles drain the tip budget faster than successful bundles refill it.
• Infrastructure determines who wins. Co-location, streaming pipelines tuned for the hot path, and tip strategy matter more than algorithmic cleverness. The work is engineering as much as research.