PaperlayerView exact revision on arXiv

Source-linked AI summary

EVAGE: Autonomous MEV Generation and Adaptation via Multi-Agent Harness

Yan Wen, Zichun Cai, Iliya Mirzaei, Xiaohua Cai, Mohammad Javad Amiri, Haoxian Chen, Chenyuan Wu

arXiv:2609.27424v1cs.CR

TL;DR

MEV strategy development and implementation depend on manual expertise and face adaptation challenges across protocols and chains. EVAGE uses an autonomous multi-agent harness to generate and adapt MEV bots offline. It reports novel variants with increased revenue and validates effectiveness across three blockchains.

  • Problem

    MEV capture is dominated by experienced teams, while manual strategy development and implementation do not scale easily across heterogeneous protocols and chains.

    Source: §1 · pp. 1–2

  • Method

    EVAGE coordinates specialized agents that generate and refine MEV bot code offline, with closed-loop diagnostics and validator-derived Proofs of Concept.

    Source: §1 · p. 2, §4.2 · pp. 5–6

  • Results

    Five discovered variants increase revenue by 1.02× to 15.97× relative to their corresponding baseline strategies, and EVAGE is evaluated across three blockchains.

    Source: §1 · pp. 2–3, §8 · p. 14

  • Takeaways & Limitations

    Experiments on over 1.5 million historical blocks validate EVAGE’s effectiveness in variant discovery and cross-protocol and cross-chain adaptation.

    Source: §8 · p. 14

    On CLMMs, the agents’ ternary search can fail to find the global optimum because the tick-partitioned profit surface need not be single-peaked.

    Source: §5.2 · p. 9

Abstract

from arXiv · show

Maximal Extractable Value (MEV) has evolved into a major economic force in blockchain ecosystems, yet its capture is dominated by experienced teams, and both strategy design and implementation rely on manual expert work that scales poorly across heterogeneous protocols and chains. We present EVAGE, the first fully autonomous multi-agent framework for end-to-end MEV strategy generation and adaptation. Equipped with three specialized operation modes, it automatically discovers novel MEV variants, adapts execution logic across disparate protocols, and ports strategies between chains, including Layer-1 and Layer-2 networks. To avoid inference latency on the critical MEV execution path, EVAGE generates and refines MEV bot code offline rather than making real-time decisions directly. Under the coordination of an orchestrator agent, three specialized subagents collectively implement and repair the full MEV bot workflow via closed-loop diagnostics, eliminating human intervention while producing validated and deterministic Proof-of-Concept implementations. We evaluate EVAGE on over 1.5M blocks from each of Ethereum, Base, and BNB Smart Chain (BSC). On Ethereum, EVAGE uncovers five novel MEV strategy variants, yielding a profit increase of 1.02$\times$ to 15.97$\times$. It also successfully adapts 11 MEV strategies from CPMM to both CLMM and Balancer V2 and ports strategies from Ethereum to Base and BSC, all with less than 60 dollars in LLM token costs.

1 Introduction

EVAGE addresses the expertise and manual-engineering burdens of MEV strategy development with an autonomous multi-agent system. It discovers strategy variants and adapts implementations across protocols and chains, with experiments reporting profitable variants and planner-code reuse.

1 Introduction

  • MEV extraction favors experienced institutional teams, while protocol-specific mathematics and interfaces and cross-chain migration make manual strategy development difficult to scale.The introduction links concentrated extraction to ordinary users’ structural disadvantage and identifies protocol adaptation and delayed chain deployment as practical challenges.Source: §1 · pp. 1–2
  • EVAGE generates and refines bot code offline, using specialized workflow stages and validator simulations to avoid real-time inference and intercept hallucinated logic.The PoC is derived from the validator’s concrete execution trace rather than produced directly by an agent.Source: §1 · p. 2
  • The proposed harness assigns Collector, Builder, and Validator roles and uses closed-loop diagnostics to generate MEV bot implementations automatically.The paper describes EVAGE as the first agentic system to autonomously generate MEV bots without human intervention.Source: §1 · p. 2
  • Adapted implementations achieve 18.13% average structural code similarity, concentrated primarily in the planner.The reported code-reuse analysis describes the planner as consistently reused during cross-protocol adaptation.Source: §1 · pp. 2–3
  • Five discovered MEV strategy variants increase revenue by 1.02× to 15.97× relative to their corresponding baseline strategies.The evaluation also identifies five novel variants for community reference.Source: §1 · p. 3
  • EVAGE is evaluated on over 1.5 million historical blocks, covering 11 Ethereum strategies, six BSC strategies, and two Base strategies.The experiments report profitable execution, practical token costs, low planning latency, and harness effectiveness.Source: §1 · p. 3

2 Background

The background introduces automated market makers and transaction-ordering strategies that form EVAGE’s setting. It contrasts CPMM reserve-based pricing with CLMM liquidity organized across discrete ticks.

2 Background

  • A CPMM swap of q units of X, with fee f and reserves (x,y), changes the reserves to (x + (1 − f)q,y−∆y(q)).The passage presents this as the reserve update under the CPMM pricing model.Source: §2 · p. 3
  • CLMMs concentrate liquidity within discrete price-range ticks, so a swap crossing a tick boundary requires an active-liquidity adjustment.The background states that the raw token price at tick t is proportional to 1.0001^t.Source: §2 · p. 3
  • A sandwich bot can front-run a pending swap and back-run it, while arbitrage exploits price discrepancies across liquidity pools or exchanges.The sandwich example also describes submitting an ordered transaction bundle to a block builder.Source: §2 · pp. 3–4

3 EVAGE Functionality Overview

EVAGE divides MEV-bot adaptation into variant exploration, protocol migration, and chain adaptation. Its modes modify workflow stages to preserve strategy logic while accommodating new protocols and execution environments.

3 EVAGE Functionality Overview

  • Variant Explorer Mode synthesizes and evaluates novel MEV strategies, commonly discovering effective variants through parameter optimization.This mode primarily modifies the planner to develop new MEV logic.Source: §3 · p. 4
  • Figure 1 maps variant exploration mainly to the planner, protocol adaptation to the collector, and cross-chain adaptation to the collector and validator.The overview describes these as complementary modes operating on stages of the data-collector, planner, and validator workflow.Source: Figure 1 · p. 4, §3 · p. 4
  • Customized protocols and heterogeneous chains make manual migration difficult because their liquidity models, data structures, fee mechanisms, and transaction processing differ.For CLMMs, swaps may traverse multiple ticks with different liquidity levels; Base has separate L2 execution and L1 data-availability fees.Source: §3 · pp. 4–5
  • Protocol migration adapts pool-state representation, victim constraints, and calldata across protocols while preserving strategy logic and reusing core planner code.The evaluation covers 11 strategies across two protocols, including tick-coverage frontiers for incomplete state snapshots and weighted-math modules for Balancer V2 routing.Source: §3 · p. 4
  • Cross-chain adaptation preserves core trading logic while adjusting market-data access, exchange interactions, network-fee calculations, and transaction construction for the target chain.The mode is evaluated on Base and BSC, and repeated adaptations to one chain incur only marginal additional cost through code reuse.Source: §3 · p. 5

4 EVAGE System Design

EVAGE separates its agent harness from a deterministic, three-stage MEV bot, keeping LLM inference off the execution path. An orchestrator coordinates specialized subagents that iteratively adapt or generate bot code and validate it through execution.

4 EVAGE System Design

  • The agent harness repairs the collector, planner, and validator code while the MEV bot executes deterministically without LLM inference on its critical path.The bot provides concrete feedback to the harness during iterative repair.Source: §4 · p. 5

4.1 MEV Bot Decomposition

  • The collector gathers transactions and liquidity states, the planner computes and parameterizes attack plans, and the validator simulates plans and diagnoses failures.The validator uses a deterministic Anvil caller on a forked EVM-compatible chain.Source: §4.1 · p. 5

4.2 Hierarchical Multi-Agent Harness

  • Protocol adaptation starts with the collector, while variant exploration starts with the builder; cross-chain adaptation also maintains independent RPC connections for each chain.Protocol adaptation preserves a strategy’s core economic intent and control flow while addressing protocol-specific differences.Source: §4.2 · pp. 5–6
  • The orchestrator routes protocol-adaptation errors to the responsible subagent and repeats validation until the bot has at least one confirmed profitable historical case.The validator evaluates profitability and captures execution traces; the builder refines plans that fail validation.Source: §4.2 · pp. 5–6
  • Each run produces agent-generated code, an experiment report, and a PoC derived from the validator’s execution trace to verify a net-positive attack on a forked block state.Agents cannot directly produce the PoC or alter Anvil execution results.Source: §4.2 · p. 6

4.3 Implementation

  • The Ethereum implementation covers 33 strategy-protocol lanes across 11 MEV strategies, with additional chain-specific implementations for Base and BNB Smart Chain.The pipeline extracts MEV candidates, derives attack parameters, and validates plans on isolated Anvil forks.Source: §4.3 · p. 7

5 Experimental Evaluation

EVAGE is evaluated on strategy exploration, cross-protocol and cross-chain adaptation, planning latency, and a multi-agent ablation. The experiments report profitable adaptations and new variants, while identifying optimization and execution boundaries.

5.1 RQ1: Strategy Reproduction and Variant Exploration

  • 1.02× to 15.97× revenue increases over corresponding baselines span five generated MEV variants across protocols.The variants broaden searches over attacker inputs or liquidity sizes, often combining HFT sizing with another strategy’s execution structure.Source: §5.1 · p. 8

5.2 RQ2: Cross-Protocol Adaptation

  • EVAGE produces executable and profitable adaptations across both target AMMs; Balancer consistently yields the fewest candidates and lowest revenue, due to substantially lower trading activity on it.For SBA on CLMMs, planning and validator stages yield 1.69 million simulations, of which only 10.9% were profitable: 75.3% failed due to pool fees, 4.1% were unprofitable by gas costs, and 9.7% were excluded for lack of daily normalized prices for certain tokens.Source: §5.2 · p. 9
  • HFT and SBA-HFT achieved the highest total revenue on CLMMs, but unbounded attacker capital removes a major practical bottleneck for JIT strategies.JIT-HFT’s 5.41× revenue gain over JIT on CPMM did not carry over to CLMM, where JIT’s heuristic sizing already captured nearly all available revenue.Source: §5.2 · p. 9
  • BUR-HFT’s 21.56× revenue increase over BUR on CPMM yielded negligible CLMM gains, while its ternary search can miss optima on CLMM’s discrete liquidity surface.Across protocol adaptations, structural similarity reached 17.52% and 18.74%, and the planner was consistently reused; exact text reuse averaged 0.66% for CLMM and 0.86% for Balancer V2.Source: §5.2 · pp. 9–10

5.3 RQ3: Cross-Chain Adaptation

  • On Base, SBA-HFT earned 1,682.92 ETH versus 16.13 ETH for SBA; migrated BSC strategies also produced profitable cases, including 5,307.04 BNB for HFT.Absolute revenue is not directly comparable across chains or strategy opportunity sets.Source: §5.3 · p. 10, Table 2 · p. 10
  • In adapting six reference strategies to CPMM on BSC, SBA consumed the most total tokens (83M), while LR had the longest runtime (2.4h) and highest uncached-input cost.BUR migration required fewer tokens and less execution time, suggesting that marginal adaptation costs decrease as shared chain infrastructure accumulates.Source: §5.3 · p. 11

5.4 RQ4: Planning Latency

  • Most Ethereum CPMM and all BSC strategies completed planning within 10 ms at P90, while SBA-HFT on CLMM required 658 ms.HFT’s maximum P90 planning latency was 212 ms on Ethereum, 23 ms on Base, and 4.9 ms on BSC; end-to-end latency also depends on infrastructure factors outside the evaluation’s scope.Source: §5.4 · p. 12

5.5 RQ5: Ablation Study

  • Across HFT, SBA, and JIT, EVAGE found roughly 17,690–20,890 candidates versus PSA’s 9,953–12,444, and EVAGE’s HFT planned rate was 25.00% versus PSA’s 7.11%.PSA’s gaps arose mainly from fewer candidates and planned cases; EVAGE’s block-level fetching, broader selector support, and capped front-run search contributed to more opportunities and executable plans.Source: §5.5 · p. 12

6 Applications of EVAGE

EVAGE is presented as a way to lower MEV development barriers and speed adaptation across protocols and chains. The applications also frame it as a benchmark for AI agents in DeFi.

Democratizing MEV

  • Autonomous bot generation is presented as a way for smaller searchers and DAOs to compete for MEV profits directly.The authors connect lower technical barriers with reduced reliance on a few institutions that capture most market share.Source: §6 · p. 13

Accelerating cross-protocol and cross-chain adaptation

  • EVAGE parses target-protocol ABIs, documentation, and state variables to reconstruct execution payloads, supporting strategy migration without human intervention.The paper argues this can help capture value during low-competition periods that are otherwise constrained by human capability.Source: §6 · p. 13

Promoting the intersection of AI and DeFi

  • EVAGE provides a benchmark for evaluating AI agents’ handling of on-chain state, custom ABIs, and MEV workflows without human intervention.The paper says its logs and operational metrics, including strategy-formulation planning latency, can inform future Web3-specific AI models.Source: §6 · p. 13

7 Related Work

Prior agentic systems discussed here automate known exploit or attack-reconstruction tasks, whereas EVAGE targets proactive MEV strategy discovery and adaptation. The paper distinguishes its workflow and adaptability from those systems.

A1

  • Unlike A1’s fixed human-engineered toolkit for smart-contract exploitation, EVAGE uses specialized agents to refine MEV workflow stages and adapt to unseen protocols and chains.The paper describes EVAGE as a longer end-to-end agentic chain with greater versatility.Source: §7 · p. 13

TxRay

  • EVAGE and TxRay differ in role assignment, task division, and revision loops; EVAGE supports flexible natural-language handoffs rather than fixed templates.TxRay focuses on postmortem analysis and reproducible proof-of-concept reconstruction from seed transactions.Source: §7 · pp. 13–14
  • EVAGE moves beyond reproducing or exploiting known attacks toward proactive MEV strategy discovery and adaptation.The comparison notes that TxRay reconstructs observed attacks and does not explore strategies beyond its observed attack set.Source: §7 · pp. 13–14

8 Conclusion

The conclusion presents EVAGE as a fully autonomous multi-agent system for MEV bot generation, validated across three blockchains and more than 1.5 million historical blocks.

8 Conclusion

  • Experiments on over 1.5 million historical blocks across three blockchains validate EVAGE for MEV variant discovery, cross-protocol adaptation, and cross-chain adaptation.The conclusion characterizes EVAGE as the first fully autonomous multi-agent system for MEV bot generation.Source: §8 · p. 14
  • EVAGE is presented as the first fully autonomous multi-agent system for MEV bot generation.This is the paper’s stated novelty claim.Source: §8 · p. 14
  • The conclusion identifies variant discovery, cross-protocol adaptation, and cross-chain adaptation as the validated capabilities.The experiments span three different blockchains.Source: §8 · p. 14

Ethical Considerations

The ethical assessment confines evaluation to offline historical replay and describes safeguards, affected stakeholders, guiding principles, and a tiered release policy.

Ethical Considerations

  • All evaluations use isolated historical replay environments rather than live trading or on-chain execution.The experiments use local forks spanning 1.5 million historical blocks across Ethereum, BSC, and Base, without broadcasting transactions or accessing credentials.Source: Ethical Considerations · p. 17
  • The assessment identifies five affected groups, including protocol defenders, users and liquidity providers, researchers, searchers and builders, and malicious adversaries.It describes the first four groups as beneficiaries and malicious adversaries as a high-risk secondary stakeholder.Source: Ethical Considerations · p. 17
  • The ethical framework names privacy, risk-benefit balance, fairness and equity, and compliance as its four principles.It says analyses use public records without linking addresses to identities and sample cross-chain blocks without targeting specific users.Source: Ethical Considerations · p. 17
  • The paper says it publishes high-level designs with defensive remediation while withholding turnkey cross-chain execution pipelines.It also reports aggregate mechanism-level findings without tracking individual wallet addresses.Source: Ethical Considerations · p. 17
  • A tiered artifact release opens the core reasoning framework and defensive modules but restricts execution components reusable for live mempool exploitation.The publication rationale cites defensive benchmarks and community oversight alongside reproducibility and safety.Source: Ethical Considerations · p. 17

A.1 Stage I: On-Chain Data Collector

EVAGE’s MEV workflow separates blockchain-state collection, deterministic planning, and fork-based validation. Its strategy planners cover single- and multi-victim trading and liquidity strategies, with HFT-style variants broadening how attack sizes or liquidity scales are selected.

A.1–A.3 Stages I–III

  • The collector extracts and authenticates swap candidates, the planner compiles deterministic executable plans, and the validator simulates them on isolated forks to determine net profit.The evaluation assumes unconstrained attacker capital and excludes searcher competition, builder payments, and network delays.Source: §A.1 · p. 17, §A.2 · p. 17, §A.3 · p. 18

B.1–B.2 HFT and SBA

  • HFT sizes a single-victim sandwich around the victim’s slippage limit, while SBA backruns a victim-induced price displacement with an opposing swap in the same pool.HFT uses binary and ternary searches; SBA forgoes cross-pool routing during planning.Source: §B.1 · p. 18, §B.2 · p. 18

B.3–B.4 JIT and BUR

  • JIT sandwiches a victim swap with temporary liquidity to capture fees, while BUR surrounds aligned same-pool victims with one sandwich sized to keep the full sequence executable.JIT’s evaluation assumes adjacent liquidity mint and burn transactions, unconstrained capital, no intervening liquidity events or swaps, and no competition.Source: §B.3 · p. 18, §B.4 · p. 19

B.5–B.6 LR and MLL

  • LR combines a partial backrun, liquidity provision, and a final backrun; MLL uses one temporary liquidity position across consecutive aligned swaps to capture fees.Their planners search liquidity-addition ratios or scales while accounting for terminal value or inventory displacement.Source: §B.5 · p. 19, §B.6 · p. 19

B.7–B.8 SBA-HFT and JIT-HFT

  • SBA-HFT searches backrun size without front-running or cross-pool routing, while JIT-HFT searches liquidity scales across three orders of magnitude, from 2.5%–200% of victim volume.JIT-HFT assumes unconstrained capital access at zero opportunity cost and measures single-victim, same-pool returns.Source: §B.7 · p. 19, §B.8 · p. 19

B.9 BUR-HFT

  • BUR-HFT retains BUR’s aligned-victim mechanism and uses range expansion, binary search, ternary search, and a local scan to select a feasible, profitable attack size.It inherits BUR’s assumptions of complete advance knowledge and unrestricted attack capital.Source: §B.9 · p. 20

B.10 LR-HFT

  • LR-HFT retains LR’s partial-backrun and liquidity sequence but jointly searches directional position size and liquidity configuration, counting only cases with incremental market value over a no-liquidity baseline.The two choices interact through price movement, post-victim inventory, pool depth, and remaining-backrun slippage.Source: §B.10 · p. 20

B.11 MLL-HFT

  • MLL-HFT preserves MLL’s temporary position across aligned victims and uses HFT-style search to choose liquidity scale against fee share, capital needs, and inventory exposure.It selects a position with the largest positive value increment over the initial deposit under historical external prices.Source: §B.11 · p. 20

C Theoretical Analysis of SBA-HFT

The SBA profit model evaluates a backrun input against output revenue, token cost, and gas. SBA-HFT differs from SBA in the candidate input sizes it searches.

C.1 Problem Setup and Profit Model

  • Net WETH profit ΠS(a) is output FS(a) minus the input’s externally priced token cost pa and network gas cost G(a).The modeled state S is the pool immediately after the victim trades.Source: §C.1 · pp. 20–21
  • SBA evaluates a handful of heuristic sizes based on victim output, whereas SBA-HFT evaluates every integer input amount up to a safe upper limit.Both strategies use the same profit formula.Source: §C.1 · p. 21
  • SBA-HFT’s search set contains SBA’s smaller heuristic search set, B ⊆ H.The paper presents this containment as the basis for its search-set dominance result.Source: §C.1 · p. 21

C.2 Search-Set Dominance

Because SBA-HFT searches a superset of SBA’s candidate sizes, its best found input cannot yield lower modeled WETH profit.

C.2 Search-Set Dominance

  • SBA-HFT’s best input aH in H yields at least the WETH profit of SBA’s best input aB in B: ΠS(aH) ≥ ΠS(aB).The proof follows from B being a subset of H, so maximizing over H cannot produce a lower maximum than maximizing over B.Source: §C.2 · p. 21
  • The dominance claim compares the best candidate sizes found by the two searches under the same profit function.It is a search-set guarantee, not a claim that every SBA-HFT candidate is more profitable.Source: §C.2 · p. 21
  • The stated guarantee is non-strict: SBA-HFT may match SBA’s best WETH profit.The theorem says “at least the same” profit.Source: §C.2 · p. 21

C.3 Strict Profit Improvement

The paper argues that SBA-HFT will almost always strictly outperform SBA in live markets because the optimal input is rarely among SBA’s heuristic sizes. Its tick-level replay and case definitions specify how the comparison and validation are represented.

C.3 Strict Profit Improvement

  • In live trading, SBA-HFT will almost always strictly outperform SBA because SBA’s heuristic sizes almost never include the market-dependent optimum.The paper says this sizing logic also applies to CLMMs such as Uniswap V3, where optimal sizing depends on tick architecture rather than victim volume.Source: §C.3 · p. 21

D Tick-Level State Transitions in SBA-HFT

  • The backrun comparison shares three initialized ticks, after which SBA-HFT crosses 18 additional initialized ticks beyond SBA’s stop at tick 197787.The tick-level table lists the crossed ticks and liquidity net for replaying the state transitions.Source: D Tick-Level State Transitions in… · p. 21, Table 6 · p. 21

D.1 Replay of the SBA-HFT Backrun

  • The SBA-HFT replay sums interval outputs to 733.36 WETH after consuming the remaining 85,501 USDC in the final interval.The replay ends at tick 197600 after the listed crossings and final partial interval.Source: §D.1 · p. 22, Table 7 · p. 22

E Case Category Definitions

  • A candidate is planned only after an executable plan is constructed, runtime-successful only after fork simulation, and profitable only after normalized revenue minus gas is positive.Missing historical token prices are marked uncomputable rather than treated as zero or negative profit.Source: E Case Category Definitions · p. 22

Related papers

Loading 2609.27424v1…