What are Arbitrum nodes and how should you run or access them?

Quick recommendation: self-host or use a managed RPC?

Before diving into node types and setup, decide whether you need to run an Arbitrum node at all. If your goal is to read chain state, submit transactions, or index events for a dApp, a managed RPC provider like OnFinality gives you a production-ready endpoint without the operational burden. If you need to independently verify the chain, run a validator, or have strict data sovereignty requirements, self-hosting a full node may be worth the cost.

Here is a simple decision path:

• You need a reliable endpoint for your app → Use a managed RPC provider. You get access to Arbitrum One and Sepolia without syncing or maintaining infrastructure.
• You want to validate transactions yourself → Run a full node in Watchtower mode.
• You need historical state beyond the default pruning window → Run an archive node or use a provider that offers archive data.
• You are building on testnet → Use a testnet endpoint like Arbitrum Sepolia to avoid mainnet costs.

If you choose a managed provider, compare factors like request limits, archive support, WebSocket availability, and failover behavior. OnFinality offers both public and dedicated Arbitrum nodes, with transparent pricing and support for many networks.

What is an Arbitrum node?

An Arbitrum node is a software client that connects to the Arbitrum network, validates blocks, and maintains the state of the chain. Arbitrum is an optimistic rollup that settles on Ethereum, so nodes must track both the L2 chain and the L1 data posted to Ethereum. The reference client is called Nitro, which is a Go implementation that combines the Geth execution engine with Arbitrum-specific components.

There are two main types of Arbitrum nodes:

• Full node: Stores the latest state and validates new blocks. It can serve RPC requests but prunes historical state by default.
• Archive node: Stores the entire history of the chain, allowing queries for any past block. Archive nodes require significantly more disk space.

There are also specialized roles like sequencer, batch poster, and validator, but these are run by the Arbitrum team and ecosystem partners. For most developers, the choice is between full and archive nodes.

Full node vs archive node: what changes for your app?

If your app only needs current balances and recent transactions, a full node is sufficient. If you need to query state from months ago, you need an archive node. Managed providers often offer both, but archive requests may cost more.

Running your own Arbitrum node: what to expect

Running a Nitro node is not a trivial task. You need to provision a machine with enough CPU, RAM, and disk, then sync the node from a snapshot or from genesis. The official docs recommend using a snapshot to avoid days of syncing.

Here is a typical Docker command to run an Arbitrum full node (simplified):

docker run --name arbitrum-node \
  -v /path/to/data:/home/user/.arbitrum \
  -p 8547:8547 \
  -p 8548:8548 \
  offchainlabs/nitro-node:v3.9.0 \
  --init.url=https://snapshot.arbitrum.io/nitro/full \
  --l1.url=https://ethereum-rpc.example.com \
  --chain.id=42161

Note that you need an Ethereum L1 RPC endpoint to sync. The node will read L1 data to verify the rollup. You also need to open ports 8547 (RPC) and 8548 (WebSocket) if you want to expose them, but be careful about security.

Key operational concerns

• State scheme: Nitro supports HashDB (default) and PathDB. You must choose before initializing the database; you cannot switch later.
• Pruning: Full nodes prune old state automatically. If you need historical data, use an archive snapshot.
• Memory: Nitro can consume several GB of RAM. Monitor your node to avoid OOM crashes.
• Watchtower mode: By default, a full node runs in Watchtower mode, which watches on-chain assertions and logs errors if it disagrees. This is not a validator role.
• Security: Exposing your RPC endpoint publicly can lead to resource exhaustion. Use firewalls and authentication if you must expose it.

Managed RPC: when it makes sense

Running your own node gives you full control, but it also means you are responsible for uptime, backups, and scaling. For most production dApps, a managed RPC provider is more practical. You get:

• High availability: Providers run multiple nodes and load balance requests.
• Archive access: You can query historical state without running an archive node.
• WebSocket support: For real-time subscriptions.
• Dedicated nodes: If you need a private endpoint with guaranteed capacity.

OnFinality offers managed Arbitrum nodes with both public and dedicated options. You can start with a free public endpoint and upgrade to a dedicated node as your traffic grows. See Arbitrum network page for details.

Chain settings for Arbitrum One and Sepolia

When connecting to Arbitrum, you need the correct chain ID and RPC URL. Here are the settings for both networks:

You can use these public endpoints for testing, but for production, consider a dedicated endpoint with higher rate limits. OnFinality's public endpoints are rate-limited; check pricing for details.

Connecting your app to an Arbitrum node

Here is an example of connecting to Arbitrum One using ethers.js:

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

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

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

getBlock();

For WebSocket subscriptions, you can use the WebSocket endpoint if available. OnFinality supports WebSocket on Arbitrum One; check the network page for the exact URL.

Common pitfalls when working with Arbitrum nodes

• Using the wrong chain ID: Make sure your wallet or app uses 42161 for mainnet and 421614 for Sepolia.
• Assuming full node has archive data: If you query a very old block on a full node, you may get an error. Use an archive endpoint.
• Ignoring rate limits: Public endpoints have limits. If your app makes many requests, you need a dedicated node.
• Not handling WebSocket reconnects: WebSocket connections can drop. Implement reconnection logic in your app.
• Forgetting L1 dependency: If you run your own node, you need a reliable Ethereum L1 endpoint. If that fails, your node cannot sync.

How to choose a provider for Arbitrum nodes

When evaluating RPC providers, consider these criteria:

• Request limits: What is the free tier? What happens when you exceed it?
• Archive support: Do they offer archive nodes? At what cost?
• WebSocket: Is it available? What is the connection limit?
• Dedicated nodes: Can you get a private node with dedicated resources?
• Geographic distribution: Are there endpoints in multiple regions for low latency?
• Support: What is the SLA and support response time?

OnFinality provides a transparent pricing page and a list of supported networks. You can start with a free public endpoint and scale to a dedicated node when needed.

Key Takeaways

• Arbitrum nodes are Nitro clients that validate and serve the Arbitrum chain.
• Full nodes prune history; archive nodes store everything.
• Self-hosting gives control but requires significant operational effort.
• Managed RPC providers like OnFinality offer production-ready endpoints with less overhead.
• Always use the correct chain ID and RPC URL for the network you target.
• For production, consider dedicated nodes to avoid rate limits and ensure reliability.

Frequently Asked Questions

What is the difference between a full node and an archive node on Arbitrum?

A full node stores the latest state and prunes old data, while an archive node keeps the entire history. Archive nodes are needed for historical queries but require much more disk space.

Do I need to run an Arbitrum node to build a dApp?

No. You can use a managed RPC provider to access Arbitrum without running your own node. This is faster to set up and often more reliable for production apps.

Can I run an Arbitrum node on a laptop?

Technically yes, but it is not recommended. The node requires significant disk space and memory, and syncing can take days. A cloud server or dedicated machine is better.

What is Watchtower mode?

Watchtower mode is the default for full nodes. It watches on-chain assertions and logs errors if it disagrees with them. It does not participate in validation.

How do I get an Arbitrum Sepolia testnet node?

You can use a public testnet endpoint like https://arbitrum-sepolia.api.onfinality.io/public or run your own node configured for Sepolia. See the Arbitrum Sepolia page for details.

What is the cost of running an Arbitrum node?

Costs vary based on hardware, cloud provider, and whether you use a managed service. Self-hosting requires paying for a server with enough disk and RAM. Managed providers charge based on usage or a flat fee for dedicated nodes.

Can I use OnFinality for Arbitrum mainnet?

Yes, OnFinality supports Arbitrum One with public and dedicated endpoints. Check the Arbitrum network page for details.