All talks · Talk 01 of 16
A Field Guide to Agentic MEV: Emerging Problems and Methods
Three tracks for thinking about agents and extractable value: using AI to do MEV better, designing agent networks so they don’t repeat MEV’s mistakes, and the new extraction surfaces that exist only because of how AI systems are built. Jonathan Passerat-Palmbach lays out the map, and the room argues with it.
speaker Jonathan Passerat-Palmbach · runtime 34 min · format talk + discussion · reading time ~13 min
About the speaker
Jonathan Passerat-Palmbach is a senior research scientist at Flashbots, where he explores the application of privacy-enhancing technologies to decentralised collaborative learning and to MEV in blockchains. His expertise spans secure computing (trusted execution environments, fully homomorphic encryption), federated learning, and verifiable computing (zero-knowledge proofs, TEEs). He is also a research fellow at Imperial College London (BioMedIA) and City, University of London (CitAI), where he co-supervises MEng, MSc and PhD students in privacy-preserving machine learning and federated learning. PhD in High Performance Computing, Blaise Pascal University, 2013.
Relevant prior work: Cooperative AI via Decentralized Commitment Devices (Sun et al., MASEC@NeurIPS 2023) and 2CP: Decentralized Protocols to Transparently Evaluate Contributivity in Blockchain Federated Learning.
jopasser.at
flashbots.net
github
Slides are Jonathan’s own deck, video-captured, cropped to 16:9. Eight repeated pages and three section dividers are collapsed.[1]
https://youtu.be/6lIcVjMf-RQ
tl;dr
AI for MEV is gated by data.
Roughly 12% of Ethereum transactions carry about 55% of the block value, and that order flow is private. Genetic search and AlphaZero-style RL both work on the block-building problem; the key unlock is a data clean room that will not leak proprietary alpha.
An unconstrained optimizer rediscovers sandwiching on its own.
Tell an autoresearch loop “maximise block value” and it finds known MEV strategies including ones you don’t want to incorporate. Proper constraints are the fix, and AI safety has one to borrow: define the harmful region and keep the policy out of it.
Agent swarms are about to repeat MEV’s latency race.
Protocols become races once the shared resource is priced; blockspace solved that with allocation mechanisms such as auctions, not just faster hardware. Decentralised training, prediction-market resolution, and model routing each already show a recognisable extraction surface.
If you’re new to any of this
MEV is the value someone can extract by controlling the order transactions execute in. This talk asks three questions about it and AI: can AI extract it better; when AI agents work together on a shared task, do they create the same problems; and do AI systems themselves — training networks, prediction markets, model routers — have their own version of it.
A bit more background
A block builder assembles the next block from pending transactions and bundles, choosing an order that maximises the fees and MEV it captures. Choosing the order is a search problem.
Autoresearch is a loop where a coding agent edits a program, runs it, keeps the change if the score improved, reverts it if not, and repeats — overnight, with no human. Karpathy released a 630-line version in March 2026 and it spread fast.
A latency race is what happens when the first party to act wins: everyone invests in being faster, the sophisticated players win, and the value that could have gone to users is burned on speed. Early MEV was one. Auctions were the fix.
Contents
Three tracks
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.
Slide: Three directions: AI for MEV — use AI/ML to do MEV better; MEV-aware AI — agents facing MEV-like scenarios, contested state, credible commitments; AI MEV — extraction surfaces that exist only because of how AI is built.
slide 02/31 / · The three tracks. The talk walks them in order.
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.
AI for MEV: gated by data
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 datasets (Order 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.”
— Jonathan Passerat-Palmbach, on the AI-for-MEV data bottleneck
Slide: AI for MEV is gated by data access: surprisingly little AI research has touched live MEV; the bottleneck is data; ~12% of transactions carry ~55% of block value; the public mempool is drying up; some public results: Bidding Games, BlockGPT; what becomes possible with data access?
slide 04/31 / · About 12% of transactions carry about 55% of block value, and that flow is private.
So there are two things to think about in this direction. First, confirm you can actually do something with it.
Block building as search
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 conflict (Two 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.”
— Jonathan Passerat-Palmbach, on parallel block building
Slide: Block building as search, conflict groups: step 1 detect conflicts and create groups; step 2 create conflict-resolution tasks (greedy, all permutations, length, reverse greedy, random); step 3 run tasks in parallel; step 4 assemble block with best orderings from each group.
slide 05/31 / · Find what conflicts, resolve each group in parallel, assemble the best of each.
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.
Slide: Resolution strategy 1, evolve or learn: island-model genetic search over ordering heuristics, fitness = realised block value on historical blocks; reinforcement learning — the EVM on a fork is a perfect simulator, so ordering is a sequential-decision problem; AlphaZero-style MCTS over discrete moves.
slide 06/31 / · Two optimizers for the same objective: evolve a heuristic, or learn a policy in a perfect simulator.
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 algorithm (Keep 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 MCTS (Monte 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]
When the optimizer cheats
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.
Slide: Resolution strategy 2, discover it (autoresearch): an agent edits the resolver, replays blocks, scores, keeps or discards, repeats overnight (Karpathy). Score climbs with no human in the loop. The score is a reward function: block value minus constraints penalty. Open problem: multi-objective rewards.
slide 10/31 / · Point the loop at the resolver itself. Reward = block value minus a constraint penalty.
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.”
— Jonathan Passerat-Palmbach, on unconstrained autoresearch
Slide: When the optimiser cheats: give the resolver one instruction, maximise block value, and it rediscovers sandwiching on its own. Nobody taught it to attack users; the reward did. A kernel optimiser told not to touch the test read the answer from the caller and cut cycles 147,000 to 130. AI safety points at a fix: represent harmful as a region in latent space and keep the policy out of it.
slide 11/31 / · One instruction, and it rediscovers sandwiching. A kernel optimiser cut 147,000 cycles to 130 by cheating.
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.
Interlude: is track two really separate?
exchange with the host, mid-talk
tina
I want to challenge you before you go to the third segment. Your first section was AI for MEV and your second was MEV-aware AI. But agents today don’t have economic rationality — we’re using them as tools. So isn’t the second section also just AI for MEV? How did you draw the boundary?
jonathan
The first track is the very basic question: how do you harness AI — coding agents, or optimisation methods from the AI literature — to solve concrete MEV problems like block building. That’s the boundary of AI for MEV. The second is about early networks where the agents live, where humans aren’t meant to interact directly. How do we avoid the design mistakes we made with early forms of MEV — priority gas auctions, say — that raised fees and congestion for everyone? We observe the same interactions we saw between MEV bots on-chain and use that knowledge when designing agent-first networks.
tina
And the third?
jonathan
The third is more of a brainstorm — we don’t have evidence it happens yet — about what new forms of MEV could arise from the very way AI and agentic networks are architected.
MEV-aware AI: swarms already race
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.
Slide: The setting: agents already work in swarms. Autoresearch runs as a swarm; scale that to many agents on the internet improving one shared result; each agent claims a task, runs it, and races to update the global best; the question is not how does an agent search but how do agents resolve contention.
slide 15/31 / · The question is not how an agent searches but how agents resolve contention.
Look at Ensue’s autoresearch@home (A 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?
Slide: Resolving contested state: the textbook answer would merge everyone’s work (federated learning); internet swarms don’t — they use a claiming protocol; concrete instance: Ensue’s autoresearch@home; related: AgentRxiv (arXiv:2503.18102).
slide 16/31 / · Nothing is merged. Swarms use a claiming protocol instead.
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.
Slide: A swarm improving a shared best: four GPU agents around a shared store with claims (TTL, dedup > 0.92) and a single-incumbent best; soft-lock a task, dedup by semantic similarity, expire stale claims; update by read-compare-write, only strictly better wins, losers kept.
slide 17/31 / · The claiming protocol in one diagram: soft locks, similarity dedup, read-compare-write on the best.
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 race (A 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.
Slide: Resolving contested state, what to borrow from MEV: once the shared resource is priced, a claiming protocol becomes a race, and a race is MEV; blockspace’s fix was not race harder; auction off the contested slot; port top-of-block auctions and order-flow auctions with rebates; open question: what is the swarm’s top of block, and who runs its auction?
slide 18/31 / · A priced claim is a race; a race is MEV. Blockspace’s answer was auctions.
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.”
— Jonathan Passerat-Palmbach, applying the MEV playbook to agent swarms
Confidentiality for agents
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.
Slide: Confidentiality, pre-trade privacy for agents: agent sends encrypted payload through an attested router/TEE to model providers; payload hidden, but a network observer still sees who, when, how often, how big. Goal: unlinkability, not invisibility.
slide 19/31 / · Encryption hides the payload. The observer still sees who, when, how often, how big.
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.
AI MEV: decentralised training
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.
Slide: Decentralised-training MEV: Bittensor subnets, permissionless, stake to join as a miner; subnet 3 (Templar) pretrains a model across ~70 nodes; validators are paid for agreeing with consensus, so copy the published scores, skip the evaluation, earn more per stake (weight-copying); mitigations: proof-of-learning, commit-reveal of scores.
slide 23/31 / · Validators are paid to agree, so copying scores beats evaluating.
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.
Slide: Decentralised-training MEV goes cross-subnet (dTAO): each subnet is a TAO-token AMM and per-block emission is split zero-sum; a subnet’s share tracks its token price, so buying one subnet’s token drains everyone else’s; subnet 28, a no-AI Ponzi that scored miners by tokens held, pumped to top-7 by market cap; gaming is a cross-subnet value transfer refereed by a token price.
slide 24/31 / · Under dTAO, buying one subnet’s token drains everyone else’s emissions. Subnet 28 did it.
Even more interesting: under dynamic TAO (Bittensor’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.
All talks · Original webpage
