DOCSEARCHbyAlgolia
Submit Docs

Arbitrum Developer Documentation

website·Indexed 41 days ago

https://developer.arbitrum.io/

Technical documentation for building on Arbitrum, a finance-native blockchain platform. Includes guidance on ArbOS, Stylus for Rust-based smart contracts, bridging assets via standard and custom gateways, and running nodes. Covers architectural differences from Ethereum, RPC methods, gas limits, and integration with Web3 libraries like ethers.js, web3.js, and viem.

Tokens
403.7K
Snippets
1.4K
Records
2.7K
Agent score
71%

What's inside Arbitrum

  1. Overview of migrating between Arbitrum RaaS providers

    Migrating between RaaS providers is an operational handoff rather than a redeployment of the Rollup. The process typically spans several days for infrastructure setup and partner coordination, though actual downtime can be limited to a few minutes with proper planning. The new operator must establish shadow infrastructure, replicate data, and pass health checks before the DNS and Batch-poster handover occurs. Normally, the chain ID and L1 Rollup contracts remain unchanged.

  3. Overview of Arbitrum Nitro Execution Environments

    Arbitrum Nitro supports two interoperable execution environments that share the same state: the traditional Ethereum Virtual Machine (EVM) for Solidity contracts and a WebAssembly (WASM) VM for Stylus contracts. While they share the same 256-bit word-based storage and a call depth limit of 1024, they differ in their instruction sets, memory management, and gas metering.

  4. Overview of Arbitrum Standard Gateway bridging

    The standard gateway is the simplest method to make an ERC-20 token bridgeable on Arbitrum. It automatically creates a StandardArbERC20 token on the child chain upon the first deposit, requiring no pre-configuration. It uses an escrow model where parent chain tokens are locked in the gateway and child chain tokens are minted/burned.

    Use the standard gateway if:

    • You have a standard ERC-20 token on the parent chain.
    • You do not need custom logic or special behaviors (e.g., no rebasing, no fee-on-transfer) on the child chain.
    • You want an automatic setup.

    Constraints:

    • Incompatibility: Not suitable for rebasing tokens, fee-on-transfer tokens, tokens with transfer hooks, or unique minting/burning logic.
    • Permanence: Once the first deposit occurs, the token is permanently assigned to the standard gateway and cannot be changed.
    • Ownership: The gateway controls the automatically deployed child chain token; it cannot be modified or upgraded by the user.

  5. Overview of the BoLD dispute protocol

    BoLD (Bounded Liquidity Delay) is a dispute protocol for optimistic Rollups active on Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia. It replaces the previous fraud-proof system—which was limited to allowlisted validators—with a permissionless validation system.

    Key improvements include:

    • Permissionless Validation: Anyone can participate in validating chain state and opening challenges.
    • Deterministic State: Because child chain states are deterministic and provable on Ethereum, any honest party can defend a correct claim.
    • Security: Enhances security for child-to-parent chain messaging and withdrawals.
    • Stage 2 Rollup Path: By allowing anyone to validate state and post fraud proofs without restrictions, BoLD helps Arbitrum meet the criteria for a 'Stage 2: No Training Wheels' Rollup as defined by L2BEAT.

  6. Overview of the Bridged USDC Standard on Arbitrum

    The Bridged USDC Standard is a specification for deploying bridged USDC on EVM blockchains. On Arbitrum, using the standard gateway instead of the default ERC-20 canonical gateway prevents two primary issues:

    1. Native vs. non-Native USDC: Standard bridged tokens are not recognized by Circle's product suite because they are collateralized rather than native.
    2. Fragmented UX: Without this standard, a chain might end up with both native and non-native USDC, forcing users to withdraw to the parent chain to convert between them.

    By using the Bridged USDC Standard, all bridged tokens are locked in a gateway that Circle can later adopt to upgrade the chain to native USDC issuance.

  7. Overview of Envio HyperIndex and HyperSync

    Envio provides two primary tools for blockchain data indexing and analytics on EVM chains, with native support for Arbitrum One and Arbitrum Nova:

    • HyperIndex: A feature-rich indexing solution that aggregates real-time or historical data into a database accessible via GraphQL. It supports indexers written in JavaScript, TypeScript, or ReScript and features automatic code generation and multi-chain support.
    • HyperSync: An accelerated data query layer that bypasses JSON-RPC to sync historical data 20-100x faster. It is used by default in HyperIndex but is also available as a standalone API for data analysts using JavaScript, Python, or Rust clients (exporting to JSON, Arrow, or Parquet).

  8. Overview of Priority Gas Auctions (PGA) for Arbitrum

    Priority Gas Auctions (PGA) is an optional transaction-ordering policy for Arbitrum chains. Unlike First-Come-First-Served (FCFS) ordering, PGA orders transactions based on the priority fee (tip) attached to them. The Sequencer runs short ordering rounds several times per block to transfer the priority queue into the block. PGA is particularly useful for chains with active DeFi, arbitrage, liquidation activity, or latency-sensitive applications like proposer-based automated market makers (propAMMs), as it converts latency competition into fee competition.

  9. Overview of the Arbitrum Nitro DA API

    The DA API is an extensibility feature in Arbitrum Nitro that allows external data availability providers to integrate with Nitro without requiring a fork of Nitro core or contracts. It enables the deployment of custom DA solutions while maintaining compatibility with the Nitro stack. Key benefits include a pluggable architecture for custom certificate formats and validation logic, full support for the BoLD challenge protocol and fraud proofs, and the ability for multiple DA systems to coexist on the same chain.

  10. Overview of Priority Gas Auctions (PGA) on Arbitrum

    Priority Gas Auctions (PGA) is a transaction ordering policy used by Arbitrum Sequencers. Instead of first-come, first-served (FCFS) or sealed-bid auctions (like Timeboost), PGA allows users to bid for transaction ordering by attaching a priority fee to each transaction. This creates a continuous, permissionless, per-transaction competition for inclusion. It is designed to lower the barrier to entry for searchers, support latency-sensitive DeFi applications (like propAMMs), and maintain fast block times.

  11. Overview of ZeroDev Smart Accounts on Arbitrum

    ZeroDev provides an ERC-4337 compliant Kernel Smart Account infrastructure for Arbitrum, allowing developers to eliminate gas fees for users through sponsored User Operations (UserOps). Key features include support for EIP-7702 (allowing EOAs to gain smart account features), Social Login onboarding (email, social media, passkeys), and advanced plugins for Session Keys and fine-grained permissions.

  12. Overview of Arbitrum chain capabilities

    Arbitrum chains allow developers to launch dedicated Layer 2 environments that anchor security and finality to Ethereum. Key customization options include:

    • Speed & Finality: Tunable block times (as low as 100ms) and configurable hard finality on Ethereum.
    • Data Availability: Support for Rollup, AnyTrust, or external DA.
    • Economics: Custom gas tokens, fee policies, and revenue capture.
    • Extensibility: Support for precompiles and Stylus.
    • Access: Permissioning, KYC/AML, and privacy controls.