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

TL;DR

On Arbitrum, a liquidation bot that works correctly against recent blocks will silently produce incomplete trace data for any pre-Nitro history — because post-migration blocks require debug_traceTransaction while classic blocks require arbtrace_transaction, and most Ethereum analytics tooling defaults to the wrong namespace without raising an error. Compound that with the explicit absence of WebSocket support on Arbitrum’s public RPC, and production DeFi infrastructure fails before any application logic runs. This guide covers the endpoint types, provider requirements, and exact setup that liquidation bots, LP monitors, and price feed relays on Arbitrum One actually need.

What is an Arbitrum RPC endpoint

Arbitrum One is an Ethereum Layer 2 optimistic rollup built on the Nitro stack. Its RPC interface exposes the full Ethereum JSON-RPC method set — eth_*, net_*, and web3_* — but extends it with Arbitrum-specific fields in transaction objects, receipts, and block headers that reflect the sequencer and L1 batch posting architecture underneath.

What user-facing DeFi actions depend on the endpoint:

• Balance reads and eth_call for reading pool state in Uniswap V3, Aave V3, GMX, and other deployed protocols
• eth_getLogs and event subscriptions for tracking swap events, liquidation calls, borrow events, and position updates
• eth_sendRawTransaction for submitting liquidation, arbitrage, and LP rebalancing transactions at sequencer speed
• debug_traceTransaction for tracing post-Nitro transactions — required for MEV analysis and liquidation forensics
• arbtrace_* methods for pre-Nitro (classic) block inspection — absent from most provider documentation, but required for any historical DeFi analytics
• eth_estimateGas — returns a two-component estimate covering both L2 execution gas and the L1 calldata cost posted to Ethereum
• eth_getBlockByNumber with Arbitrum-specific block header fields: l1BlockNumber, sendCount, and sendRoot

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

The quality of a DeFi deployment on Arbitrum depends on whether the endpoint surfaces all of this data consistently — a provider that blocks debug_* or does not index pre-Nitro traces will silently omit liquidation history that any serious risk model depends on.

How Arbitrum RPC differs from Ethereum RPC

Arbitrum is EVM-compatible, so standard Ethereum tooling connects without changes to syntax or SDK configuration. But several Arbitrum-specific behaviors affect how DeFi infrastructure behaves at the RPC layer in ways that are not visible until something breaks.

Property	Ethereum Mainnet	Arbitrum One
Block time	~12 seconds	~250 ms
Throughput	~15–30 TPS	Up to ~40,000 TPS theoretical (Nitro)
Gas token	ETH	ETH
Consensus	Proof-of-Stake	Optimistic Rollup (sequencer + L1 batch posting)
Transaction finality	~12 minutes (2 epochs)	Soft: ~1 second; Hard: ~1 week (L1 challenge period)
Trace namespace	debug_*	debug_* (post-Nitro) and arbtrace_* (pre-Nitro)
Gas accounting	Single gasUsed field	Two-part: L2 execution + gasUsedForL1 (calldata cost)
block.number in Solidity	Returns current L2 block	Returns L1 block number with a delay of several minutes

The dual trace namespace is the DeFi-specific detail most providers omit from their documentation. Arbitrum One migrated to Nitro in August 2022, creating a block history split: classic blocks require arbtrace_* queries, post-Nitro blocks require debug_*. For a protocol-level analytics backfill or LP fee reconstruction job spanning the full chain history, this split is a hard requirement — not a minor edge case.

Why DeFi on Arbitrum demands more from RPC than a standard dApp

Most dApps query state: read a balance, render a price, display a portfolio. DeFi on Arbitrum does all of that simultaneously across thousands of positions, at block speed, with financial consequences for every missed event or stale read.

A liquidation bot monitoring Aave V3 on Arbitrum polls health factors across active positions every new block (~250ms cadence), subscribes to LiquidationCall events via WebSocket, and fires raw transactions when a position becomes undercollateralized — all while competing against other bots targeting the same positions. At that request frequency, a shared public endpoint does not just degrade; it hits the Offchain Labs rate limit and starts returning 429 errors on precisely the calls that matter.

The DeFi-specific RPC load on Arbitrum looks like this:

• Price feeds: Continuous eth_call to on-chain oracles or DEX pool slots — Uniswap V3 slot0 reads are among the most frequent calls on the entire network
• Event indexing: eth_getLogs across multiple block ranges, with filter topics matching swap, liquidity, and borrow events from multiple protocol contracts simultaneously
• Liquidation triggers: Transaction simulation via eth_estimateGas before submission, then eth_sendRawTransaction with precise timing
• Historical backfills: Archive-depth eth_getLogs to reconstruct pool fee history, TVL snapshots, or a position’s full lifecycle

None of this is compatible with a rate-limited public endpoint. Chainstack’s web3 builders infrastructure is built for this class of workload: high-throughput, subscription-heavy, and archive-requiring.

Real-time price feed and on-chain event indexing requirements

The two most latency-sensitive RPC operations in Arbitrum DeFi are price reads and event subscriptions. Getting either wrong introduces slippage, missed liquidations, or stale position data — errors that compound in automated systems.

Price feeds via polling require a consistent eth_call cadence to oracle contracts or DEX pool state. On Arbitrum’s ~250ms block time, a price feed polling every block generates roughly 345,600 requests per day per monitored asset. At that volume, even a 5ms increase in p99 response time creates a price lag that can cross the threshold where a liquidation opportunity becomes a losing trade.

Chainlink and Pyth feeds on Arbitrum are updated more frequently than their Ethereum mainnet equivalents because block time is shorter. This means on-chain oracle data is fresher, but it also means any provider latency that causes your eth_call to lag behind the oracle update cycle introduces systematic mispricing.

Event subscriptions via WebSocket are the production standard for event-driven DeFi — eth_subscribe with a logs filter for LiquidationCall, Swap, and Borrow events. The immediate problem is that Arbitrum’s public RPC explicitly has no WebSocket support, forcing subscription logic onto managed providers. The secondary problem is that WebSocket connections to poorly maintained providers drop silently on Arbitrum — and a dropped subscription on a liquidation bot means missed events with no error signal.

The operational discipline for production event indexing:

• Maintain both a WebSocket subscription (primary) and a polling fallback with gap detection
• On reconnect, backfill missed logs with eth_getLogs from the last confirmed block to current head
• Monitor subscription lag — if the last received event timestamp drifts more than 2 blocks behind the current head, treat the connection as stale

MEV exposure and how endpoint choice affects it

Arbitrum One’s sequencer processes transactions in FCFS (first-come, first-served) order rather than through a fee auction. There is no public pending mempool visible to external observers. This changes MEV dynamics compared to Ethereum mainnet but does not eliminate competition.

Sandwich attacks are structurally less viable on Arbitrum because the sequencer does not expose pending transactions to third parties before inclusion. However, time-sensitive MEV still exists at the application layer — bots monitor on-chain state changes and race to respond within the same block. For DeFi teams, this means:

• A liquidation bot races against other bots watching the same Aave V3 health factors
• An arbitrage bot between Uniswap V3 and Camelot competes for the first post-price-update transaction
• A liquidity rebalancing system operates within a window measured in sequencer queue slots

Endpoint latency determines whether you win or lose these races. A geographically distant provider node introduces variable round-trip time that costs position in the sequencer queue. A shared-infrastructure provider routing multiple tenants through the same connection compounds the problem.

There is no private mempool relay on Arbitrum equivalent to Ethereum’s Flashbots. Dedicated Nodes isolate your traffic from shared infrastructure, eliminating contention from other tenants’ requests — the closest equivalent to a private submission path available on Arbitrum today.

Archive access for historical liquidity and analytics backfills

On-chain DeFi analytics on Arbitrum requires archive access for any query that reaches back beyond the full node’s pruning window — typically beyond ~128 blocks on non-archive providers.

The Arbitrum-specific archiving challenge is the two-era block history: pre-Nitro blocks (before block 22207818) are classic blocks with a different internal format, and backfills crossing this boundary require a provider that handles both eras without silently omitting data. Most analytics tools miss this entirely.

DeFi use cases that require Arbitrum archive node access:

Analytics workload	Why archive is required
Historical LP fee income reconstruction	eth_getLogs from pool deployment date — often far outside the full-node pruning window
Aave V3 liquidation price history	LiquidationCall events since protocol deployment — required for risk model training data
GMX open interest history	Position open/close events across the full protocol lifetime
TVL snapshots at arbitrary block heights	eth_call to read pool state at historical blocks — requires archive beyond the pruning window
Protocol audit and forensic analysis	Complete trace of all historical contract interactions using arbtrace_* or debug_*
Pendle yield strategy backtesting	Historical yield rate reconstruction across full vesting periods

Chainstack supports Arbitrum archive data — available on both Global Nodes and Dedicated Nodes — covering both pre-Nitro and post-Nitro chain history. For large archive backfills, a Dedicated Node eliminates query timeout issues that appear on shared archive endpoints under sustained load.

Arbitrum RPC endpoint options

Public vs private Arbitrum RPC endpoints

On Arbitrum, the public vs private endpoint decision is not primarily about reliability — it is about whether your DeFi infrastructure can function at all. The two features most critical for production DeFi (WebSocket support and archive depth) are both absent from the official public endpoint.

Official public endpoints:

• Mainnet: https://arb1.arbitrum.io/rpc
• Testnet (Sepolia): https://sepolia-rollup.arbitrum.io/rpc

⚠️ Arbitrum’s public RPC explicitly does not support WebSocket connections. This is an architectural limitation documented by Offchain Labs, not a temporary constraint. For any DeFi application relying on eth_subscribe for real-time event subscriptions, a managed provider is a hard requirement. The Arbitrum docs recommend using professional RPC providers for production workloads.

Feature	Public endpoint	Managed private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Local development and testing	Production DeFi workloads
WebSocket support	Not available	Available
Archive access	Not available	Available
Pre-Nitro trace access	Not documented	Full arbtrace_* and debug_*

📖 For a detailed comparison of Arbitrum RPC providers including archive access, trace namespace support, and DeFi-specific pricing, see Top 7 Arbitrum RPC providers for DeFi and production in 2026.

The absence of WebSocket on the public endpoint is the hard architectural limit for DeFi: you cannot run an event-driven liquidation system, an LP rebalancer, or a real-time price feed relay without a managed provider. Any team building serious DeFi on Arbitrum needs an RPC endpoint for DeFi workloads — one that supports eth_subscribe — and the public endpoint cannot provide it.

Full node vs archive Arbitrum node

The full vs archive distinction on Arbitrum is felt specifically by DeFi analytics and risk tooling that queries historical pool state, not just current balances.

Full node access	Archive node access
Real-time price feeds from on-chain oracles	Historical eth_getLogs from pool deployment date
Current account balances and collateral ratios	Aave V3 liquidation event history since protocol launch
Live Uniswap V3 pool slot0 state reads	GMX position open/close events across the full protocol lifetime
Transaction submission and gas estimation	TVL reconstruction at arbitrary historical block heights
Post-Nitro debug_* traces on recent blocks	Pre-Nitro arbtrace_* traces for classic block history

Chainstack supports Arbitrum archive data including both pre-Nitro and post-Nitro chain history, accessible through Global Nodes and Dedicated Nodes.

HTTPS vs WebSockets

Arbitrum’s ~250ms block cadence makes transport choice more consequential than on slower chains. With blocks arriving roughly four times per second, a polling strategy that opens a new HTTP connection per block generates significant overhead — and still lags a persistent WebSocket subscription by the time the TCP handshake completes.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Price reads, state queries, tx submission	Liquidation triggers, LP event monitoring, block head subscriptions
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

WebSocket is not available on Arbitrum’s public endpoint — it is a managed-provider-only feature. For DeFi infrastructure where subscription lag translates directly to missed liquidation opportunities, the reconnect and heartbeat logic required for WebSocket is mandatory overhead, not optional complexity.

How to get a private Arbitrum RPC endpoint with Chainstack

To deploy a private Arbitrum RPC node on Chainstack:

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

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

const urlInfo = {
    url: 'YOUR_CHAINSTACK_ENDPOINT'
};
// Network ID 42161 for Arbitrum One mainnet; 421614 for Arbitrum Sepolia testnet
const provider = new ethers.providers.JsonRpcProvider(urlInfo, 42161);

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

📖 For the full integration guide including Hardhat, Foundry, ethers.js, and web3.js setup, 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 indexes Arbitrum One and Arbitrum Sepolia, making it easy to add the network to MetaMask or other wallets with a single click. However, Chainlist aggregates public RPC endpoints from community submissions — it is not an infrastructure provider and does not offer WebSocket support, archive access, or rate-limit guarantees. Any RPC URL added via Chainlist should be replaced with a managed endpoint before deploying to production DeFi infrastructure.

Chainstack pricing for Arbitrum RPC

Chainstack bills on a flat Request Unit model — one RU per standard method call, two RU per archive call — which forecasts more predictably than compute-unit models that multiply cost based on method type. See the full Chainstack pricing page for plan details and overage rates.

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

Advanced options:

• Archive Node add-on — available for Arbitrum; archive calls count at 2 RU per call
• Unlimited Node add-on — from $149/month, flat rate with 25–500 RPS tiers, no per-request billing
• Dedicated Nodes: from $0.50/hour compute + $0.01/20 GB/hour storage

How to estimate monthly cost

1. Identify baseline request volume: count daily eth_call, eth_getLogs, and eth_sendRawTransaction calls across all contracts monitored
2. Add subscription overhead: each eth_subscribe call counts as 1 RU on connect, plus 1 RU per received event
3. Separate archive from full-node calls: archive queries (any block beyond ~128 from head) cost 2 RU — backfill jobs can consume a plan’s monthly allocation in hours
4. Multiply by 30 for the monthly estimate
5. For DeFi-specific cost modeling: a liquidation bot polling every block on Arbitrum generates ~345,600 requests per day per monitored contract pair. A single TVL history backfill running eth_getLogs from protocol deployment date can push tens of millions of RU in a single job. Plan a tier that absorbs burst archive usage without hitting overage on backfill runs.

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set (2s is a reasonable ceiling for DeFi latency-sensitive calls)
• Retry logic with exponential backoff implemented
• Credentials stored in env or secret manager — never hardcoded
• Monitoring for latency, error rate, and throttling in place
• Alerts for sustained degradation (p99 above threshold, error rate above 1%)
• WebSocket reconnect logic with missed-event backfill on reconnect
• Archive provider confirmed for any eth_getLogs job spanning beyond 128 blocks from head
• Both debug_* and arbtrace_* trace namespaces confirmed available on your provider before launch
• L1 finality lag accounted for in settlement confirmation UX — Arbitrum hard finality requires ~1 week
• gasUsedForL1 field parsed separately in gas accounting logic — Arbitrum receipts include it alongside standard gasUsed

Troubleshooting common Arbitrum RPC issues

Issue	Symptom	How to Fix
429 Too Many Requests	Requests fail under load	Move to a managed provider with RPS limits matched to your DeFi workload volume
WebSocket disconnects	Subscription events stop arriving without error signal	Add reconnect logic with backfill: on reconnect, call eth_getLogs from last confirmed block to current head
Missing trace data for historical blocks	debug_traceTransaction returns empty or null for blocks before 22207818	Use arbtrace_transaction for pre-Nitro classic blocks — confirm your provider supports both trace namespaces
Stale price feed	eth_call to oracle or pool slot returns a value older than expected	Provider is lagging behind the sequencer — verify block freshness with eth_blockNumber before trusting state reads
Gas estimate causes transaction failure	eth_estimateGas returns a value that results in an out-of-gas error	Arbitrum estimates include L1 calldata cost in gasUsedForL1 — your gas buffer must account for both components
Address mismatch on bridge transactions	L1→L2 transactions show an unexpected from address	Arbitrum aliases the L1 sender address on cross-chain transactions — the from field returns the aliased address
Archive calls fail for historical blocks	eth_getLogs or eth_call returns an error for blocks beyond ~128 from head	Confirm the endpoint is an archive node — full nodes prune state outside their window

Conclusion

The failure mode is not a crash — it is silence. A DeFi analytics pipeline migrated from Ethereum to Arbitrum will process every recent block without error, then return empty results for pre-Nitro historical queries because the provider does not surface arbtrace_*. The risk model runs on partial data. The first missed liquidation does not trigger an exception; it simply does not happen, and the cause requires forensic investigation to identify.

Production DeFi on Arbitrum requires a single managed endpoint that handles both trace namespaces, supports WebSocket for event subscriptions, provides archive access for historical queries, and maintains the latency needed to compete in the sequencer’s FCFS queue. A provider missing any one of these is architecturally incompatible with serious DeFi infrastructure on Arbitrum One — not a performance limitation, but a functional one.

FAQ

Why does my trace query return empty results on some Arbitrum transactions?

Arbitrum One’s block history has two distinct trace namespaces. Blocks before block 22207818 are pre-Nitro (“classic”) blocks and require arbtrace_transaction and related arbtrace_* methods. Blocks at or after that number use debug_traceTransaction. A provider that only exposes debug_* will silently return empty results for all pre-Nitro traces without raising an error. This is the most common silent failure pattern in Arbitrum DeFi analytics and backfill jobs.

Does Arbitrum have a public mempool I can monitor for MEV?

No. Arbitrum One’s sequencer processes transactions FCFS without exposing a public mempool to external observers. MEV on Arbitrum is primarily time-based: bots race to respond to on-chain state changes within the same block rather than extract value from pending transaction ordering. This makes endpoint latency and geographic proximity to the sequencer the primary competitive variables — not mempool access.

Why does Arbitrum’s public endpoint not support WebSocket?

Offchain Labs explicitly provides no WebSocket support on public endpoints. This is not a temporary constraint — it is an architectural policy to manage shared infrastructure costs. Any DeFi application requiring eth_subscribe for event-driven logic must use a managed provider. There is no workaround using the public endpoint.

How do I account for the L1 finality delay in a DeFi application?

Arbitrum transactions have two finality levels: L2 soft finality (sequencer confirmation, ~1 second) and L1 hard finality (posted to Ethereum and past the challenge period, ~1 week). For most DeFi operations — swaps, borrows, liquidations — L2 soft finality is sufficient and what most protocols treat as confirmed. For bridge withdrawals or cross-chain settlement requiring L1 guarantees, the full challenge period must elapse. Build this distinction explicitly into any confirmation UX or settlement logic.

Can I use standard Ethereum monitoring tools with Arbitrum?

Most EVM monitoring tools work without modification for current-state queries. The exceptions are tools relying on trace APIs — these need to account for the arbtrace_* / debug_* split for pre/post-Nitro blocks. Tools like Tenderly handle Arbitrum natively, but custom dashboards using raw debug_* calls need to be updated to handle pre-Nitro history. Gas dashboards also require updates to parse the Arbitrum-specific gasUsedForL1 field from transaction receipts.

What RPS tier do I need for a production Arbitrum liquidation bot?

A single bot monitoring 100 Aave V3 positions and polling health factors every block generates approximately 2,400 RPC calls per minute (100 positions × 4 blocks/second). Add event subscriptions, gas estimation, and transaction submission, and a single-protocol liquidation bot typically needs 250–400 RPS sustained with 3–5x burst capacity during liquidation windows. The Growth plan (250 RPS) handles a single-protocol bot; the Pro plan (400 RPS) is the right baseline for multi-protocol DeFi infrastructure.

Additional resources

• Arbitrum L1 to L2 messaging smart contract — Chainstack tutorial
• Chainstack Arbitrum tooling documentation
• Arbitrum developer documentation
• RPC infrastructure for RWA: EVM node requirements — Chainstack Blog
• Top 7 Arbitrum RPC providers for DeFi and production in 2026 — Chainstack Blog
• More Arbitrum tutorials and articles on the Chainstack Blog