Proxies for MEV Bots: Architecture, RPC Distribution, and Security

Maximal Extractable Value (MEV) represents the profit a bot can extract by reordering, inserting, or censoring transactions within a block. MEV bots compete in a high-stakes environment where milliseconds determine profit or loss, and where adversaries actively try to exploit your infrastructure. Proxy architecture is not optional in this space — it is a core component of any competitive MEV operation.

This article covers the proxy infrastructure required for MEV bots, from RPC distribution patterns to security hardening against adversarial attacks.

Understanding MEV and Why Infrastructure Matters

MEV bots operate in three primary categories:

Sandwich attacks: Detecting pending transactions in the mempool and placing orders before and after them
Arbitrage: Identifying price discrepancies across DEX pools and executing atomic swaps
Liquidations: Monitoring lending protocols for undercollateralized positions and executing liquidations

All three strategies require constant mempool monitoring, rapid transaction submission, and connection to multiple block builders. Each of these operations generates substantial RPC traffic that must be distributed across multiple endpoints and IP addresses.

A single MEV bot monitoring Ethereum’s mempool can generate over 50,000 RPC calls per minute. Without proxy distribution, you will be rate-limited within seconds on any RPC provider.

MEV Bot Proxy Architecture

The Three-Layer Model

Layer 1: Mempool Monitoring
  └── Distributed WebSocket connections via proxy pool A
  └── Connected to 5-10 RPC providers simultaneously

Layer 2: Opportunity Analysis
  └── Local computation (no proxy needed)
  └── Price feeds via proxy pool B

Layer 3: Transaction Submission
  └── Direct connections to block builders (Flashbots, MEV Blocker)
  └── Backup submission via proxy pool C to public mempool

Layer 1: Mempool Monitoring Infrastructure

Mempool monitoring requires persistent WebSocket connections to multiple Ethereum nodes. Each connection streams pending transactions in real time, and your bot must process them before competing bots do.

import asyncio
import websockets
import json
from typing import Dict, Set

class MempoolMonitor:
    def __init__(self, rpc_ws_endpoints: list, proxy_pool: list):
        self.endpoints = rpc_ws_endpoints
        self.proxies = proxy_pool
        self.seen_txs: Set[str] = set()
        self.pending_queue = asyncio.Queue()

    async def connect_to_node(self, ws_url: str, proxy: str):
        """Maintain persistent WebSocket connection through proxy."""
        import aiohttp

        while True:
            try:
                connector = aiohttp.TCPConnector()
                session = aiohttp.ClientSession(connector=connector)

                # Subscribe to pending transactions
                async with session.ws_connect(
                    ws_url,
                    proxy=f"http://{proxy}"
                ) as ws:
                    # Subscribe to newPendingTransactions
                    subscribe_msg = {
                        "jsonrpc": "2.0",
                        "method": "eth_subscribe",
                        "params": ["newPendingTransactions"],
                        "id": 1
                    }
                    await ws.send_json(subscribe_msg)

                    async for msg in ws:
                        if msg.type == aiohttp.WSMsgType.TEXT:
                            data = json.loads(msg.data)
                            if "params" in data:
                                tx_hash = data["params"]["result"]
                                if tx_hash not in self.seen_txs:
                                    self.seen_txs.add(tx_hash)
                                    await self.pending_queue.put(tx_hash)

            except Exception as e:
                print(f"Connection lost to {ws_url}: {e}")
                await asyncio.sleep(1)
                # Reconnect automatically
            finally:
                await session.close()

    async def start_monitoring(self):
        """Launch parallel WebSocket connections across all nodes."""
        tasks = []
        for i, endpoint in enumerate(self.endpoints):
            proxy = self.proxies[i % len(self.proxies)]
            task = asyncio.create_task(
                self.connect_to_node(endpoint, proxy)
            )
            tasks.append(task)
        await asyncio.gather(*tasks)

Layer 2: Transaction Analysis

Once your bot identifies a pending transaction, it needs to simulate the transaction’s effect on DEX pool states. This requires rapid eth_call requests through your proxy infrastructure.

class TransactionAnalyzer:
    def __init__(self, proxy_manager):
        self.proxy_manager = proxy_manager

    async def simulate_sandwich(self, target_tx: dict,
                                 pool_address: str) -> dict:
        """Simulate a sandwich attack to determine profitability."""
        conn = self.proxy_manager.get_connection("ethereum")

        # Simulate front-run transaction
        front_run_call = {
            "jsonrpc": "2.0",
            "method": "eth_call",
            "params": [{
                "to": pool_address,
                "data": self._encode_swap(
                    target_tx["amount"],
                    direction="front"
                ),
                "from": self.bot_address,
            }, "pending"],  # simulate against pending state
            "id": 1
        }

        async with aiohttp.ClientSession() as session:
            async with session.post(
                conn["rpc"],
                json=front_run_call,
                proxy=conn["proxy"]["http"],
                timeout=aiohttp.ClientTimeout(total=1)
            ) as resp:
                result = await resp.json()
                return self._calculate_profit(result)

Layer 3: Transaction Submission

For transaction submission, MEV bots use private channels like Flashbots Protect or MEV Blocker to avoid front-running by other bots. However, backup submission through the public mempool requires proxies.

class TransactionSubmitter:
    def __init__(self, proxy_pool: list):
        self.proxy_pool = proxy_pool
        self.builder_endpoints = [
            "https://relay.flashbots.net",
            "https://rpc.mevblocker.io",
            "https://builder0x69.io",
        ]

    async def submit_bundle(self, signed_txs: list, target_block: int):
        """Submit transaction bundle to multiple builders."""
        bundle = {
            "jsonrpc": "2.0",
            "method": "eth_sendBundle",
            "params": [{
                "txs": signed_txs,
                "blockNumber": hex(target_block),
            }],
            "id": 1
        }

        tasks = []
        for builder in self.builder_endpoints:
            proxy = random.choice(self.proxy_pool)
            tasks.append(self._submit_to_builder(builder, bundle, proxy))

        results = await asyncio.gather(*tasks, return_exceptions=True)
        return [r for r in results if not isinstance(r, Exception)]

    async def _submit_to_builder(self, builder_url, bundle, proxy):
        async with aiohttp.ClientSession() as session:
            async with session.post(
                builder_url,
                json=bundle,
                proxy=f"http://{proxy}",
                timeout=aiohttp.ClientTimeout(total=2)
            ) as resp:
                return await resp.json()

RPC Distribution Strategy

Provider Diversification

Never rely on a single RPC provider. Distribute across at least three providers:

Provider	Use Case	Rate Limit Approach
Alchemy	Primary mempool monitoring	3+ API keys with proxy rotation
QuickNode	Backup monitoring + simulation	Dedicated endpoints per proxy
Self-hosted node	Transaction submission + validation	Direct connection
BlastAPI	Price feed monitoring	Rotate via mobile proxies

Proxy-to-RPC Mapping

Map specific proxies to specific RPC endpoints to maintain consistent sessions and avoid triggering rate limit resets:

PROXY_RPC_MAPPING = {
    "proxy-1.example.com:8080": [
        "https://eth-mainnet.g.alchemy.com/v2/KEY_1",
        "https://eth-mainnet.g.alchemy.com/v2/KEY_2",
    ],
    "proxy-2.example.com:8080": [
        "https://cool-dawn-cherry.quiknode.pro/KEY/",
        "https://rough-winter-log.quiknode.pro/KEY/",
    ],
}

Security Considerations for MEV Bots

MEV is an adversarial environment. Other bots will actively try to exploit your infrastructure.

Private Key Protection

Never send private keys through proxy connections. Sign transactions locally and send only signed transaction data through proxies.

# CORRECT: Sign locally, submit through proxy
signed_tx = w3.eth.account.sign_transaction(tx_dict, private_key)
# Send signed_tx.rawTransaction through proxy

# WRONG: Never do this
# w3.middleware_onion.add(construct_sign_and_send_raw_middleware(private_key))
# This would send the private key through the proxy connection

IP Fingerprint Isolation

Your MEV bot’s IP addresses should never be linked to your personal identity or other trading operations. Use dedicated mobile proxies exclusively for MEV operations, separate from any other trading activity.

RPC Response Validation

Malicious RPC providers or compromised proxies can return false data to trick your bot into unprofitable trades:

async def validated_rpc_call(method, params, min_confirmations=2):
    """Query multiple RPCs and require consensus."""
    results = []
    for _ in range(min_confirmations + 1):
        conn = proxy_manager.get_connection("ethereum")
        try:
            result = await rpc_call(conn, method, params)
            results.append(result)
        except Exception:
            continue

    if len(results) < min_confirmations:
        raise Exception("Insufficient RPC responses for consensus")

    # Check that responses agree
    if len(set(str(r) for r in results)) == 1:
        return results[0]
    else:
        # Responses disagree - use majority
        from collections import Counter
        counter = Counter(str(r) for r in results)
        return results[0]  # Simplified; use proper consensus logic

Rate Limit Obfuscation

Sophisticated RPC providers track request patterns, not just volume. Randomize your request timing slightly to avoid detection. For a deeper understanding of how rate limiting and IP-based restrictions work, the proxy glossary is a useful reference.

import random

async def obfuscated_request(session, url, payload, proxy):
    # Add slight random delay to break pattern detection
    jitter = random.uniform(0.001, 0.01)  # 1-10ms jitter
    await asyncio.sleep(jitter)
    async with session.post(url, json=payload, proxy=proxy) as resp:
        return await resp.json()

Proxy Infrastructure Sizing for MEV

MEV Strategy	WS Connections	RPC Calls/min	Recommended Proxies
Simple arbitrage	3-5	5,000-10,000	5-8
Sandwich attacks	5-10	20,000-50,000	10-20
Liquidations	5-8	10,000-30,000	8-15
Multi-strategy	10-20	50,000+	20-40

Monitoring Your MEV Infrastructure

Track these metrics for each proxy in your MEV infrastructure:

WebSocket uptime: Percentage of time each mempool connection stays alive
RPC response latency (p50, p95, p99): Critical for time-sensitive MEV
Rate limit hits: Number of 429 responses per proxy per hour
Transaction inclusion rate: Percentage of submitted bundles that land on-chain
Proxy rotation frequency: How often each proxy cycles to a new IP

Conclusion

MEV bot proxy infrastructure requires a fundamentally different approach than standard trading bot proxies. The combination of persistent WebSocket connections, high-volume RPC calls, and adversarial security requirements demands careful architectural planning. Build your infrastructure in layers, isolate proxy pools by function, and never compromise on security — in MEV, your infrastructure is your competitive advantage.