DEV Community: Merunas Grincalaitis

How to Test an MEV Bot on a Mainnet Fork With Anvil

Merunas Grincalaitis — Thu, 22 Oct 2026 21:42:37 +0000

The most expensive way to test an MEV bot is on mainnet with real money. A bug in the swap math, a wrong token decimal, an approval missing in the contract, and the "test" costs a few hundred dollars in gas or a lot more in bad trades.

The cheap way is a mainnet fork. You run a local copy of Ethereum that starts from the real chain state at a block you choose. Every pool, every token balance and every contract is there, but the ETH is fake and nothing you do touches the real chain. Foundry's Anvil makes this really easy.

This is the setup I'd recommend for testing any bot: arbitrage, liquidation, sniping, anything.

Install Foundry and start a fork

If you don't have Foundry yet, install it from getfoundry.sh. Then you need an archive-capable RPC URL. A free tier from a node provider works to start, or your own node if you have one.

Start the fork:

anvil --fork-url $ETH_RPC_URL --fork-block-number 21000000

That gives you a local node on http://127.0.0.1:8545 with mainnet state as of that block. Anvil fetches the state it needs from your RPC as you go and caches it, so the first calls are slower than the rest.

Always pin the block number. If you don't, you fork from the latest block, and every test run starts from a different state. Pinned blocks make your tests reproducible, and Anvil can reuse its cache. The forking docs cover the options.

Don't use the default accounts with real keys

Anvil starts with ten accounts, each with 10,000 fake ETH, from a well-known test mnemonic. Those keys are public. Everyone has them. If you ever use one of them on a real network by accident, whatever's in it gets taken immediately.

The Anvil docs warn about this. Use your own mnemonic for forks:

anvil --fork-url $ETH_RPC_URL --fork-block-number 21000000 \
  --mnemonic "your own test mnemonic that is never used on mainnet"

And keep your real bot keys out of the test environment completely.

The custom methods that make forks useful

Anvil has a set of custom RPC methods beyond normal Ethereum JSON-RPC. These are the ones I use most for bots.

Impersonate any address

You can send transactions as any address without its private key. That's how you get tokens for testing, by impersonating a whale, or how you replay a transaction from a real user.

cast rpc anvil_impersonateAccount $WHALE
cast send $USDC "transfer(address,uint256)" $MY_BOT 1000000000 \
  --from $WHALE --unlocked
cast rpc anvil_stopImpersonatingAccount $WHALE

Or start Anvil with --auto-impersonate to allow it for every address.

Set balances, code and storage directly

cast rpc anvil_setBalance $MY_BOT 0xDE0B6B3A7640000   # 1 ETH
cast rpc anvil_setCode $ADDRESS $BYTECODE
cast rpc anvil_setStorageAt $ADDRESS $SLOT $VALUE

anvil_setCode is great for swapping a contract for a modified version, for example a mock oracle you can move whenever you want. That's how you test a liquidation bot: change the price, see if your bot finds the position and closes it.

Control mining

This is the important one for MEV. By default, Anvil mines a block for every transaction instantly. That's useless if your bot needs to react to pending transactions. So turn it off:

anvil --fork-url $ETH_RPC_URL --fork-block-number 21000000 --no-mining

Now transactions sit in Anvil's pool until you mine. You can see them with txpool_content, the same way your bot would watch a mempool, and then mine when you're ready:

cast rpc txpool_content
cast rpc anvil_mine

This lets you simulate the real flow: a "victim" transaction arrives in the pool, your bot sees it, builds its response, and you mine one block to see the result. You can also use --block-time 12 for regular 12-second blocks.

Snapshots

cast rpc evm_snapshot     # returns an id
# ... run your test ...
cast rpc evm_revert $SNAPSHOT_ID   # back to the snapshot

Snapshot before each test case and revert afterwards. You can run the same scenario a hundred times without restarting Anvil or fetching state again.

Traces

Start Anvil with --print-traces and you'll see the full call trace for every transaction in the terminal. When your bot's transaction reverts with a useless error, this tells you which call failed and why.

Replay a real opportunity

This is where forks really help. Find a real MEV transaction on Etherscan, a liquidation or an arbitrage that another bot won. Note its block number, then:

Fork at the block before it: --fork-block-number <block - 1>.
Disable mining.
Send the transactions that came before it in that block (impersonating their senders), so the state is the same as when the opportunity appeared.
Run your bot and see if it finds the same opportunity, and how much it would have made.
Compare your gas usage to the winner's.

You can also inspect any historical transaction directly with cast run:

cast run $TX_HASH --rpc-url $ETH_RPC_URL

That replays the transaction locally and prints its trace, which is great for understanding what a competitor's contract actually does.

Do this for twenty historical opportunities and you'll learn more about your strategy than from a month of reading.

Forge tests for the contract

For the on-chain part of the bot, write Foundry tests that run against a fork:

function setUp() public {
    vm.createSelectFork(vm.envString("ETH_RPC_URL"), 21_000_000);
    deal(USDC, address(bot), 1_000e6);
}

function test_arbitrageIsProfitable() public {
    uint256 before = IERC20(WETH).balanceOf(address(bot));
    bot.execute(route);
    assertGt(IERC20(WETH).balanceOf(address(bot)), before);
}

deal from forge-std sets a token balance for you, so you don't need to find a whale. Add tests for the failure cases too: what happens if the price moved, if the pool is empty, if the token takes a fee. Those are the ones that lose real money.

What a fork can't tell you

A fork is great for checking that your logic and contracts work. It doesn't tell you whether you'll win on mainnet:

No competition. On your fork, you're the only bot. On mainnet, ten others see the same opportunity.
No builder auction. Your bundle doesn't compete for inclusion. To learn how that part works, read Flashbots bundles explained.
No latency. Real bots fail because they're 200ms too slow. A fork won't show that.
Your RPC is the bottleneck. Forks fetch state on demand, so heavy tests can hit rate limits on free RPC plans.

So use the fork to make sure the bot is correct, then go live with small size to find out if it's competitive.

My testing checklist before going live

[ ] Contract tests pass on a fork, including failure cases
[ ] Bot finds and handles at least ten replayed historical opportunities
[ ] Gas usage is close to (or lower than) the bots that won those opportunities
[ ] Profit calculation includes gas and the builder payment
[ ] No private key from the test setup is used anywhere real
[ ] Kill switch and max position size are tested

If you're building a liquidation bot, I wrote about the strategy side in how liquidation bots work on Aave. For arbitrage, start with how to build a profitable MEV arbitrage bot.

And if you want me to build or review a bot for you, message me on Telegram. The ready-made MEVDAO tools, the Sniper Bot, Sniping Group and Token Rescue Bot, are on the features page. Join the MEV Secrets email list right below for weekly tips.

Originally published on the MEV DAO blog.

Flashbots Bundles Explained: How to Send eth_sendBundle and Why Yours Isn't Landing

Merunas Grincalaitis — Thu, 22 Oct 2026 21:42:27 +0000

Almost every MEV bot on Ethereum, whether it's an arbitrage bot, a sniper or a rescue script, ends up sending bundles. And almost every developer who sends their first bundle has the same experience: the request returns a bundle hash, everything looks fine, and nothing ever shows up on-chain.

This guide covers what a bundle is, how to send one properly, and a practical checklist for figuring out why yours isn't landing.

What a bundle is

A bundle is an ordered list of signed transactions that you send privately to a block builder instead of broadcasting them to the public mempool. The builder will include the whole bundle, in exactly that order, in one block, or it won't include any of it.

Flashbots popularized this. Their Quick Start describes the flow: searchers send bundles to builders, builders simulate them to make sure they don't revert, build full blocks, and deliver those blocks to validators through mev-boost relays. Validators running mev-boost pick the most valuable block offered to them.

Three properties make bundles so useful:

Atomic. All of the transactions land together or none do. That's what makes things like sponsored wallet rescues possible, where one transaction funds an account and the next ones spend that ETH in the same block. I covered that in how to rescue tokens from a compromised wallet with a sweeper bot.
Ordered. You control the sequence, which is how backruns and same-block snipes work.
Private and revert-protected. Bundles aren't visible in the public mempool before inclusion, and failed bundles don't land on-chain, so you don't pay gas for a trade that didn't work.

How to send a bundle

The endpoints

Flashbots has two main endpoints on mainnet, and mixing them up is a common first mistake. Per the Flashbots guide on sending transactions and bundles:

rpc.flashbots.net is Flashbots Protect, a drop-in wallet RPC for regular users. It takes normal eth_sendRawTransaction calls. It does not take bundles.
relay.flashbots.net is for searchers and bots. It accepts bundles and private transactions through Flashbots-specific methods. It does not support regular Ethereum RPC methods, so you still need a normal node for nonces, gas estimates and receipts.

For testing, there's also a Sepolia relay at relay-sepolia.flashbots.net.

The signing key

Every request to the relay is signed with an ECDSA key that identifies you as a searcher. The signature goes in the X-Flashbots-Signature header as address:signature, where the signature is over the JSON body. This key doesn't hold funds and shouldn't be your trading key. Flashbots uses it to build a reputation for you over time, and higher-reputation searchers get better access when the network is congested. So reuse the same identity key instead of generating a new one every run.

The eth_sendBundle request

The JSON-RPC docs describe the payload. The core fields are:

txs: an array of signed raw transactions, in order.
blockNumber: the hex block number this bundle is valid for.
Optional: minTimestamp and maxTimestamp, revertingTxHashes (transactions that are allowed to revert without killing the bundle), replacementUuid (to replace or cancel a bundle later) and builders (a list of other registered builders that should also receive the bundle).

The same docs list limits of 100 transactions and 300,000 bytes per bundle.

A minimal request body looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_sendBundle",
  "params": [
    {
      "txs": ["0x02f8...", "0x02f8..."],
      "blockNumber": "0x1499a2c"
    }
  ]
}

If you're in JavaScript, the official ethers-provider-flashbots-bundle library handles signing and gives you simulate() and sendBundle() helpers. Note that its README says it's designed for an existing ethers.js v5 installation.

Target the next block, and resubmit every block

A bundle is valid for one block. If you target block N+1 and it isn't included there, it's gone. The library README is explicit that if your bundle should be valid until it's mined, you need to resubmit for every block, and the target should always be a future block, never the current one.

Resubmitting each block is also your chance to re-check the opportunity, update fees to the new base fee, and re-sign with the correct nonce.

mev_sendBundle and MEV-Share

Flashbots also has mev_sendBundle, a newer format that supports MEV-Share, where you can backrun user transactions that are only partially revealed through hints. Their MEV-Share searcher writeup explains the strategies. If you're just starting, eth_sendBundle is the simple option and is what most examples use.

Always simulate first

Before you send anything, simulate it with eth_callBundle (the library's simulate() method). The simulation runs your signed transactions in order on top of a given block and returns gas used, fees paid and coinbase payments for each transaction.

This catches the majority of problems before they cost you an opportunity. The Flashbots troubleshooting guide recommends simulating, logging the results, and keeping a record of every bundle and its signed transactions, because a bundle that fails leaves no trace on Etherscan to debug from.

Why your bundle isn't being included: the checklist

The Flashbots troubleshooting guide lists five reasons a bundle doesn't land, in the order you should check them.

1. A transaction in the bundle reverts

If any transaction reverts (and isn't listed in revertingTxHashes), the whole bundle is dropped. Common causes: wrong nonce, insufficient balance, a stale price that makes your slippage check fail, a deadline that's already passed, or a token transfer that the token contract blocks.

Fix: simulate against the block you're targeting and read the per-transaction results.

2. You're not paying enough for the blockspace

Your transactions must pay at least the base fee, or the block would be invalid. Beyond that, the builder compares what your bundle pays with what it would earn from other transactions using the same gas. The docs give a simple example: if your bundle pays a 1 gwei priority fee but the cheapest transaction in the block pays 2 gwei, the builder is better off leaving your bundle out.

What matters is the effective priority fee: everything the bundle pays the builder (priority fees plus any direct ETH transfers to the block's coinbase), divided by the gas it uses.

Fix: pay more, or use less gas for the same result. Gas optimization is a bid in disguise.

3. A competitor bid more for the same opportunity

Builders roughly simulate each bundle at the top of the block, sort by effective priority fee, and then add bundles one by one as long as they still work. If another bundle that touches the same state goes first, yours may revert, collide on a nonce, or pay less than it did in isolation. Then it's dropped.

The auction is blind, so you can't see competing bids in advance. You can look afterward: the library's getConflictingBundle() helper re-simulates the target block to find which bundle conflicted with yours and how much it paid.

Fix: compare your effective priority fee with the winner's. If you're consistently outbid, the opportunity may be too competitive. In that case, a less crowded strategy beats a higher bid. My take on that is in how to build a profitable MEV arbitrage bot.

4. Your bundle arrived too late

Your bundle has to reach the builder, get simulated, go into a block, and get through a relay to the validator, all before the slot. The troubleshooting guide notes each of those steps can take around 1 to 2 seconds. There's also a window where your node still thinks the chain is at block X while the rest of the network has already seen X+1, so you're targeting a block that's already been built.

Fix: cut your own processing time, use low-latency, well-synced nodes, and send your bundle as early as you can in the slot.

5. The validator isn't running mev-boost

mev-boost is opt-in. If the validator for a slot doesn't run it, or isn't connected to a relay your builder submits to, no bundle will land in that block. Research on the builder market, such as this 2024 study, found that the large majority of blocks since the Merge come through mev-boost, but not all of them.

Fix: nothing to fix. Resubmit for the next block.

Send to more than one builder

Flashbots is one builder among several. The builder market is concentrated in a handful of players, and their share changes over time. You can see current relay and builder shares on relayscan.io and slot-level data on mevboost.pics.

If you only send to one builder, you only get into blocks that builder wins. You can use the builders field to have Flashbots share your bundle with other registered builders, and many builders run their own bundle endpoints. Check each builder's documentation for its exact API before relying on it.

Get refunds when you overpay

Eligible bundles that land in blocks built by BuilderNet (the block-building network Flashbots operates together with partners) can earn refunds of part of what they paid, based on how much they contributed to the block's value. The rules are in the BuilderNet refunds documentation. The Flashbots RPC docs include flashbots_getFeeRefundsByRecipient and related methods so you can see what you've earned, and flashbots_setFeeRefundRecipient to send refunds to a different address. It's worth checking, especially if you bid aggressively.

The short version

Use relay.flashbots.net for bundles, with a stable identity key.
Simulate with eth_callBundle every time.
Target the next block and resubmit every block.
Check the five failure reasons in order: reverts, fee too low, outbid, too late, no mev-boost.
Send to multiple builders.

If you'd rather not build all of this yourself, the MEVDAO Sniper Bot and Token Rescue Bot already handle bundle building, simulation and submission for sniping and wallet rescues. They're included in the MEVDAO subscription with a 3-day free trial.

For more guides like this, join the free MEV Secrets email list below. And if you want a custom MEV bot built, message me on Telegram.

Originally published on the MEV DAO blog.