How to Build an MEV Bot: The Open-Source Tools That Still Work

Say you decide to build an MEV bot. Not read about one, build one. Watch Ethereum's mempool, spot a profitable trade, simulate it locally, submit it to a block builder before anyone else can. Where do you start?

Almost nobody starts from scratch. MEV (maximal extractable value, the profit a searcher captures by choosing which transactions land and in what order ) has had a public tooling ecosystem for years: a Rust EVM good enough that reth and Foundry both build on it, sandwich and liquidation bots, symbolic-execution engines, enough Flashbots plumbing to sign a bundle without reading an RFC. The hard part isn't finding tools. It's knowing which ones are alive, which you're legally allowed to reuse, and which are impressive-looking corpses.

One caveat before you build any of this. This is a map of tooling, not a push to run it. Some MEV is broadly accepted as useful: arbitrage keeps prices aligned across venues, and liquidations keep lending markets solvent. Sandwiching and general frontrunning are not. They profit by making ordinary users' trades execute worse, which is why the ecosystem calls them toxic. Studying the mechanics is worthwhile; pointing a live bot at real users is a different choice, and not one I'm advising. None of this is financial or legal advice.

Before the catalog, the map. You can't tell where a tool fits until you can see the shape of the thing you're building.

The 60-second primer

If "sandwich" and "searcher" are new: a pending Ethereum transaction waits in a public pool, the mempool , until a builder includes it. Anyone watching a large swap can front-run it (buy first, pushing the price up), let it execute at the worse price, then back-run it (sell into the bump). That swap is the meat, the two trades around it are the bread: one flavor of MEV , profit from controlling ordering rather than from a market view. The gain comes straight out of the swapper's slippage, which is why sandwiching is called toxic MEV; rusty-sando 's own README uses the word. Arbitrage, liquidations, and NFT-mint sniping are others. Whatever the strategy, the infrastructure is identical: watch pending transactions, simulate outcomes without spending gas, size the trade, and submit privately through Flashbots so the attempt isn't itself front-run.

The stack

None of these tools is a bot on its own. They're layers, and the wiring between them is most of the work.

Read it top to bottom as one data flow.

A single alloy provider is the spine. It opens the WebSocket subscription that feeds the mempool watcher, and it's also what amms-rs or PoolSync use to discover pools and keep their reserves fresh.

Those synced reserves seed revm 's in-memory fork. This is the move that makes searching viable: revm executes a transaction against forked state in-process, so testing a hundred candidate trade sizes is a hundred function calls, not a hundred eth_call round trips. It's why nearly every alive Rust bot is, underneath, a revm wrapper.

The strategy layer joins two inputs (the decoded pending swap and the simulated result) and searches for the trade size that maximizes profit. artemis and kabu give you the Collector → Strategy → Executor scaffolding so you aren't hand-rolling that plumbing.

The winning size becomes calldata for a gas-golfed Huff contract, gets wrapped into a bundle, signed, and handed to the Flashbots relay. Before any of that touches mainnet, mev-flood stands up a throwaway network with DEXes and swap traffic to exercise the whole loop.

Two seams cost the real time: keeping pool state consistent with the fork revm executes against, and decoding router calldata for every swap variant. The rest is standard glue.

The shortlist

Twelve tools worth starting with, in the order the diagram uses them. The status tags ( active , stalled , archived ) are what matters here; check each repo's own license before you reuse its code. Status checked 24 July 2026.

• revm : the from-scratch Rust EVM that forks chain state into memory so you simulate in-process instead of over the network. The keystone. active

• alloy : the Ethereum library for Rust (providers, signing, ABI, pubsub). The modern successor to ethers-rs . active

• foundry / anvil : forking, tests, and a local fork node to simulate against; pair with reth for a full local database. active

• amms-rs : discover, sync, and reason about AMM pools (UniV2/V3, Balancer, ERC-4626) from Alloy. The default pool layer for a new Rust bot. active

• degenbot : the same job in Python, with real pool and token objects for UniV2/V3/V4, Curve, and Aave. The fastest way to prototype. active

• artemis : Paradigm's Collector → Strategy → Executor framework; the pattern most Rust bots still copy. stalled

• kabu : a full production-grade Rust MEV framework, and the maintained fork after loom went closed-source. active

• univ3-revm-arbitrage : a guided walk through eth_call vs anvil vs revm for a UniV3 arb. The clearest way to learn revm-based trade sizing. active

• rusty-sando : the clearest Huff-optimized sandwich bot in the open, contract and searcher both. archived

• grim-reaper : an Aave V3 liquidation bot written in Huff for gas efficiency. active

• mev-flood : spin up a local network with DEXes and swap traffic to test a bot without touching mainnet. stalled

• simple-arbitrage : Flashbots' canonical worked example of building and signing a bundle, the submission step the rest of the shortlist only gestures at. Read it alongside the Flashbots docs . stalled

Where these bots cheat

Read the simulation code in these bots and a few shortcuts recur: each one a place the reference implementation quietly stops matching mainnet. Three are worth recognizing before you trust any bot's simulation.

The first is in the pool math. A bot scores a candidate trade by running it through revm against forked pool state, but not every bot models the exact math for concentrated-liquidity pools. You'll see Uniswap V3 priced with a constant-product formula meant for V2:

      
        PoolState::V3(v3) => {
    let liq = U256::from(v3.liquidity);
    amount_in * liq / (liq + amount_in)
}
                                  
      
    

Real V3 liquidity concentrates into discrete price ranges, and a trade crossing a tick boundary needs tick-aware math this doesn't do. It misprices anything but the shallowest V3 trades, an easy way for a bot to look profitable in simulation and lose money live.

The second is balance setup. To simulate a trade the bot's account needs to already hold the tokens, and a fast way to arrange that is to write the balance straight into storage instead of running a real transfer() , the same trick Foundry's deal cheatcode uses. It means guessing the slot that holds the ERC-20's balanceOf mapping, usually slot 0, but not every token compiles that way. Guess wrong, or hit a token with transfer hooks, and the simulation silently diverges from on-chain reality.

The third is the submit path, and it's the one to check before you trust any "dry-run by default" claim. A bot can read as if live submission is one environment variable away (a LIVE_MODE flag, a relay client constructed, a log line that flips to "SUBMITTING") while the actual network call one level down is commented out or stubbed. Sometimes that's a deliberate safety property; either way it can mean the bot has no working path to mainnet at all. Verify it at the source, because a config flag and a wired-up send are not the same claim.

A word on licenses

Before you copy code out of any of these, sort it by what its license lets you do. These are stable facts about the license families, not claims about specific repos; the specific license is yours to check, because it can change:

• Permissive (MIT / Apache): safe to vendor and adapt; keep the notice.

• GPL: fine to run as a standalone tool, risky to link into your own code.

• AGPL: stricter still, and it can trigger even when you only offer the software as a hosted service, so invoke it, don't embed it.

• No LICENSE file: all rights reserved by default; read and learn from it, but don't ship it.

Why so much of this is dead

There's a faster way to tell which of these projects are alive than reading commit dates: check which Ethereum library each one is built on. The ecosystem went through a migration from ethers-rs to alloy , and almost everything abandoned died around the time ethers-rs wound down, while almost everything still maintained bet on Alloy. The dependency graph dates a project more honestly than its last commit.

The deeper pattern isn't about libraries. A well-designed reference implementation goes viral, gets forked a hundred times, and quietly stops being maintained, because whoever wrote it extracted what they needed and moved on, or found something more valuable behind closed doors. MEV makes that incentive unusually naked. loom , a full production-grade Rust framework, states in its own README that it "is not public anymore"; development moved to a closed product and the community answered with the kabu fork. The star counts mislead in the same direction: artemis and manticore both carry thousands of GitHub stars and are both effectively frozen.

So: start on revm , reach for Alloy-native libraries, and test against mev-flood before you point anything at mainnet. The tooling is real and a lot of it is excellent. It's just further into decay than the star counts suggest. Read the code, not the badge.

---

Appendix: every repo referenced

Status reflects each repo's last commit date and whether GitHub marks it archived, checked by hand on 24 July 2026, not a live feed, so re-verify before you rely on it. Licenses aren't listed on purpose; confirm each repo's own before reusing its code.

---

Hey, if you got something out of this, I write more about Ethereum internals, MEV, and searcher infrastructure over at sgurgul.dev . Come poke around.