Predicting Many Pools at Once: The Speculative State Layer

The Single Pool Was a Comfortable Lie

My bot tracks one pool well. It really does. The reserves are fresh, the predicted state lines up with what the chain confirms a moment later, and the math comes out clean. For a few days I let myself think the hard part was over and that I had finally built something that knew what was going on. I had not.

The humbling realization is that almost every arbitrage opportunity worth taking does not live inside a single pool. It lives in the gap between two or three pools that have drifted out of agreement with each other. A cyclic route buys on one venue, swaps through a second, and sells on a third — and the only way I see the opportunity is if I know the state of all three at the same moment. Tracking one pool cleanly was a starting line dressed up as a finish line. The real game is holding a coherent, synchronized picture of many pools at once.

That picture is what I have started calling the speculative state layer. It is the bot's internal model of the market — what it believes is true right now about every pool it watches — and it has to be maintained, refreshed, and partially thrown away every block. This is the part of the system that decides whether the bot is hunting real opportunities or chasing ghosts at scale.

What "Predicted State" Actually Means

The blockchain is always a little ahead of me. By the time a slot is confirmed and the new account state propagates through whatever pipeline I am listening on, the validator has already started building the next block. If I want to act inside the next slot, I cannot just react to what I see — I have to act on a forecast.

A technical implementation guide puts the concept in plain operational terms: "State prediction involves simulating sequences of pending transactions to determine future state at execution time — if ten swaps are pending on a pool before your arbitrage transaction, simulate all ten to predict the post-execution reserves." That sentence is the whole job in one line. I am not reading a pool. I am projecting a pool forward through whatever I think is about to happen to it, and using that projection as if it were ground truth — knowing full well it might not be.

The analogy I keep returning to is a TV broadcaster calling a play before the replay confirms it. A good color commentator does not wait for the official ruling to say what happened on the field. He sees the trajectory, he commits to a call, and he updates if the replay contradicts him. That is exactly what the speculative state layer does. It commits to a working hypothesis about each pool, acts on it, and stands ready to be wrong.

The stakes of being wrong are real. The same source notes that "inaccurate state prediction leads to failed transactions or missed profit; the competition's profit margin advantage often comes from superior simulation accuracy." A bad guess does not just cost an opportunity. It costs gas, it costs latency, and it teaches the wrong lesson to whatever logic is sitting downstream of the prediction.

Why Reading the Chain Is Not Enough

It is tempting to think that the answer is just to read the chain faster. Subscribe to better feeds, colocate next to a validator, drink directly from the firehose. None of that solves the underlying problem, because the underlying problem is not bandwidth. It is causality.

The ETH Zurich team behind the optimistic MEV paper gives the cleanest framing I have seen: "Optimistic MEV denotes MEV strategies in which the existence and parameters of a profitable opportunity are determined within the transaction itself through on-chain computation at execution time, rather than being verified off-chain prior to submission." In other words, the leading bots are not even waiting for confirmation in the traditional sense. They submit transactions that read pool state on-chain, decide whether the opportunity actually exists in that moment, and either execute or bail out. The decision happens inside the same transaction that does the work.

The paper makes this concrete: these transactions frequently begin with top-level STATICCALL operations directed at DEX liquidity pools to read real-time reserves and prices, after which the contract decides whether to execute a swap or terminate without trading based on those on-chain checks. The strategy is structured around the assumption that the off-chain prediction might be wrong, and the contract acts as the final judge.

That is a different mental model than "see opportunity, take opportunity." It is closer to a baseball scout's report: the scout says the kid has a major-league arm, but the team still has him throw a bullpen in front of the front office before signing the check. The scout's call is the prediction; the bullpen is the on-chain check. Both layers exist, and both layers can disagree.

Which brings me to the obvious question: if the on-chain layer is the final judge, why bother with a careful off-chain prediction at all? Because the off-chain layer decides whether to even submit the bullpen invitation. Without a credible prediction, the bot is firing transactions blind, paying gas to discover nothing. With a sharp prediction, the bot only spends gas on attempts that pass a real filter.

Borrowing a Decades-Old Idea From Databases

The model that makes the speculative state layer click for me is one I learned years before I touched a blockchain: multi-version concurrency control, or MVCC. It is the trick that lets a database serve many readers and writers at the same time without anyone stepping on anyone else's toes, and it is older than most of the engineers working on MEV today.

The core idea of MVCC is simple: when the database updates a piece of data, it does not overwrite the original — it creates a newer version alongside it, storing multiple versions of the same item. The PostgreSQL documentation describes the same behavior: each SQL statement sees a snapshot of the data as it was some time ago, regardless of the current state of the underlying data.

That is exactly the structure I want for pool state. The confirmed version of each pool is one record. The predicted version, derived from pending transactions or a short-horizon model, is another record sitting next to it. Readers — meaning the routing engine, the profit calculator, the safety checks — work off whichever version is appropriate. The confirmed version is the past; the predicted version is the working draft.

A retail inventory dock is the everyday version of this idea. The inventory system has two views of every SKU. One view is the official count, updated only when receiving signs off on a delivery. The other view is the working count, updated continuously as forklifts move pallets, with the understanding that the working count and the official count will reconcile when the shift closes. The store manager does not run the floor off the official count alone — that count is always behind. He runs it off the working count and accepts that some of those working numbers will be wrong by the end of the night.

There is a key difference between database MVCC and what I am building, and it matters. In a database, every version that exists is at least a committed candidate — the transaction that wrote it eventually either commits or aborts cleanly. In my prediction layer, a speculative version of a pool is a guess that might never be confirmed by the chain. It is closer to a sticky note than to a database row. When reality arrives, the sticky note is either validated and absorbed, or it is crumpled and thrown away. The layer has to be designed for that disposability from the start.

Consistency Across Many Pools at the Same Block

Once there are many pools and many versions, the next problem is consistency. If I am evaluating a three-leg cycle, I cannot mix a snapshot of Pool A from block 100 with a snapshot of Pool B from block 99 and a prediction of Pool C from somewhere in between. Combining those snapshots produces an answer that does not correspond to any moment in time. It is fiction.

A practitioner write-up by 7suyash7 on building a multi-protocol arbitrage bot names this invariant directly: "The ArbitrageEngine explicitly checks that all snapshots used for a given calculation were derived from the same Block Number." That sentence is doing more work than it looks like it is doing. It says the routing engine is forbidden from running math across snapshots that disagree on which moment they describe. The block number is the timestamp, and the timestamp has to match.

This is the same problem an NFL replay official faces when he is trying to figure out whether a receiver had control of the ball at the exact moment his second foot landed inbounds. You cannot answer that question by stringing together frames from different angles taken at different moments. You have to lock everything to a single frame and decide what was true in that frame. If the angles disagree about which moment they show, the call collapses.

The author also describes the design that makes consistency possible at all: "Monitor and update thousands of pools concurrently, from a specific block up to the latest one," with the market modeled as "a complex, tangled graph made up of thousands of pools." That graph is the predicted state layer in its most concrete form. Each pool is a node with a versioned snapshot. Each route through the graph is an evaluation that has to be tagged with a single block number, and any evaluation whose snapshots do not agree on that tag is rejected before it ever touches the cost model.

Under the hood, the implementation pattern that shows up over and over in the literature is a concurrent map guarded by a reader-writer lock — many readers can pull snapshots in parallel, a single writer publishes the next version atomically. That is the mechanical side of the same idea. The structural side is the invariant: never mix versions across pools.

State Has a Shelf Life

Predictions decay. That is not a flaw to engineer around; it is the nature of the layer. The chain moves forward, and any prediction that does not get validated by an on-chain observation within some window has to be treated as expired. A speculative state layer without expiry is just a junk drawer with a lock on it.

The academic work that makes this most painfully clear is the "Towards Event-Aware Forecasting in DeFi" paper, which assembled a dataset of 8,917,353 on-chain events across 359 liquidity pools spanning January 2024 through September 2025. The authors note that "liquidity events and interest rate updates occur atomically within the same block" and that "the rapid decay at k=1 suggests an extremely short information diffusion window." Whatever a model knew about a pool at one block is mostly useless by the next one.

The interval statistics in the same paper are sobering. For the Pendle subset, the mean gap between events on a pool is 48.5 blocks, the median is 16 blocks, and the long tail stretches to a maximum observed gap of 1,426 blocks. Translation: most of the time, a pool sees activity within a handful of blocks, but every once in a while it sits frozen for a long stretch. A naive cache-everything-for-thirty-seconds policy would either drop too many fresh updates or hold onto fossils. Neither is acceptable.

The paper also reports a real, measurable improvement from better time prediction — "an average of 56.41% reduction in time prediction error" across eight temporal point process models when their UWM loss function is applied. Even with that gain, the underlying point is that the layer has to admit it does not know exactly when the next event will hit a given pool, and structure its expiry policy around that uncertainty rather than wishing it away. Each predicted snapshot carries an implicit shelf life, and the layer has to know when to throw it out.

This is closer to a pharmacy than to a database. Every bottle on the shelf has an expiration date, and the pharmacist's job is not to argue with the date — it is to honor it. If the bottle is in date, it goes out the door. If it is past the date, it goes in the bin, even if it looks fine. The cost of dispensing an expired prediction is higher than the cost of throwing it away.

What Tracking More Pools Actually Buys

Here is where I have to be honest with myself. A bigger state layer means more routes evaluated, more candidate arbitrages surfaced, and more opportunities visible. It does not necessarily mean more money in the wallet. The economics of this game are getting tighter, not looser, and a wider net does not change the math at the bottom.

The ETH Zurich paper reports the success rates of speculative submissions on three different chains in Q1 2025. On Base, the actual arbitrage success rate is 0.58 percent of cyclic arbitrage attempts (about 6.3 percent of cyclic arbitrage transactions succeed in landing some kind of arbitrage). On Optimism, the comparable figure is 1.49 percent (12 percent of cyclic arbitrage transactions). On Arbitrum, where blockspace is more expensive, around 77 percent of non-reverted attempts succeed. The shape of the picture is clear: on the chains where blockspace is cheap, bots can afford to spray and pray; on the chains where it is expensive, they have to be selective. A wider state layer pushes a bot's behavior toward the spray-and-pray end of the spectrum, which is fine if the chain rewards it and brutal if it does not.

Gas consumption tells the same story from the other side. On Base, cyclic arbitrage accounts for 51 percent of on-chain gas; on Optimism, 55 percent; on Arbitrum, just 7 percent. The cheap chains are saturated with attempts, most of which fail. The expensive chain forces discipline. None of that is a function of how many pools I track. It is a function of where I am playing.

The other study that keeps me grounded is the dynamic-weight AMM paper, which followed the same pool over six months from July 2025 to January 2026 and found that competition compressed the per-trade extraction from $2.58 to $0.28 and the total six-month extraction from $51.55 to $22.00, even as trade frequency went from 20 trades in two hours to 78. Four times as many trades, less than half the dollars. Watching that pool through a wider state layer would not have changed the trajectory. The opportunity got harder to monetize even as it got easier to detect.

A 2026 infrastructure guide for Solana trading bots adds a final, painful nuance specific to this chain: simulation "catches routes that look profitable off-chain but fail on-chain due to pool state changes between detection and execution." Even a perfect prediction layer cannot promise that the route will still be there when the transaction lands. The gap between predicted profit and confirmed profit is a structural feature of the environment, not a bug I can engineer out.

An MEV report I have been reading on Solana specifically tells a story that captures both halves of this. A searcher "purchases 2.11513 SOL with 45 USDC on Orca and then sells 2.115 SOL for 45.0045 USDC on Phoenix" because, in that moment, "the Orca AMM continues to quote based on a stale price, creating an arbitrage opportunity." The opportunity is real, the dollars are real, and a wider state layer is exactly what makes it visible across a venue boundary. But the dollars in that example are small, and the searcher who landed it had to be the first to see it and the first to act. Detection is necessary; it is not sufficient.

The Honest View of Where This Leaves Me

The speculative state layer is, on paper, an exciting piece of architecture. In practice it is an obligation. It commits me to maintaining a consistent forecast of many pools at once, throwing away stale predictions on a tight schedule, and absorbing on-chain reality as the final judge. The reward for doing all of that well is the ability to see opportunities I would otherwise miss. It is not, by itself, the ability to profit from them.

What the layer changes is the surface area of the problem. Without it, I was solving a single-pool problem and pretending it was the whole game. With it, I am solving the actual game, which is a graph problem with versioned nodes, a decay function, and an adversary on the other side who is solving the same problem and probably has a head start. The layer is not a moat. It is the price of admission to a market that has already been running without me.

That is a healthier framing than the one I had a month ago. A month ago I would have said the goal was to be right about pool state. Now I think the goal is to be honestly uncertain about pool state in a structured way — to know which version of which pool I am working from, to know how old that version is, to know how to replace it, and to know when to throw it out. The bot does not need an answer it can trust forever. It needs a working draft it can update without lying to itself about what it knows.

When the chain confirms one of my predictions, the speculative layer absorbs the confirmation and moves on. When the chain contradicts a prediction, the layer accepts the contradiction and discards the bad version. When too much time passes with no observation, the layer expires the prediction and waits for new data. None of those operations are glamorous. All of them have to happen, on every pool, every block, for as long as the bot is alive.

It feels less like a victory and more like the start of a longer conversation with the chain. The bot used to talk past it. Now it is starting to listen.

Key Takeaways

• A single-pool view is a comfortable illusion. Most opportunities sit between pools, which means the bot needs a synchronized view of many pools at once.
• Predicted state is a working hypothesis, not a fact. The job is to project pools forward under pending activity and stand ready to be wrong.
• The MVCC pattern from databases — keep multiple versions of the same record and let readers see a coherent snapshot — maps cleanly onto pool state, with one twist: predicted versions can be discarded if reality contradicts them.
• Consistency across pools requires a strict invariant: every snapshot used in a calculation must share the same block tag. Mixing block numbers across pools produces fiction, not analysis.
• Predictions decay fast. The academic literature shows a steep information-diffusion drop within a single block, and any prediction layer needs an explicit expiry policy rather than an implicit one.
• More pools tracked does not equal more money earned. Success rates on cheap-blockspace chains are low single digits, and competition has compressed per-trade extraction even as trade volume rises. Detection is necessary; profitability is a separate fight.