How to get an Ethereum RPC endpoint for MEV (2026 guide)

TL;DR

The moment your arbitrage transaction hits Ethereum’s public mempool, a sandwich bot can see it, copy it, and land ahead of you in the same block — you pay gas to fund someone else’s profit. That single design fact, plus the reality that block space is auctioned in roughly 12-second slots where 50ms of node latency decides who wins, is what separates a hobby bot from a profitable one. This guide shows how to get an Ethereum RPC endpoint built for MEV and arbitrage: private transaction routing, low-latency reads, and the historical data you need to backtest a strategy before you risk capital.

What is an Ethereum RPC endpoint

An Ethereum RPC endpoint is the JSON-RPC interface your bot uses to talk to an execution-layer node — reading state, simulating trades, and broadcasting signed transactions. For MEV and arbitrage specifically, the endpoint is not just a data tap; it is the path your transaction travels to a block builder. A standard endpoint drops your raw transaction into the public mempool, where it is visible to every searcher on the network before it is mined. An MEV-aware endpoint can instead route that same eth_sendRawTransaction payload privately to builders, skipping public exposure entirely.

For a searcher or arbitrage bot, the actions that depend on the endpoint are concrete and latency-sensitive:

• Streaming pending transactions and new blocks in real time (eth_subscribe to newPendingTransactions and newHeads)
• Simulating a trade before committing to it (eth_call, eth_estimateGas, and debug_traceCall for full execution traces)
• Reading pool reserves, prices, and balances across DEXs (eth_getLogs, eth_call against contracts)
• Broadcasting the winning transaction or bundle (eth_sendRawTransaction)
• Confirming inclusion and reconstructing what happened (eth_getTransactionReceipt, eth_getBlockByNumber)

You can review the full list of supported methods in the Ethereum JSON-RPC API documentation.

In MEV, endpoint quality is measured in milliseconds and in whether your order flow stays private. A read that arrives one block late is a price you can no longer trade on, and a transaction that surfaces in the public mempool is an opportunity you have just handed to a faster bot.

How MEV and arbitrage RPC differs from standard Ethereum RPC

Most Ethereum RPC guides optimize for correctness and uptime. MEV optimizes for time and secrecy, and those two priorities reshape what you need from an endpoint. The difference is not the chain — it is the workload.

Property	Standard Ethereum RPC	MEV / arbitrage RPC
Transaction path	Public mempool, visible to all	Private route to block builders
Latency tolerance	Seconds are fine	Sub-200ms; 50ms decides a backrun
Node geography	Anywhere	Co-located near builder/relay infrastructure
Mempool access	Optional	Core data source for opportunity detection
Simulation needs	Occasional eth_call	Constant debug_traceCall / state simulation
Historical data	Recent blocks	Deep archive for strategy backtesting

These differences explain why a generic shared endpoint quietly costs you money on Ethereum. A profitable backrun has to be spotted, simulated, and submitted inside a single 12-second slot, and the public mempool turns every transaction you broadcast into a signal your competitors can trade against. Provider selection for MEV is therefore a decision about transaction privacy and propagation speed first, and raw request volume second.

Ethereum RPC endpoint options

Public vs private Ethereum RPC endpoints

For MEV and arbitrage, the public-versus-private decision is not about reliability — it is about whether your strategy survives contact with the mempool. A public endpoint broadcasts your intent to the entire network; a private, managed endpoint can route around it.

Official public endpoints:

• Mainnet: https://cloudflare-eth.com
• Testnet (Sepolia): https://rpc.sepolia.org

⚠️ Public Ethereum endpoints broadcast every transaction to the open mempool and apply shared rate limits that throttle the moment your bot starts polling each block. There is no private order flow and no latency guarantee — both are disqualifying for competitive MEV. The Ethereum docs themselves recommend using professional RPC providers for production workloads, in the Ethereum JSON-RPC API documentation.

Property	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Transaction privacy	None — public mempool	Private builder routing available
Latency	Best-effort, shared	Low-latency, regional
Archive access	Not available	Available

For MEV, a managed endpoint is not a convenience upgrade — it is the only configuration where your transactions are not visible to the bots you are competing against before they land.

📖 For a detailed comparison of Ethereum RPC providers, see Best Ethereum RPC providers in 2026.

Full node vs archive Ethereum node

For an arbitrage strategy, historical data is not a compliance nice-to-have — it is how you know whether the strategy was ever profitable. Backtesting a DEX arbitrage model means replaying past blocks at the exact state they held, which a full node cannot give you beyond its recent-block pruning window.

Full node access	Archive node access
Live pool reserves and prices for execution	Replaying historical DEX states to backtest a strategy
Real-time mempool and new-block subscriptions	Reconstructing past sandwich and arbitrage opportunities
Current account balances and nonce tracking	Historical eth_getLogs backfills across the full chain

If you are tuning a strategy, you will spend more time against an archive node than a full one. Replaying months of swaps to measure how often an opportunity actually appeared — and how much it paid after gas — requires querying historical state with debug_traceCall and eth_call at past block heights, which is exactly what a Chainstack archive node is built for. Archive nodes consume double the request units of a full node, which is worth factoring into a backtesting budget.

HTTPS vs WebSockets

For MEV, persistent connections are not optional. Polling for new blocks over HTTPS adds a full round-trip of latency to the one event your bot most needs to react to instantly — a new block or a new pending transaction. A WebSocket subscription pushes that event to you the moment the node sees it.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Simulation calls, state reads, broadcasting	newPendingTransactions and newHeads streams, live opportunity detection
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

A practical MEV setup uses both: WebSocket subscriptions to detect opportunities as they appear, and HTTPS calls for simulation and the final transaction send. The WebSocket stream is your eyes; the HTTPS path is your trigger finger.

How to get a private Ethereum RPC endpoint with Chainstack

1. Log in to the Chainstack console (or create an account).
2. Create a new project
3. Select Ethereum as your blockchain protocol
4. Choose network: Ethereum Mainnet or Sepolia / Holesky testnet
5. Deploy the node
6. Open Access and credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

On Ethereum mainnet, MEV protection is included by default at the deploy step — the add-on ships enabled and shows as Included in checkout, so your eth_sendRawTransaction payloads route privately to block builders from the very first request instead of hitting the public mempool. If a strategy actually needs public-mempool visibility, click Disable on the MEV Protection card before deploying. WARP and Unlimited Node, by contrast, are opt-in and start disabled. The same default applies to BNB Smart Chain, Arbitrum, and Base mainnet nodes.

For competitive workloads you can deploy a private Ethereum RPC node on Chainstack as a regional Dedicated Node placed close to builder infrastructure, and pair it with Trader Nodes for transaction propagation. The connection itself uses standard tooling — here is the ethers.js setup from the Chainstack docs:

import { ethers } from 'ethers';

// HTTP provider for simulation, state reads, and broadcasting
const httpProvider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ENDPOINT");
httpProvider.getBlockNumber().then(console.log);

// WebSocket provider for real-time block and mempool subscriptions
const wsProvider = new ethers.WebSocketProvider("YOUR_CHAINSTACK_WS_ENDPOINT");
wsProvider.on("block", (blockNumber) => {
    // Each new block is a fresh window to detect arbitrage opportunities
    console.log("New block:", blockNumber);
});

📖 For the full integration guide, see the Chainstack Ethereum tooling documentation.

You can also access Chainstack Ethereum RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

For the privacy and propagation side of an MEV stack, Chainstack Trader Nodes route transactions through a bloXroute BDN — landing them up to 2.5x faster than regular peer-to-peer propagation on EVM chains — and MEV protection sends your signed eth_sendRawTransaction payload directly to block builders instead of the public mempool, removing front-running exposure.

Using Chainlist

Ethereum is on Chainlist, which makes it easy to add the network and a public RPC URL to a wallet like MetaMask. Chainlist is a convenience directory, not an infrastructure provider — the endpoints it lists are shared and public, so any RPC URL you pull from it should be replaced with a managed endpoint before you run a single dollar of real arbitrage capital through it.

Chainstack pricing for Ethereum RPC

Chainstack bills on request units rather than opaque compute-unit multipliers, so a bot that fires thousands of calls during a volatility spike stays predictable instead of detonating your invoice. See the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3M RU	25	$20
Growth	$49/mo	20M RU	250	$15
Pro	$199/mo	80M RU	400	$12.50
Business	$499/mo	200M RU	600	$10
Enterprise	from $990/mo	400M+ RU	Unlimited	$5

Advanced options relevant to MEV and arbitrage workloads:

• Dedicated Nodes — from $0.50/hour per node plus storage, for regional placement and latency control
• Unlimited Node — flat-fee RPS tiers (from $149/mo at 25 RPS) that remove per-request billing, ideal for bots that spike unpredictably
• Warp Transactions — $0.15 per transaction for bloXroute-accelerated propagation
• Archive node — from $49/mo, for backtesting against full chain history (archive calls consume 2x request units)

How to estimate monthly cost

1. Count your steady-state reads per second (mempool subscriptions, block subscriptions, state polls)
2. Add simulation calls — debug_traceCall and eth_call per opportunity evaluated
3. Multiply by your active trading hours to get a monthly RU baseline
4. Add transaction sends, priced separately if you use Warp Transactions
5. Buffer hard for volatility: an arbitrage bot polling every block and simulating each candidate can multiply its request volume several times over during a single market event — size for the spike, not the average, or self-throttling will cost you the exact opportunities that pay best

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• Private transaction routing confirmed — your sends never touch the public mempool
• Node co-located in the region closest to builder/relay infrastructure to minimize propagation latency
• Rate limiter in place so a per-block polling loop does not self-throttle during volatility

You can benchmark endpoint latency before committing with the Chainstack performance dashboard.

Troubleshooting common Ethereum RPC issues

Issue	How to fix
429 Too Many Requests	Move off shared public endpoints to a managed plan or an Unlimited Node; add a client-side rate limiter
WebSocket disconnects mid-stream	Implement reconnect with heartbeat, and backfill missed blocks via eth_getBlockByNumber on reconnect
Your transactions keep getting front-run	Stop broadcasting to the public mempool — route sends through MEV-protected private builder submission instead
Backrun lands too late, in the next block	Reduce node latency with a regional Dedicated Node and accelerated propagation; a 50ms saving changes inclusion outcomes
eth_getLogs query times out on large ranges	Narrow the block range, or run the historical backfill against an archive node
Backtest results don’t match live state	You are querying pruned state on a full node; replay against an archive node at the exact historical block height

Conclusion

The failure mode in Ethereum MEV is rarely a crash — it is a slow, invisible leak. Your bot works, your code is correct, and you still lose, because every profitable transaction you broadcast to the public mempool gets read and front-run before it mines, and every read that travels through a shared endpoint arrives a beat after the searcher who paid for a faster path. You do not get an error message. You get a success rate that is quietly 40% lower than it should be, and a strategy that looked profitable in backtests bleeding out in production.

The pattern that works is not complicated, but it is non-negotiable: route your transactions privately to builders so they are never exposed to the mempool, place your node in the region closest to the infrastructure that produces blocks, and backtest against archive data before you commit capital. Pair a Dedicated Node for low-latency reads with private transaction submission for your sends. Do not run real arbitrage capital through a public endpoint — not once.

Start on the free tier to wire up your reads and simulations, then move to dedicated, MEV-protected infrastructure before you go live.

FAQ

Why does the public mempool hurt arbitrage bots on Ethereum? Every transaction you send to the public mempool is visible to other searchers before it is included in a block. For arbitrage, that means a faster bot can copy your trade and land it ahead of you in the same block, capturing the profit while you pay gas. Private transaction routing to block builders is the only way to keep your order flow from becoming a public signal.

How much does latency actually matter for Ethereum MEV? Ethereum produces a block roughly every 12 seconds, and the competition to land a backrun or arbitrage inside that slot is decided in milliseconds. A 50ms difference in node latency is enough to flip a profitable opportunity into a missed one, which is why MEV-focused setups co-locate nodes near builder infrastructure rather than running on a generic shared endpoint.

Do I need an archive node to build an arbitrage strategy? For backtesting, yes. A full node prunes older state, so replaying historical DEX prices and reconstructing past opportunities to validate a strategy requires querying past block heights — exactly what an archive node provides. For live execution, a full node with low-latency reads is sufficient.

Can I run an MEV bot with ethers.js and a standard Ethereum endpoint? You can read state and broadcast transactions with ethers.js against any standard endpoint, but a competitive MEV bot also needs private transaction submission and low-latency propagation that public endpoints do not offer. The tooling stays the same; the endpoint underneath it is what changes.

What is the difference between MEV protection and Warp Transactions on Chainstack? MEV protection routes your signed transaction privately to block builders so it bypasses the public mempool, removing front-running exposure. Warp Transactions accelerate propagation through a bloXroute BDN, landing transactions up to 2.5x faster than regular peer-to-peer broadcasting on EVM chains. They solve different parts of the same problem — privacy and speed — and are often used together. On Ethereum mainnet, MEV protection is included by default when you deploy a node (you can Disable it on the deploy screen), whereas WARP is opt-in.

Which metrics should I monitor for an Ethereum MEV endpoint? Track end-to-end request latency, transaction inclusion rate (how often your sends land), error and throttling rates, and WebSocket connection stability. For arbitrage specifically, also monitor the gap between when you detect an opportunity and when your transaction is broadcast — that delay is where most lost profit hides.

Additional resources

• Sending Trader Node Warp transactions with web3.js, ethers.js, web3.py, and ethClient.go — Chainstack Docs tutorial
• Chainstack Ethereum tooling documentation
• Ethereum JSON-RPC API documentation — official Ethereum docs
• AI trading agent stack — building an autonomous EVM trading agent on Chainstack
• More Ethereum tutorials and articles on the Chainstack Blog
• Best Ethereum RPC providers in 2026