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

Created Jul 28, 2026 Updated Jul 28, 2026

Chainstack

TL;DR

An AI agent watching Arbitrum will miss events it was built to react to: blocks land every ~250ms, the public endpoint has no WebSocket, and polling eth_getLogs fast enough to keep up burns request budget while still arriving late. Worse, because Arbitrum settles to Ethereum L1, an agent can confidently act on a transaction that looks confirmed on L2 but has not yet finalized below. This guide shows how to get an Arbitrum RPC endpoint that survives an autonomous agent’s burst-and-parallel load and gives it real-time, finality-aware data.

What is an Arbitrum RPC endpoint

An Arbitrum RPC endpoint is the JSON-RPC interface your agent talks to in order to read state and submit transactions on Arbitrum One. It speaks the same Ethereum JSON-RPC dialect you already know — eth_call, eth_getLogs, eth_sendRawTransaction — but Arbitrum’s Nitro stack layers extra fields and a handful of L2-native methods on top. Transaction receipts carry l1BlockNumber and gasUsedForL1, blocks expose sendRoot and sendCount, and there are Arbitrum-only calls like eth_sendRawTransactionConditional and eth_sendRawTransactionSync that an agent submitting its own transactions will want to understand.

For an AI agent operating on Arbitrum, the endpoint is the only sensory organ it has. Concretely, it depends on the endpoint for:

Reading balances and contract state before deciding on an action (eth_call, eth_getBalance)
Streaming or polling on-chain events the agent reacts to (eth_getLogs, or eth_subscribe over WebSocket)
Simulating a transaction’s outcome before committing capital (eth_call, eth_estimateGas)
Broadcasting signed transactions and tracking their receipts (eth_sendRawTransaction, eth_getTransactionReceipt)
Reading L1 settlement fields to judge whether an action is truly final

You can review the full list of supported and Arbitrum-specific methods in the Arbitrum JSON-RPC methods documentation.

Endpoint quality is not a background concern for an agent the way it is for a human-driven dApp. A person retries a failed click; an autonomous agent in a tight reasoning loop interprets a dropped response, a throttle, or a stale read as ground truth and acts on it. On Arbitrum, where state changes four times a second, the gap between “what the endpoint returned” and “what is actually true on-chain” is where agents make expensive mistakes.

How Arbitrum RPC differs from Ethereum RPC

Arbitrum is EVM-equivalent, so most of your tooling carries over unchanged. But several differences directly shape how an agent should consume the endpoint:

Property	Ethereum L1	Arbitrum One
Block time	~12s	~250ms
Finality	Single-layer, ~13 min	L2 soft confirmation, final only after L1 settlement
Gas accounting	Execution only	Execution + L1 calldata posting (`gasUsedForL1`)
Pre-Nitro history	N/A	Blocks before #22,207,815 require `arbtrace_`, not `debug_`
Sequencer endpoint	N/A	Accepts only `eth_sendRawTransaction` and `eth_sendRawTransactionConditional`

These differences matter for agents specifically. The ~250ms block time means an event-driven agent generates far more polling pressure per minute than the same agent on Ethereum would. The split finality model means confirmation logic written for L1 will mislead an agent about when an action is irreversible. And the Nitro migration boundary means any agent that backfills historical data has to know which trace namespace to call depending on the block range — a provider that exposes only one will silently return nothing for the other.

Arbitrum RPC endpoint options

Public vs private Arbitrum RPC endpoints

For an autonomous agent, the public-versus-private decision comes down to one question: can the endpoint keep up with a process that never sleeps, never pauses to think, and fires requests in bursts? A public endpoint is built for occasional human-paced reads, not for an agent that produces dozens of parallel calls in the time it takes a person to blink.

Official public endpoints:

Mainnet: https://arb1.arbitrum.io/rpc
Testnet: https://sepolia-rollup.arbitrum.io/rpc

⚠️ The official Arbitrum public RPC offers no uptime, latency, or rate-limit guarantees, and exposes no WebSocket — it is described as a general-purpose endpoint for development and low-volume reads. The Arbitrum node providers documentation states plainly that any application depending on availability should use a third-party node provider. For an agent that reacts to events in real time, the missing WebSocket alone is disqualifying.

Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
WebSocket / `eth_subscribe`	Not available	Available
Burst & parallel load	Throttled, unpredictable	Provisioned RPS headroom
Archive + `arbtrace_*` access	Not available	Available

For an AI agent, the deciding factor is not cost — it is that a shared endpoint with no WebSocket forces the agent into high-frequency polling against 250ms blocks, which is exactly the load pattern that gets it throttled.

📖 For a detailed comparison of Arbitrum RPC providers, see Top 7 Arbitrum RPC providers for DeFi and production in 2026.

Full node vs archive Arbitrum node

For an agent, historical access on Arbitrum is about reconstructing context: replaying past trades, auditing its own prior decisions, or backfilling event history after downtime. The Nitro migration makes this non-trivial, because pre-migration history lives behind a different trace namespace than recent blocks.

Full node access	Archive node access
Current balances and contract state for live decisions	Replaying an agent’s historical positions and PnL
Recent event logs the agent reacts to	Backfilling event history after an outage beyond the recent window
Transaction simulation against latest state	Reconstructing pre-Nitro state via `arbtrace_*`

Archive access is what lets an analytics or audit agent answer “what did the chain look like when I made that decision” rather than only “what does it look like now.” Chainstack supports Arbitrum archive nodes, and an archive node exposes both the debug_* and arbtrace_* namespaces an agent needs to query across the Nitro boundary.

HTTPS vs WebSockets

For an event-reactive agent on a 250ms-block chain, this is the single most consequential transport choice. Polling means repeated eth_getLogs calls on an interval — and any interval long enough to be affordable is long enough to miss the event the agent was supposed to act on. A persistent WebSocket subscription pushes the event the moment it lands.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	One-off state reads, simulations, broadcasting transactions	Real-time event subscriptions, tracking new blocks, reacting to fills
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

Because the public Arbitrum endpoint provides no WebSocket, an agent that needs eth_subscribe("logs") or eth_subscribe("newHeads") must use a managed provider — there is no public path to real-time event delivery on Arbitrum.

How to get a private Arbitrum RPC endpoint with Chainstack

You can deploy a private Arbitrum RPC node on Chainstack in a few steps:

Log in to the Chainstack console (or create an account)
Create a new project
Select Arbitrum as your blockchain protocol
Choose network: Arbitrum One mainnet or Arbitrum 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

A minimal connection check with ethers.js looks like this:

const { ethers } = require("ethers");

var urlInfo = {
    url: 'YOUR_CHAINSTACK_ENDPOINT',
    user: 'USERNAME',
    password: 'PASSWORD'
};
// 42161 is the Arbitrum One chain ID; use 421614 for Arbitrum Sepolia
var provider = new ethers.providers.JsonRpcProvider(urlInfo, 42161);

provider.getBlockNumber().then(console.log);

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

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

Using Chainlist

Chainlist will add Arbitrum One to a wallet by chain ID, but it is a network directory, not an infrastructure provider — the endpoints it surfaces are the same unguaranteed public URLs. Any RPC URL pulled from Chainlist should be swapped for a managed endpoint before an agent goes anywhere near production.

Chainstack pricing for Arbitrum RPC

Chainstack bills on request units rather than opaque compute units, which makes an agent’s spend far easier to model when its request volume is bursty by nature. 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	$990+	400M+ RU	Unlimited	$5

Advanced options relevant to agent workloads:

Archive access (from the Growth tier) — archive requests consume 2 RU each; needed for arbtrace_* and historical reconstruction. Pairs with archive node deployments.
Unlimited Node — flat-fee RPS tiers (25–500 RPS) that remove per-request metering, well suited to an agent with sustained, predictable polling.
Dedicated Nodes — from $0.50/hour per node plus storage, for agents that need isolated, predictable throughput.

How to estimate monthly cost

Estimate your agent’s steady-state requests per second across reads, simulations, and subscriptions
Multiply by seconds per month to get baseline request units
Add archive multiplier (2 RU) for any historical or trace queries
Compare the total against plan RU ceilings and RPS limits
On Arbitrum specifically, budget for burst: a single agent reacting to 250ms blocks can spike to many times its average RPS during volatile periods — size for the peak, not the mean, or the agent self-throttles at the worst moment.

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
WebSocket reconnect + heartbeat logic, with event backfill after a dropped connection (agents must not silently miss fills)
L1 finality lag accounted for in the agent’s confirmation logic — do not treat an L2 soft confirmation as irreversible
Rate limiter on the agent’s own outbound calls to prevent accidental self-throttling against 250ms blocks

Benchmark candidate endpoints before committing: the Chainstack performance dashboard tracks Arbitrum RPC latency in real time.

Troubleshooting common Arbitrum RPC issues

Symptom	Cause	How to fix
`429 Too Many Requests`	Agent’s burst RPS exceeds a shared endpoint’s ceiling	Move to a managed endpoint with provisioned RPS; add a client-side rate limiter
WebSocket disconnects, agent stops reacting	Idle timeout or network drop with no reconnect	Implement reconnect + heartbeat, and backfill missed events with `eth_getLogs` over the gap
Agent acts on a “confirmed” tx that later reverts	Treated L2 soft confirmation as final before L1 settlement	Gate irreversible actions on L1 finality; read `l1BlockNumber` and settlement state
`arbtrace_*` returns empty for old blocks	Querying pre-Nitro history with `debug_*` (or vice versa)	Route trace calls by block range: `arbtrace_` before #22,207,815, `debug_` after
Gas estimates too low, tx underpriced	Ignored L1 calldata cost in gas accounting	Account for `gasUsedForL1`; re-estimate with `eth_estimateGas` against a current node
Missed events despite polling	Poll interval longer than 250ms block time	Switch to `eth_subscribe` over WebSocket instead of interval polling

Conclusion

The failure that actually catches agent teams on Arbitrum is not an outage — it is silence. The agent polls, the endpoint answers slowly or returns a stale log, and the agent makes a decision on data that was already obsolete by the time it arrived. There is no error to catch, no exception to log. The position is wrong, the trade is late, the audit trail is incomplete, and the only signal you get is a result that does not match what the chain actually did. On a chain producing blocks four times a second, that gap opens fast.

The pattern that works is direct: subscribe, do not poll. Put the agent on a managed endpoint with WebSocket so events arrive the moment they land, gate any irreversible action on L1 finality rather than L2 soft confirmation, and route trace queries by the Nitro block boundary so historical reconstruction never returns empty. Provision for burst RPS, not average — an autonomous agent’s worst moment to get throttled is also its busiest.

Start on the free tier to wire up and test your agent, then move to Dedicated Nodes when throughput predictability becomes non-negotiable.

Start building with Chainstack →

FAQ

Why can’t my AI agent just use the public Arbitrum RPC? Because the public endpoint has no WebSocket and no rate-limit guarantees. An agent that reacts to events is forced into high-frequency eth_getLogs polling against 250ms blocks, which both gets throttled and arrives late. Real-time agents need eth_subscribe, which only managed providers offer on Arbitrum.

How does L1 finality affect my agent’s transaction confirmation on Arbitrum? A transaction can look confirmed on Arbitrum’s L2 within moments but is only truly final once it settles to Ethereum L1. An agent that treats the L2 soft confirmation as irreversible can act on state that could still change. Read the l1BlockNumber and settlement fields and gate high-stakes actions on L1 finality.

Do I need an archive node for an Arbitrum agent? Only if the agent reconstructs history — replaying past positions, backfilling events after downtime, or running audits. If so, you need archive access that exposes both debug_* and arbtrace_*, because Arbitrum’s Nitro migration split historical trace data across the two namespaces at block #22,207,815.

How do I handle rate limits when my agent reacts to every block? Subscribe over WebSocket instead of polling to cut request volume, batch independent JSON-RPC calls into single requests, and add a client-side rate limiter so the agent never self-throttles. Then size your plan for peak burst RPS, not the average.

Which SDKs work for building an Arbitrum agent? Standard Ethereum tooling works unchanged: ethers.js, web3.js, web3.py, Hardhat, and Foundry. Just account for Arbitrum’s extra receipt fields (gasUsedForL1) and L2-native methods when your agent submits or inspects transactions.

What metrics should I monitor for an agent on Arbitrum? Track endpoint latency (p99, not average), error and throttle rates, WebSocket connection health, and the lag between event emission and the agent’s reaction. For agents that transact, also monitor the delay between L2 confirmation and L1 settlement so finality assumptions stay honest.