OnFinality

Posted on Jul 30 • Originally published at onfinality.io

Arbitrum API Endpoint: Chain Settings, Methods, and Best Practices

#web3 #blockchain #arbitrum #tutorial

Arbitrum API Decision Checklist

Before integrating the Arbitrum API into your project, evaluate these key areas:

Criterion	What to check	Why it matters
Network selection	Arbitrum One vs Arbitrum Nova vs testnet (Sepolia)	Different chains serve different use cases: One for DeFi, Nova for gaming/social, Sepolia for staging
RPC provider	Supported endpoints, rate limits, WebSocket availability, archive data	Free public endpoints are unreliable for production; a dedicated node or managed service ensures uptime
Method compatibility	All standard `eth_` methods work; verify custom Arbitrum methods	Arbitrum extends Ethereum RPC with rollup-specific methods like `arb_getL1BaseFee`
Gas pricing	EIP-1559, L1 data fee component	Transaction cost estimation differs from Ethereum mainnet; use `eth_estimateGas` and `arb_gasPrice`
WebSocket support	For real-time subscriptions (`eth_subscribe`)	Essential for monitoring events, pending transactions, and price feeds
Archive data	Trace and historical state access	Debugging, analytics, and indexing often require archive nodes
Failover and redundancy	Multiple endpoints, automatic retry, load balancing	Eliminates single points of failure in production environments

Arbitrum Network Overview

Arbitrum is a leading Layer 2 scaling solution for Ethereum, using optimistic rollups to deliver fast, low-cost transactions while inheriting Ethereum's security. It is fully EVM-compatible, meaning existing Solidity contracts and Ethereum tooling (Hardhat, Foundry, ethers.js) work with minimal changes. The main networks are:

Arbitrum One – Mainnet for high-value DeFi, trading, and general-purpose dApps (chain ID: 42161).
Arbitrum Nova – AnyTrust-based sidechain optimized for gaming and social applications (chain ID: 42170).
Arbitrum Sepolia – Testnet for development and staging (chain ID: 421614).

All networks expose the same JSON-RPC interface, but providers may limit access to certain networks or endpoints.

Arbitrum API Endpoints

To interact with Arbitrum, you send JSON-RPC requests to an RPC endpoint. Public endpoints exist but are often rate-limited and unreliable for production use. For production workloads, use a managed RPC service or run your own node.

Example Arbitrum One mainnet endpoint (for testing only):

https://arb1.arbitrum.io/rpc

Example request using curl:

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

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x1234567"
}

For private endpoints with higher rate limits and WebSocket support, services like OnFinality offer dedicated Arbitrum RPC endpoints with configurable limits and analytics.

Supported JSON-RPC Methods

Arbitrum supports all standard Ethereum JSON-RPC methods (eth_*, net_*, web3_*). Additionally, it provides Arbitrum-specific methods for rollup-related queries:

Method	Description
`eth_blockNumber`	Latest block number
`eth_getBalance`	Account balance (in wei)
`eth_call`	Execute a constant function call
`eth_sendRawTransaction`	Broadcast a signed transaction
`eth_getTransactionReceipt`	Transaction receipt by hash
`eth_estimateGas`	Estimate gas cost for a transaction
`eth_subscribe`	Subscribe to events (WebSocket only)
`arb_getL1BaseFee`	Current L1 base fee (in wei)
`arb_gasPrice`	Current gas price including L1 data fee

Using the Arbitrum API in JavaScript

Here's how to connect to Arbitrum using viem (or ethers.js):

import { createPublicClient, http } from 'viem'
import { arbitrum } from 'viem/chains'

const client = createPublicClient({
  chain: arbitrum,
  transport: http('https://arb1.arbitrum.io/rpc')
})

async function getBlockNumber() {
  const blockNumber = await client.getBlockNumber()
  console.log('Current block:', blockNumber)
}

For production, replace the public endpoint with your provider's private endpoint to avoid rate limiting.

Gas Pricing on Arbitrum

Arbitrum transactions include two fee components:

L2 execution fee – Covers computation on the rollup, denominated in gwei (EIP-1559).
L1 data fee – Cost to post transaction data to Ethereum L1, varies with L1 gas prices.

Use arb_gasPrice to get the total gas price (including L1 overhead). When estimating gas, call eth_estimateGas and then apply a buffer (e.g., 20%) to avoid out-of-gas errors during high L1 congestion.

Example estimation with curl:

curl https://arb1.arbitrum.io/rpc \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{"from":"0x...","to":"0x...","value":"0x0"}],"id":1}'

Choosing an RPC Provider for Arbitrum

When selecting a provider for your Arbitrum dApp, consider:

Rate limits – Free tier limits can block high-frequency requests. Check your app's expected request volume.
WebSocket support – Required for real-time data feeds. Many public endpoints disable WebSocket.
Archive data – If you need historical state or traces (e.g., for explorers or analytics), ensure the provider offers archive nodes.
Geographic latency – Choose endpoints close to your user base or deploy in multiple regions.

Managed providers like OnFinality offer dedicated Arbitrum endpoints with customizable rate limits, WebSocket, and archive access. Compare RPC pricing to find a plan that fits your scale.

Common Pitfalls and Troubleshooting

Wrong network ID – Verify chain ID: Arbitrum One is 42161, Nova is 42170, Sepolia testnet is 421614.
L1 data fee fluctuations – L1 gas prices can spike, making transactions more expensive. Monitor arb_getL1BaseFee regularly.
Stale data with public endpoints – Public endpoints may lag behind the latest block. Use private endpoints with confirmed low latency.
WebSocket disconnects – Implement reconnection logic (e.g., exponential backoff) to handle temporary failures.
Nonce management – Arbitrum uses the same nonce system as Ethereum. Keep track of pending transactions to avoid nonce mismatches.

Key Takeaways

Arbitrum API is fully Ethereum JSON-RPC compatible, so most existing code works without changes.
Use arb_gasPrice and arb_getL1BaseFee for accurate fee estimation.
Public RPC endpoints are suitable for development only; production apps require a reliable provider with WebSocket and archive support.
Evaluate providers based on rate limits, geographic coverage, and additional services like dedicated nodes.
Test on Arbitrum Sepolia before deploying to mainnet to catch any network-specific issues.

Frequently Asked Questions

Q: Is the Arbitrum API the same as the Ethereum API?
A: Yes, Arbitrum supports the full set of Ethereum JSON-RPC methods. It adds a few rollup-specific methods for L1 fee data.

Q: Do I need an API key to use Arbitrum?
A: Public endpoints do not require an API key but are rate-limited. Most managed services require an API key for authentication and usage tracking.

Q: Can I use the same code for Arbitrum One and Nova?
A: Yes, both networks share the same RPC interface. Just update the chain ID and endpoint URL.

Q: How do I get L1 data fees?
A: Call arb_getL1BaseFee to get the current L1 base fee in wei.

Q: What is the best RPC provider for Arbitrum?
A: The best provider depends on your workload. Evaluate options based on rate limits, WebSocket, archive data, and support. Check supported networks for Arbitrum availability across providers.

For more details, explore OnFinality's Arbitrum RPC endpoints and choose a plan that fits your project's needs.

Related resources

Originally published at OnFinality.

DEV Community