How Fast Do MEV Bots Execute? Latency Breakdown (2026)
**Answer first** — Modern MEV bots execute the full **detection → simulation → submission → inclusion** cycle in **30–200 milliseconds** on Ethereum and **5–50 milliseconds** on So
Answer first — Modern MEV bots execute the full detection → simulation → submission → inclusion cycle in 30–200 milliseconds on Ethereum and 5–50 milliseconds on Solana. The total time from a target transaction appearing in the mempool to the bot's response landing in a block is dominated by network latency (RPC round-trip) and block time, not the bot's computation. Top searchers run co-located infrastructure that shaves 20-40ms vs cloud bots.
The 4-Stage MEV Latency Breakdown
Every MEV bot operates on this pipeline:
[Detect] → [Simulate] → [Submit] → [Include]
↓ ↓ ↓ ↓
RPC Local Relay Block
~30ms ~5-20ms ~20-100ms ~12s ETH / ~400ms SOL
Stage 1: Detection (mempool monitoring)
The bot subscribes to the mempool via WebSocket (WSS) RPC. When a target transaction (large swap, undercollateralized loan) appears, the bot is notified.
Typical latency:
- Premium RPC providers (BloXroute, Alchemy, QuickNode): 15-50ms
- Public RPCs: 100-400ms (often unusable for MEV)
The trick: WSS region matters more than raw bandwidth. A bot in Frankfurt connected to a Frankfurt RPC node beats a bot in Tokyo connected to the same provider via US East. See chain-specific WSS guides — for example, best WSS endpoints for Ethereum.
Stage 2: Simulation
Before submitting, the bot simulates the bundle locally to verify profitability and avoid wasted gas on reverts.
Typical latency:
- Anvil fork (FRB Agent default): 3-15ms
- Custom EVM (advanced searchers): 1-5ms
This stage is mostly CPU-bound. A modern desktop CPU is faster than most cloud-VM allocations because of dedicated cores.
Stage 3: Submission (bundle to relay)
The bot submits the bundle to a private relay (Flashbots on Ethereum, Jito on Solana).
Typical latency:
- Flashbots Relay: 30-80ms round-trip
- Jito Block Engine: 20-60ms
- BloXroute relays: 15-40ms
Searchers using multi-relay fan-out submit to 3-5 relays simultaneously to maximize inclusion probability.
Stage 4: Inclusion (block production)
This is out of the bot's control — it's just block time:
| Chain | Block time | Inclusion delay |
|---|---|---|
| Solana | ~400ms | Sub-second |
| BNB | ~3s | 3 seconds |
| Polygon | ~2s | 2 seconds |
| Ethereum | ~12s | 6-12 seconds (median) |
| Base/Arb/OP | 2s | 2 seconds |
| Monad | ~500ms | Sub-second |
| Berachain | ~2s | 2 seconds |
End-to-End Real Numbers
Combining the stages, here's what a competitive bot achieves on each chain:
Ethereum (slot-based, 12s blocks)
- Detection: 30ms
- Simulation: 10ms
- Submission: 50ms
- Wait for slot: 0-12s
- Total to block inclusion: ~6-12s (mostly slot wait)
Solana (continuous block production)
- Detection: 15ms
- Simulation: 5ms
- Submission: 30ms
- Block production: 400ms
- Total: ~450ms
L2s (Base, Arbitrum, Optimism — 2s blocks)
- Detection: 20ms
- Simulation: 8ms
- Submission: 40ms
- Block: 2s
- Total: ~2.1s
What Makes a Bot "Fast"?
Three factors dominate:
-
RPC quality (~60% of variance)
- Region-matched WSS endpoints beat raw bandwidth
- Premium providers beat public endpoints by 5-10×
-
Hardware locality (~25% of variance)
- Local execution > cloud (FRB Agent runs on user's Windows machine)
- Desktop CPUs > shared VM cores
-
Code efficiency (~15% of variance)
- Simulation engine quality (Anvil fork tuning)
- Bundle assembly micro-optimizations
Why Local Execution Beats Cloud Bots
Cloud-based Telegram bots (Maestro, BONKbot) run on the platform's servers. Every action incurs:
User browser → TG cloud → Bot servers → RPC → Relay
Each hop adds 30-150ms. A user in Singapore using a US-hosted Telegram bot may experience 200-500ms total user-perceived latency.
FRB Agent runs locally on the user's Windows machine, giving:
Local FRB → Premium RPC → Relay
That's typically 80-150ms savings versus cloud Telegram alternatives. On Solana sniping, this is the difference between landing the snipe and missing it.
See FRB vs Telegram Scripts for the full comparison.
The Speed Ceiling
Beyond a point, more speed doesn't help. If your bot detects + simulates + submits in 50ms total, you're already faster than the next block. Competitive edge then shifts to:
- Strategy quality (which targets to chase)
- Capital efficiency (right-sized bundles)
- Inclusion rate (private relay multi-fan-out)
FRB Agent operates within this performance envelope by default.
How to Test Your Latency
Use the WSS Latency Test tool to measure your endpoint quality. If you're seeing >100ms median latency to your chosen RPC, switch providers.
Common Misconceptions
"Faster bot = more money" Only up to a point. Above the speed ceiling, capital and strategy matter more.
"Cloud bots are faster because they have better servers" False. The extra hop through the platform usually costs more than the server upgrade saves.
"Fiber gigabit internet makes my bot faster" Marginal. Latency to RPC matters; bandwidth doesn't (MEV requests are tiny).
Practical Latency Optimization Steps
If your end-to-end latency is over 200ms on Ethereum or over 80ms on Solana, these are the highest-leverage fixes — ordered by expected impact:
Step 1 — Match your RPC region to your target chain's validator geography. Most Ethereum validators run in US-East-1 or EU-West. Most Solana validator leaders are in US-East and EU-West as well. Check your WSS provider's available regions and select the one geographically closest to the dominant validator cluster.
Step 2 — Switch to a premium WSS provider. Public RPCs introduce 100–400ms detection lag because they're shared across thousands of users. A premium provider (QuickNode, BloXroute, Alchemy Growth) typically delivers 15–50ms to the target chain. The monthly cost ($50–$200) pays back in improved inclusion rate within days for most active operators.
Step 3 — Run FRB Agent locally, not in the cloud. Local execution on a Windows desktop with dedicated CPU cores outperforms cloud VM allocations because modern MEV bot simulation is CPU-bound and desktop cores run faster than shared cloud cores. The network path also shortens: local → RPC → relay vs cloud server → RPC → relay → user.
Step 4 — Enable multi-relay fan-out. Submitting to a single relay (e.g., only Flashbots) means your bundle only reaches whatever fraction of the next block that relay's builders win (30–60%). Fan-out across Flashbots + Titan + beaverbuild pushes coverage above 90%. This doesn't reduce latency directly but dramatically improves inclusion probability at the same latency.
Step 5 — Pre-warm your standby RPC. Sending a lightweight keepalive request to your standby endpoint every 60 seconds prevents cold-start delays when rotation is needed. Cold-start on premium RPCs can add 200–500ms on the first request after idle.
Related Reading
阅读后的下一步
启动 FRB 控制台
连接您的钱包，通过 6 位 PIN 码配对节点客户端，然后分配上述合约。
相关文章
延伸阅读与工具
讨论
暂无笔记。添加第一条观察，或在以下平台与团队分享链接 X (@MCFRB).