Arbitrum RPC Nodes & Endpoints

Arbitrum One RPC URLs you can use right now

Third-party endpoints, free and shared. Nitro's fast blocks make them feel excellent until a trace-heavy or log-heavy job arrives and the rate limiter does too.

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://arb1.arbitrum.io/rpc");
const blockNumber = await provider.getBlockNumber();
console.log("Arbitrum One block:", blockNumber);

Where shared Arbitrum endpoints run out

Arbitrum One produces blocks roughly every 250 milliseconds, which changes the math of sharing an endpoint. On a shared public RPC, a single network round trip can span several Arbitrum blocks, so a bot that reads state, decides, and submits is often acting on a chain that has already moved on. Add the rate limits public endpoints apply during volatile markets, exactly the moments perps and arbitrage strategies need throughput, and the free URL becomes the most expensive part of the stack.

A dedicated Arbitrum RPC node gives your workload the whole node: no shared quotas, room for arbtrace calls and wide eth_getLogs ranges, and the option to consume the sequencer feed for the earliest possible view of transaction ordering. On BLAZED.sh the model goes further, running your container on the node host itself so reads stay on a local socket.

Nitro's block model, and why block.number surprises people

Arbitrum Nitro runs its own block sequence, but it also exposes Ethereum's, and code written for mainnet often conflates them. Inside a contract, block.number reports the L1 block, not the Arbitrum one, which means any logic that treats it as a local clock, a deadline, or a per-block counter behaves differently here than it did in testing. Arbitrum provides ArbSys.arbBlockNumber() for the L2 sequence, and getting the two the wrong way round is one of the more common porting bugs on this chain.

The same split shows up at the RPC layer. Timestamps come from the sequencer and advance with L2 blocks, while the batch that anchors those blocks to Ethereum lands later, so an indexer that assumes one block equals one settled unit of history will drift. None of this is a defect; it is the cost of a rollup being fast at the top and settled underneath. It does mean an Arbitrum indexer needs to be explicit about which of the two clocks each query is asking about, rather than inheriting the assumption from mainnet code.

Arbitrum RPC latency is a distance problem

With 250 millisecond blocks, latency budgets on Arbitrum are tighter than almost anywhere else in the EVM world. A remote gateway adds tens to low hundreds of milliseconds per call across the public internet, which is several block times, before any provider-side queueing. Co-location removes that path: on our live Ethereum product, calls from a container on the node host complete in under 10 milliseconds, and dedicated Arbitrum nodes will follow the same architecture. No remote endpoint, however fast its marketing page, can beat not crossing the network at all.

What dedicated Arbitrum node hosting will cost

BLAZED.sh prices node access in per-request credits granted monthly by your subscription, with a deliberately narrow weight spread: most RPC methods cost a single credit, and only a handful of heavy operations cost more. Dedicated Arbitrum One nodes will launch on the same credit model, with the waitlist deciding rollout priority.

Trading workloads on Arbitrum are read-heavy, and reads are single-credit calls, so even a tight evaluation loop maps to a predictable monthly credit count rather than a compute-unit surprise.

Perfect for

What is Arbitrum One?

Arbitrum Nitro compiles the EVM to WASM and uses fraud proofs to settle to Ethereum, giving developers near-perfect EVM compatibility at a fraction of mainnet gas. It has among the highest total value locked of any L2, so a large share of on-chain trading, lending, and perps activity flows through Arbitrum RPC endpoints. Reads with chain ID 42161 behave like any Ethereum node, but Arbitrum exposes a couple of chain-specific methods (for example arbtrace and L1 gas estimation) that matter for accurate fee prediction. High-frequency strategies and indexers feel every millisecond of RPC latency here, which is exactly the pain a co-located, dedicated node removes.

Arbitrum RPC: frequently asked questions