Frontrunning Bot Development

Frontrunning Bot Development

Every second Ethereum mempool contains thousands of unconfirmed transactions. Large token buy on Uniswap is visible before being included in a block. Bot spots it, sends its own transaction with higher gas price—gets included first, raises price. Victim buys expensive. Bot sells. Classic sandwich. This is frontrunning in its basic form.

Developing a frontrunning bot is simultaneously work with low-level mempool, MEV economics, and speed engineering. 100-millisecond delay costs real money.

Architecture: from mempool to execution

Mempool monitoring

Standard eth_subscribe("pendingTransactions") via WebSocket gives transaction hashes. For frontrunning you need transaction body: txpool_content or eth_getTransactionByHash—additional RPC call with delay. Already a loss in speed.

Right approach—connect to nodes with newPendingTransactions full subscription (some clients support returning full body immediately). Or connect directly to multiple nodes simultaneously—whoever sent first is faster. We use: own geth/Erigon node + Alchemy/Infura as fallback, WebSocket connections to both.

Calldata decoding: identify target contract and function. For Uniswap v2/v3—parse swapExactTokensForTokens, exactInputSingle, other swap functions. Calculate expected price impact. If impact > threshold—sandwich candidate.

Profitability calculation

Bot must calculate in milliseconds:

• Current pool reserves (SLOAD from cached state or RPC call)
• Victim's price impact
• Optimal size of own transaction (via binary search or analytical formula)
• Gas cost (front + back transaction)
• Expected profit after gas deduction

If expectedProfit > gasCost * safetyFactor—send bundle of transactions. Safety factor usually 1.2-1.5, otherwise any slip loses money.

Execution priority: gas price vs Flashbots

Naive approach—higher gas than victim. Worked until 2021. Now it's priority gas auction: you raise gas, competitors see and raise theirs, profit goes to gas. Plus failed transactions pay gas—if victim cancelled transaction or competitor beat you, you still paid.

Flashbots MEV-Boost—the right solution. Send bundle (multiple transactions as unit) directly to block builder, bypassing public mempool. Either bundle executes completely or isn't included—no risk of partial execution and paying for failed transactions. Payment to builder via coinbase transfer at end of bundle (part of profit).

const bundle = [
  { transaction: frontrunTx, signer: wallet },
  { hash: victimTxHash }, // victim
  { transaction: backrunTx, signer: wallet }
];
await flashbotsProvider.sendBundle(bundle, targetBlockNumber);

Strategy types

Sandwich attacks—most common on DEX. Require precise victim slippage calculation: if their minAmountOut almost equals optimal—sandwich won't work, victim gets revert.

Pure backrunning—back transaction only, no front. For example: large swap creates arb-opportunity between Uniswap and Curve. Bot notices this, inserts its arb-swap right after victim's transaction in same block. Less aggressive, less competition with other MEV-bots.

Liquidation frontrunning—monitor positions in Aave/Compound close to liquidation threshold. On oracle price drop—race for first liquidation with liquidation bonus.

Tech stack

Written in TypeScript (viem/ethers.js) or Rust for maximum decode speed. Go also popular among MEV-bots for low latency.

For swap calculations—either local Uniswap v2/v3 formula implementation (no RPC) or Uniswap SDK v4 with local pool state cache. Local simulation via eth_call with stateOverride lets you verify transaction without sending.

Flashbots SDK (@flashbots/ethers-provider-bundle) for EVM chains. On other networks: MEV Blocker for Gnosis Chain, aori/mev-share on Ethereum for more cooperative strategies.

Competitive environment and reality

MEV-bots—highly competitive space. On Ethereum mainnet hundreds of professional bots from well-funded teams operate. Arbitrum and other L2s offer less competition but less volume.

Real profitability depends on: strategy uniqueness, infrastructure speed, state caching quality. Publicly known strategies quickly become unprofitable due to copying.

Timeline estimates

Basic sandwich-bot for one DEX (Uniswap v2/v3) with Flashbots integration—1-2 weeks. Multichain bot with multiple strategies and monitoring—3-5 weeks. Custom MEV infrastructure with own node and simulator—2+ months.

Cost calculated after discussing strategies and target networks.