Using Arbitrum

05 September 2026

Arbitrum is a layer-2 scaling solution for Ethereum that bundles transactions off-chain and posts compressed proofs to Ethereum mainnet. It inherits Ethereum's security model while offering faster and cheaper transactions. But "using Arbitrum" covers more than just sending a transaction. There are two main Arbitrum chains - One and Nova - each with different trade-offs. There are bridges, wallets, RPC providers, and a stack of technical details that can trip up newcomers and experienced users alike. This pillar page maps the entire territory. Every topic here has a dedicated spoke page that dives deeper; you'll find those handoffs throughout.

The two arbitrum chains: one vs nova

The first thing to understand is that there isn't just one Arbitrum. There are two production chains: Arbitrum One and Arbitrum Nova. Both are based on the same Nitro technology stack, but they differ in how they guarantee data availability.

Arbitrum One is a classic optimistic rollup. It posts all transaction calldata to Ethereum L1, which makes its security guarantees very close to Ethereum's. Every byte of data is stored on Ethereum's ledger. That security comes at a cost: L1 calldata posting fees make up a significant portion of the total transaction fee. Arbitrum Nova, by contrast, uses a Data Availability Committee (DAC) model called AnyTrust. Instead of posting all data to L1, it relies on a trusted committee to store data off-chain, with only a hash posted to L1. This makes Nova dramatically cheaper - and also slightly less permissionless in theory. In practice, the committee is designed to be trust-minimized: as long as at least 2 of 4 members are honest, the data remains available.

Your choice between the two depends on what you are doing. DeFi applications that require strong finality and don't mind paying a bit more in fees typically run on Arbitrum One. Gaming or social applications with high transaction volumes and lower value per transaction often prefer Nova. The spoke page Arbitrum One vs Nova Which Chain Should You Use covers the decision criteria in full, including fee comparisons and ecosystem support.

Moving funds on and off arbitrum

Bridging is where most users first interact with Arbitrum's mechanism design. The canonical way to move funds from Ethereum to Arbitrum is through the Arbitrum Bridge at bridge.arbitrum.io. This uses Arbitrum's L1-to-L2 message passing system. When you deposit ETH or tokens, the bridge creates a retryable ticket on L1. That ticket must be redeemed on L2 within 7 days, or it expires and your funds are returned to L1. The Arbitrum Portal serves as an aggregator, showing you official bridge interfaces and ecosystem apps.

The spoke page How Arbitrum Retryable Tickets Work and Why They Expire explains the lifecycle: how auto-redeem works (the bridge handles it for you in most cases), what happens if you manually create a retryable ticket and forget to fund the redeeming address, and how the 7-day expiry deadline works.

Withdrawing from Arbitrum back to Ethereum is a different story. It requires a 7-day challenge period. After you initiate a withdrawal on L2, you must wait for this window to pass before you can prove and execute the withdrawal on L1. This is not a bug; it's the core security guarantee of an optimistic rollup. During those 7 days, any honest validator can challenge a fraudulent state root. The spoke page Why Arbitrum Withdrawals Take 7 Days and How to Speed Them Up explains the mechanism and reviews fast bridge options like Hop Protocol, Across Protocol, Stargate, and Orbiter Finance that front the funds for a fee, letting you bypass the wait. The trade-off: you trust the fast bridge's solvency and smart contract security instead of Arbitrum's native withdrawal guarantee.

Speaking of trust, the spoke page Arbitrum Native Bridge vs Hop Across Stargate Which Is Safest directly compares the canonical bridge with these third-party alternatives. The native bridge is slower but minimises trust assumptions. Third-party bridges offer speed but introduce additional attack surfaces, including the risk of unverified contracts granting unlimited token approvals.

Wallets, rpcs, and block explorers

To use Arbitrum, you need a wallet configured for the correct chain. MetaMask, Rabby Wallet, Ledger, Trezor, and Safe (formerly Gnosis Safe) all support Arbitrum One and Nova. The most common error here is sending funds to an L1 address and expecting them to appear on L2, or vice versa. Arbitrum uses the same address format as Ethereum, but the chains are separate - funds on L1 do not exist on L2 unless bridged. The spoke page How to Set Up MetaMask Rabby and Ledger for Arbitrum walks through adding the networks manually, including the correct chain IDs (42161 for Arbitrum One, 42170 for Nova).

RPC endpoints are how your wallet communicates with the network. You can use public endpoints, but they are rate-limited and unreliable for frequent use. Commercial providers like Alchemy, Infura, and QuickNode offer dedicated Arbitrum RPCs with higher limits and better uptime. The spoke page Best Arbitrum RPC Providers Alchemy vs Infura vs QuickNode compares performance, pricing, and features like archival data access. Chainlist can help you add the correct RPC URL to your wallet with one click.

Block explorers let you verify transactions. Arbiscan is the most comprehensive explorer for Arbitrum One and Nova. Etherscan also has an Arbitrum One explorer at the same URL under a different tab. Both show L2 transactions, L1-to-L2 messages, and the underlying Ethereum data. L2Beat and DefiLlama provide aggregator-level data on Arbitrum's activity and security metrics.

Common Transaction Errors and How to Fix Them

Users run into a handful of recurring errors on Arbitrum. The most frequent are easy to diagnose.

"Insufficient funds for gas" on L2: You need ETH in your L2 wallet to pay for gas. You cannot pay Arbitrum gas with tokens or with L1 ETH. If your L2 balance shows zero ETH but you have tokens, bridge some ETH over first.

"Execution reverted": This is the generic catch-all for a failed contract call. The transaction reached the Arbitrum chain but the contract rejected it - common with slippage tolerance issues on DEXs like Uniswap or Aave on Arbitrum.

"Gas estimation failed": This happens before submission. The wallet tried to estimate gas and got a revert. Often this means the transaction would fail even if you paid higher gas. Check your inputs, approval amounts, and whether you are interacting with the correct contract.

"Transaction underpriced": Your gas bid is below the network floor. Arbitrum has a minimum base fee per block. Use your wallet's suggested gas or set a priority fee above the minimum.

"Nonce too low" / "Nonce too high": These mean your wallet's recorded nonce does not match the chain. A nonce that is too low indicates an already-used nonce (resend with a higher nonce). A nonce that is too high means you have pending transactions that need to be confirmed or cancelled first.

The spoke page How to Fix Arbitrum Gas Estimation Failed and Underpriced Errors covers these and other errors like "Retryable ticket expired" and "Outbox entry not yet created" in detail, with step-by-step fixes.

The sequencer: how it works and what happens when it fails

Arbitrum uses a sequencer to order transactions. The sequencer is a privileged node that receives transactions and puts them in a deterministic order before posting them to L1 in batches. This gives users fast pre-confirmation (you see results in seconds) and prevents frontrunning based on L1 ordering. The sequencer follows a first-come-first-served policy.

But the sequencer is a single point of centralization in the short term. If the sequencer goes down, you cannot get your transaction included through the normal path. However, Arbitrum has a force-inclusion mechanism via the delayed inbox. You can submit your transaction directly to an Ethereum L1 contract, and after roughly 24 hours, it will be forced into the L2 chain. This ensures censorship resistance, albeit with a delay. The spoke page What Happens When the Arbitrum Sequencer Goes Down explains the force-inclusion path, the conditions under which it activates, and why it does not work on Arbitrum Nova (which lacks the delayed inbox for architectural reasons).

A related pattern: the sequencer also provides a real-time sequencer feed for streaming transactions. Clients subscribing to this feed see transactions before they are posted to L1. If you run your own Nitro node, you can choose whether to subscribe to the feed or rely solely on L1 data. The spoke page on sequencer downtime covers this in more detail.

L1-to-L2 messaging and address aliasing

When you send a message from Ethereum to Arbitrum - depositing ETH through the bridge or calling a contract on L2 - Arbitrum applies address aliasing. The sender address on L2 will not be exactly the same as the sender address on L1. Instead, it is computed by taking the L1 address, adding an offset that is the length of the address (20 bytes), and taking the resulting keccak hash. In practice, this means if your contract on L1 calls a function on an L2 contract, the L2 contract sees the caller as a different address - the aliased version. This prevents a class of cross-chain replay attacks where a message intended for L1 could be misused on L2.

The spoke page Why Arbitrum Changes Your Sender Address on L1 to L2 Calls walks through how to compute the aliased address, why it matters, and how smart contract developers should handle it. For simple token deposits through the bridge, the bridge handles aliasing automatically - you do not need to worry about it. But if you are building a bridge or cross-chain protocol, ignoring aliasing will break your deployment.

Block and finality semantics

Arbitrum blocks are not the same as Ethereum blocks. The block.number in a smart contract on Arbitrum reflects the L2 block number, not the L1 block number. L2 blocks are produced roughly every 0.25 seconds, much faster than Ethereum's 12-second average. Using block.number for time-based logic (like vesting schedules or time locks) will break because the relationship between L2 blocks and real time is not fixed. The spoke page Arbitrum Block Number vs Ethereum Block Number Key Differences explains the implications and recommends using block.timestamp or explicit timestamps instead.

Finality on Arbitrum is also tiered. The sequencer gives you "soft" finality within seconds; the transaction is visible on L2 and cannot be reverted by the sequencer afterward. However, true finality - meaning the transaction cannot be challenged or reversed - only arrives after the 7-day dispute window on L1. If the sequencer is honest and the transaction has no fraud proof challenge, the two converge. But if you rely on an L2 transaction for a high-value asset before the 7-day window passes, you accept the risk that a fraud proof could roll back the chain state. The spoke page When Is an Arbitrum Transaction Final Compared to Ethereum breaks down the four stages of finality: pre-confirmation, confirmed by sequencer, posted to L1, and after the challenge period.

Economics: gas fees and fee components

Gas fees on Arbitrum consist of two main components: the L2 execution fee (gas used × L2 gas price) and the L1 calldata posting fee (the cost of posting your transaction data to Ethereum). The L1 component often dominates during high-Ethereum-fee periods. Arbitrum's Nitro architecture includes Nitro compression that reduces the size of calldata, lowering L1 costs significantly compared to earlier versions.

The L2 gas price has a base fee that fluctuates with network demand and a priority fee (tip) that goes to the sequencer. Arbitrum enforces a minimum base fee to prevent spam. There is no built-in maximum block gas limit in the traditional sense, but practical limits exist based on sequencer capacity.

Retryable ticket submissions incur additional L1 gas costs because they generate an L1 transaction. The total cost includes the L1 calldata for the retryable submission plus the L2 execution when redeemed. If the retryable auto-redeems, the redeeming contract pays that L2 gas; if it fails or is not funded, the sender must redeem it manually and pay the L2 gas.

There is a persistent misconception that Arbitrum transactions are free or nearly free. They are cheaper than Ethereum mainnet, often by an order of magnitude, but they are not free. Small transactions - like a simple ETH transfer - cost a few cents during normal conditions but can spike during high-demand periods. The spoke page How ETH Works as the Native Gas Token on Arbitrum One clarifies that you pay gas in ETH on Arbitrum One. You do not need the ARB token to transact. ARB is a governance token, not a gas token. (Orbit chains can optionally use custom gas tokens, but that is a separate topic.)

Development: SDK, nodes, and smart contract tooling

For developers, Arbitrum offers the Arbitrum SDK (@arbitrum/sdk) to programmatically interact with the bridge, retryable tickets, and L1-to-L2 messaging. You can also interact directly with the bridge contracts, but the SDK handles many edge cases - address aliasing, gas estimation for retryables, and outbox proof calculation. The spoke page When to Use the Arbitrum SDK Instead of Direct Smart Contract Calls compares the two approaches, including when you might prefer to call the contracts directly for lower overhead.

Running your own Nitro node gives you full control over data access and avoids RPC rate limits. You need to run an Ethereum execution client (like Geth) and consensus client, plus the Nitro node software. For most developers, using a commercial RPC provider is simpler and cheaper for small-scale use. The spoke page Best Arbitrum RPC Providers includes guidance on when to self-host versus buy access.

OpenZeppelin Defender and Tenderly both support Arbitrum for debugging and monitoring. Thirdweb offers prebuilt contracts that deploy to Arbitrum. Dune Analytics has public dashboards tracking Arbitrum metrics like TVL, active addresses, and bridge volumes.

For more advanced projects, Arbitrum Orbit lets you launch your own custom L2 or L3 chain using the same Nitro stack. You can choose between rollup and AnyTrust mode, select a custom gas token, and configure your own validators. This is more complex than deploying on Arbitrum One, and the ecosystem tooling is still maturing. The spoke pages for Orbit-related decisions are reserved for later expansion.

Safety and Scams

Sending funds to the wrong chain is the most common and most destructive mistake. A user who sends ETH from their L1 wallet to an Arbitrum address that belongs to them on L1 will lose those funds - they are on L1, not Arbitrum. The same error happens in reverse. Always verify that your wallet is set to the correct network before confirming a transaction.

Phishing sites impersonating the Arbitrum bridge are widespread. Always use bookmarked URLs: bridge.arbitrum.io and portal.arbitrum.io. Never connect your wallet to a bridge from a search result or social media link. The spoke page How to Avoid Arbitrum Bridge Phishing Sites and Token Scams lists red flags, including fake airdrop claims and sites that request unlimited token approvals.

Third-party bridges present a different risk profile. If you use Hop, Across, Stargate, or Orbiter Finance, verify you are on the correct frontend and that you are not granting unlimited approval. Check each bridge's contract on Arbiscan to confirm it is a verified contract.

The Roadmap Ahead

This pillar page covers the fundamentals of using Arbitrum today. Each spoke page listed at the top goes deeper into a single topic. If you are new to Arbitrum, start with the chain comparison and the bridge safety page. If you hit a specific error, find that error in the spoke page on gas estimation and underpriced errors. Developers should read the retryable tickets, L1-to-L2 messaging, and SDK pages.

The landscape changes. Orbit chains, new fast bridges, and protocol upgrades alter the trade-offs. This page will be updated as those changes settle. For now, these are the first principles that have remained stable since the Nitro upgrade.

Back to arbitrum