Introduction

Decentralized exchanges (DEXs) rely on token reserves to determine swap prices, enabling permissionless trading, but also unintentionally introducing MEV opportunities. Because attackers can reorder, insert, or remove transactions around DEX trades, they can exploit temporary price discrepancies to extract profit via arbitrage or sandwich attacks.

Why MEV Search Is So Slow Today?

MEV search is an optimization problem: given a mempool and a DEX environment, we want to evaluate thousands, sometimes millions of possible transaction bundles and choose the most profitable one.

To diagnose the bottlenecks, we replayed seven historical arbitrage MEV examples (see the Appendix) using two state-of-the-art tools:

• Foundry, the fastest CPU-side EVM in Rust
• Lanturn, an MEV searcher in TypeScrip

Environment:

• Intel i7
• RTX3090Ti 24G
• SSD 1T
• Ubuntu 22.04

We ran 1,000 replays for each tool and measured how time is divided across the three main stages:

1. Forking from mainnet state
2. Generating input bundles
3. Executing smart contracts

image1542×618 56.9 KB

Our findings matched previous research: input generation is trivial (<1%), but EVM execution and forking dominate end-to-end latency. Foundry spends:

• 80.89% of its time on forking (27.87 ms)
• 18.82% on executing swaps (6.49 ms)

Lanturn performs even worse: its EVM execution is 17.8× slower and forking 1.98× slower than Foundry, despite multi-threading.

In short: MEV search is limited by CPU execution speed, and CPUs simply cannot explore the search space fast enough.

Compiling MEV Bot to GPU Code

To break out of this CPU bottleneck, we use GPU:

1. Write the MEV bot in Solidity (e.g., a router performing multi-hop arbitrage)
2. Compile the smart contract to LLVM IR using mau
3. Generate PTX code (CUDA assembly) using LLVM backend
4. Execute it natively on GPU threads

Here’s the Solidity bot we use as a running example. Its fallback handler parses a compressed byte-format describing the swaps, determines the DEX type, and calls the correct swap() function:

// SPDX-License-Identifier: UNLICENSEDpragma solidity 0.7.6;import "./libraries/uniswapv2/UniswapV2Pair.sol";import "./libraries/uniswapv3/UniswapV3Pair.sol";import "./libraries/sushiswap/SushiswapPair.sol";import "./libraries/pancakeswap/PancakeswapPair.sol";contract MEV {fallback(bytes calldata data) external payable returns (bytes memory) {uint256 amount = abi.decode(data[:32], (uint256));uint32 swap_len = uint32(abi.decode(data[32:], (bytes4)));uint32[] memory swap_vec = new uint32[](swap_len);uint32[] memory token_vec = new uint32[](swap_len);uint32 calldata_size = uint32(data.length);uint32 swaps_buf_size = (calldata_size - 32 - 4) / 2;for (uint32 i = 0; i < swap_len; i++) {swap_vec[i] = uint32(abi.decode(data[36 + i * 4:], (bytes4)));uint256 token_word = abi.decode(data[36 + swaps_buf_size + 32 * (i / 8):], (uint256));token_vec[i] = uint32(token_word >> (256 - 32 * (i % 8 + 1)));}for (uint32 i = 0; i < swap_len; i++) {bool reversed = token_vec[i] > token_vec[(i + 1) % swap_len];uint32 swap_u32 = swap_vec[i];uint8 dex_type = uint8(swap_u32 >> 24);address dex = address(swap_u32 & 0xFFFFFF);if (dex_type == 1) {amount = UniswapV2Pair(dex).swap(reversed, amount);} else if (dex_type == 2) {amount = UniswapV3Pair(dex).swap(reversed, amount)} else if (dex_type == 3) {amount = SushiswapPair(dex).swap(reversed, amount);} else if (dex_type == 4) {amount = PancakeswapPair(dex).swap(reversed, amount);} else if (dex_type == 5) {continue;}}return abi.encodePacked(amount);}}

Once compiled to PTX, this bot becomes executable GPU code. Instead of evaluating one bundle at a time, as CPUs do, we launch tens of thousands of threads, each testing a different candidate bundle.

Parallel Genetic Algorithm: Searching Thousands of Bundles at Once

A parallel genetic algorithm (GA) is used to search bundles on GPU. Each GPU thread represents one individual (i.e., one bundle) in a population. In each generation, the algorithm performs:

image1292×308 27.8 KB

1. Selection – choose the top-profit bundles
2. Crossover – recombine them into new bundles as offsprings
3. Mutation – tweak DEXs, tokens, or ordering to get new bundles as invariants
4. Evaluation – run MEV bot with the invariants bundles on the GPU

This workflow allows us to explore a vast search space extremely quickly. Multiple populations can be evaluated concurrently, enabling broad and deep search coverage.

Performance Results

Table: New MEV Opportunities Identified in 2025 Q1 Blocks

Across experiments, we achieve 3.3M–5.1M transactions per second, outperforming Lanturn by ~100,000×. On real data from Q1 2025, the system uncovered MEV opportunities spanning 2 to 14 transactions, amounting to $1.1M in extractable profit.

Runtime Overhead: Lightweight and Stable

image680×498 40.4 KB

MEVISOR introduces two types of overhead: cold startup and per-search overhead.

Cold Boost (one-time)

Before searching, the GPU must load the PTX bot and initialize memory.
This costs 7.03 seconds, but only happens once and is amortized across all future searches.

Runtime Overhead

The main runtime cost is loading DEX state snapshots into GPU memory.

As we scale from 64 to 540 DEX pools:

• Loading latency stays stable at ~0.30 seconds
• GPU memory usage increases linearly (774 MB → 1.58 GB)

Even with hundreds of DEXs, MEVISOR stays comfortably below the VRAM limits of commodity GPUs and maintains low, predictable overhead.

Appendix

Motivation Examples