Lowest Latency Reth RPCs for MEV Trading (2026)

Answer first — The lowest latency Reth RPC setup for Ethereum MEV in 2026 requires running a self-hosted Paradigm Reth node on bare-metal hardware (NVMe Gen4/5, 64 GB DDR5) co-located near primary block builders in AWS us-east-1 or equivalent Equinix facilities. Connecting FRB Agent directly to the local Reth WebSocket endpoint (ws://127.0.0.1:8546) eliminates internet round-trip time entirely, achieving sub-1 ms internal latency for mempool event delivery. This guide covers why Reth, how to configure it, and how to integrate it with FRB for production MEV execution.

Mastery Path: Layer 2 Mastery

• Arbitrum MEV Latency
• Base MEV Strategies
• Optimism Playbook
• Reth RPC Mastery (Current)
• Best WSS Endpoints by Chain

Why Self-Hosted Reth Beats Shared RPC Providers

The competitive advantage in MEV is measured in milliseconds. Every millisecond between when a profitable pending transaction enters the Ethereum network and when your bot detects it is a window for a faster competitor to capture the opportunity instead.

Shared RPC providers (Alchemy, QuickNode, Infura) serve thousands of concurrent users. They apply rate limiting, queue requests, and use load balancers that add 20–150 ms of overhead depending on congestion. This overhead is invisible during normal usage — it only matters in the narrow windows when MEV opportunities are live.

Self-hosted Reth eliminates the shared queue entirely. Your node receives and processes pending transactions from peers with no intermediary. Latency from the peer network to your application is bounded only by network propagation time and local processing speed.

The quantitative difference: shared RPC endpoints for Ethereum mempool subscriptions typically deliver eth_subscribe events 30–200 ms after the node sees them during moderate load. A local Reth node with WSS connected on localhost delivers the same events in under 2 ms.

Why Reth Over Geth, Erigon, or Nethermind

Reth is a Rust-based Ethereum execution client developed by Paradigm, designed from the ground up for performance and modularity. Compared to the alternatives:

Reth vs Geth:

• Reth syncs from genesis faster than Geth in every published benchmark
• Reth uses MDBX (memory-mapped B-tree) instead of LevelDB — significantly faster for the random-read pattern of state lookups during mempool simulation
• Reth's WebSocket implementation has lower serialization overhead, resulting in 5–15 ms lower event delivery latency for high-frequency subscriptions

Reth vs Erigon:

• Erigon also uses MDBX and has excellent historical read performance
• Reth's active development pace and Paradigm's MEV-focused contributions make it more responsive to searcher-specific optimization needs
• Reth has a more stable WebSocket API with better behavior under high subscription volume

Reth vs Nethermind:

• Nethermind is .NET based; Reth is Rust — the memory management model of Rust produces more predictable latency under GC-pressure scenarios that .NET encounters during high-load periods
• Reth's debug namespace is more complete, which matters for simulation workflows

For MEV execution in 2026, Reth is the reference client.

Hardware Requirements (2026 Specifications)

Storage — non-negotiable: Ethereum archive state exceeds 2 TB as of 2026. The storage performance requirement is not throughput (MB/s) but IOPS — random read/write operations per second, which determines how fast Reth can respond to state queries during bundle simulation.

• Minimum: 4 TB NVMe Gen4 SSD (Samsung 990 Pro, WD Black SN850 equivalent)
• Recommended: 4 TB NVMe Gen5 SSD — approximately 2× the IOPS of Gen4, which directly reduces simulation latency for complex multi-hop bundle verification
• Do not use SATA SSDs — SATA III is capped at ~550 MB/s sequential and ~100K IOPS. NVMe Gen4 delivers ~7,000 MB/s and ~1M+ IOPS. The difference is measurable in bundle simulation time.

RAM:

• Minimum: 32 GB DDR4
• Recommended: 64 GB DDR5 — Reth's MDBX implementation benefits significantly from large OS page cache; more RAM means more of the state trie stays in cache, reducing SSD reads during peak simulation load

CPU:

• Minimum: 8 cores, modern architecture (Intel Core i7-12th gen or AMD Ryzen 7)
• Recommended: AMD EPYC (server-grade) or Intel Core i9 with high single-thread performance — Reth's simulation path is partially single-threaded, so clock speed matters more than core count for the critical latency path

Network:

• 1 Gbps symmetric dedicated connection minimum
• 10 Gbps preferred for data centers with high peer counts
• Low-latency routing to Equinix IX points (NY4, FR2) where major block builders and validators peer

Physical Location: Co-Location

The physical distance between your node and the block builders is the latency floor you cannot engineer around. Speed of light in fiber is approximately 200,000 km/s, which means 1 ms of latency per 200 km of fiber path.

Primary target data centers:

• AWS us-east-1 / Equinix NY4 (Ashburn, Virginia) — the largest concentration of Ethereum block builder infrastructure in North America
• Equinix FR2 (Frankfurt) — primary European builder hub; covers Flashbots and most European relay operators
• Equinix TY3 (Tokyo) — relevant for Asian searcher operations, less critical for primary MEV competition

Running your Reth node in one of these data centers and connecting FRB Agent on the same server eliminates internet latency entirely. The WSS connection between FRB and Reth traverses only loopback — effectively zero latency.

Reth Node Configuration

Install Reth from the official binary releases at github.com/paradigmxyz/reth. Verify the checksum before running.

Optimized launch configuration for MEV:

reth node \
  --chain mainnet \
  --http \
  --http.api "eth,net,web3,debug,txpool" \
  --ws \
  --ws.api "eth,net,web3,debug,txpool" \
  --ws.origins "*" \
  --db.map-size 4000000000000 \
  --discovery.v4 \
  --max-outbound-peers 100 \
  --max-inbound-peers 30 \
  --log.file.filter info
Copy

Key flags explained:

--http.api and --ws.api — include txpool to subscribe to pending transaction events. This is the API namespace that delivers mempool data. Without it, you can only query committed state.

--db.map-size 4000000000000 — sets MDBX memory map size to 4 TB, matching your disk allocation. This prevents MDBX from needing to resize the map (which causes brief pauses) and allows the entire dataset to be addressable.

--max-outbound-peers 100 — more peers means faster propagation of pending transactions from the network. Your node hears about mempool entries faster when it's connected to more peers.

--max-inbound-peers 30 — allow some inbound connections to maintain network health, but limit them to prevent resource exhaustion from peer requests.

Connecting FRB Agent to Your Reth Node

Once Reth is fully synced (which takes 6–24 hours from scratch with fast hardware on archive sync), configure FRB to use it as the primary node.

1. In FRB Agent, navigate to Settings → Networks → Ethereum → RPC Configuration
2. Set Node Type to Custom / Localhost
3. Set WSS Endpoint to ws://127.0.0.1:8546
4. Set HTTP Endpoint to http://127.0.0.1:8545
5. Run the built-in latency benchmark — the result should read under 2 ms for local WSS

If FRB Agent runs on the same server as Reth (recommended for production), all traffic stays on loopback. Bundle simulation, mempool subscription events, and state queries are all local — there is no internet round-trip in the critical path.

If FRB Agent runs on a separate server in the same data center, connect via the private network interface rather than the public IP. This keeps traffic within the data center's internal network (typically 0.1–1 ms) rather than routing through the public internet.

Firewall and Access Control

A public-facing Reth node is a security liability. Configure the firewall to block external access to ports 8545 and 8546 entirely:

## Allow only localhost access to RPC ports
iptables -A INPUT -s 127.0.0.1 -p tcp --dport 8545 -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -p tcp --dport 8546 -j ACCEPT
iptables -A INPUT -p tcp --dport 8545 -j DROP
iptables -A INPUT -p tcp --dport 8546 -j DROP

## Keep P2P port (30303) accessible for peer discovery
iptables -A INPUT -p tcp --dport 30303 -j ACCEPT
iptables -A INPUT -p udp --dport 30303 -j ACCEPT
Copy

Also restrict txpool API access. The mempool subscription is a high-value data feed — exposing it publicly invites competitors to use your infrastructure.

Monitoring and Maintenance

Sync status: Monitor eth_syncing via the HTTP endpoint. The node is fully operational only when this returns false.

Peer count: Keep peer count above 20 at all times. Low peer count means delayed propagation of pending transactions. If peer count drops, check firewall rules for P2P port 30303.

Disk usage: Check weekly. Ethereum state grows approximately 50–100 GB per month. At 4 TB total, you have roughly 24–36 months of headroom — plan for storage expansion before running out.

Reth version: Update Reth when new releases include performance improvements. Check the changelog at github.com/paradigmxyz/reth/releases monthly.

Conclusion

A self-hosted Reth node running on co-located bare-metal hardware is the infrastructure baseline for tier-1 Ethereum MEV operations in 2026. The combination of Reth's Rust-based performance, MDBX state storage, and co-location near major block builders creates a setup that shared RPC providers structurally cannot match for latency-sensitive execution.

FRB Agent integrating directly with a local Reth WSS endpoint eliminates every external network hop in the MEV execution path — from event detection to bundle simulation to relay submission. See the Flashbots Private RPC Guide for relay configuration once your node is live.