Arbitrum Endpoint: Chain Settings, RPC URLs, and Debugging

Quick decision guide: which Arbitrum endpoint should you use?

If you are building a dApp, indexer, or backend service that talks to Arbitrum, the first decision is whether to use a public endpoint, a dedicated node, or an API service. Here is a quick way to decide:

• Prototyping or low-volume testing: Use the public Arbitrum RPC endpoint. It is free and fine for development, but it is shared and may be rate-limited under heavy load.
• Production dApp or service with consistent traffic: Use a managed RPC API service like OnFinality. You get higher throughput, WebSocket support, and access to debug/trace methods without running your own infrastructure.
• Heavy archival or custom indexing workloads: Consider a dedicated node. This gives you exclusive access to a node, full control over method availability, and predictable performance.

For most teams, a managed API service is the right balance of cost and reliability. You can start with the public endpoint, then move to a dedicated node or API plan as your traffic grows. Check the RPC pricing page to compare options.

What is an Arbitrum endpoint?

An Arbitrum endpoint is a URL that your application uses to send JSON-RPC requests to the Arbitrum network. It is the entry point for reading blockchain data, sending transactions, and subscribing to events. Endpoints are typically provided by node operators, either as public services or through commercial RPC providers.

Arbitrum is an Ethereum Layer 2 that uses optimistic rollups. It inherits Ethereum's security while offering lower fees and higher throughput. To interact with Arbitrum, you need an endpoint that points to either Arbitrum One (mainnet) or Arbitrum Sepolia (testnet).

Arbitrum chain settings at a glance

Here are the key chain settings you need to configure your wallet or dApp:

These settings are used when adding Arbitrum to MetaMask or other wallets. The public RPC URLs are provided by OnFinality and are suitable for development and light usage.

How to connect to Arbitrum with ethers.js

Here is a simple example using ethers.js to connect to Arbitrum One and read the latest block number:

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

const provider = new ethers.JsonRpcProvider("https://arbitrum.api.onfinality.io/public");

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Current block number:", blockNumber);
}

getBlockNumber();

For WebSocket subscriptions, you can use the WebSocket endpoint (if available) to listen for new pending transactions or block headers. OnFinality supports WebSocket on Arbitrum One; check the Arbitrum network page for the exact URL.

Using curl for a quick JSON-RPC call

You can test an endpoint with a simple curl command. For example, to get the latest block number on Arbitrum One:

curl -X POST https://arbitrum.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

This returns a hexadecimal block number. You can use similar calls for eth_getBalance, eth_call, or eth_getLogs.

Common failure modes and how to debug them

Even with a reliable endpoint, you may encounter issues. Here are common failure modes and how to diagnose them:

How to choose between public RPC, API service, and dedicated node

Your choice depends on your workload. Here is a comparison to help you decide:

OnFinality offers all three options. You can start with the public endpoint and upgrade as needed. See the supported RPC networks page for a full list of networks and available features.

Production readiness checklist

Before deploying to production, go through this checklist:

• Use a dedicated or managed endpoint – avoid public endpoints for production traffic.
• Implement retries and backoff – handle transient failures gracefully.
• Monitor rate limits – track your usage and upgrade before hitting limits.
• Use WebSocket for real-time data – if your app needs live updates, use WebSocket instead of polling.
• Test on testnet first – deploy on Arbitrum Sepolia to validate your integration.
• Secure your API keys – if using a private endpoint, keep keys out of client-side code.

Key Takeaways

• An Arbitrum endpoint is the URL you use to interact with the Arbitrum network via JSON-RPC.
• Arbitrum One uses chain ID 42161, and Arbitrum Sepolia uses 421614.
• OnFinality provides public endpoints for both networks, plus managed API and dedicated node options.
• Choose your endpoint based on workload: public for dev, API for production, dedicated for heavy indexing.
• Debug common issues by checking rate limits, method support, and chain ID.

Frequently Asked Questions

What is the Arbitrum RPC endpoint?

OnFinality provides public endpoints: https://arbitrum.api.onfinality.io/public for Arbitrum One and https://arbitrum-sepolia.api.onfinality.io/public for Arbitrum Sepolia.

What is the Arbitrum chain ID?

Arbitrum One uses chain ID 42161, and Arbitrum Sepolia uses 421614.

Can I use WebSocket with Arbitrum?

Yes, OnFinality supports WebSocket on Arbitrum One. Check the Arbitrum network page for the WebSocket URL.

How do I get test ETH on Arbitrum Sepolia?

You can use a Sepolia faucet to get test ETH, which is then usable on Arbitrum Sepolia.

What is the difference between a public endpoint and a dedicated node?

A public endpoint is shared and rate-limited, while a dedicated node is exclusive to you, offering higher performance and customizability.

For more details on pricing and network support, visit the RPC pricing and supported networks pages.