Arbitrum RPC: A Developer's Guide (Chain ID 42161, ~250ms Blocks, Fake Gas Limit)

Arbitrum One is the rollup most Ethereum code runs on unmodified, and that is exactly the problem: it does run, right up until a number stops meaning what your code assumes it means. The block gas limit is a placeholder. The priority fee is zero. safe and finalized move on a scale of minutes, not the seven days everyone associates with optimistic rollups. None of these will throw an error at you — they will just quietly make your dashboards, alerts and fee logic wrong.

Everything below was measured today through https://rpc.swiftnodes.io/rpc/arbitrum, so you can re-run every probe yourself.

The essentials

• Chain ID: 42161 (0xa4b1)
• Block height at time of writing: ~506,697,453
• Block time: ~250 ms (measured 18 blocks in 4 seconds)
• Gas token: ETH, 18 decimals
• Base fee: ~0.02 gwei (0.020224 gwei measured)
• Priority fee: eth_maxPriorityFeePerGas returns 0
• Block gas limit: 1,125,899,906,842,624 — that is exactly 2⁵⁰, a sentinel, not capacity
• Stack: Nitro, sequencer-ordered, proofs posted to Ethereum
• WebSocket: supported, eth_subscribe verified working
• Archive state: not served on this route — see Archive access

The latency of the endpoint you pick matters more here than on most chains. At 250 ms blocks, a provider that adds 300 ms of round trip makes you feel every round trip roughly once per block.

Connecting: the setup

curl

# Chain ID — expect 0xa4b1 (42161)
curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0xa4b1"}

# Latest block
curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# Fee ceiling — the number you actually want
curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x1336750"}   = 0.020145744 gwei

viem

Stating the chain explicitly keeps working on every version, and it puts the field that matters in front of you:

import { createPublicClient, http, defineChain } from 'viem';

const arbitrum = defineChain({
  id: 42161,
  name: 'Arbitrum One',
  nativeCurrency: { name: 'Ether', symbol: 'ETH', decimals: 18 },
  rpcUrls: {
    default: { http: ['https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY'] },
  },
});

const client = createPublicClient({ chain: arbitrum, transport: http() });

const blockNumber = await client.getBlockNumber();
const gasPrice = await client.getGasPrice(); // ~0.02 gwei

ethers v6

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider(
  'https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY',
  42161,
);

await provider.getBlockNumber();

What's the same as Ethereum

The eth_* surface is complete and standard: eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_sendRawTransaction, filters, eth_feeHistory, the pending/safe/finalized tags. Solidity contracts, ABIs, viem, ethers, Foundry and Hardhat all work as-is. That compatibility is genuinely excellent and it is why Arbitrum won.

Blocks even carry the fields you expect, which is what makes the next section easy to miss.

What's different from Ethereum

The block gas limit is a sentinel

Fetch a block and read gasLimit:

curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}'

The block I pulled reported gasLimit: 0x4000000000000 — that is 1,125,899,906,842,624, exactly 2⁵⁰ — with gasUsed of 398,374 in the same block. Any calculation of the form "this block is 0.0000354% full" or "I have 1.1 quadrillion gas of headroom" is nonsense. Nitro does not bound blocks the way L1 does; capacity is governed by the sequencer and by a separate per-second gas supply.

Practical consequence: never size a transaction against the block gas limit here. Use eth_estimateGas for the transaction you are sending, and treat the block's gasLimit as decoration. If you run a mempool-style backlog monitor or a "block utilization" alert copied from an L1 dashboard, it is reporting a constant on Arbitrum.

Priority fee is zero, and that is not an error

curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_maxPriorityFeePerGas","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x0"}

eth_maxPriorityFeePerGas answers with 0x0. The RPC is not broken — the fee market is not a two-dimensional auction here, so there is no tip component to estimate. Inclusion is the sequencer's decision, not a bidding contest between validators.

Two things follow. The common maxFeePerGas = 2 × baseFee + tip recipe computes 2 × baseFee + 0, which is fine but adds nothing; and "bump the priority fee to unstick a stuck transaction" does not work as an operational lever on this chain. If your retry logic escalates tips, it is burning effort on a parameter the sequencer ignores. Read estimating gas properly for where these heuristics stop transferring.

safe and finalized are minutes, not days

This is the one that surprises people most. Measured directly:

"Optimistic rollup means seven days" describes the challenge window for exiting to L1, not how these block tags advance. They move on a minutes scale, tracking what nodes have confirmed among themselves. So if your code waits for finalized believing it has crossed the dispute window, it is waiting roughly twenty minutes for a guarantee that the tag does not carry.

For value-bearing operations, decide what you actually need. If you need "the sequencer will not reorder this", safe is a reasonable marker. If you need "this is unarguably true on Ethereum", track the Rollup contract's confirmed roots on L1 — a different query entirely. Soft vs hard finality on L2s covers the distinction.

Consensus fields are placeholders

The same block object carries difficulty: 0x1, nonce: 0x0000000000273449, and uncles: []. There is no proof of work and no uncle mechanism; these are fixed or structural values kept so L1-shaped code keeps parsing. It also carries one field L1 blocks do not have: l1BlockNumber, an explicit pointer into Ethereum. That pairing is useful — it is how you tie an Arbitrum block back to L1 context — but do not expect it from tools written against mainnet types.

System addresses answer with 0xfe

A check written as "does code exist at this address?" behaves oddly. Querying Arbitrum's system addresses returned the single byte 0xfe rather than contract bytecode, while a nearby unused address returned plain 0x. So a naive non-empty-code test reads as "something is deployed here" and gives you nothing to decode. Check the specific address list you care about rather than inferring from code size.

The arb_* namespace may not be there

Every Arbitrum-specific method I tried through our endpoint was refused:

{"error":{"code":-32601,"message":"the method arb_getStorageRoot does not exist/is not available"}}

That applies to the arb_* names I probed (arb_getBlockReceipts, arb_getStorageRoot, arb_getChainConfig, arb_getNodeInterfaceVersion, arb_getAddressTable). Availability of this namespace is a provider-by-provider decision, so treat it as absent until you have confirmed it on your own endpoint — and if you are migrating from a provider that exposed it, that migration is where things break, not in the standard eth_* calls. The -32601 shape is covered in JSON-RPC error codes, decoded.

The methods you'll actually use

Nothing exotic; the traps are all in what the numbers mean. The general RPC endpoint primer and the Ethereum reference are the baseline this one is a diff against.

Archive access

Be deliberate here if your workload reads history, because Arbitrum archive is a weak point right now.

A state read at an early block on the default route returns a pruned node's honest answer — missing trie node … as a JSON-RPC error at HTTP 200 — and asking for archive routing says so plainly:

{"error":"No archive node available for this chain","chain":"arbitrum"}

That is how it behaves as of 2026-09-19. It did not read that way when this post was first written: ?archive=1 used to answer

{"error":"Backend node error","message":"Unexpected token 'A', \"Access tok\"... is not valid JSON"}

which was an expired upstream key (Access token missing or invalid., served as text/plain) surfacing through a failed JSON parse. Fixed, but worth keeping as the cautionary version, because both lessons generalise:

1. Verify archive with a real historical query before you build on it. Ask for eth_getBalance at block 2 and see what comes back. A provider that serves eth_blockNumber beautifully may not be keeping state.
2. An error's shape can lie about its category. "Archive requests require a personal token" is a billing statement wearing the clothes of an RPC failure, and a JSON parse error can wear the clothes of an outage that isn't real. Distinguishing capability limits from transient faults from plain bugs is the whole game in retry design — retry and backoff covers the taxonomy, and full node vs archive node explains why this tier costs what it costs.

Recent-state reads, receipts and logs across recent ranges work normally. If you need deep historical state on Arbitrum, confirm it with your provider explicitly rather than assuming from the word "archive" appearing on a pricing page.

WebSocket subscriptions

Verified end to end on this chain — subscribe, then a real head within about a second:

+414ms   OPEN
+620ms   eth_subscribe -> 0x77888af906b7608f…
+743ms   newHeads notification, block 506,697,680

const ws = new WebSocket('wss://rpc.swiftnodes.io/ws/arbitrum?key=YOUR_API_KEY');
ws.onopen = () => ws.send(JSON.stringify({
  jsonrpc: '2.0', id: 1, method: 'eth_subscribe', params: ['newHeads'],
}));

At 250 ms blocks, treat notifications as a signal to re-read rather than a queue you must not miss — you will drop heads during any reconnect. Surviving WebSocket reconnects without losing events is the pattern, and our Arbitrum WebSocket write-up covers this chain's specific failure modes.

Compared to the L2s around it

Base shares the sequencer model but not the fee shape or the sentinel limit. The zkEVM columns are in its own guide, and the sequencer concept behind all of these is unpacked in what a sequencer is.

Production considerations

Poll like you mean it. At 250 ms blocks a 12-second poll interval is roughly 48 blocks of blind spot. Either subscribe or shorten the interval, and bound requests with JSON-RPC batching where you need many reads.

Never derive capacity from gasLimit. It is a constant. Estimate per transaction.

Stop escalating tips. They are zero here by design; use eth_gasPrice and a margin.

Re-label what "finalized" means in your own code. If a risk model treats it as the seven-day window, it is 20 minutes of comfort instead of a week of certainty.

Index with confirmations you can defend. Chain reorganisation here is sequencer-level, not PoW-style; handling chain reorgs in indexers is the pattern.

Confirm archive before depending on it, as above, on any chain you choose.

Choosing an Arbitrum RPC endpoint

1. What is its end-to-end latency to you? On a 250 ms chain, the round trip is the whole user experience. Measure it yourself from your own region rather than trusting a marketed number — public versus paid endpoints covers what actually moves once you are past the free tier.

2. What happens when its upstream is behind or rate-limited? A single upstream gives you its outages and its 429s. Failover across independent endpoints is the difference between a blip and an incident, which is the point of routing through a layer that tries several upstreams per request and benches any that fall behind the chain head.

3. Will it tell you the truth about capabilities? The good answer is a measured one. Check eth_getCode on a chain-specific address, try an arb_* method, request a balance at block 2. A provider that admits what it does not serve saves you a production discovery.

The short version

Arbitrum One (chain ID 42161) speaks standard eth_* on ~250 ms blocks, so nearly all Ethereum code and tooling works unchanged. What changes is meaning: the block gasLimit is the sentinel 2⁵⁰ rather than capacity, eth_maxPriorityFeePerGas returns 0 because inclusion is sequenced not auctioned, difficulty and nonce are placeholders, blocks carry an extra l1BlockNumber, arb_* methods may be refused, and safe/finalized sat about 3,022 and 4,480 blocks behind head — roughly 13 and 19 minutes — not the seven-day dispute window. Archive state reads are currently the weak spot on this route, so verify any historical read with a real query.

For Arbitrum RPC with per-request failover across independent upstreams and a working eth_subscribe, grab a free API key and point your app at:

https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY

One key covers all 75 chains, and the free tier is 2 requests per second — enough to run every probe above, including the finality measurements, while you check the numbers for yourself.