MEV Bot Development

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1 servicesAll 1306 services
MEV Bot Development
Complex
~1-2 weeks
FAQ
Blockchain Development Services
Blockchain Development Stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1214
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1161
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    852
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1041
  • image_logo-advance_0.png
    B2B Advance company logo design
    561
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    823

Developing an MEV Bot

MEV is not an exploit or a gray area. It's competitive infrastructure: a searcher notices an opportunity in the mempool before others, builds a bundle, and sends it through Flashbots/MEV-Boost. The MEV market on Ethereum — $600M+ extracted in 2023 according to mevboost.pics. Most of it — arbitrage and liquidations, not sandwiching. MEV bot development is high-load financial system development with millisecond-level latency.

MEV Bot Architecture: What's Actually Hard

Transaction Simulation Before Sending

The MEV developer's main tool is not the contract itself, but the simulation engine. Before sending a bundle through eth_sendBundle to Flashbots relay, you need to know for sure: will this transaction be profitable after gas and bribe?

Standard approach: eth_call on an archive node with stateOverride — substitute your address balance and simulate execution. But eth_call doesn't account for state changes inside the bundle. For accurate simulation — debug_traceCall or your own EVM (revm on Rust).

We use revm (Rust EVM implementation) for local simulation with forked mainnet state. Simulation latency: 1-3ms vs 20-50ms through RPC eth_call. When competing for arbitrage, this difference is critical.

Opportunity Detection: Three Main Vectors

Arbitrage between DEXes. Token A/B price on Uniswap v3 differs from Curve. Bot calculates optimal swap size through Newton-Raphson on x*y=k curve (Uniswap v2) or get_dy (Curve StableSwap). Flash loan from Aave v3 covers capital requirement — 0.05% fee.

Key challenge: optimal swap size maximizing profit. For Uniswap v2 this is analytical:

optimal_amount_in = sqrt(reserve0 * reserve1 * 997 / 1000) - reserve0

For v3 with concentrated liquidity — need tick-by-tick calculation through QuoterV2.

Liquidations. Monitor health factor of positions in Aave v2/v3, Compound v3, Euler. When health factor drops below 1.0 (Aave) or collateral ratio breaks (Compound) — call liquidationCall / liquidate. Profit = liquidation bonus (5-15% depending on asset).

Problem: several bots see one position simultaneously. The one who offered more bribe to MEV-Boost builder or got into an earlier private mempool wins.

Sandwich — we don't do it. Sandwich attacks harm regular users. Arbitrage and liquidations are useful market functions.

Infrastructure: Node, Latency, Builder Connection

MEV without your own node is handicapped. Public RPC adds 50-200ms. You need geth/reth in --txpool.globalslots 10000 mode with enabled txpool subscription via WebSocket. For liquidations, Alchemy/QuickNode WebSocket is enough — latency is acceptable (positions don't close instantly).

For arbitrage — own node or dedicated node from provider (Alchemy Growth plan, ~15ms latency). Flashbots eth_sendBundle sent directly to builders (beaverbuild, rsync, titan), bypassing public mempool.

Execution Contract

The on-chain contract itself is simple executor: receives swap parameters, executes through Uniswap/Curve router, checks profit via require(profit > minProfit), returns funds. No fund storage on contract — only transient flows via flash loan.

Protection from copying: execution function checks msg.sender == owner and optionally block.coinbase == expectedBuilder (for protection against front-run in public mempool).

Development Stack

Python (quick prototype) → Rust (production). web3.py for prototyping logic, ethers-rs + revm for production bot. Solidity executor contract — Foundry. Monitoring via Prometheus + Grafana: tracks per second, gas consumption, profit/loss by session.

Work Process

Strategy analysis (2-5 days). Define vector: arbitrage between specific pairs, liquidations in specific protocols. Calculate historical opportunity using on-chain data via Dune Analytics or The Graph.

Python prototype (3-5 days). Detection logic + simulation through RPC. Backtest on historical data (through archive node).

Production Rust (1-2 weeks). Rewrite hot path. WebSocket subscriptions, local simulation via revm, async executor via tokio.

Contract + deployment (3-5 days). Executor in Solidity, tests in Foundry, mainnet deployment.

Infrastructure setup. Node, Flashbots relay connection, monitoring. This often takes as long as bot development itself.

Timeline Guidelines

Simple arbitrage bot (2 DEXes, one pair): 1-2 weeks. Multi-DEX arbitrage with route optimization: 3-4 weeks. System with liquidations + arbitrage + Rust infrastructure: 6-8 weeks. Timelines heavily depend on latency requirements and strategy complexity.