A Field Guide to Agentic MEV_

We just speed-ran through the presentations. If you want the longer versions, we recorded them, and there's an elaborated version of these slides. The goal of this talk is to map what's going on with agents and MEV — not just how we can use agents today to play the MEV games, but the potential future MEV-type behaviours we'll see because agents exist.

I broke it into three tracks. The first is what we can use today. The second is what we should be aware of when designing agent networks. The third is what MEV could arise from AI-based activity itself — decentralised training, prediction markets, and so on.

If you look at the literature, there's surprisingly little work using AI for MEV-type activity. My hypothesis is that it's because there's not much valuable data in public. A lot of the valuable flow — the bundles — lives in proprietary datasetsOrder flow sent directly to builders rather than through the public mempool. Builders can see it; researchers mostly cannot.. We at Flashbots can play with it, but not everyone has access.

“The hypothesis that I have is that it’s because there’s not so much valuable data that’s available in the public.”

So there are two things to think about in this direction. First, confirm you can actually do something with it.

About a year and a half ago we started looking at parallelising the builder. In short, block building happens in two phases. First, identify transactions that conflictTwo transactions conflict if they touch the same state, so their relative order changes the outcome. Transactions that don't conflict can be ordered independently. with one another and group them. Then resolve the ordering within each group separately. You don't parallelise execution; you parallelise conflict resolution.

“You don’t parallelize every execution, you just parallelize the resolution of the conflict.”

I remember trying to explain this to someone here at two a.m. in a hookah lounge over extremely loud music, and I think I failed — but they kept asking the right question, which I'd forgotten to ask myself:[10] what is the objective function? The crude form is: maximise the MEV extracted for the block. And you can pursue that in many ways.

What you're doing is swapping out each of the algorithms in these boxes. The ones in production today are simple. If a group is small, try every possible order. Some do greedy ordering. Some pack the block knapsack-style and do their best in the time allocated.

Once you have an objective function you can point any optimizer at it and say: build me the best block you can find. You can do that with a genetic algorithmKeep a population of candidate orderings, score each on historical blocks, keep the best, mutate and recombine, repeat. Island-model variants run several populations and occasionally migrate winners between them., and it works — we have evidence. It tends to be slow, so it's good for finding how much theoretical MEV a block contains, but not something to put in production where you need a block in under two seconds. Or you can use reinforcement learning. We're fortunate to be in a perfect-simulator setting: the EVM on a fork lets you simulate exactly what would happen. So you can throw AlphaZero-style MCTSMonte Carlo tree search: explore possible sequences of moves, favouring branches that have scored well. AlphaZero pairs it with a learned policy to guide the search. at ordering and, in theory, learn a better placement strategy. We haven't confirmed it yet, but there's a reason it should work.

I'm going to skip through autoresearch — everyone here knows what it is.[2]

The interesting thing when you extend the optimizer to an autoresearch setting is that I think of it as removing or adding degrees of freedom. In the GA or the RL, everything is constrained: you've got a function. In autoresearch there are no guardrails — the agent can rewrite the whole rbuilder.

Intuitively, "make me the best block" isn't good enough on its own. We've seen in various autoresearch scenarios that the agent finds shortcuts. Give it one instruction and it will rediscover sandwiching, or front-running, and all the things you don't want on a public blockchain. So you need to inject constraints and guide the optimizer.

“The AI agent will try to find shortcuts in the problem, right? So we’ll probably rediscover sandwiching, or we’ll rediscover front-running.”

How? You can try to encode multiple objectives inside the optimizer, which isn't what people usually do with autoresearch — they latch onto a single scalar. Or you can think of it as an AI safety problem: observe what the policy is doing in latent space and try to identify and isolate harmful regions. That's a direction, not a mitigation that works yet. But it's a nice approach, and it sets the stage for what we'll be doing with the demo agents by the end of the workshop.

exchange with the host, mid-talk

Once you have autoresearch-type loops, you've seen them deployed on the web. You can run one on your laptop, but the real goal is a huge swarm of agents across the internet collaborating toward a goal. There are two assumptions you could make. Either all the agents are aligned and harmonious and willing to contribute — that can work, and it's what some people do.

Look at Ensue's autoresearch@homeA SETI@home-style fork of Karpathy's autoresearch: agents on different GPUs claim experiments against a shared store, avoid duplicating work, and jointly drive down a training loss.: people are willing to contribute to the network, like SETI@home and Folding@home back in the day. Or you ask the harder question: can you harness agents with misaligned incentives? How do you make sure they contribute to a shared goal when they're competing for a reward?

The textbook answer would merge everyone's work — federated learning, average the updates. Internet swarms don't do that. Nothing is merged. They use a claiming protocol: soft-lock a task, deduplicate by semantic similarity, expire stale claims, and update the global best by read-compare-write where only a strictly better result wins.

Now imagine those agents aren't using anything subtle. They grab a task and race to improve the current best. What happens is that you can only compete on hardware and latency. And we've seen exactly that in MEV markets: it became a latency raceA contest where whoever acts first wins. Participants invest in speed rather than quality, and the best-capitalised players capture the value. where the rich get richer — the most sophisticated actors captured the value because they could set up the hardware and the fast channels to the coordinator that verifies updates. We don't want that. We're here to build a new network where everyone can participate early without the same level of sophistication.

What we learned from the MEV playbook is that to avoid latency races, you use auctions. Not a top-of-block auction exactly, but the same idea: agents bid, maybe, on their confidence in their contribution. What would it mean to not only contribute but to express how good you think your contribution is by placing a bid? That's an open question. And who runs the swarm's auction?

“If you want to avoid latency races, you can try to use auctions to make these agents compete.”

Another thing from the MEV playbook: front-running by observing the behaviour of other agents. That's been central to our week at SBC. We demoed a new anonymous-broadcast network this week — Anymone[3] — anyone can participate, it's a chat, you can send a message without knowing who's in the network. More than that, you want these primitives to stop your metadata leaking.

I should not be able to identify who you are and where you're talking from and use that to slow you down. If I know you're very good and close to solving a task, and I want to delay you so my contribution lands first, I should not be able to do that from your IP or the time of day you send. This is something we've always said is important for MEV on-chain, and it's a primitive we want to reuse for autoresearch swarms. Phil is probably the best person in the room to talk about what throughput we can expect and how it scales to these applications.

One I find particularly interesting — the evolution of what I worked on previously — is decentralised training. Every hype cycle tries to pair AI and crypto, and most of it is nonsense. But for maybe the first time, we've seen a valuable contribution emerge from the crypto community to the AI community. The problem: how do you train a large language model across the internet? Training is optimised for GPUs on proprietary links in a single data centre. All the optimiser tricks assume that. So teams like Pluralis and Nous[4] designed internet-first training stacks that compress communication and reduce how often nodes need to sync. And it turns out to be relevant to the big labs too, because they've hit the scale where training doesn't fit in one data centre anymore.

Anyone here a Bittensor miner? Anyone doing decentralised training? A few hesitant hands. Anyone heard of it as a scam? Unfortunately, when you work on the crypto side, a lot of the examples get dismissed for obvious reasons — there's a token. But for market-structure researchers these are interesting phenomena.

Simplified: there's a subnet — subnet 3, Templar — that does exactly what I described, training a model across the internet.[5] You have miners who stake to join, and validators who assess the contributions. The catch is that validators are paid for agreeing with consensus. Stick to that objective and you've incentivised validators to say what everyone else says, even at the expense of not doing the computation — just copy your neighbour's scores. One mitigation people are trying: commit to your score before anyone reveals theirs.

The issue is that commit-reveal goes back to a latency race. If I'm first to learn the new state the network agreed on, I have an advantage over every other node instantly. So commit-reveal solves one problem and doesn't solve the other. In decentralised training we should expect a latency race to arise because of how the network is coordinated. Not backed by data — a thought exercise. If you want to observe it in the real world today, go look.

Even more interesting: under dynamic TAOBittensor's 2025 change where each subnet has its own token traded against TAO in an AMM, and the network's emission is split across subnets in proportion to their token prices., these subnets also operate as AMMs that decide the emissions of the wider network. If you think about how the network rewards progress, you can pump your subnet to fake activity, earn higher emissions, and by doing so gain control over the bigger network. That's been seen. And we've seen it in MEV as well — people study cross-domain MEV. It comes down to a game of sophisticated players who can allocate hardware, manpower, and capital to capture the opportunity. In decentralised training we can expect the same dynamics unless we do something special. A new type of MEV, but very much resembling what we've seen before.

Another one to be aware of — there were several interesting presentations on it at SBC.[12] In prediction markets the issue is how you resolve the market. Yes, we've seen evidence of markets being poorly structured, so there's imperfection and there are arbitrage opportunities. But what matters to me is that the deeper problem is that nobody agrees how to resolve them. It boils down to an oracle problemGetting a trustworthy answer about the real world onto a system that can't observe it. Who decides what happened, and what stops them lying?, and we've seen that in MEV before. The clear direction is more robust resolution mechanisms that don't rely on a single entity.

To make it concrete: there's another Bittensor subnet, Numinous, doing very cool stuff — incentivising agents to forecast the outcome of prediction markets.[6] Think of it as a decentralised oracle that resolves before the market does, either to guide you as a trader or as one input into resolution. But how do you grade the agents' submissions? They still have the miner/validator split, and the validators need to see the predictions in the clear to rank them. Which means validators get access to the miners' strategy — the last thing any researcher wants to reveal, because it's the most valuable thing they have. So even though the idea is interesting, it's not sustainable given the behaviours we've seen in MEV. This is where privacy comes in: validators in TEEs, or programmable constraints.

Last point. An analogy — not verified, something to explore today. The AI token market is starting to resemble DeFi. Instead of sending a swap, you send an intent and ask solvers for the best quote. In AI you do the same: send a prompt to a router and ask for the best model at the best price. What's interesting is who captures the value. If you're a good router, your incentive is eventually to stop routing to the other providers and route to your own model, to capture a bigger margin. I'm told that happens. Dmarz, you looked into this — he has a whole talk on it.

So: an evolution. AI for MEV, as Tina said, is the unsophisticated scenario — we're developing new strategies, and the unlock is data access, which you can also think of as building gyms for these environments. The second track applies the MEV playbook: designing mechanisms for the behaviours we see. The third is observing what happens in these networks today — how decentralised training coordinates, how prediction markets resolve — because that's where the new forms come from.

I'm not sure there's much to make here yet, but there are a bunch of papers to be written in these directions. There's a more elaborate version of these slides, and I'll leave you with some prompts for research topics you can set agents against.

audience questions reconstructed — see note below

Questions are reconstructed; answers are near-verbatim.[8]

shown but not discussed

Jonathan skips this slide on stage — "I'm going to skip through autoresearch, everyone here knows what it is." It's the loop the rest of the talk assumes, so it's kept here.

Every dotted-underline term above, in full, with sources.