DOCSEARCHbyAlgolia
Submit Docs

Arbitrum Documentation

website·Indexed 41 days ago

https://docs.arbitrum.io

Technical documentation for the Arbitrum blockchain platform. Includes guides on building decentralized applications with Solidity and Stylus, managing the Arbitrum bridge, running nodes, and launching custom chains. Covers architectural differences from Ethereum, RPC methods, gas limits, and cross-chain messaging, as well as specific details on ArbOS and the Machine Payments Protocol (MPP).

Tokens
400.1K
Snippets
1.4K
Records
2.7K
Agent score
73%

What's inside Arbitrum

  1. Overview of Arbitrum Nova

    Arbitrum Nova is a high-performance production chain designed for applications requiring higher transaction throughput and lower costs. Unlike Arbitrum One, it implements the AnyTrust protocol, which introduces a Data Availability Committee (DAC) to expedite storing and posting transaction data. This introduces a mild trust assumption (assuming at least two DAC members are honest) in exchange for increased affordability and performance.

  2. Overview of ORA Onchain AI Oracle (OAO)

    ORA is a verifiable oracle protocol that brings AI and complex compute onchain to Ethereum. Its primary product, the Onchain AI Oracle (OAO), allows developers to integrate verifiable AI inference directly into smart contracts, overcoming the computational limitations of standard smart contracts.

  3. Overview of Arbitrum Compliance Filtering

    Compliance Filtering is an optional feature available in ArbOS 61 (Elara) that allows chain owners to block transactions involving restricted addresses for regulatory purposes. It operates across two layers to ensure enforcement regardless of how a transaction enters the system: the Sequencer (primary enforcement) and the State Transition Function (STF) for transactions submitted via the Delayed Inbox. This feature is disabled by default.

  4. Overview of Arbitrum L1 to L3 Teleportation

    Teleportation allows users to bridge tokens from Ethereum (L1) directly to an Arbitrum Layer 3 (L3) in a single transaction. Instead of manually bridging L1 → L2 and then L2 → L3, the Arbitrum SDK coordinates a chain of retryable tickets:

    1. Tokens are deposited into the L1-to-L2 bridge.
    2. An L2 retryable forwards tokens to the L2-to-L3 bridge.
    3. An L3 retryable mints or releases tokens to the destination address.

    For ETH, a 'double retryable' pattern is used. Gas fees for each leg are bundled into the initial L1 transaction.

  5. Overview of the Arbitrum Canonical Token Bridge

    The Arbitrum stack uses a "canonical token bridge" to ensure ERC-20 token transfers between parent and child chains. The architecture consists of contracts deployed on both chains that communicate via the retryable ticket protocol. Deployment is managed through a TokenBridgeCreator contract, which creates the parent chain contracts and sends messages to the child chain to create the counterpart contracts.

  6. Overview of Arbitrum chain fee types

    Every transaction on an Arbitrum chain collects four types of fees, which are internally split and can be sent to different configurable fee collector addresses:

    • Arbitrum chain base fee: Fees for executing the transaction based on the configured minimum base price.
    • Arbitrum chain surplus fee: Fees collected when the chain is congested (actual base price is higher than the minimum base price).
    • Parent chain base fee: Fees for posting the transaction on the parent chain, calculated based on transaction size and the parent chain's base fee.
    • Parent chain surplus fee: Extra fees rewarded to the Batch Poster, if configured.

  7. Overview of Supra VRF Integration

    Supra VRF provides tamper-proof, unbiased, and cryptographically verifiable random numbers for smart contracts. The integration involves two primary contracts:

    1. Supra Router Contract: Used to request and receive random numbers.
    2. Supra Deposit Contract: Used to whitelist requester smart contracts and manage deposits for callback transaction gas fees.

    Prerequisite: Users must first have their customer-controlled wallet address registered with the Supra team to manage access permissions and gas fee payments.

  8. Overview of the Arbitrum Platform

    Arbitrum is a finance-native blockchain platform that provides infrastructure for applications, tokenization, and the creation of dedicated blockchains. The ecosystem consists of several key components: Arbitrum One, Arbitrum Nova, Arbitrum chains, Nitro, Stylus, and various supporting protocols.

  9. Overview of Mirror Data Availability Server (DAS)

    A mirror DAS is used to complement a Data Availability Committee (DAC) setup. Its primary purpose is to handle public REST requests for stored batches of information, acting as a buffer for the main DAS. This prevents the main DAS from being exposed to public spam attacks and allows it to focus exclusively on storing received data. Additionally, mirror DAS instances provide network resiliency if a primary DAS goes down. A mirror DAS reads information from the main DAS via its private REST interface.

  10. Overview of Arbitrum Canonical Factory Contracts

    Arbitrum uses canonical factory contracts to streamline the deployment and initialization of new chains and token bridges.

    • RollupCreator: Processes the creation of necessary contracts and sends initialization messages from the parent to the child chain.
    • TokenBridgeCreator: Creates token bridge contracts in both the parent and child chains (using parent-to-child messaging).

    Using these canonical contracts ensures end-to-end atomic deployment, gas efficiency, and access to the latest contract features. For most users, it is strongly recommended to use the Arbitrum Chain SDK to interact with these contracts to avoid misconfiguration.

  11. Overview of parent-to-child chain messaging

    Parent-to-child chain messaging in Arbitrum allows users to submit transactions, deposit native tokens, or send arbitrary data from a parent chain (e.g., Ethereum) to a child chain (e.g., Arbitrum One or Nova). There are three primary categories of messaging:

    1. Native token bridging: Depositing the child chain's gas token (ETH or a custom gas token) via the Delayed Inbox.
    2. Transactions via the Delayed Inbox: Sending arbitrary data or function calls. These are split into 'Unsigned messages' (which use address aliasing) and 'Signed messages' (which prove EOA ownership).
    3. Retryable tickets: The canonical mechanism for initiating transactions on a parent chain that trigger execution on a child chain, used for general messaging and specialized features like token bridging.

  12. Overview of Arbitrum custom genesis state

    Custom genesis state allows Arbitrum chain operators to deploy chains with pre-existing state loaded from a genesis.json file. This is primarily used to:

    • Predeploy smart contracts: Load contract bytecode into the first block so infrastructure (e.g., Gnosis Safe) is available at launch.
    • Set initial account state: Pre-configure account balances, nonces, and contract storage.
    • Enable advanced features: Launch chains with customizations like compliance-focused transaction filtering or native mint/burn via third-party bridges.

    Critical Solvency Warning: Preallocating account balances credits ETH (or gas tokens) without requiring deposits into the parent-chain bridge. If total preallocated balances exceed the bridge's backing, the chain is insolvent from genesis, and withdrawals may fail once the bridge is drained.