How to get an Ethereum RPC endpoint for AI agents (2026)

Created Jul 31, 2026 Updated Aug 3, 2026

Chainstack

TL;DR

Choosing an Ethereum RPC endpoint for an AI agent is a different problem than choosing one for a dApp. A single agent can fire 50 to 200 JSON-RPC calls in the time it takes you to refill your coffee, and on a shared public endpoint the one 429 that lands mid-cycle can leave a transaction half-submitted, with on-chain state your agent can no longer reason about. Public endpoints were tuned for smooth, sequential human traffic, not the bursty parallel loops that autonomous agents run for hours. This guide shows how Ethereum RPC behaves under agent load and how to get a private endpoint that survives it.

What is an Ethereum RPC endpoint

An Ethereum RPC endpoint is the JSON-RPC interface your code talks to in order to read and write to the Ethereum network without running your own execution and consensus clients. Every call, whether it comes from a wallet, a backend, or an AI agent, is an HTTP or WebSocket request carrying a method name like eth_call or eth_sendRawTransaction and a set of params, answered by a node that holds Ethereum state. On Ethereum specifically, that node speaks the standardized eth_, net_, and web3_ namespaces, plus the Beacon Chain API on the consensus layer and the heavier debug_ and trace_ namespaces when you need execution-level introspection.

What depends on the endpoint, in practice:

Reading account balances and nonces with eth_getBalance and eth_getTransactionCount
Calling view functions and simulating execution with eth_call and eth_simulateV1
Pulling event history with eth_getLogs for indexing and reconciliation
Broadcasting signed transactions with eth_sendRawTransaction and polling eth_getTransactionReceipt
Subscribing to new heads, logs, and pending transactions over WebSocket with eth_subscribe
Replaying historical execution with debug_traceTransaction and trace_block on an archive node

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

Endpoint quality stops being an abstraction the moment an autonomous agent is the caller. A human waits out a slow response, but an agent’s reasoning chain stalls, retries, and sometimes acts on stale data. When the probability of hitting at least one P99-tail response climbs past 60% across a 100-call workflow, a “mostly fast” endpoint is not fast enough. The tail is where agent logic breaks.

How Ethereum RPC load differs for AI agents

The methods an AI agent calls are the same ones a dApp calls. What is different, and what actually drives endpoint selection here, is the shape of the traffic. A standard “how Ethereum differs from chain X” table is the wrong comparison for this guide; the meaningful contrast is human dApp load versus autonomous agent load on the same Ethereum endpoint.

Dimension	Human dApp traffic	AI agent traffic
Request timing	Smooth, user-paced	Jagged bursts fired during LLM reasoning cycles
Concurrency	Sequential per user	Deep parallelism across concurrent sub-agents
Session length	Seconds to minutes	Continuous loops running hours or longer
Tolerance for a dropped call	High, the user just retries	Low, a 429 can corrupt mid-chain state
Heavy-method mix	Rare `eth_getLogs` / trace	Routine `debug_traceBlock`, batched `eth_call`

These differences matter for provider selection because the failure modes that a shared endpoint hides under human traffic become routine under agent traffic. Burst RPS trips rate limits during tight reasoning loops, long-running cycles accumulate rate-limit pressure that a one-shot transaction never exposes, and the archive and trace calls agents lean on cost more and are throttled harder on public infrastructure.

Ethereum RPC endpoint options

Public vs private Ethereum RPC endpoints

For AI agents, the public-versus-private decision is not really about reliability averages. It is about the tail and the state machine behind it. A shared endpoint can serve 99% of an agent’s calls perfectly and still break the agent on the 1% that arrive as a 429 in the middle of a sign-and-broadcast sequence, leaving an on-chain action the agent then has to reconcile blind.

Official public endpoints:

Mainnet: https://ethereum-rpc.publicnode.com
Testnet (Sepolia): https://ethereum-sepolia-rpc.publicnode.com

⚠️ Public Ethereum endpoints aggressively rate-limit by RPS and RPM, cap eth_getLogs block ranges, and routinely disable debug_ and trace_ methods entirely. Even Ethereum’s own guidance points developers to node services rather than self-hosting for production reliability, and agent workloads make that gap impossible to ignore.

Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limiting	Aggressive RPS/RPM caps	No aggressive throttling
`debug_`/`trace_` access	Usually disabled	Full support
Archive depth	Recent blocks only	Full history available

For a deeper comparison of the field, see Best Ethereum RPC providers for production workloads in 2026.

The point for agents is concrete. When one bot can emit 200 calls per coffee break across parallel sub-agents, a managed endpoint with predictable headroom is not an upgrade. It is the condition under which the agent’s reasoning stays consistent with chain state.

Full node vs archive Ethereum node

For an Ethereum AI agent, the full-versus-archive question maps directly onto what the agent reasons about: live decisions need current state, while any agent that backfills, audits, or replays needs history older than the roughly 128 blocks a full node keeps.

Full node access	Archive node access
Real-time balance and price reads for live trading decisions	Historical `eth_getLogs` backfills for position reconstruction
Current `eth_call` against deployed contracts	`debug_traceTransaction` replay for post-mortem analysis
Broadcasting and receipt polling for execution agents	State-at-block queries for compliance and reconciliation

An on-chain analyst agent that replays historical instruction flow, or a treasury agent that reconciles balances across past blocks, cannot run on a full node. Those calls require an archive node. On Chainstack, Ethereum archive access is available, with archive requests metered at a higher request-unit weight than standard calls. If your agent only acts on live state, a full node is the cheaper and correct choice.

HTTPS vs WebSockets

For event-driven agents, the choice between HTTPS and WebSockets is the choice between polling and being pushed to, and polling is exactly the pattern that burns through an agent’s rate budget. A price-monitor agent that polls an oracle every block over HTTPS generates sustained, repetitive load. The same agent on a WebSocket subscription gets the update pushed once and spends nothing waiting.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	One-shot reads, `eth_call`, transaction broadcast	`newHeads`/`logs` subscriptions for monitoring agents
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

WebSocket support is available on Chainstack Ethereum endpoints. Public endpoints often expose WebSockets only with tight connection caps, so any agent relying on subscriptions for event-driven logic should validate WebSocket stability on its provider before launch.

How to get a private Ethereum RPC endpoint with Chainstack

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

Once your endpoint is live, deploy against a private Ethereum RPC node on Chainstack using your SDK of choice. A minimal ethers.js connection looks like this:

import { ethers } from 'ethers';

// HTTPS provider — swap in your Chainstack endpoint
const provider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ENDPOINT");

// One meaningful read: current block height confirms connectivity
provider.getBlockNumber().then((block) => {
  console.log(`Connected to Ethereum at block ${block}`);
});

📖 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.

Using Chainlist

Ethereum is on Chainlist (chain ID 1), so wallets like MetaMask can pull a network configuration from it in a couple of clicks. Useful as it is, Chainlist is a directory, not an infrastructure provider, and the public URLs it lists carry no SLA and throttle hard. Treat any Chainlist RPC URL as a development convenience and swap it for a managed endpoint before your agent touches production.

Chainstack pricing for Ethereum RPC

Chainstack meters usage in request units rather than opaque per-method compute credits, which makes an agent’s spend far easier to forecast when its call volume swings with reasoning load. 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	20M RU	250	$15
Pro	$199	80M RU	400	$12.50
Business	$499	200M RU	600	$10
Enterprise	from $990	400M+ RU	Unlimited	$5

Advanced options relevant to agent workloads:

Archive requests are metered at a higher request-unit weight, so budget for it if your agent backfills history. Archive access starts from $49/mo; see Chainstack archive data.
The Unlimited Node add-on offers flat-fee RPS tiers when an agent fleet’s request volume is high but steady.
Dedicated Nodes start from $0.50/hour per node (plus storage) and remove rate-limit contention entirely, the cleanest fit for agents that cannot tolerate a shared-tenant 429.

How to estimate monthly cost

Estimate steady-state reads per agent per minute and multiply by your agent count.
Add execution-path calls, broadcasts plus receipt polling, per expected transaction.
Weight archive and trace calls at their higher request-unit cost.
Convert to monthly request units and match to a plan tier.
Then add agent-specific headroom: a single misconfigured polling loop or a fan-out of concurrent sub-agents can multiply baseline load several times over in seconds. Size for the burst, not the average, or the burst will size your 429s for you.

Production readiness checklist

Primary + fallback RPC provider configured
Request timeout policy set
Retry logic with exponential backoff and jitter implemented
Credentials stored in env/secret manager (never hardcoded)
Monitoring for latency, error rate, and throttling
Alerts for sustained degradation
Rate limiter in the agent runtime to prevent self-inflicted 429s during burst loops
debug_/trace_ and archive depth confirmed on your provider if the agent backfills or replays
WebSocket reconnect + missed-event backfill logic for subscription-driven agents

Benchmark candidate endpoints before committing. The Chainstack performance dashboard shows live latency you can compare against your agent’s tail-latency budget.

Troubleshooting common Ethereum RPC issues

Issue	Cause	How to fix
`429 Too Many Requests` during burst loops	Burst RPS exceeds the shared endpoint’s rate cap	Move to a managed endpoint; add a client-side rate limiter and exponential backoff with jitter
WebSocket disconnects mid-subscription	Idle timeout or connection cap on the endpoint	Implement reconnect + heartbeat, then backfill missed `newHeads`/`logs` on reconnect
`eth_getLogs` returns “query returned more than N results”	Block range too wide for the endpoint’s log limit	Split the query into smaller block ranges; use an archive node for deep backfills
`debug_`/`trace_` method not found	Namespace disabled on the public endpoint	Use a private endpoint with the `debug` namespace enabled
Transaction confirmed in code but state looks stale to the agent	Acting before finality, on a block that later reorgs	Wait for finality (~2 epochs) before the agent treats state as settled
Nonce too low / replacement errors under parallel sub-agents	Multiple sub-agents racing the same signing key	Centralize nonce management per key; serialize broadcasts from one account

Conclusion

The failure that catches AI agent teams off guard on Ethereum is not an outage. It is a 429 that arrives in the 0.6 seconds between signing a transaction and confirming it landed. The agent’s reasoning loop assumes the broadcast succeeded, moves on, and now its model of the chain disagrees with the chain itself. That class of bug is brutal to diagnose because the endpoint looks healthy in aggregate; the damage hides entirely in the tail, exactly where agent logic is least able to recover.

The pattern that works is simple and non-negotiable: put agents on dedicated or managed Ethereum infrastructure with rate headroom sized for burst, not average, load. Run a client-side rate limiter so the agent never throttles itself, replace polling with WebSocket subscriptions wherever the workflow is event-driven, and confirm archive and trace access before launch if the agent ever looks backward. Public endpoints are for building the agent, not for running it.

Spin up a free Ethereum endpoint on the Developer plan to prototype, then move to Dedicated Nodes when your agent goes live.

Start building with Chainstack →

FAQ

Which Ethereum SDKs work with a Chainstack endpoint? All of them. A Chainstack Ethereum endpoint is standard JSON-RPC, so ethers.js, viem, web3.js, web3.py, and Nethereum connect by swapping in your endpoint URL. For agent runtimes, ethers.js and viem are the most common choices because their provider abstractions make connection pooling and fallback configuration straightforward.

Is a public Ethereum endpoint enough to run an AI agent? For prototyping, yes; for a live agent, no. Public endpoints throttle by RPS and RPM and frequently disable the debug_/trace_ methods agents lean on. The deeper problem is the latency tail: across a 100-call reasoning chain, the odds of hitting at least one slow P99 response approach two-thirds, and that single stall is enough to desync an agent from chain state.

How do I keep my agent from hitting rate limits on Ethereum? Put a rate limiter inside the agent runtime so it self-paces below your plan’s RPS, batch multi-variable reads into single eth_call round-trips, and replace block-by-block polling with WebSocket subscriptions. Then size your plan for burst load, because a fan-out of concurrent sub-agents multiplies request volume far faster than a sequential dApp ever would.

What metrics should I monitor for an Ethereum agent endpoint? Track P99 latency (not just average), 429 rate, WebSocket disconnect frequency, and request-unit consumption against your plan ceiling. For agents, tail latency and throttle rate are the leading indicators of trouble, because they predict the mid-cycle stalls that corrupt agent state long before average latency moves.

Do AI agents on Ethereum need an archive node? Only if the agent reads history older than roughly the last 128 blocks. Historical eth_getLogs backfills, debug_traceTransaction replay, or state-at-block reconciliation all require archive access. Live trading and execution agents that act on current state run fine on a full node, which is cheaper.

How does Ethereum finality affect transaction confirmation for an agent? Ethereum reaches finality after about two epochs (~13 minutes), and blocks can reorg before then. An execution agent that treats a single confirmation as settled risks acting on a state that gets reorged out, so build a finality wait into the agent’s confirmation logic and let its reasoning commit only to truly settled state.