Most write-ups about MEV focus on strategy: arbitrage, liquidations, sandwiching, backruns. Strategy is necessary, but it is not what separates a profitable searcher from a spectator. The deciding factor is usually time. By the time a pending transaction reaches you over a public RPC gateway, has been parsed, evaluated, and answered with a fresh state read across the network, the opportunity may already belong to someone closer to the chain. This post is about where those milliseconds go and how co-located node access closes the gap.

The latency budget of an MEV opportunity

Every MEV play is a race from “an opportunity appeared” to “my transaction is in the block.” That budget gets spent in a few places:

  1. Seeing the trigger. A pending transaction or a new block has to reach your code. Over a remote gateway, that is a network hop plus the provider’s own internal fan-out.
  2. Evaluating it. You read current reserves or state, run your model, and decide. Each state read is another round-trip if your node is remote.
  3. Acting. You sign and submit, which is yet another hop to wherever your transaction enters the system.

The strategy lives in step 2. But steps 1 and 3, and every state read inside step 2, are pure infrastructure latency. On a remote RPC path, region, peering, TLS, and provider load all add to a round-trip you pay repeatedly inside a single decision. For a read-then-act loop, that infrastructure time often dominates the math entirely.

Where remote RPC costs you

Calling a gateway across the public internet adds latency in ways that are easy to underestimate:

  • The round-trip is per call, not per opportunity. A single arbitrage check might read several pools. Each read crosses the network, so the cost compounds with the complexity of your strategy.
  • Mempool visibility is second-hand. If you only learn about pending transactions through a remote subscription, you are downstream of the provider’s view of the network, not the network itself.
  • Variance is the enemy. MEV is competitive at the tail. An average latency that looks fine can still lose to the p99 spikes that show up exactly during the volatile moments when opportunities cluster.

What co-location changes

The structural fix is to stop calling across the network: put your code on the same host as a fully synced node. That is the model BLAZED.sh is built around. Your container or script runs next to the node and talks to it over a local socket (ws://eth:8545 today; IPC is the maximum-performance local transport generally and a future direction), so:

  • State reads stay on the box. Reading reserves or account state during evaluation does not leave the machine, so the per-read cost inside your decision loop collapses.
  • You subscribe to the mempool locally. You watch pending transactions over the node’s own connection instead of a downstream relay. For the mechanics, see how to access the Ethereum mempool, and to watch the pool live, the BLAZED.sh mempool visualizer shows gas, base fee, and arbitrage and sandwich detection in real time.
  • Pricing is predictable for read-heavy loops. Your tight evaluation loop still draws credits, but with a simple, mostly-uniform weight from a monthly credit allowance, not the wide per-method compute-unit weighting of a remote gateway.

Co-location is not a magic edge over every competitor, and it does not replace strategy, block-builder relationships, or good execution. What it does is remove the infrastructure latency that you would otherwise pay on every read, which is the part of the budget you can actually control.

A concrete example: graph arbitrage

Multi-pair arbitrage detection is a clean illustration. Finding negative cycles with Bellman-Ford across a token graph, covered in graph theory arbitrage detection, means reading many pool reserves to build the graph, then re-checking before you act. On a remote gateway, every one of those reads is a network round-trip, and the graph is stale by the time you finish building it. Run the same scanner on the node and the reads are local, so the graph reflects state much closer to the moment you act on it.

Getting started

If latency is your bottleneck, the path is short:

  1. Move the evaluation loop onto the node so state reads are local. The deployment docs cover containers and scripts.
  2. Subscribe to the mempool over the local WebSocket rather than a remote relay.
  3. Check the supported networks for what is live and what is planned.

Conclusion

MEV rewards whoever is closest to the chain when an opportunity appears. Strategy decides whether a play is worth making; latency decides whether you are the one who makes it. Most of that latency is infrastructure you can remove by running your code on the node instead of calling one across the internet. Start with the mempool access guide and the deployment docs.