DOCSEARCHbyAlgolia
Submit Docs

Arbitrum Documentation

repository·master·Indexed 42 days ago

https://github.com/offchainlabs/arbitrum-docs

Technical guides, developer references, and user documentation for the Arbitrum ecosystem. Includes resources for the Nitro CLI, contract addresses, and precompile tables.

Tokens
314K
Snippets
684
Records
1.2K
Agent score
53%

What's inside Arbitrum

  1. Overview of the Arbitrum chain SDK capabilities

    master

    The Arbitrum chain SDK is the recommended toolset for deploying and managing new Arbitrum chains. It provides tools and scripts to automate the following tasks:

    • Core Contract Management: Configuration and deployment of your Arbitrum chain's core contracts.
    • Token Bridge Management: Configuration and deployment of the chain's TokenBridge contracts.
    • Genesis Customization: Generation of custom genesis files containing predeployed contracts and specific account allocations.
    • Chain Lifecycle: Initialization of your chain and post-deployment configuration management.

  2. Overview of Covalent Indexing and Querying APIs

    master

    Covalent is a hosted blockchain data solution that provides access to historical and current onchain data for over 200 blockchains, including Arbitrum One, Nova, and Arbitrum chains. It maintains a full replica of supported blockchains, allowing access to account balances, transaction histories, contract log events, and NFT metadata.

    Covalent is ideal for retrieving normalized, aggregated, and enhanced multichain data that goes beyond standard RPC provider capabilities.

  3. Overview of launching an Arbitrum chain

    master

    Arbitrum chains allow you to launch a customizable blockchain using the Arbitrum Nitro codebase without the overhead of running a full Layer 1. Instead of bootstrapping a validator set, your chain anchors its security and finality to Ethereum, converting security into a usage-based expense.

    Key Benefits for Developers and Organizations:

    • Economic Control: You capture fee revenue and priority-access value. Costs scale with usage via dynamic gas targets rather than fixed fees. You can implement custom gas tokens, fee policies, and direct revenue capture.
    • Performance & Finality:
      • Soft Finality: Sub-second responsiveness for users.
      • Hard Finality: Configurable settlement on Ethereum within minutes.
      • Withdrawals: Native withdrawals possible in as little as 15 minutes.
      • Latency: Tunable block times as low as 100ms.
    • Deep Customization: Full control over throughput, Data Availability (Rollup, AnyTrust, or external DA), sequencing/MEV rules, KYC/AML permissioning, privacy, precompiles, and governance.
    • Ecosystem Integration: Your chain plugs into Ethereum's liquidity and the Arbitrum ecosystem. You can follow a "launch-and-migrate" path: start on the shared Arbitrum One network and migrate to a dedicated chain using the same stack to avoid replatforming.
    • Future Proofing: Automatically inherit Ethereum and Arbitrum upgrades (like Stylus) without custom engineering.

  4. Nitro node roles overview

    master

    A summary of available Nitro node roles, their defining flags, and requirements:

    RoleDefining flagsWallet/Bond ReqNotes
    RPC node (full node)none (default)NoneDefault role; follows chain and serves JSON-RPC.
    Archive node--execution.caching.archiveNoneRetains historical state for arbitrary past block queries.
    Sequencer--node.sequencer + --execution.sequencer.enableNoneOrders transactions. One per chain/coordinator set.
    Batch poster--node.batch-poster.enableFunded parent-chain walletPosts batches to parent chain. One active (via Redis lock).
    Validator (staker)--node.staker.strategy (active value)Funded wallet and bondPerforms onchain validation. One active per wallet.
    Validation servernitro-val binary + --node.block-validator.validation-server.urlNoneUsed for split-validation setups.
    Feed relayrelay binary + --node.feed.input.url + --chain.idNoneStateless fan-out of feeds.

    Common Requirements:

    • Most roles require a parent-chain connection via --parent-chain.connection.url.
    • Nodes on Ethereum L1 also require --parent-chain.blob-client.beacon-url for EIP-4844 blobs.
    • Setting --chain.id or --chain.name auto-fills several defaults like --execution.forwarding-target and --node.feed.input.url for known chains.

  5. Understand the value proposition of Arbitrum chains

    master

    Arbitrum chains are dedicated chains built with Arbitrum technology that allow teams to host EVM-compatible smart contracts using self-managed infrastructure. They provide isolation of compute resources from public Arbitrum L2 chains.

    Core Values:

    • Scalability: Overcomes Ethereum bottlenecks by dividing activity into opt-in environments.
    • Flexible Security: Allows experimentation with different security models (e.g., optimizing for lower fees like Arbitrum Nova).
    • Flexible Execution: Enables restrictive or specialized execution environments (e.g., restricting smart contract functionality for optimization).
    • Flexible Governance: Allows teams to define their own governance protocols.

  6. Stylus Rust SDK Documentation Index

    master

    The Stylus Rust SDK documentation is organized into several key areas to help developers build, test, and deploy WebAssembly (WASM) contracts on Arbitrum Nitro:

    Fundamentals

    • Project Structure: Layout, #[entrypoint] macro, and #[public] methods.
    • Global Variables/Functions: Accessing blockchain context (message sender, block info, crypto) via self.vm().
    • Contracts: Storage definition, method declarations, and lifecycle.
    • Testing: Unit testing contracts using TestVM locally.

    Data Types

    • Primitives: Rust primitives (bool, integers, addresses) with automatic ABI encoding.
    • Compound Types: Arrays, vectors, tuples, and custom structs.
    • Storage: Persistent state using storage types and the sol_storage! macro.
    • Conversions: Mapping between Rust types and Solidity-compatible types.

    Advanced Topics

    • Rust vs Solidity: Key differences in contract development.
    • Recommended Packages: Compatible third-party Rust crates.
    • Minimal Entrypoints: Custom entrypoints for gas efficiency.
    • Hostio Exports: Low-level host I/O functions.

    CLI & Tooling

    • Commands: Reference for cargo stylus commands and flags.
    • Verification: Verifying deployed contracts via reproducible builds.
    • ABI Export: Generating Solidity-compatible ABI files.
    • Debugging: Replaying transactions locally with GDB, LLDB, or StylusDB.
    • Optimization: Reducing WASM binary size.
    • Non-Rust WASM: Deploying contracts written in C/C++.

    WASM Concepts

    • WebAssembly: Compilation, deployment, and execution in Arbitrum Nitro.
    • VM Differences: Stylus WASM vs. traditional EVM behavior.
    • Activation: The contract activation process.
    • Caching: Using the WASM caching system for performance.

    Troubleshooting & Reference

  7. Use anytrusttool for key management and testing

    master

    The anytrusttool binary is a command-line utility used for managing cryptographic keys, computing keyset hashes, and interacting with Data Availability (DA) committee members via RPC or REST.

    Note: The datool binary is deprecated. Use anytrusttool for all operations in Nitro Docker images (v3.11.2 and later).

    anytrusttool [keygen | dumpkeyset | client | generatehash] ...

  8. Use Brownie for Python-based smart contract development

    master

    Brownie is a Python-based framework for developing and testing smart contracts on the EVM.

    Key features include:

    • Support for Solidity and Vyper
    • Integration with pytest for contract testing
    • Trace-based coverage evaluation
    • Property-based and stateful testing via Hypothesis
    • Python-style tracebacks and custom error strings for debugging

  9. Benefits of deploying an Arbitrum chain

    master

    Deploying an Arbitrum chain provides several advantages:

    • Permissionless Deployment: Leverage battle-tested technology to deploy L2s/L3s that settle to any supported parent chain.
    • Governance Freedom: Arbitrum chains are not required to be governed by the Arbitrum DAO.
    • Customization Flexibility: Developers are free to modify any part of the stack. This includes implementing:
      • Custom gas tokens
      • Alternative Data Availability (DA) integrations
      • Novel sequencing mechanisms
      • Account abstraction
      • Alternative Virtual Machines (altVMs)

  10. Available Codex API data types

    master

    Codex exposes a single GraphQL endpoint with 73 query operations. Key data categories include:

    • Token Data: Real-time and historical token prices, OHLCV candlestick charts, metadata, and scam filtering.
    • DEX Trades: Swap events across decentralized exchanges with pair-level detail, filtering, and sorting.
    • Liquidity Pools: Pool reserves, volume, fees, and newly created pairs for DEX protocols on Arbitrum.
    • Wallet Analytics: Token balances, transaction history, and holdings across 100+ networks.
    • Real-Time Subscriptions: 25 real-time data streams via WebSocket (wss://graph.codex.io/graphql) for live updates on prices, trades, pairs, wallet activity, and token launches.
    • Webhooks: Push-based notifications for onchain events delivered to your server.

  12. Understand the ArbOS 51 Dia upgrade changes

    master

    ArbOS 51 Dia is an upgrade for Arbitrum Chains designed to support Ethereum's Fusaka upgrade and introduce several improvements to gas pricing, block utilization, and resource tracking.

    Key changes include:

    • EVM Compatibility: Support for EIP-7951 (secp256r1), EIP-7825 (transaction gas limit cap), EIP-7939 (CLZ opcode), EIP-7823 (ModExp bounds), EIP-7883 (ModExp gas cost), EIP-2537 (BLS12-381), and EIP-7642 (networking).
    • Gas & Pricing: Introduction of MaxTxGasLimit for better block utilization, a new pricing model with multiple gas targets/adjustment windows, and increased minimum L2 base fee (from 0.01 to 0.02 gwei).
    • Resource Tracking: Instrumentation of the State Transition Function (STF) to track computation, storage access, storage growth, and history growth for future constraint-based pricing.
    • Native Token Support: Capability for native token mint/burn to allow interoperable tokens (like LayerZero OFTs) to act as native gas tokens.
    • Bug Fixes: Standardized calldata price calculations, EIP-7702 precompile alignment, and fixes for ARM/x86 architecture divergence.