Backrunning Bot Development
Backrunning is the execution of a transaction immediately after a target transaction in the same block. Unlike frontrunning, the backrunner doesn't compete with the user — they exploit the changed blockchain state after the target transaction. Classic example: a large swap moves price in the pool, the backrunner arbitrages the difference between that pool and others.
The difference between a bot that makes money and a bot that burns gas to zero is in implementation details. We've seen bots that correctly detect opportunity but lose everything in gas wars with competitors.
Where Money Is Lost in Wrong Implementation
Gas as the Main Expense Item
Backrunning is competitive. Dozens of bots monitor the same mempool. If your bot didn't win the gas auction — the transaction gets included after someone else's, the opportunity is already used, you pay gas for a revert.
Typical mistake: bot sends transaction with gasPrice = targetTx.gasPrice + 1 gwei. Competitor sets + 2 gwei. Endless escalation means arbitrage profit is entirely consumed by gas.
Correct approach: calculate maximum allowable gas price from expected profit. If arbitrage yields $50, gas limit 200k, acceptable expense ratio 60% — maximum gas price = $30 / (200000 * ethPrice). Bot shouldn't set it higher than this threshold.
Simulation Before Submission
Sending transaction without prior simulation is burning gas. Blockchain state changes between the moment you detect opportunity and the moment it's included in block. Another bot might already have used the same arbitrage delta.
Use eth_call with block: "pending" or Tenderly simulation API to verify profit immediately before submission. If simulation shows loss — don't submit.
Bundle via Flashbots Instead of Public Mempool
Sending via public mempool on Ethereum — almost guaranteed loss to competitors with Flashbots access. Flashbots MEV-Boost allows sending bundle of transactions directly to builders, without public mempool.
Bundle structure: [targetTx, backrunTx]. Builder includes them sequentially. Backrun is guaranteed to come after target in the same block. Payment to builder — coinbaseFee in backrun transaction: block.coinbase.transfer(profit * 90 / 100).
On L2 chains (Arbitrum, Optimism), MEV infrastructure differs. Arbitrum FCFS (first-come-first-served) at sequencer — latency to sequencer endpoint matters more than gas auction.
Bot Architecture
Three System Layers
Monitoring layer. WebSocket subscription to pending transactions via eth_subscribe("pendingTransactions"). Analyze target transaction calldata — decode via ABI of known protocols (Uniswap v2/v3, SushiSwap, 1inch). If it's swap with sufficient size — pass to opportunity evaluator.
Opportunity evaluator. Simulate target transaction: what will pool price be after it? Calculate arbitrage route: through which pools conduct reverse swap to equalize price? Calculate net profit accounting for gas and slippage.
Execution layer. Form backrun transaction. Choose between Flashbots bundle and public mempool based on chain and profit size. Submit and monitor inclusion.
Smart Contract for Bot
For atomicity (not to lose money on partial execution) — execute via smart contract, not EOA:
contract BackrunExecutor {
address private immutable owner;
function execute(
address[] calldata path,
uint256 amountIn,
uint256 minProfit
) external {
// swap through pools
uint256 received = _executeSwaps(path, amountIn);
require(received >= amountIn + minProfit, "Insufficient profit");
// send % to builder
block.coinbase.transfer(msg.value);
}
}
minProfit protects against execution when profit is zero or negative. If arbitrage delta disappears between simulation and inclusion — transaction reverts. Gas is lost, but less than potential loss.
Multi-Chain and Routing
| Chain | MEV Infrastructure | Latency | Competition |
|---|---|---|---|
| Ethereum | Flashbots MEV-Boost | ~12s blocks | High |
| Arbitrum | Sequencer FCFS | ~250ms blocks | Medium |
| BSC | Public mempool + bscscan | ~3s blocks | High |
| Polygon | Flashbots PoS | ~2s blocks | Medium |
| Base | Optimism MEV-Share | ~2s blocks | Low |
On Arbitrum, due to fast blocks and FCFS, speed of RPC connection matters more than strategy complexity. A bot with co-location near Arbitrum sequencer consistently beats a bot with identical logic but higher latency.
Development Stack
TypeScript/Node.js + ethers.js v6 for monitoring and transaction building. Python for backtesting strategies on historical data (via The Graph or archive node).
Flashbots SDK (@flashbots/ethers-provider-bundle) for bundle submission. For multi-builder strategy — Flashbots MEV-Share or direct integrations with builder API (beaverbuild, rsync-builder).
Bot deployment: dedicated server with minimal latency to Ethereum/L2 nodes. AWS Frankfurt or Hetzner for Ethereum. Direct WSS to node, not via Infura/Alchemy — every 50ms counts.
Timeline Estimates
Basic backrunning bot for one DEX on one chain — 1 week. Multi-chain system with several strategies and Flashbots integration — 2 weeks. Including smart contract executor, mainnet fork tests, and infrastructure deployment.