Introducing the Open Source MEV Simulator

Today, we release an open source MEV simulator for the community.

It’s designed to help researchers, developers, wallets, educators, and DeFi users model different MEV attacks, run local experiments, change assumptions, and extend the simulator with new scenarios.

For this MEV simulator release, we prepared the simplest scenario possible to show it in action. This scenario asks one question:

If I trade roughly $3,000 per transaction, three times a week for a year, what percentage of my trading volume do I silently lose to sandwich attacks compared with using an encrypted or private mempool?

Again, this won’t accurately reflect reality, rather its purpose is to showcase the simulator in action and to give people a feeling for the problem space.

The Setup

To answer that question, we built a local blockchain simulator to calculate the damage. Trading roughly $3,000 per transaction, three times a week for a full year. We pitted two simulated traders against each other in a controlled environment using Anvil (Foundry) as the EVM backend and a mid-sized Uniswap V2 AMM pool.

• The Public Trader: Submits every swap openly to the public mempool.
• The Private Trader: Submits every swap to an encrypted/private mempool (invisible to bots).
• The Sandwicher (MEV Bot): Monitors the public mempool and ruthlessly exploits every profitable opportunity.

Both traders make random buy/sell decisions each block. The only systematic difference between them is mempool visibility.

The Results: A $12,000 Loss

When you look at a single trade, the loss looks like a rounding error. It’s often a small fraction of a percent that most people would think of as normal market volatility. But when you zoom out over a year, the impact is brutal.

The 1-Year Financial Breakdown

🛑 The Bottom Line

By using the public mempool, the trader silently lost 2.65% of their total trading volume to MEV bots. That equates to $79.53 stolen per trade, totaling $12,406 over the year.

The private trader paid the exact same 0.3% AMM fee and faced the same natural slippage. The $12,406 gap is pure loss from sandwich attacks - value that existed in your wallet at the start of the year and vanished by the end of it with zero benefit to you.

Caveats and Realism Notes

This simulation is deliberately simplified. Key differences from mainnet Ethereum:

• 100% sandwich rate: In this model the bot sandwiches every public trade. In practice, gas costs ($2–50/tx) impose a minimum profitable trade size, so smaller trades are often skipped. Realistic sandwich rates for $3K trades are probably 20–50%.
• No gas costs: The simulation does not model transaction fees. Adding realistic gas would reduce the effective MEV loss (some sandwiches become unprofitable) and make the break-even bot behaviour more accurate.
• No slippage protection: Traders accept any output amount. Real wallets default to 0.5–1% slippage tolerance; a tight limit causes the victim tx to revert when sandwiched, converting the "loss per trade" into a "trade failure rate" instead.
• No competing bots: On mainnet, hundreds of bots compete for the same opportunities via priority gas auctions, driving more of the MEV value to validators rather than any single bot.
• No external price oracle: Real AMMs are kept in sync with CEX prices by arbitrageurs. Here the pool price drifts with random trades, adding P&L noise unrelated to MEV.

Accounting for the 100% sandwich rate assumption, a more realistic estimate for this trade size on a liquid mainnet pool is probably 1–3% of volume - which is where our 2.65% simulation lands when the bot is sized conservatively (5× victim).

Conclusions

1. The cost is real and measurable. Even at conservative assumptions, using the public mempool costs a regular DeFi trader in the range of 1–3% of traded volume in MEV extraction.
2. For $3K/trade × 3×/week, that is roughly $12,000–$26,000 per year depending on how aggressively bots are capitalised.
3. The fix is simple. Using an encrypted mempool (Flashbots Protect, MEV Blocker, CoW Swap, or similar) eliminates sandwich exposure entirely at zero cost to the user.
4. Tight slippage tolerance is a partial defence. Setting max slippage to 0.5–1% causes sandwiched transactions to revert rather than execute at the bad price — though this introduces trade failure risk.
5. The MEV doesn't all go to the bot. In competitive, liquid markets the extracted value flows largely to liquidity providers and validators, not the sandwicher itself.

Run It Yourself

Want to stress-test these numbers or tweak the pool sizes? The entire simulator can run locally on your machine.

1. Clone and install

This simulation runs entirely locally. You need Python 3.11+, Node.js 20+, and Foundry installed.

git clone https://github.com/brainbot-com/mev-simulator
cd mev-simulator

# Python backend
python -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install -e ".[dev,server]"

# Frontend
cd frontend && npm install && cd ..

2. Explore interactively with the UI

Start the backend:

uvicorn server.main:app --port 8000

Start the frontend (in a second terminal):

cd frontend && npm run dev

Open http://localhost:5173. Select the UniswapV2 Sandwich Attack scenario, click Load, then Start. Watch blocks build in real time, with the mempool viewer showing public trades being sandwiched and the charts showing diverging P&L curves.

3. Tweak the parameters

Edit scenarios/uniswap_v2_sandwich/default_config.json, or pass a custom config through the UI's JSON config field:

{
  "initial_liquidity": 1000000.0,
  "trader_amount": 3000.0,
  "front_run_amount": 15000.0,
  "trader_interval": 12.0
}

Key levers:

• front_run_amount — controls how aggressively the bot is capitalised; directly sets MEV % per trade
• initial_liquidity — pool depth; larger pool = smaller price impact per trade
• trader_amount — victim trade size
• trader_interval — seconds between trades (12 = every block; increase to space trades out)

4. Ask questions with an AI coding agent

If you open this repo with an agentic coding tool - Claude Code, Cursor, OpenCode, GitHub Copilot Agent Mode, or similar - you can ask it to design and run custom scenarios for you directly. That's exactly how this analysis was produced. You don't need to touch the code. Example prompts that worked:

• "understand this project and host it for me here locally"
• "create a scenario: $3,000 per trade, 3 trades per week for a year. run it and tell me the numbers"
• "how can we bring the MEV loss down to ~3%? run it again with those changes"
• "give me a report on this to publish alongside a blog post"

The agent reads the code, designs the scenario config, starts the servers, runs the simulation, and interprets the results - all in one conversation.

Contribute

The MEV simulator is open source and built to be extended.

So, run your own scenarios, challenge the assumptions, improve the model, or add new examples for others to learn from.

Toxic MEV is a problem for everyone, but its impact is not always easy to see. This simulator is one way to make that impact more visible, measurable, and easier to understand.