Arbitrum 

Overview

Arbitrum is a suite of Layer-2 scaling solutions for Ethereum, with two live and operational Layer-2 blockchains (Arbitrum One and Arbitrum Nova), Arbitrum Orbits, and the BOLD Protocol among other scalability solutions specialized in fostering the adoption of Ethereum L2 rollups. 

Arbitrum One

Arbitrum One was introduced in 2018 as a cryptocurrency system designed to address the scalability and privacy limitations of previous systems like Ethereum. It enables smart contracts by allowing parties to create virtual machines (VMs) that execute contract functionality. The protocol incentivizes off-chain agreement on VM behavior through mechanism design, reducing the need for on-chain verification and offering scalability improvements. The system also supports the advancement of VM states on-chain for honest parties in case of off-chain disagreements.

Arbitrum contracts are designed to be managed by a set of verifiers, representing the underlying consensus mechanism. Participants are incentivized to follow the protocol’s rules, as verifiers only need to verify a few digital signatures for each contract if parties adhere to their incentives. Even if participants act counter to their incentives, the Arbitrum protocol efficiently handles disputes without extensively examining contract execution.

Arbitrum introduces the “any-trust” guarantee, enabling any honest manager to ensure that a contract behaves according to its code. Parties involved in a contract can serve as managers themselves or appoint trusted individuals to manage the contract on their behalf. The simplicity of the any-trust guarantee allows for efficient contract management.

Instead of requiring every verifier to emulate the execution of every contract, Arbitrum relies on designated managers to manage a contract’s virtual machine (VM). Verifiers track only the hash of the VM’s state, reducing the cost for verifiers significantly. This design encourages managers to agree on VM behavior off-chain, and if unanimous agreement isn’t achieved, a bisection protocol is used to resolve disagreements efficiently.

Arbitrum is designed to work with various consensus mechanisms. While it assumes the existence of a consensus mechanism for publishing transactions, its design remains adaptable to different types of consensus, including centralized publishers, quorum-based consensus systems, or Nakamoto consensus as seen in Bitcoin.

The Arbitrum Protocol

Arbitrum employs a framework that enables the creation and operation of Virtual Machines (VMs) with diverse functionalities. VMs are software programs operating within the Arbitrum Virtual Machine Architecture. The protocol distinguishes between two primary actors: “keys” and “VMs.” 

• Keys are identified by the cryptographic hash of their public key and can take action by signing them with the corresponding private key. 
• VMs, on the other hand, execute actions by processing code. 
• Both keys and VMs can possess currency, and the protocol tracks their respective currency holdings.

Creating a VM involves a specific transaction type that includes a cryptographic hash of the initial VM state and relevant parameters, such as challenge period duration, payment amounts, and a list of VM managers.

For each VM, the Verifier monitors the hashed state, currency holdings, and inbox hash. Changes to a VM’s state are enabled through assertions about its execution. These assertions specify executed instructions, resulting state hash, and actions taken (like payments), along with preconditions indicating the prior state, time bounds, balance, and inbox hash. The protocol dictates the conditions for accepting an assertion. Upon acceptance, the VM’s state is considered changed, and the stated actions are carried out.

Assertions come in two forms: unanimous and disputable. 

• Unanimous assertions are signed by all VM managers and are accepted by miners if eligible. They are relatively straightforward to verify, incurring minimal transaction fees. 
• Disputable assertions, however, are signed by only one manager and require an accompanying deposit. Such assertions are initially published as pending, and a challenge window is provided for other managers to contest the assertion. If no challenge arises during this interval, the assertion is accepted, and the VM’s state is updated. The asserting manager regains their deposit.

These mechanisms ensure the secure execution of VMs, even in cases where only one manager is involved or disputes arise, with a careful balance of incentives and safeguards.

System Roles

The Arbitrum protocol involves four distinct roles that play integral parts in its functioning:

Role	Description
Verifier	The Verifier is responsible for verifying transaction legitimacy and publishing accepted transactions. It can be a central entity, a distributed multi-party consensus system (like a quorum system or a collection of miners using Nakamoto consensus), or even a smart contract on an existing cryptocurrency platform.
Key	A Key represents a participant in the protocol with currency ownership and transaction proposal capabilities. Each Key is identified by a public key or its hash. It can propose transactions by digitally signing them using its private key.
VM (Virtual Machine)	A VM is a virtual participant with defined behavior according to the Arbitrum Virtual Machine (AVM) Specification. VMs can own currency, conduct transactions, send/receive messages. They are created via a dedicated transaction type.
Manager of a VM	Managers supervise a specific VM’s progress and functionality. Managers are designated during VM creation and identified by the hash of their public key.

Lifecycle of a VM

The life cycle of an Arbitrum Virtual Machine (VM) involves distinct stages and interactions that ensure the VM’s integrity and execution. 

1. Creation of VM: An Arbitrum VM comes into existence through a dedicated transaction. This transaction includes critical details such as the initial state hash of the VM, a list of managers assigned to oversee the VM, and specific parameters. The initial state hash acts as a cryptographic commitment to the VM’s state, encapsulating its code and initial data. Multiple VMs can coexist simultaneously, often with different groups of managers.
2. State Change by Managers: Once a VM is created, its assigned managers possess the authority to initiate changes in the VM’s state. The Arbitrum protocol guarantees that a single honest manager has the power to ensure that state changes align with the VM’s code and existing state, ensuring valid execution based on the Arbitrum Virtual Machine (AVM) Specification.
3. Assertions and State Changes: Managers can assert the execution of specific actions that alter the VM’s state, provided certain conditions are met. These assertions predict how the VM’s state will evolve if specific prerequisites are satisfied. For an assertion to be eligible, specific criteria must be met, including the assertion’s preconditions, the VM not being in a halted state, and the assertion not overspending the VM’s funds. Assertions entail details like the new state hash and the actions performed by the VM, such as sending messages or currency.
4. Unanimous and Disputable Assertions: Unanimous assertions are endorsed by all managers linked to the VM. If an eligible unanimous assertion is made, the Verifier swiftly acknowledges it as the new VM state. In contrast, disputable assertions are backed by a solitary manager who attaches a currency deposit to the assertion. If an eligible disputable assertion is made, it becomes pending. If the assertion remains unchallenged within a designated timeframe, it is accepted by the Verifier, and the asserter retrieves their deposit. If another manager challenges the assertion, a bisection protocol is triggered. This protocol determines which party is truthful. The one found to be dishonest forfeits their deposit.
5. Advancing State and Halted State: The VM’s state evolves following the processes described earlier, and this continues until the VM reaches a halted state. At this stage, further changes to the state are impossible. Both the Verifier and managers can consider the VM’s lifecycle complete.

The Bisection Protocol

The Bisection Protocol within Arbitrum is a vital mechanism designed to resolve disputes arising from a manager’s disputable assertion and another manager’s challenge. The protocol ensures a fair and efficient process for determining the truthfulness of assertions within the system. 

When a manager challenges an assertion, the challenging manager is required to deposit funds as a commitment. Subsequently, a game ensues between the asserter and the challenger, conducted via a public protocol to determine the incorrect party. The winner of the game recovers their deposited funds and claims half of the losing party’s deposit. The remaining half of the loser’s deposit is awarded to the Verifier as compensation for overseeing the game.

The game progresses through alternating steps. After a challenge is raised, the asserter is allotted a specific time window to bisect their preceding assertion. If the initial assertion encompassed N steps of VM execution, the two new assertions must involve bN/2c and dN/2e steps respectively, while collectively remaining equivalent to the original assertion. Failure to present a valid bisection within the stipulated time results in victory for the challenger. Once a valid bisection is offered, the challenger must challenge one of the new assertions within their designated time frame.

The two players – asserter and challenger – take turns making moves within the allotted time intervals; failure to make a move within the time limit results in a loss. Each move requires a small additional deposit, which contributes to the game’s stakes.

After a logarithmic sequence of bisections, the challenger will eventually challenge an assertion centered around a single step of execution. At this juncture, the asserter must provide a one-step proof. This proof establishes that, given the initial state and assuming the preconditions, executing a single instruction within the VM will lead to the intended final state and trigger any specified public actions. The Verifier verifies this one-step proof, sealing the game’s outcome.

1. Initiation and Currency Deposits: The Bisection Protocol is initiated when a manager makes a disputable assertion, and another manager challenges it. Both the asserter (the one who made the assertion) and the challenger place a currency deposit as part of this process.
2. Bisecting the Assertion: In each step of the Bisection Protocol, the asserter divides the initial assertion into two separate assertions. Each of these new assertions involves half the number of steps of computation performed by the VM. The challenger then selects one of these halves to challenge.
3. Iterative Bisection Process: The asserter and challenger continue this bisection process iteratively. They refine the assertion by halving its complexity with each step, allowing the dispute to be focused on a smaller and more specific aspect of the original assertion.
4. Single-Step Challenge and Proof: The bisection process ultimately reaches a point where the assertion revolves around a single step of computation executed by the VM (e.g., the execution of one instruction). At this stage, if the challenger disputes the single-step assertion, the asserter must provide a one-step proof to the Verifier for validation.
5. Determining the Winner: If the asserter successfully provides correct proof for the one-step assertion, they win the dispute. In case of failure, the challenger emerges victorious. The winning party retrieves their deposit and takes half of the loser’s deposit, with the other half going to the Verifier.
6. Blockchain Transactions and Time Limits: The Bisection Protocol is executed through a series of blockchain transactions made by both the asserter and the challenger. Each party has a limited timeframe to make their next move within the protocol. Failure to meet deadlines results in the losing party’s disadvantage.
7. Verifier’s Role: The Verifier’s role is to verify the validity of each move within the protocol. They check the facial validity of moves, ensuring that assertions are correctly bisected, and the resulting assertions align with the original one.

The Verifier’s Role

In the Arbitrum protocol, the Verifier plays a pivotal role in ensuring the validity of transactions and the smooth operation of the system. Its responsibilities include:

• Verification and Publication: The Verifier is a mechanism that verifies transactions and subsequently publishes verified transactions. This mechanism can take the form of a distributed protocol involving multiple participants. Its primary task is to verify the legitimacy of transactions and make them publicly accessible.
• Tracking VM Information: The Verifier maintains crucial information about each Virtual Machine (VM). This includes storing parameters like the list of VM managers, as well as three dynamic pieces of information that change over time:
  • Hash of VM State: Represents a cryptographic commitment to the current state of the VM, which includes its code and data.
  • Currency Amount: Tracks the amount of currency held by the VM.
  • Hash of VM Inbox: Holds messages directed to the VM.
• State Advancement and Assertions: The state of a VM advances through the execution of its program. This progress is facilitated by the Verifier’s acceptance of assertions made by the VM’s managers. An assertion is a statement about the change in the VM’s state based on certain preconditions.
• Handling Challenged Assertions: If an assertion is challenged by another party, the Verifier does not accept it, even if the asserter eventually wins the challenge. Instead, the challenged assertion is considered “orphaned.” After the challenge concludes, the asserter has the option to resubmit the same assertion, although this would be unwise if the assertion is incorrect.
• Ensuring Correctness and Progress: The protocol is designed to empower a single honest manager to prevent incorrect assertions from being accepted by challenging them. Additionally, an honest manager can ensure VM progress by making disputable assertions. However, malicious managers can exploit a bisection protocol loophole to delay progress temporarily at the cost of half of their deposit.

Key Assumptions and Tradeoffs

The design of the protocol involves a set of key assumptions and tradeoffs that shape its functionality and effectiveness. These assumptions and tradeoffs contribute to the protocol’s security, efficiency, and overall feasibility. 

• VM Initialization and Stake: Arbitrum enables the creator of a VM to define its code, initial data, and managers. The Verifier ensures that a VM can spend currency only if it was previously sent to it. Therefore, parties who are unfamiliar with a VM’s state or disapprove of its attributes can safely disregard it. 
  • Parties are expected to engage with and trust VMs that were correctly initialized and have a stake in their proper execution.
  • The protocol accommodates the creation of obscure or unfair VMs, with other parties having the freedom to ignore them. 
  • Trustworthy managers are key to ensuring proper VM behavior.
• Trust and Managers: Trust in a VM’s managers is pivotal. A party can trust a manager by becoming a manager themselves. A mature Arbitrum ecosystem is anticipated to feature “manager-as-a-service” entities, incentivized to maintain reputations for honesty and potentially assuming legal responsibilities for manager duties.
• Time Window Assumption: Arbitrum assumes that managers can send challenges or responses to the Verifier within specified time windows, akin to getting transactions included in a blockchain. While common in blockchain contexts, it is a crucial assumption that can be addressed by extending challenge intervals, a configurable parameter for each VM.
• Denial of Service Attacks: Denial of service (DoS) attacks against honest managers are addressed through several factors:
  • Uncertainty of Prevention: If a DoS attacker can’t ensure prevention of honest manager challenges, but only reduce challenge probability, the risk of penalty might deter false assertions, especially if deposit amounts increase.
  • Replication for Availability: Managers can improve availability using replication, including undercover replicas that attackers aren’t aware of.
  • Stalling VM Progress: A malicious manager can stall a VM by continually challenging assertions. However, the attacker loses at least half of each deposit and delays the VM only for one bisection protocol run. It’s assumed that substantial deposit amounts will discourage this attack strategy.

The design aims to strike a balance between enabling flexibility, ensuring proper behavior, and mitigating potential vulnerabilities. 

Design Benefits

• Scalability: One of the most prominent features of Arbitrum is its scalability. Managers can continuously execute a virtual machine without incurring substantial transaction fees. These fees are not only minimal but remain independent of the complexity of the executed code. In an optimal scenario where participants act in line with incentives, disputes are rare. However, even in the event of a dispute, Arbitrum’s Verifier can efficiently resolve it with minimal impact on honest parties, while imposing significant costs on dishonest actors.
• Privacy: Arbitrum’s design is well-suited for private smart contracts. Unless a dispute arises, the internal state of a virtual machine remains hidden from the Verifier. Even during disputes, only a single step of the machine’s execution is revealed to the Verifier, maintaining the majority of the machine’s state in obscurity. In fact, the protocol’s privacy attributes are a direct outcome of its model. Unlike systems aiming for “global correctness,” Arbitrum’s Verifier does not need to execute a VM’s code, eliminating the necessity to expose the code and state for public verification. This contrast with other systems like Ethereum, which require public code and state for verification, showcases Arbitrum’s privacy advantages.
• Flexibility: Arbitrum introduces flexibility through unanimous assertions. Managers possess the ability to reset a machine to any desired state and take actions, even if these actions are invalid according to the machine’s code. However, unanimous agreement among managers is crucial for such actions. This flexibility allows for diverse scenarios, such as restoring a machine to a functional state after a software bug or winding down a machine’s operations. The presence of honest managers ensures that such actions align with the overall system’s integrity.

VM Architecture

The Arbitrum Virtual Machine (AVM) is designed to facilitate efficient verification of one-step proofs and to enable the creation and execution of Virtual Machines with bounded space and time complexities. 

VM Types and Values

• The AVM employs a type system that includes various data types such as null, booleans, characters, 64-bit integers, 64-bit floating-point numbers, byte arrays (up to 32 bytes), and tuples.
• Tuples are a fundamental type that can hold up to eight Arbitrum values, including other tuples recursively, allowing for complex tree data structures.
• All values are immutable, and the system computes the hash of each tuple when created, allowing for constant-time computation of value hashes.

VM State

• The VM state is organized hierarchically, which enables incremental updates and efficient computation of the state hash using Merkle Tree structures.
• The state includes elements such as an instruction stack, a data stack for values, a call stack for procedure call information, a static constant for immutable data, and a mutable register that holds a single value.
• The state is organized such that instructions can only modify items near the root of the state tree, ensuring efficient updates and verification.

Instructions and Control Flow

• The AVM uses a stack-based architecture for its instructions.
• Instructions include manipulating the top of the stack, arithmetic, and logic operations, type conversions, hashing values, computing subsequences of byte arrays, and concatenating byte arrays.
• Control flow instructions include conditional jumps, procedure calls, and returns.
• Tuple-related instructions involve creating new tuples, reading slots from tuples, and copying tuples while modifying slot values.

Instruction Stack

• Instead of a traditional program counter, the AVM uses an “instruction stack” that holds instructions for the program’s remainder.
• Instructions are popped from the stack for execution, and certain instructions, like jumps and procedure calls, modify the instruction stack.
• This approach ensures constant space usage and allows for constant-time verification of instruction and instruction stack values.

Assembler and Loader

• The Arbitrum assembler translates programs written in the Arbitrum assembly language into executable files.
• The assembler offers syntactic sugar for control structures, supports library file inclusion, and provides convenience features for programming.

Standard Library

• The standard library contains essential facilities written in Arbitrum assembly code.
• It includes data structures like vectors and key-value stores, memory space abstractions, time handling, and message management.

Interacting With Other VMs or Keys

• VMs interact by sending and receiving messages.
• Messages contain values, currency amounts, and sender/receiver identities.
• The send instruction is used to send messages, and the inbox instruction copies the VM’s message inbox to the stack.

Preconditions, Assertions, and One-Step Proofs

• An assertion is a claim about a VM’s execution interval and includes preconditions.
• Precondition elements include the VM’s state before execution, inbox hash, lower bound on currency balance, and lower/upper bounds on time.
• An assertion contains the VM’s state after execution, the number of instructions executed, and the emitted messages.
• A one-step proof is a correctness proof for an assertion covering a single instruction, assuming a set of preconditions.
• The proof expands needed parts of the state tree for verification, enabling the Verifier to emulate the instruction’s execution.
• One-step proofs require providing values consistent with hash values, facilitating constant-time verification.

Messages and Inbox

• Messages can be sent to a VM through message delivery transactions or the send instruction.
• Messages include data, currency, and sender/receiver identities.
• Each VM has an inbox tracked by the Verifier, and messages can be appended to it.
• The inbox instruction pushes the inbox’s state onto the VM’s stack.
• VM managers track the inbox state, and Verifiers only track inbox hashes for efficient verification.

Extensions

Extensions demonstrate how Arbitrum’s design can be adapted and enhanced to accommodate various scenarios and requirements, such as off-chain communication, improved privacy, and direct blockchain reading.

Off-Chain Communication

While Arbitrum significantly increases computation capacity within existing cost structures, communication between VM managers and the VM itself often relies on on-chain interactions. Off-chain progress involves using state-channel and sidechain techniques to enable managers to communicate with VMs and advance their state off-chain.

Zero-Knowledge One-Step Proofs

Despite its privacy advantages, there is a scenario where a small privacy leak might occur during the submission of one-step proofs. Managers providing a proof reveal a portion of the state as part of the proof. To enhance privacy, extensions could implement one-step proofs using zero-knowledge protocols like Bulletproofs. 

This involves encoding a one-step VM transition as an arithmetic circuit and proving the validity of the transition. While Bulletproofs offer benefits by not requiring a trusted setup, they may lead to linear verification time in the circuit size. However, for one-step transitions, this is expected to be manageable due to their small size and infrequent occurrence.

Blockchain Reading

The original Arbitrum VM design does not allow VMs to directly read the blockchain. For Arbitrum to be launched as a public blockchain, an extension is added to the VM instruction set to enable direct blockchain reading.

This involves encoding blocks as Arbitrum tuples, where one field of the tuple contains the representation of the previous block, allowing a VM to read earlier blocks. The precondition of an assertion would specify a recent block height, and a VM instruction pushes the associated block tuple onto the stack.

The Verifier only needs to track the hash of each block’s tuple to verify this instruction’s one-step proof. As a result, reading the blockchain does not require loading large amounts of data onto a VM’s data stack. Instead, it involves putting the top-level tuple of the specified block on the stack, allowing for lazy expansion when needed.

Arbitrum Nitro

Arbitrum Nitro is a second-generation Layer 2 blockchain protocol designed to enhance throughput, finality speed, and dispute resolution efficiency compared to previous rollup solutions. The protocol implements various design principles to achieve these properties. To achieve that, Arbitrum Nitro supports the execution of smart contracts, operating as a “Layer 2” solution built on top of the Ethereum network. It maintains compatibility with Ethereum by running smart contract applications through the Ethereum Virtual Machine (EVM) and providing a familiar API. 

As an optimistic rollup, the protocol relies on the safety and liveness of the underlying Ethereum chain, as well as on the assumption of honest participation by at least one Nitro protocol participant. The protocol’s optimistic nature emphasizes efficient execution when participants act in line with their incentives. 

Nitro has been deployed on the Arbitrum One chain since August 31, 2022.

Design Approach

Nitro’s design focuses on four distinctive features that organize its architecture and functionality:

• Sequencing Followed by Deterministic Execution: Nitro processes transactions in two main stages to ensure consistent and predictable outcomes. 
  • The first stage involves arranging transactions in the order they will be executed and then committing to this sequence.
  • The second stage applies a deterministic state transition function to each transaction, one after the other. 
• Geth at the Core: Nitro leverages code from the open-source go-ethereum (Geth) package, which is a widely used Ethereum execution layer node software. By integrating Geth’s core execution and state maintenance functions as a library, Nitro ensures compatibility with Ethereum’s existing infrastructure.
• Separate Execution from Proving: This dual-target approach optimizes execution speed and ensures that the code used for proving is structured and machine-independent.
  • Nitro’s state transition function code is compiled for two different targets. One version is compiled for native execution within a Nitro node during regular operations.
  • The same code is also compiled into portable WebAssembly (wasm) code, which is used for the fraud-proof protocol. 
• Optimistic Rollup with Interactive Fraud Proofs:
  • Nitro builds upon the optimistic roll-up concept introduced in the original Arbitrum design.
  • It employs an improved optimistic roll-up protocol that incorporates an optimized dissection-based interactive fraud-proof protocol.

Sequencing Followed by Deterministic Execution

The concept of “sequencing followed by deterministic execution” in Nitro refers to the two-step process of handling submitted transactions within the system. This approach ensures that transactions are processed in an orderly manner and that their execution outcomes are predictable and consistent. 

1. The first phase involves a component known as the “Sequencer.” This component is responsible for organizing the submitted transactions into a specific order or sequence.
   1. The Sequencer arranges the transactions in the order they will be processed, essentially creating a queue of transactions.
   2. Once the transactions are arranged in the desired order, the Sequencer commits to this order. This commitment helps ensure the integrity of the chosen sequence.
2. Deterministic State Transition Function:
   1. In the second phase, the transactions are processed one by one in the sequence established by the Sequencer.
   2. A deterministic state transition function, which defines how the system’s state evolves based on the execution of transactions, is applied to each transaction.
   3. The deterministic nature of this function means that given the same initial state and the same transaction, the outcome will always be the same. This ensures that the state transitions are predictable and consistent across all nodes in the network.

The Sequencer

In Nitro, the Sequencer plays a critical role in ordering incoming transactions honestly, based on a first-come, first-served policy. While the Sequencer’s task is central to the system’s operation, it is important to note that its role is limited and specific.

• Ordering Transactions Honestly: The primary responsibility of the Sequencer is to arrange incoming transactions in the order they are received. This is achieved by following a first-come, first-served policy, where the earliest submitted transaction is placed first in the sequence, followed by subsequent transactions in the order they arrive.
• Trust and Future Plans: Currently, the Sequencer is operated by Offchain Labs, and it is considered a centralized component. However, there are plans to transition to a committee-based sequencing protocol in the future. This approach aims to distribute the responsibility of sequencing among multiple participants, enhancing decentralization and reducing reliance on a single entity.
• Limited Authority: The Sequencer’s authority is limited to ordering transactions. It does not possess the power to prevent the overall progress of the Nitro chain, nor does it have the ability to prevent the inclusion of any specific transaction. Its role is solely to establish the order in which transactions are processed.
• Transaction Ordering Publication: The Sequencer makes the transaction ordering information available to the public through two methods:
  • Real-Time Feed: The Sequencer publishes a real-time feed of the transaction sequence. This feed represents the Sequencer’s commitment to recording transactions in a specific order. Parties can subscribe to this feed to monitor the sequence.
  • Ethereum Calldata: The Sequencer also posts the transaction sequence as Ethereum calldata. It compiles a batch of consecutive transactions, compresses them using a compression algorithm, and sends the compressed result to the Nitro chain’s Inbox contract on the Ethereum Layer 1 (L1) chain.
• Finality and Authoritativeness: Batches of transactions sent to the Nitro chain’s Inbox contract represent the final and authoritative transaction ordering. Once the transaction sent by the Sequencer to the Inbox achieves finality on the Ethereum Layer 1 chain, the transaction sequence on the Nitro chain is considered finalized.

The Sequencer and Censorship Resistance

The Sequencer in the Arbitrum ecosystem plays a pivotal role in processing and ordering transactions on the layer 2 network. While the Sequencer operates with certain security assumptions, it is essential to maintain censorship resistance and trustless security within the Arbitrum Rollup protocol, even in the presence of a malfunctioning or malicious Sequencer.

The core Inbox, represented by the sequencerInboxAccs byte array in the Bridge contract, is central to the transaction processing in Arbitrum. Transactions included in the core Inbox have fixed ordering, deterministic execution, and trustless finality (see “Transaction Lifecycle”). The role of the Sequencer revolves around how transactions enter this core Inbox, while subsequent stages ensure the security and reliability of transactions.

• Happy/Common Case – Sequencer Is Live and Well-behaved: In this scenario, when a user initiates a transaction, they can either send the signed transaction directly to the Sequencer via an RPC request or submit an L1 transaction to the Sequencer on the underlying layer 1. Upon receiving the transaction, the Sequencer executes it and promptly provides the user with a transaction receipt. The Sequencer then includes the transaction in a batch and posts it on layer 1, confirming its finality.
• Unhappy/Uncommon Case – Sequencer Isn’t Doing Its Job: If the Sequencer is unresponsive or malicious, a user can ensure their transaction’s inclusion in the core Inbox through the following steps:
  • The user submits their L2 message via an L1 transaction into the delayed Inbox (represented by delayedInboxAccs in the Bridge contract).
  • After a certain time delay (currently around 24 hours), the user can use the forceInclusion method in the SequencerInbox contract. This method allows any account to move a message from the delayed Inbox to the core Inbox, effectively finalizing the transaction.

While the force inclusion path introduces uncertainty in transaction ordering during the waiting period, it guarantees eventual inclusion in the core Inbox, ensuring trustless security. Although the force inclusion route is slow and considered an “unhappy” path, its availability ensures that Arbitrum Rollup maintains censorship resistance and security even in scenarios where the Sequencer is uncooperative.

The Delayed Inbox

The “Delayed Inbox” is a feature within the Nitro system that serves as an alternative method for submitting transactions to the Nitro chain. While most user transactions are submitted directly to the Sequencer and included in its batches, the Delayed Inbox offers a way to submit transactions for specific purposes.

• Purpose and Use Cases: The Delayed Inbox serves two main purposes:
  • Transactions from L1 Ethereum Contracts: The Delayed Inbox allows transactions to be submitted by Layer 1 (L1) Ethereum contracts. These contracts are unable to generate the digital signatures required for direct submission through the Sequencer.
  • Backup Submission Method: The Delayed Inbox also acts as a backup method for transaction submission. If the Sequencer begins censoring valid transactions, the Delayed Inbox provides an alternative channel to ensure transaction inclusion.
• Adding Transactions to the Delayed Inbox: Transactions are added to the Delayed Inbox by invoking a specific method on the Nitro chain’s inbox contracts. These contracts maintain a queue of transactions that are timestamped.
• Sequencer Inclusion: The Sequencer has the ability to include the first message from the delayed inbox queue in its transaction sequence. An honest Sequencer does this after a short delay to ensure that the arrival of the message in the delayed inbox is not invalidated by a potential reorganization of the L1 chain. This delay is typically set to a duration that would prevent such issues, often around 10 minutes.
• Forced Inclusion: If a message has been in the delayed inbox for a period exceeding a certain threshold (usually 24 hours), any participant can force the inclusion of that message as the next transaction in the chain’s inbox. This ensures that the message will be executed without relying solely on the Sequencer’s actions.
• Preventing Censorship: The concept of forced inclusion serves as a safeguard against censorship by the Sequencer. By allowing any participant to trigger the inclusion of a message that has been delayed for an extended period, censorship attempts by the Sequencer can be mitigated.
• Malicious Sequencer or Downtime: The need for forced inclusion typically arises in situations where the Sequencer behaves maliciously by censoring transactions or is experiencing prolonged downtime. In such cases, participants can take action to ensure that important transactions are included in the chain.

Deterministic Execution

After transactions have been ordered by the Sequencer, they move into the execution phase of Nitro, where they are processed by the chain’s State Transition Function (STF). 

The STF takes two main inputs: 

• The current state of the chain (represented by the root hash of an Ethereum state tree). This state encapsulates the current state of all accounts, smart contracts, and data on the chain. 
• Incoming messages (transactions). 

In terms of execution, the STF is designed to be fully deterministic. This means that executing the STF on a given transaction will produce the same result every time, as long as the input state and the transaction remain the same. The execution process of the STF emulates the state changes that occur due to the transaction’s execution. It calculates how the transaction affects the account balances, contract storage, and other aspects of the state.

The STF then produces two key outputs: 

• An updated state: The STF produces an updated state, which reflects the changes that occurred due to the execution of the incoming transaction. This updated state is used as the basis for processing subsequent transactions.
• A new block header that is compatible with Ethereum. This block header includes relevant information about the state changes that occurred due to the transaction.

The deterministic nature of the STF ensures that the outcome of executing a transaction depends only on the transaction’s data and the state before the transaction was executed. This means that the result of a transaction can be calculated using the genesis state of the Nitro chain, the sequence of transactions leading up to the current one, and the transaction itself. The history and state of the chain can be determined without the need for communication or consensus among nodes because it is solely dependent on the visible transaction sequence.

While Nitro ensures determinism and maintains its own execution state, it also interacts with the Layer 1 (L1) Ethereum chain using a rollup sub-protocol. This sub-protocol confirms and records the results of transactions to the L1 Ethereum chain. However, it’s important to note that this sub-protocol does not decide the outcome of transactions but rather confirms the results that were already known to honest participants in the Nitro protocol.

Software Architecture

The software architecture of Nitro is built upon the concept of “geth at the core,” referring to the integration of the go-ethereum (geth) software, which is widely used as the execution layer node software for Ethereum. Nitro’s architecture is organized into three main layers, each serving distinct functions:

• Base Layer – Geth Core: The foundation of Nitro’s architecture incorporates the core functionality of go-ethereum (geth). This includes components responsible for emulating the execution of Ethereum Virtual Machine (EVM) contracts and maintaining the data structures that constitute the Ethereum state. Nitro integrates this code by compiling it as a library, with some minor adaptations to add essential hooks.
• Middle Layer – ArbOS: The middle layer, known as ArbOS, is custom software designed to provide additional features associated with Layer 2 functionality. This layer handles tasks such as decompressing and parsing the data batches produced by the Sequencer, accounting for Layer 1 gas costs, collecting fees to reimburse for gas costs, and supporting functionalities related to cross-chain bridges. For instance, ArbOS facilitates the deposit of Ether and tokens from Layer 1 (L1) to Nitro and the withdrawal of these assets back to L1.
• Top Layer – Node Software: The top layer primarily consists of node software, largely derived from geth. This layer manages connections and incoming Remote Procedure Call (RPC) requests from clients. It also provides other high-level functionalities necessary for operating a blockchain node compatible with Ethereum. This includes handling communication with clients and executing various network-related tasks.

The overall architecture is often referred to as a “geth sandwich” due to the interweaving of the geth components at the bottom and top layers of the architecture, with the custom ArbOS layer situated in the middle. This structure leverages the proven capabilities of geth while enhancing its functionality to suit Nitro’s requirements.

The State Transition Function (STF), which forms a crucial part of Nitro’s operation, spans the lower geth layer and a portion of the middle ArbOS layer. 

ArbOS

ArbOS is a custom software layer within the Nitro architecture that serves as a crucial component for managing the operations and functionalities of a Layer 2 (L2) blockchain. ArbOS is responsible for implementing various features responsible for ensuring efficient bookkeeping, cross-chain communication, and L2-specific fee tracking and collection.

• Bookkeeping Functions: ArbOS facilitates the maintenance of accurate and up-to-date records of transactions, states, and other data relevant to the operation of the Layer 2 chain. This bookkeeping ensures the integrity and consistency of the blockchain’s state transitions and transaction history.
• Cross-Chain Communication: One of the important aspects of Layer 2 chains is their ability to interact with the Layer 1 (L1) Ethereum blockchain. ArbOS handles cross-chain communication, enabling the exchange of information, assets, and data between the Layer 2 chain and the L1 Ethereum blockchain.
• L2-Specific Fee Tracking and Collection: As a Layer 2 solution, Nitro aims to optimize and reduce transaction fees compared to on-chain transactions. ArbOS is responsible for tracking and collecting fees that are specific to the Layer 2 environment. These fees may be used to cover the cost of executing transactions on the Layer 2 chain and compensating participants for their role in the network.

By including ArbOS functionality in the STF, Nitro ensures that the execution of transactions takes into account Layer 2-specific operations and requirements.

In the context of the Layer 2 Nitro chain, all the state is stored using Ethereum’s Merkle Patricia state trie data structure. This encompasses the state of ArbOS, which can be modified as part of the State Transition Function (STF).

ArbOS utilizes Ethereum’s storage slots in a specialized Ethereum account with an undisclosed private key. The selection of these specific slots is driven by several objectives:

• Single Ethereum Account for ArbOS State: All the state information of ArbOS is kept within the storage of a single Ethereum account. This helps in centralizing and managing ArbOS’s state-related data efficiently.
• Independent Sub-Components: To avoid data collisions and conflicts, sub-components within ArbOS are allowed to manage their respective states independently.
• Maintaining Locality: To ensure efficient data retrieval and storage, reasonable locality is maintained within each sub-component.
• Future Extensibility: The chosen structure doesn’t hinder the incorporation of future additions to the state.

The Nitro chain’s state representation adheres to a hierarchical structure composed of nested “spaces.” Each space is a mapping from a 256-bit index to a 256-bit value. All values within these spaces are initially set to zero. This hierarchical structure is mapped onto a single flat key-value store, which serves as the storage for the specialized Ethereum contract.

Each space is associated with a key. The key of the root space is designated as zero. For a subspace named “n” within a space with the key “k”, the key used to access it is calculated using Ethereum’s Keccak256 hash function: H(k||n).

Within a space keyed by “k,” the item with index “i” is stored at location H'(k||i) in the underlying flat storage. Here, H’ represents a locality-preserving hash function. Specifically, H'(x) takes the hash of all but the last 8 bits of “x,” truncates the result to 248 bits, and then appends the last 8 bits of “x.” This approach ensures that groups of 256 indices are kept contiguous by the hash function, thus maintaining the integrity of data even as it’s stored and retrieved.

The use of this locality-preserving hash function contributes to reducing the cost of state access and storage, especially when Ethereum adopts a state representation that rewards data contiguity in the future.

Cross-chain Interaction

• Outbox: The Outbox in Nitro is a way to enable Layer 2 (L2) to Layer 1 (L1) contract calls. When an L1 contract wants to interact with Nitro, it creates a message on the L2. This message is like a “ticket” that gets redeemed on L1. The ticket contains information about the L2 sender, the L1 destination, and data for the call. The L1 execution only happens after the message’s dispute period passes and its Rollup Block is confirmed.
• Inbox: The Inbox is managed by L1 Ethereum contracts and records messages sent to a Nitro chain. There are two parts: the main Inbox and the Delayed Inbox. 
  • The main Inbox receives messages from the Sequencer and merges them with messages from the Delayed Inbox. 
  • The Delayed Inbox is for L1 contracts to submit messages to Nitro and provides an alternative to the Sequencer, ensuring messages are not lost even if the Sequencer misbehaves.
• Retryable Tickets: Retryable Tickets allow Layer 1 transactions to be designated as retryable, meaning if they fail, a ticket is created for the transaction. This ticket can be redeemed later by providing gas funds for a retry. This is useful for cases where Layer 1 contracts need to ensure that a deposit transaction runs on Layer 2. The submitter pays a fee, which is refunded if the transaction succeeds, or used to cover costs if a retryable ticket is made.
• Token Bridge: Nitro’s cross-chain messaging allows for the creation of a Token Bridge, an application for transferring assets between Ethereum and Nitro. It enables depositing and withdrawing tokens between the chains. When tokens are deposited, they’re minted on L2, and when withdrawn, they’re burned on L2 and released on L1. A Token Bridge contract handles these operations. Different types of token bridge features are possible, including bridging non-fungible tokens, atomic swaps, and bridging custom tokens.

Gas and Fees

Nitro handles gas fees in a way that’s similar to other blockchains. It collects fees from transactions to cover operational costs and incentivize proper resource usage. 

Gas Fees on Nitro

• Nitro charges fees in NitroGas, which is the Layer 2 gas unit specific to Nitro chains. Ethereum’s Layer 1 gas unit is referred to as L1Gas.
• Each EVM instruction costs the same in terms of NitroGas and L1Gas.
• Transactions on Nitro specify a gas limit, which is the maximum NitroGas they can use. Transactions also indicate a maximum base fee they’re willing to pay.
• The transaction’s actual NitroGas usage cannot exceed the product of its gas limit and maximum base fee.
• The transaction’s sender authorizes a deduction from their $ETH account for gas costs, up to a certain limit.
• This approach maintains a familiar user experience for developers and users using standard tools and wallets.

L2 Gas Metering and Pricing

• Nitro tracks NitroGas usage and adjusts the base fee accordingly to balance demand and capacity.
• Nitro’s basefee adjustment algorithm operates at one-second granularity, as opposed to Ethereum’s one-block adjustment.
• A chain’s speed limit reflects its sustainable capacity. NitroGas usage can temporarily exceed the speed limit but must average within the limit over time.
• Nitro uses a backlog parameter to track usage relative to the speed limit.
• The base fee calculation formula ensures the backlog remains bounded and the system remains balanced.
• Nitro’s base fee growth helps keep the backlog in check, even in high-demand scenarios.

L1 Gas Metering and Pricing

• Transactions also use Layer 1 resources on Ethereum, which are charged in NitroGas. However, these charges are not considered in the backlog since they don’t consume Nitro chain resources.
• The Sequencer, responsible for submitting Ethereum transactions to post data batches, incurs L1 costs.
• Nitro approximates how transactions contribute to the compressibility of batches to distribute costs among transactions.
• Data pricing adapts to minimize the difference between collected data fees and Sequencer’s data costs, avoiding sudden fluctuations.
• The pricer algorithm tracks owed amounts, reimbursement funds, recent data units, and L1 data unit prices.
• The pricer algorithm adaptively adjusts the price based on surplus, equilibration, and smoothing parameters.

Compiling for Execution Versus Proving

In the design of a practical roll-up system like Nitro, a key challenge is finding a balance between optimizing regular execution performance and ensuring reliable results for proving purposes. Nitro addresses this challenge by utilizing the same source code for both execution and proving, but compiling it into different forms for each scenario.

Compiling for Execution

• When preparing the Nitro node software for regular execution, the conventional Go compiler is employed.
• This process generates native code that is specific to the architecture of the target deployment environment.
• The node software is distributed in source code format, and also as a Docker image containing the compiled binary.
• The goal of this compilation is to ensure efficient and high-performance execution of the Nitro node software.

Compiling for Proving

• The section of the code responsible for the State Transition Function (STF) is separately compiled by the Go compiler into WebAssembly (wasm).
• WebAssembly is a typed and portable machine code format that is used for its reliability and portability in the context of proofs.
• The wasm code then undergoes a straightforward transformation to a format referred to as WAVM.
• In the event of a dispute over the accurate outcome of executing the STF, an interactive fraud-proof protocol is employed, referencing the WAVM code for resolution.

WAVM

The wasm (WebAssembly) format possesses several advantageous characteristics that make it suitable for facilitating fraud proofs. It is portable, structured, well-defined, designed for secure execution of untrusted code, and comes with robust tooling and support. However, to fully serve its purpose, wasm requires specific adjustments. Nitro introduces a modified version of wasm known as WAVM (WebAssembly for Verifiability), achieved through a straightforward transformation process that takes wasm code from the compiler and adapts it for proving purposes.

WAVM differs from wasm in three primary ways:

• Removal of Unnecessary Features:
  • Certain features of wasm that are not generated by the Go compiler are eliminated in WAVM.
  • During the transformation stage, a check ensures that these irrelevant features are absent.
• Feature Restriction:
  • Specific features in wasm are restricted in WAVM. For instance, WAVM omits floating-point instructions.
  • In cases where floating-point instructions are present in the original wasm code, the transformer replaces them with calls to the Berkeley SoftFloat library.
  • Nested control flow structures in wasm are flattened in WAVM, simplifying them to jumps without nesting.
  • Instructions in wasm that have variable execution times are transformed into constructs that employ fixed-cost instructions in WAVM, streamlining the proving process.
• Additional Opcodes for Blockchain Interaction:
  • WAVM introduces new opcodes that allow the WAVM code to interact with the blockchain environment.
  • These additional instructions enable WAVM to read and write the blockchain’s global state, access messages from the chain’s inbox, and signal the successful conclusion of the execution of the State Transition Function.

Within WAVM, there’s a capability that enables the virtual machine to combine multiple wasm binaries, referred to as modules. Each module retains its own distinct code, globals, and memory. 

• Isolated Modules: 
  • Each module operates independently with its own code and memory space.
  • Modules can be implemented in different programming languages or have diverse functionalities.
• Inter-Module Communication:
  • The modules can communicate with each other through a dedicated WAVM instruction called CrossModuleCall.
  • This instruction allows one module to invoke functions or code within another module.
  • The called module can access and modify the memory of the calling module, facilitating the exchange of data between modules.
• Practical Example:
  • In the context of Nitro, the State Transition Function (STF) written in Go, the bootloader written in Rust, and libraries written in C can all coexist and operate within the same WAVM machine.
  • Without the module system, potential memory management conflicts between different programming languages could arise.
  • However, by using the module system, these components can maintain separate and isolated memory spaces, avoiding interference.

WAVM custom opcodes not available in WASM 

WAVM floating point implementation 

WAVM modules 

Optimistic Rollup Protocol

The optimistic roll-up protocol implemented in Nitro is the method by which the L2 (Layer 2) chain’s states and associated data are confirmed on the L1 (Layer 1) Ethereum chain. This protocol is designed to allow L2 transactions to be processed with a high degree of efficiency while maintaining the security and integrity of the system.

• The roll-up protocol involves the creation of Rollup Blocks (RBlocks), which are distinct from L2 blocks and encapsulate sequences of L2 blocks.
• RBlocks are created less frequently compared to L2 blocks, resulting in a much lower number of RBlocks.
• An RBlock contains key information, including the L2 block number, header hash for the corresponding L2 block, the number of incoming messages processed, a digest of outbox messages, a pointer to a predecessor RBlock, and additional necessary data.

An RBlock is considered valid if it meets certain criteria. This validity can be achieved through confirmation by the protocol.

• Correct execution of the L2 chain based on the RBlock’s L2 block number, header hash, number of incoming messages, and digest of message output.
• Absence of any older sibling RBlocks that are invalid.
• Validity of the RBlock’s predecessor.

A valid chain of RBlocks is formed over time, with confirmed RBlocks constituting the initial section of this chain. Any party can stake on a specific RBlock, asserting its validity and the validity of its predecessor and the chain of predecessors back to the genesis RBlock.

The protocol’s design ensures that the RBlock chain remains a single chain, and the set of valid RBlocks constitutes a prefix of this chain. By staking on an RBlock, a party asserts not only the validity of that RBlock but also the validity of the entire chain leading back to the genesis RBlock.

In Nitro, the optimistic roll-up system operates in a way that encourages parties to only stake on valid RBlocks, ensuring the security and reliability of the system. Honest parties, which always make valid claims, are guaranteed to win challenges.

Honest parties engage in challenges against parties with differing claims, ultimately eliminating the parties with false claims.

As false claims are eliminated, the overall protocol can make progress and maintain the integrity of the RBlock chain.

The Base Case

• Parties are incentivized to stake only on valid RBlocks due to the potential loss of their stake if they stake on an invalid one.
• Valid RBlocks, which have been confirmed, form a continuous chain that extends from the confirmed RBlocks.

Challenge Mechanisms

• If two parties stake on different successors of the same RBlock, a challenge is initiated to resolve the disagreement.
• The challenge aims to determine the validity of the RBlock claimed by each party and identify any false claims.
• The challenge sub-protocol ensures that a party with a valid claim can always win a challenge by presenting valid evidence at each stage of the challenge.

Challenge Resolution

• The party that loses the challenge has its stake removed from all RBlocks.
• Half of the losing party’s stake is given to the winning party, and the other half is added to a public goods fund.
• This mechanism incentivizes parties to only stake on valid RBlocks and penalizes those making false claims.

The image below shows an example of what the chain state looks like if several validators are being malicious. 

1. RBlock 100 has been confirmed.
2. RBlock 101 claimed to be a correct successor to RBlock 100, but 101 was rejected (hence the X drawn in it).
3. RBlock 102 was eventually confirmed as the correct successor to 100.
4. RBlock 103 was confirmed and is now the latest confirmed RBlock.
5. RBlock 104 was proposed as a successor to RBlock 103, and 105 was proposed as a successor to 104. 104 was rejected as incorrect, and as a consequence 105 was rejected because its predecessor was rejected.
6. RBlock 106 is unresolved. It claims to be a correct successor to RBlock 103 but the protocol hasn’t yet decided whether to confirm or reject it. It is the first unresolved RBlock.
7. RBlocks 107 and 108 claim to chain from 106. They are also unresolved. If 106 is rejected, they will be automatically rejected too.
8. RBlock 109 disagrees with RBlock 106, because they both claim the same predecessor. At least one of them will eventually be rejected, but the protocol hasn’t yet resolved them.
9. RBlock 110 claims to follow 109. It is unresolved. If 109 is rejected, 110 will be automatically rejected too.
10. RBlock 111 claims to follow 104. 111 will inevitably be rejected because its predecessor has already been rejected. But it hasn’t been rejected yet, because the protocol resolves RBlocks in RBlock number order, so the protocol will have to resolve 106 through 110, in order, before it can resolve 111. After 110 has been resolved, 111 can be rejected immediately.

Staking

Staking ensures the integrity and security of the network. Similar to PoS networks, validators referred to as stakers deposit funds to participate in the validation process and maintain the accuracy of the chain.

• Stakers deposit funds that are held in the Arbitrum Layer 1 contracts.
• A single stake can cover a sequence of RBlocks, representing a coherent claim about the correct history of the chain.
• Each staker is staked on the latest confirmed RBlock, and they can also stake on one successor RBlock of their currently staked RBlock.

This arrangement ensures that validators are invested in the validity of the RBlocks they participate in, as they have something to lose if a block is rejected.

To create a new RBlock, a validator must already be staked on the predecessor RBlock. This requirement ensures that block creators have a stake at risk, incentivizing them to propose valid and accurate RBlocks.

If a validator is staked on an RBlock, they can add their stake to any one successor RBlock of that Block. Note that this process does not require placing a new stake; the validator’s existing stake is extended to cover the successor RBlock. 

• If a staker is only staked on the latest confirmed RBlock (and possibly earlier RBlocks), they can request to have their stake refunded.
  • Refunding the stake involves returning the staked funds and ending their staker status.
• If a staker loses a challenge, their stake is removed from all RBlocks, and they forfeit the staked funds.
  • This provides an incentive for stakers to ensure their claims and contributions are valid and secure.
• The current minimum stake amount is typically the base stake amount, a parameter of the Nitro chain.
  • In cases where RBlocks are not being confirmed quickly, the minimum stake amount temporarily increases to discourage malicious parties from attempting to delay progress
  • The escalation is exponential and based on the time since the deadline of the first unresolved RBlock passed. This prevents delay attacks by increasing the cost of false stakes.

Rules for Confirming and Rejecting RBlocks

• The first unresolved RBlock can be confirmed if certain conditions are met, including staker presence and adherence to the sequence of confirmed RBlocks.
• The first unresolved RBlock can be rejected if the predecessor RBlock has been rejected or if specific criteria, such as staker presence, are not met.

Challenges

Assuming the rollup chain shown below:

RBlocks 93 and 95 are siblings (they both have 92 as predecessor). Alice is staked on 93 and Bob is staked on 95.

Since we can see that Alice and Bob have conflicting claims about the correctness of RBlock 93, a challenge can be initiated to determine the accurate state of affairs. Alice believes RBlock 93 is correct, while Bob asserts it’s incorrect due to his stake in RBlock 95 (which implies that RBlock 93 must be wrong if RBlock 92 is the last correct block).

• When two stakers are staked on sibling RBlocks (blocks that share the same parent), and neither is already in an active challenge, anyone can initiate a challenge between them.
• The Nitro roll-up protocol will handle and referee the challenge, ultimately deciding a winner and confiscating the losing party’s stake. The loser will then be removed as a staker.

The challenge process operates in two phases: dissection and one-step proof. In the dissection phase, the dispute is gradually narrowed down until it becomes a disagreement about a single execution instruction. This is achieved through a back-and-forth game played by Alice and Bob, with an Ethereum contract acting as the referee. Alice, the defender, makes the first move.

By systematically dissecting the claims and executing a challenge game, Nitro can reach a resolution and maintain the integrity of the network. The winner’s claim is validated, while the losing staker’s stake is confiscated, discouraging false claims and enhancing the overall trustworthiness of the blockchain.

• Alice’s correct claim: 
  • If Alice’s initial claim is correct, she can offer a truthful midpoint claim, which would have two half-size claims, both of which will also be correct.
  • At each stage, Alice defends a correct claim, leading to her having a correct one-step claim at the end of the protocol. This claim can be proven, allowing Alice to win the challenge.
• Bob’s corrective claim:
  • If Alice’s initial claim is incorrect, her claimed endpoint after N steps is incorrect.
  • When Alice offers her midpoint state claim, it can be either correct or incorrect.
  • If Alice’s midpoint claim is incorrect, Bob can challenge her first-half claim, which will also be incorrect.
  • If Alice’s midpoint state claim is correct, her second-half claim must be incorrect. Therefore, Bob can challenge that claim.
  • At each stage, Bob identifies an incorrect half-size claim to challenge, leading to a sequence of challenges on incorrect claims.
  • At the end, Alice has an incorrect one-step claim, and she cannot prove it, allowing Bob to win the challenge.

The dissection protocol begins with dissection over Layer 2 blocks, narrowing the dispute down to a single Layer 2 Nitro block.  It then further dissects down to a single execution of the State Transition Function.

Instead of dividing the claim into two segments of size N/2, the K-way dissection divides it into K segments of size N/K. This reduces the number of rounds significantly. The protocol also handles cases where the AVM might halt or wait due to an exhausted inbox. Additionally, time limits are introduced for each player to ensure the game progresses and concludes in a reasonable timeframe.

Validators

Validators are nodes that actively participate in the rollup protocol and help advance the state of the chain. Offchain Labs provides open-source validator software to facilitate this process, but validators have the flexibility to choose their own strategies. There are three common validator strategies:

• Active Validator Strategy: Active validators propose new RBlocks and actively participate in the rollup protocol.
  • They are always staked because creating an RBlock requires being staked.
  • Generally, a chain only needs one honest active validator to efficiently function.
  • Offchain Labs, for example, runs an active validator for the Arbitrum One chain.
• Defensive Validator Strategy: Defensive validators monitor the roll-up protocol and intervene if an incorrect RBlock is proposed.
  • They do not stake when things are going well, but they stake or post a correct RBlock if someone attempts to propose an incorrect one.
  • This strategy defends the correct outcome in case of dishonest behavior.
• Watchtower Validator Strategy: Watchtower validators do not stake but act as observers.
  • They raise the alarm if they detect an incorrect RBlock being proposed.
  • This strategy assumes that other staked validators will intervene to challenge incorrect behavior.

Under normal conditions, defensive and watchtower validators mainly observe the network. This creates uncertainty for malicious actors, as they won’t know the number of defensive and watchtower validators operating in incognito. Some validators might announce themselves, while others remain hidden, making it challenging for attackers to predict the response.

Validators can be motivated by various factors:

• Financial Incentives: 
  • Some validators are paid by the chain creators or other parties. Funds from user transaction fees can be used to compensate validators.
  • Validators can earn rewards for their participation and contribution to the network’s security.
• Protecting Investments:
  • Parties with significant assets at stake on the chain, such as dApp developers, exchanges, and liquidity providers, may choose to validate to safeguard their investments.
• Personal Interest:
  • Individuals who are power users, early adopters, or simply value the security and integrity of the network might choose to validate.

Full Nodes

Full nodes in Arbitrum serve a similar role to full nodes in Ethereum. They are responsible for maintaining the state of the Arbitrum chain and providing an interface for users and applications to interact with the chain. 

• Maintaining State: Full nodes keep track of the current state of the Arbitrum chain. This includes information about account balances, smart contract states, transaction history, and more.
• Inbox Messages: Full nodes receive and process inbox messages generated by the rollup protocol. These inbox messages are used to advance the state of the Layer 2 chain. Full nodes focus on the Layer 2 processing without directly participating in the rollup protocol itself.
• API Access: Full nodes expose an API that allows external applications, users, and other nodes to interact with the Arbitrum chain. This API enables developers to retrieve information from the chain, submit transactions, query contract states, and more.

The Sequencer

The Sequencer helps provide faster confirmation times for transactions and enhances the user experience by allowing immediate result guarantees. 

The Role of the Sequencer

• Immediate Confirmation: The Sequencer is a specially designated full node that has the power to control the ordering of transactions within the Arbitrum chain’s inbox. This control allows the Sequencer to guarantee the results of user transactions without waiting for Ethereum’s block confirmations.
• Transaction Ordering: By influencing the ordering of transactions, the Sequencer ensures that users receive instant confirmation of their transactions’ results. This is in contrast to the uncertainty that arises from not knowing the exact order of transactions submitted by different users.
• API Interaction: Clients interact with the Sequencer in the same way they interact with any full node. Wallet software can be configured to use the network URL pointing to the Sequencer, enabling users to seamlessly enjoy the benefits of immediate confirmation.

Inboxes and Transaction Ordering

• Sequencer’s Control: Only the Sequencer can directly add new messages to the main inbox. It tags these messages with Ethereum block numbers and timestamps. This control over ordering gives the Sequencer more influence over determining the results of transactions.
• Delayed Inbox: Messages submitted by non-Sequencer nodes are placed in the “delayed inbox” queue. These messages wait until the Sequencer releases them into the main inbox. A well-behaved Sequencer typically releases these messages after about ten minutes.
• Prompt Release: A well-behaved Sequencer minimizes delay for non-Sequencer transactions by releasing delayed messages promptly. This ensures that messages waiting in the delayed inbox can achieve finality relatively quickly.

Tradeoffs and Trust

• Trade-off with Finality: The presence of the Sequencer introduces a trade-off between transaction finality and delay. Transactions that use the Sequencer experience faster finality, while those going through the delayed inbox have slightly slower finality due to the two-step process.
• Trust in Sequencer: Trust is essential when using a centralized Sequencer like the one currently operated by Offchain Labs. Users must trust that the Sequencer will behave correctly and fairly.

Decentralized Fair Sequencing

• Long-Term Solution: The goal is to transition from a centralized Sequencer to a decentralized and fair sequencing mechanism. This would involve a committee of nodes working together to achieve transaction ordering that is both decentralized and trustworthy.
• Research and Development: Research conducted by Cornell Tech, including Offchain Labs’ CEO, has developed algorithms for decentralized fair sequencing. These concepts form the basis for the longer-term solution, which aims to ensure transaction ordering integrity without relying on a centralized entity.

Bridging

Bridging involves asynchronous cross-chain calls. These calls are used for contract-to-contract interactions between the L1 and the L2, allowing transactions to be submitted on one chain and that will be executed on the other chain.

L1 Contracts Submitting L2 Transactions

• Direct L2 Transaction Submission: An L1 contract can submit an L2 transaction by calling the Nitro chain’s inbox contract on Ethereum. This triggers an L2 transaction that will execute later. However, the L1 caller won’t be able to see the results of this L2 transaction.
• Advantages and Disadvantages: This method is relatively simple and low-latency. However, the L2 transaction may revert if the L1 caller doesn’t provide the correct L2 gas price and maximum gas amount. Since the L1 caller can’t see the L2 transaction’s result, it can’t be certain of its success.
• Alternative Ticket-Based System: An alternative method is to use a ticket-based system for L1-to-L2 calls. In this approach, an L1 contract submits a “retryable” transaction. If the L2 transaction fails, a “ticketID” is created, representing the failed transaction. Later, anyone can redeem this ticket and re-execute the transaction on L2.
• Retrying Failed Transactions: When a ticket is redeemed, the saved transaction is re-executed on L2 with the original sender, destination, call value, and calldata. If the redemption succeeds, the ticket is canceled; if it fails, the ticket remains available for redemption.

L2 Contracts Submitting L1 Transactions

• L2-to-L1 Calls: L2 contracts can call a method in the precompiled ArbSys contract, which triggers an L1 transaction. Once the execution of the L2 transaction containing the submission is confirmed on L1, a ticket is generated in the L1 outbox contract.
• Ticket-Based Redemption: Any user can trigger the ticket by calling a specific L1 outbox method and submitting the ticketID. If the L1 transaction doesn’t revert, the ticket is marked as redeemed.
• Lifetime of Tickets: L2-to-L1 tickets have an unlimited lifetime until they’re successfully redeemed. They don’t require rent and are recorded in Ethereum storage.

L1 to L2 Messaging

Arbitrum uses retryable ticks for L1 to L2 messaging. This is a mechanism for creating cross-chain messages and ensuring the atomicity of the operations between the L1 and the L2.

1. Submission: Users initiate the creation of a retryable ticket by calling the createRetryableTicket function of the inbox contract on L1.

1. Parameters need to be set carefully, including destination L2 address, L2 call value, maximum submission cost, gas limit, and more.
2. The user’s deposit must cover the L1 submission and L2 execution costs.
3. If successful, a new ticket with a unique TicketID is created on L2, and funds are deducted from the user and placed into escrow.

2. Automatic Redemption: If conditions are met (user’s L2 balance and gas price), the ticket is automatically redeemed on L2, executing the L2 message.

1. If successful, the submission fee is refunded to the user, and the ticket is deleted from the retryable buffer.
2. If unsuccessful, the submission fee remains in escrow for a future redemption attempt.

3. Manual Redemption: If the automatic redemption fails, anyone can manually redeem the ticket by calling the redeem precompile method.

1. Redeem attempts are scheduled to be executed as soon as possible on L2, ensuring eventual redemption.
2. If a ticket is not redeemed within a fixed period (one week), it expires and is automatically discarded unless renewed.
3. Funds in the escrowed call value are paid out to the callValueRefundAddress specified during ticket submission.
4. Redeeming the cost of a ticket doesn’t increase over time; it depends on the current gas price and required gas for execution.

At the end of the lifecycle, Two types of L2 transaction receipts are emitted:

• Ticket Creation Receipt: Indicates successful creation of a ticket, with a TicketCreated event containing the TicketID.
• Redeem Attempt Receipt: Represents the result of an attempted L2 execution of a ticket (success/failure), with a RedeemScheduled event and TicketID.

L2 to L1 Messaging

Contract calls can also be initiated on the L2 for execution on the L1.

From the protocol perspective:

1. An L2-to-L1 message is part of the L2 state in an Arbitrum chain.
2. Upon the confirmation of an RBlock (typically about 1 week after its assertion), the Merkle root of all L2-to-L1 messages in that RBlock is posted on L1 in the Outbox contract.
3. The Outbox contract enables users to execute their L2-to-L1 messages by validating Merkle proofs of inclusion and tracking spent messages.

From the client perspective:

1. To initiate an L2-to-L1 message, a client calls the L2 ArbSys precompile contract’s sendTxToL1 method.
2. After inclusion in an assertion (typically within an hour) and assertion confirmation (typically about 1 week), any client can execute the message.
3. Clients retrieve proof data through the Arbitrum chain’s “virtual” NodeInterface contract’s constructOutboxProof method.
4. The returned data is used in the Outbox’s executeTransaction method to perform the L1 execution.

This design ensures that the overhead for confirming nodes remains constant and that they only update the constant-sized outgoing message root hash. Unlike Retryables, L2-to-L1 messages can’t provide in-protocol automatic L1 execution due to Ethereum’s lack of scheduled execution affordances.

• A week-long delay before executing outgoing messages is inherent to the nature of Arbitrum Rollup and Optimistic Rollup L2 solutions.
  • It allows time for Arbitrum validators to detect and prove faults before Ethereum accepts the results.
  • This delay ensures the protocol’s security by providing a window for detecting and handling any issues.

Lifecycle of an Arbitrum Transaction

1. Sequencer Receives Transaction: The transaction lifecycle begins with the Sequencer, responsible for ordering transactions and receiving a transaction from a client. Transactions can be received either directly from the client or from layer 1 via the Delayed Inbox.
2. Finality Check – Trusted / Soft Confirmation: At this point, the client relies on the Sequencer’s soft confirmation, assuming a degree of trust in the Sequencer’s transaction processing.
3. Sequencer Orders Transaction (Off-Chain): The Sequencer orders the transaction in its off-chain Inbox and executes it using the Arbitrum Nitro VM. It provides the client with an instant transaction receipt.
4. Finality Check – Ethereum-Equivalent Finality: The client’s transaction’s finality is now equivalent to a regular Ethereum transaction, provided there’s at least one well-behaved active Arbitrum validator.
5. Sequencer Posts Transaction in a Batch (On-Chain): The Sequencer posts a batch of transactions, including the client’s transaction, to layer 1 as calldata. The Sequencer typically posts batches every few minutes.
6. Finality Check –  Ethereum-Equivalent Finality: The client can treat their transaction’s finality as equivalent to an ordinary Ethereum transaction since the batch is posted on layer 1, ensuring security and reliability.
7. Validator Asserts RBlock that Includes Transaction: An active validator executes the Arbitrum VM over the inputs in the Inbox, asserting a rollup block (RBlock) on layer 1. This process occurs approximately every 30-60 minutes.
8. Finality Check – Still the Same Ethereum-Equivalent Finality: The transaction’s finality remains secure, even during a dispute, as the assertion process doesn’t impact the previously established Ethereum-equivalent finality.
9. RBlock is Confirmed on L1: Once disputes are resolved and sufficient time has passed, the RBlock is confirmed on layer 1. The Outbox root on layer 1 is updated, indicating successful processing.
10. Finality Check – L2-to-L1 Messages Executable on L1: If the transaction included L2-to-L1 messages, these messages can now be executed in the Outbox on layer 1.

The Challenge Subprotocol

The challenge subprotocol in Nitro is designed to resolve disputes between parties and determine the validity of their claims about block results and execution steps. The protocol is divided into three phases, which aim to bisectionally narrow down the dispute to a single WAVM instruction’s execution. 

• Phase 1: Bisecting Over Blocks:
  1. Alice and Bob begin with a disagreement over a range of block states, spanning from block number B to block number B + N.
  2. Each round, they agree on a midpoint state SM at block M = B + ⌊N/2⌋.
  3. Bob indicates whether he agrees or disagrees with Alice’s claimed midpoint state SM.
  4. Depending on Bob’s response, the protocol either reduces the dispute range by half (if agreed) or maintains the start point while reducing the range (if disagreed).
  5. This process continues for at most ⌈log2N⌉ rounds until N becomes 1.
• Phase 2: Bisecting Over Instructions:
  1. Alice and Bob now disagree over a single Nitro block’s contents or state after execution.
  2. Alice claims the number of WAVM instructions executed (K) during that invocation.
  3. The protocol mimics Phase 1’s bisection process, but now the dispute is over instructions rather than blocks. The disagreement is about the state of the WAVM virtual machine executing the State Transition Function.
  4. After at most ⌈log2K⌉ rounds of bisection, the dispute is narrowed down to the execution of a single WAVM instruction.
• Phase 3: One-step Proof:
  1. In this phase, Alice and Bob agree on the hash of the WAVM VM state but disagree on the hash after executing one more WAVM instruction.
  2. Alice must present a one-step proof verification contract on Ethereum, along with a witness to support her claim about the single step of execution.
  3. The verification contract confirms whether the execution of the single instruction can transition the VM from the “before” state hash to the “after” state hash.
  4. The witness consists of a partial expansion of the Merkle tree representing the “before” state. The verifier uses this partial tree to read the next instruction, simulate its execution, calculate the Merkle root hash of the resulting state, and compare it to the “after” state hash.
  5. If Alice’s one-step proof is valid, she wins the challenge; otherwise, Bob wins.

The use of the Merkle tree and the witness in the verification process allows for efficient validation using a feasible amount of Ethereum gas.

AnyTrust: Nitro with External Data Availability

In the context of the Nitro roll-up system, “AnyTrust” is a variant that introduces a slight trust assumption to reduce costs. This variant leverages an external Data Availability Committee to handle data availability, which lowers the cost associated with data posting on the L1 Ethereum chain. 

AnyTrust support is included in the Nitro code base.

The feature can be enabled or disabled using a configuration switch, allowing flexibility in choosing whether to adopt the AnyTrust variant.

Availability and Trust Assumption

• The standard Nitro protocol requires that all Arbitrum nodes have access to the data of every Layer 2 (L2) transaction in the Arbitrum chain’s inbox.
• Data availability is achieved by posting data on the L1 Ethereum chain as calldata. However, this incurs a significant cost.
• The AnyTrust variant introduces a trust assumption and uses an external Data Availability Committee to store and provide access to data. The assumption is that at least two members of the Committee are honest.

Data Availability Committee

• The Committee consists of N members, and AnyTrust assumes that at least two of them are honest.
• With this assumption, if N – 1 members commit to providing access to certain data, at least one of those members must be honest. This ensures that the data will be available when needed, facilitating the overall functioning of the Arbitrum protocol.

Sequencer Behavior

• In AnyTrust, the Sequencer doesn’t post data for its batches on the L1 Ethereum chain as in the standard Nitro protocol.
• Instead, for each batch, the Sequencer posts a Data Availability Certificate that contains the hash of the batch data. This certificate serves as proof that the batch data with that specific hash is available from the Committee, under the assumption that at least two Committee members are honest.

AnyTrust Components

AnyTrust is a variant of Arbitrum Nitro technology that lowers costs by accepting a mild trust assumption.

In the AnyTrust variant of the Nitro roll-up system, several components work together to enable the efficient handling of data availability using an external Data Availability Committee.

Keysets

• A Keyset specifies the public keys of Committee members and the number of signatures required for a Data Availability Certificate (DACert) to be considered valid.
• Keysets allow for Committee membership changes and provide Committee members with the ability to change their keys.
• A Keyset contains information such as the number of Committee members, each member’s BLS public key, and the required number of Committee signatures.
• Keysets are identified by their hashes.
• The L1 KeysetManager contract maintains a list of valid Keysets. The L2 chain’s Owner can add or remove Keysets from this list.
• When a Keyset becomes valid, the KeysetManager contract emits an L1 Ethereum event containing the Keyset’s hash and full contents, which allows the contents to be recovered based on the hash.

Data Availability Certificates (DACerts)

• A DACert is a central concept in AnyTrust and is used to prove the availability of data blocks from the Committee.
• A DACert contains the hash of a data block, an expiration time, and proof that a sufficient number of Committee members have signed the (hash, expiration time) pair.
• The proof includes the hash of the Keyset used for signing, a bitmap indicating which Committee members signed, and a BLS aggregated signature that proves those parties signed.
• Due to the 2-of-N trust assumption, a valid DACert proves that the data block’s preimage (hash) will be available from at least one honest Committee member until the expiration time.
• In AnyTrust, the Sequencer can choose to post a full data block or a DACert on the L1 Ethereum chain. The L2 code will handle the verification of the DACert’s validity.

Data Availability Servers (DAS)

• Committee members run Data Availability Server (DAS) software, which exposes two APIs.
• The Sequencer API is meant to be called only by the Arbitrum chain’s Sequencer. It allows the Sequencer to submit data blocks to the DAS for storage.
• The REST API is meant to be available to the public. It is a cacheable RESTful HTTP(S) protocol that allows data blocks to be fetched by their hashes.
• DAS software supports various storage options, including local files, BadgerDB database, Amazon S3, and more. It also offers optional caching using tools like Bigcache or Redis.

Sequencer-Committee Interaction

• When the Nitro Sequencer wants to post a data batch using the Committee, it sends the data and an expiration time to all Committee members in parallel via RPC.
• Each Committee member stores the data and signs the (hash, expiration time) pair using its BLS key.
• The Sequencer collects enough signatures and aggregates them to create a valid DACert for the (hash, expiration time) pair.
• The Sequencer posts the DACert to the L1 inbox contract, making it available to the AnyTrust chain software at L2.
• If the Sequencer fails to collect enough signatures in a reasonable time, it can fall back to posting full data directly to the L1 chain. The L2 software can handle both data posting formats.

Data Pricing

• AnyTrust significantly reduces the amount of L1 data required for the same number of transactions, leading to lower prices for transaction data.
• The pricing algorithm remains similar to that of a normal Nitro chain, but with AnyTrust, the Sequencer’s data spending is much lower (posting data availability certificates instead of full data).
• This results in a much lower price per data unit on user transactions. If the Sequencer falls back to posting full data, the data price will rise to compensate.

The Assertion Tree

The Assertion Tree in the Arbitrum protocol represents the state of an Arbitrum chain and the process of confirming that state back on Ethereum through “assertions” or “disputable assertions” (DAs). 

• The state of an Arbitrum chain is confirmed through assertions made by Arbitrum validators on Ethereum.
• An assertion is a claim made by a validator about the state of the Arbitrum chain. To make an assertion, a validator must post a bond in Ether.
• In the normal case, valid assertions build on one another, forming a sequence of valid states.
• If two or more conflicting assertions exist, the Assertion Tree branches into multiple branches, each representing a different sequence of states.
• The deterministic nature of the Arbitrum chain’s rules ensures that, given a chain state and inputs, there’s only one valid output.
• If the Assertion Tree has multiple branches, at most one branch represents the valid chain state, assuming at least one honest active validator.

• Conflicting assertions can be disputed through a process called an Interactive Challenge, which involves a fixed time period (around 1 week).
• After the challenge period, one of the conflicting assertions will be rejected, and the validator who posted it will lose their stake.
• The assertion that survives the challenge process is the one that accurately represents the valid chain stat

For an assertion to be confirmed and the validator’s stake to be recovered, sufficient time for disputes must have passed, and no conflicting branches can exist in the Assertion Tree. These conditions ensure that as long as at least one honest active validator exists, the valid chain state will ultimately be confirmed.

During a dispute, validators can continue making assertions and users can continue transacting on L2. The primary delay that users experience during a dispute is related to their L2 to L1 messages, or withdrawals. However, a delay attacker attempting to cause deliberate delays will find this attack to be very costly, as each bit of delay gained requires the attacker to lose more stake. 

Arbitrum Nova

Arbitrum Nova is an Arbitrum chain that harnesses the power of AnyTrust technology. This technology stands parallel to Arbitrum One, which itself is built upon the innovative Arbitrum Rollup technology.

Drawing inspiration from Arbitrum Nitro, AnyTrust serves as a variant that harnesses a mild trust assumption to drive down costs. This calculated approach allows for a substantial reduction in transaction fees without compromising on security.

Some of the key features that differentiate Arbitrum Nova include:

• Ultra-Low Transaction Costs.
• Tailored to the needs of High-Volume DApp.
• Cryptographic Security: Users retain complete control over their assets, ensuring security and autonomy.
• EVM Compatibility: Seamlessly compatible with Ethereum’s EVM (Ethereum Virtual Machine).

On the one hand, Arbitrum Nova is poised to shine as the preferred platform for gaming and social applications. On the other hand, Arbitrum One retains its role as the hub for DeFi initiatives and numerous NFT projects.

Data Availability Committee (DAC): Fortifying Security

Built upon the foundation of AnyTrust, the Data Availability Committee (DAC) operates with a crucial assumption—out of a committee of N members, at least two must be honest. This ensures that even if a majority of members fail to provide data, the network remains functional. In the absence of sufficient committee support, data is seamlessly posted on Layer 1—reminiscent of Arbitrum Rollup’s withdrawal mechanism. Once the DAC is reinstated, the network effortlessly shifts back to its high-speed, low-cost mode.

DACert: Paving the Way for Efficiency

Sequencers, in their role of data compression and batching, submit their work to the DAC, accompanied by a data availability certificate (DACert). This certificate serves as proof of data availability, facilitating a streamlined process. The obtained certificate is then broadcasted as a data availability promise on the Ethereum network by sequencers.

In stark contrast to conventional networks, Arbitrum Nova operates on the premise of DACerts—certificates attesting to data availability—rather than transmitting full data. This strategic approach significantly curtails costs, positioning Arbitrum Nova as a frontrunner in achieving ultra-low transaction fees for users.

Posting Transaction Batches

In Arbitrum Nova, the process of posting transaction batches to L1 involves submitting a hash of transaction data, an aggregate BLS signature from DAC members, and a hashed keyset. While L1 does not directly validate BLS signatures, faulty batches with invalid signatures are challenged by Validators, leading to a dispute resolution process that involves the BLS library in the WASM code.

1. Hash of Transaction Data: Instead of posting the complete transaction data, the Sequencer on Arbitrum Nova submits a hash of the transaction data. This hash serves as a reference to the actual transaction data stored off-chain. This approach helps save gas costs and reduce the amount of data that needs to be posted to L1.
2. Aggregate BLS Signature: The most important aspect of the submission is the aggregate BLS signature. This signature is generated by aggregating the signatures of all members of the Data Availability Committee (DAC). The DAC members are responsible for producing and storing the off-chain data of transactions. The BLS signature serves as proof that the DAC members have collectively approved the batch of transactions.
3. Hash of Keyset: The hash of the keyset is another crucial field that’s included in the L1 submission by the Sequencer. The keyset represents the set of public keys belonging to the DAC members who have signed the transactions. This hashed list of public keys includes additional information, such as the required quorum (the minimum number of signatures required for approval).
4. Accessing Keyset Information: In order to verify the keyset and its associated information, a user can access the Sequencer Inbox on L1. The Rollup Owner, who manages the Sequencer, has previously set up the Sequencer Inbox and posted all the necessary keyset information. This information includes the list of public keys along with the quorum requirement.
5. Keyset Verification: The hashed keyset information can be used to ensure that the Sequencer’s submission is valid. The keyset hash must match the information provided by the Sequencer in the Sequencer Inbox. If the keyset does not match, the submission will be rejected.
6. Signature Validation: Interestingly, while L1 does check the keyset hash, it doesn’t directly validate the BLS signatures themselves. There is no pre-compile on Ethereum for BLS signature validation. This means that even though the signature is not checked on L1, faulty batches with invalid signatures will face challenges within the fraud-proof system.
7. Challenge Process: If the Validators, who are responsible for off-chain validation, detect a batch with invalid signatures, they will initiate a challenge process. The faulty batch will be flagged as part of the standard fraud-proof mechanism. Validators will challenge the batch, triggering a dispute over the validity of the BLS signature.
8. Resolution of Dispute: The challenge will eventually lead to a resolution where the disagreement over the validity of the BLS signature is addressed. Since Arbitrum Nova is built on Nitro, which uses WebAssembly (WASM) underneath, the dispute resolution will involve a BLS library included in the WASM code. This library will be utilized to determine the correctness of the signatures.

Arbitrum Orbit

 Arbitrum Orbit empowers developers to seamlessly and permissionlessly inaugurate their very own Layer 3 (L3) blockchains within the Arbitrum ecosystem. Arbitrum Orbit introduces a way to create personalized chains that seamlessly integrate with Arbitrum’s Layer 2 (L2) chains: Arbitrum One, Arbitrum Nova, or Arbitrum Goerli. By establishing your Orbit chain, you gain full ownership and customization capabilities for privacy settings, permissions, governance, fee tokens, and more.

Arbitrum Orbit’s L3 chains also embrace the forthcoming release of Arbitrum Stylus, a monumental advancement enabling developers to harness the power of programming languages like C, C++, and Rust, alongside Solidity and other EVM languages, for their chains. This amalgamation of versatile languages enhances the toolkit available to developers, fostering innovation and diversification in the ecosystem.

Arbitrum Orbit offers remarkable possibilities that extend the realm of decentralized applications and protocols:

• Launch Nitro-powered blockchain networks: Experience the benefits of Nitro’s fraud proofs, advanced compression, EVM+ compatibility through Stylus, and continuous enhancements.
• Guarantee gas price reliability: Orbit chains provide dedicated throughput and traffic isolation, ensuring consistent gas prices for users.
• Flexible permissions: Tailor access to control data reading and contract deployment. From fully permissionless structures to custom permission policies, the choice is yours.
• Efficient fee collection: Utilize a token of your choice for iterative domain-specific mechanism designs and value capture opportunities.

Arbitrum Orbit serves as a deployable, customizable fork of Arbitrum’s L2 Nitro technology stack. It acts as a tightly integrated extension to Arbitrum’s L2 chains, offering the potential to progressively decentralize applications and adopt Ethereum’s base layer security.

 

The categorization of Orbit chains as “app chains” hinges on individual interpretations. Although Orbit chains can certainly serve as application-specific chains, their scope goes beyond that. These chains facilitate the hosting of EVM-compatible smart contracts through self-managed infrastructure. This isolation of compute and storage resources from Arbitrum’s public L2 chains ensures a tailored experience. Here’s a glimpse of the possibilities:

• Diverse Application Scenarios: Orbit chains can accommodate one or multiple dApps, an entire ecosystem of dApps, or even none at all.
• Support for Centralized Services: These chains can also host arbitrary EVM contracts for private, centralized services.
• Flexible Purpose: Orbit chains can be designed for specific or general purposes, offering a spectrum of use cases.
• Innovative Configurations: The potential exists to construct dApps that rely on multiple Orbit chains, fostering novel redundancy, high availability, and trust mechanisms.

All Orbit chains operate on self-managed nodes powered by Arbitrum Nitro’s node software. This software implements both AnyTrust and Rollup protocols. An Orbit chain can be configured to process and settle transactions using either protocol. This signifies that an Orbit chain isn’t isolated in its own blockchain network. By launching an Orbit chain, you’re becoming part of a network of connected chains that can communicate and exchange information.

Licensing Nuances of Orbit

Your capacity to modify and adapt the Arbitrum Nitro codebase is fully endorsed by the Orbit chain license. This license, bestowed upon Orbit Chains, is marked by two key attributes:

• Perpetual Nature: The license is perpetual, safeguarding your authority to use the software license indefinitely.
• Recursive Character: Remarkably, your Orbit chain can host other chains governed by the same license, enabling a recursive licensing structure.

However, it’s important to note that the Arbitrum Orbit license doesn’t inherently extend to chains settling on non-Arbitrum-DAO-governed chains. If your intention is to launch an independent Arbitrum Nitro chain as an L2 on Ethereum, there are two avenues:

• Seek Assistance from Offchain Labs: Offchain Labs, the original developer of the Arbitrum Nitro codebase, possesses the authority to grant custom licenses.
• Engage the Arbitrum DAO: The launch of the Arbitrum DAO has conferred co-licensor rights to approve additional L2s on Ethereum. To explore this route, you must submit a proposal to the Arbitrum DAO, and their decision will determine the licensing for your proposed L2 chain.

Arbitrum Orbit AnyTrust Chains

With Orbit, Offchain Labs is introducing the capability to easily launch Arbitrum Orbit AnyTrust chains. These chains offer ultra-low-cost transactions and high-speed processing, making them ideal for high-volume use cases such as gaming, social projects, and finance. 

AnyTrust chains enable significantly lower transaction costs compared to Layer 1, faster withdrawals, custom fee tokens, and strong security guarantees. This expansion in the Orbit ecosystem enhances the variety of deployment options available to developers.

• Lower Transaction Costs: AnyTrust chains offer transaction costs approximately 30–150 times cheaper than Layer 1 Ethereum. This cost reduction is achieved through the use of a Data Availability Committee (DAC) that stores calldata, minimizing the need for transaction data to be posted on Ethereum.
• Faster Withdrawals: AnyTrust chains will soon feature faster withdrawals, reducing the waiting period from days to minutes. Transactions can be confirmed and executed immediately when a quorum of DAC members confirms the transaction’s outcome.
• Custom Fee Tokens: Support for custom fee tokens will be integrated into Arbitrum Nitro, enabling chains to accept native ERC20 tokens as payment for transaction fees. This feature enhances value capture and flexibility for project teams and their ecosystems.
• Strong Security Guarantees: AnyTrust chains are operated by a committee of nodes, relying on a minimal assumption about the number of honest committee members. This trust requirement is smaller than conventional BFT sidechains, providing strong security guarantees.

Differentiating AnyTrust From Rollups

Arbitrum Rollup is a trustless and permissionless Optimistic Rollup protocol that posts all chain data on Layer 1 Ethereum. In contrast, Arbitrum AnyTrust introduces a trust assumption to achieve lower fees. Data availability is managed by a Data Availability Committee (DAC), introducing the requirement that a certain threshold of committee members are honest. If this threshold is met, data doesn’t need to be posted on Ethereum, resulting in significantly lower fees.

Chain Type	General-purpose Optimistic Rollup	General-purpose AnyTrust
Tech stack	Nitro (fully EVM compatible)	Nitro (fully EVM compatible)
Calldata storage	Calldata posted to Ethereum L1	Calldata sent to the data availability committee
Gas savings	10-50x cheaper than L1	30-150x cheaper than L1
Average transaction confirmation time	< 1s	< 1s

Stylus

Stylus shatters the confines of Solidity exclusivity, enabling a diverse range of programming languages to coexist harmoniously within the realms of Arbitrum One and Nova. This pioneering approach paves the way for Rust, C, C++, and more to seamlessly cohabit the same blockchain alongside traditional Solidity dApps. With Stylus, developers, both newcomers and seasoned Web3 veterans, can leverage their existing skills and preferences to contribute to the Arbitrum ecosystem without the constraints of learning a new language.

Stylus ushers in an innovative model where user programs, compiled into WASM, are transmuted on-chain into a format that ensures bounded execution and enforces safety. WASM sandboxing empowers the near-native speed execution of user programs while upholding the same security guarantees leveraged by web browsers. Malicious programs are eliminated with on-chain proofs, all without necessitating EVM invocation.

Faster dApps and Lower Fees

Stylus transcends mere linguistic diversity and introduces a profound boost in performance. Building upon Arbitrum’s Nitro upgrade, which yielded a 10x performance enhancement, Stylus shatters expectations once again. 

Rust-based Arbitrum dApps achieve speeds exceeding an order of magnitude compared to their Solidity and Vyper counterparts. The result: lower fees and the ushering of a new era of high-compute blockchain applications across a spectrum of industries.

The Ethereum community’s persistent efforts to enhance the Ethereum Virtual Machine (EVM) become more profound with Stylus, allowing users to create their own specialized smart contracts known as precompiles. This flexibility enables the deployment of customized cryptography libraries, whether it’s a novel pairing curve for a zk team or a unique hashing algorithm for an alt-L1 bridge. Ethereum researchers are poised to explore, design, and iterate on EIP precompiles seamlessly through Stylus, without the need for individual testnets.

Lifecycle of a Stylus Contract

1. Coding: 

1. Developers write smart contracts using programming languages supported by Stylus. These languages include Rust, C++, C, and others that can be compiled into WebAssembly (WASM).
2. Contracts written in Stylus-supported languages can utilize the “Ethereum API,” allowing them to perform EVM-specific functions similar to those done in Solidity.
3. Stylus contracts can include libraries and external dependencies as long as they are compatible with the chosen programming language.

2. Compilation:

1. The contract code is compiled off-chain using a standard WASM compiler for the chosen programming language (e.g., Clang for C contracts).
2. The resulting WASM bytecode is posted onto the Arbitrum chain in compressed form, defining the contract’s behavior deterministically.
3. Users interact with the ArbWasm precompile and call the compileProgram method to generate efficient, machine-specific native assembly tailored for each Arbitrum node’s hardware. During this step, the WASM bytecode is instrumented to ensure safe execution and deterministic fraud proofs within Arbitrum’s VM.
4. Gas metering is added to each WASM opcode, measured in “ink,” a unit similar to Ethereum’s gas but smaller. This is because WASM execution is much faster than EVM execution, and many WASM ops can be executed for each EVM op.

3. Execution:

1. Stylus contracts are executed using Wasmer, a WASM runtime, which offers significant gas savings compared to executing equivalent operations in the EVM.
2. Contracts written in Solidity behave the same way as they do on Ethereum and are executed in an EVM-equivalent manner.
3. Stylus contracts are executed in parallel with EVM contracts, and both types of contracts access and modify the same state trie.

4. Proving:

1. Similar to the Nitro stack, Stylus has a fraud-proving mechanism that relies on proving the invalidity of a state update via smart contracts on Ethereum. These “fraud proofs” are crucial for ensuring the security and safety of the chain’s state updates.
2. The Stylus proving model extends Nitro’s fraud prover, “Arbitrator.” Validators bisect over user programs’ execution history, identifying and proving individual opcodes within the WASM program.
3. During the compilation step, instrumentation ensures the termination and determinism of the proving process, allowing validators to identify and prove individual opcodes within the user’s WASM program.
4. The fraud-proving mechanism guarantees the safety and validity of user-written contracts on the Arbitrum chain.

BOLD – Bounded Liquidity Delay

BOLD (Bounded Liquidity Delay) is a dispute protocol designed to facilitate permissionless validation for Arbitrum chains. BOLD aims to ensure safety and liveness of chains, minimize state settlement latency, and counter malicious parties that may raise costs for honest participants. This protocol extends to Arbitrum One and Nova chains, moving towards greater decentralization by allowing a single, honest validator to effectively challenge any number of adversaries.

Background

Optimistic Rollup chains, including Arbitrum One and Nova, utilize fraud proofs for state settlement on Ethereum. Validators post verified claims about the L2 state to a smart contract. During a 7-day period, these claims can be challenged, initiating a dispute resolution process. Once confirmed, the L2 state is deemed correct on Ethereum. This process supports bridging assets between Arbitrum chains and Ethereum L1, albeit with a 7-day delay. However, the existing validation process is vulnerable to denial-of-service attacks, impeding true permissionless validation.

The BOLD Protocol

BOLD introduces a novel approach to validation, addressing the delay attack vulnerability. It provides a fixed, upper-bound 7-day delay while remaining immune to delay attacks. This new protocol, designed by Offchain Labs, enhances the permissionless nature of validation, advancing decentralization by ensuring that a single honest validator can challenge malicious claims effectively. The protocol’s code and research specification are available on GitHub, and the codebase is also being contributed to the Arbitrum Nitro codebase for further development and testing.

• Guaranteed Time Bounds: BOLD guarantees fixed upper bounds on confirmation times for Optimistic Rollup settlement.
• Adversarial Resistance: A single honest party can prevail against any number of malicious claims.
• Deterministic Execution: BOLD disputes are linked to the deterministic execution of an L2 state, allowing any agreement party to defend it.
• Strong Immunity to Faked Proofs: As the honest L2 state is deterministic, adversaries cannot fabricate proofs of execution.

Why the Project Was Created

The inception of Arbitrum was driven by a clear and compelling vision to address the fundamental challenges faced by Ethereum and the broader blockchain ecosystem. As Ethereum’s mainnet (layer 1) grappled with transaction throughput limitations, the need for layer 2 protocols emerged as a solution to enhance performance and user experiences.

The team at Offchain Labs recognized these challenges as opportunities to push the boundaries of what was possible. They saw the potential for blockchain technology to revolutionize industries, empower individuals, and reshape the digital landscape. However, to achieve this, a solution was needed that could seamlessly integrate the benefits of decentralization with the efficiency and performance demanded by real-world applications.

Offchain Labs, the company behind Arbitrum, was founded in 2018 by Ed Felten, Steven Goldfeder, and Harry Kalodner. Arbitrum was introduced as Offchain Labs’ core scalability solution on April 15, 2019. The project underwent several significant milestones:

• Testnet Launch and Mainnet Deployment: On February 11, 2020, the Arbitrum rollup went live on testnet. The Arbitrum testnet on Ethereum’s Kovan test network was opened to all participants on October 14, 2020. Arbitrum achieved mainnet status on May 28, 2021, opening it up to developers.

• Arbitrum One Public Launch and Upgrade: Arbitrum One was publicly launched on August 31, 2021, enabling users and protocols to interact with the rollup. On August 31, 2022, Arbitrum One underwent a major upgrade to the Nitro stack, resulting in increased throughput and reduced gas fees.

• Introduction of Arbitrum Nova: Arbitrum Nova, the second roll-up blockchain, was publicly launched on August 9, 2022. Utilizing the AnyTrust protocol, Arbitrum Nova was designed to optimize gaming and social applications. Notably, platforms like Reddit adopted Arbitrum Nova for their community points system.

• Development of Stylus Programming Language: On February 7, 2023, Arbitrum announced the development of Stylus, an upgraded programming language for Arbitrum. Stylus aims to enable non-EVM-compatible programming languages, like Rust, to run on Arbitrum One and Arbitrum Nova.
• Creation of Arbitrum Foundation and DAO: On March 16, 2023, Arbitrum announced the formation of the Arbitrum Foundation, Arbitrum DAO, and the $ARB token. This phase aimed to further decentralize the Arbitrum suite by transitioning control from Offchain Labs to the Arbitrum DAO. The Arbitrum Security Council, consisting of 12 individuals with selective emergency powers, was established to oversee the suite’s security. These features were publicly launched on March 23, 2023, allowing eligible users to claim the $ARB airdrop.

Why Scaling Smart Contracts is Difficult

The Verifier’s Dilemma

When attempting to make smart contracts work efficiently, a common approach is to make all miners or validators within a cryptocurrency network simulate every step of the smart contract’s actions. This might seem simple, but it creates a big problem for scalability.

This problem is called the Verifier’s Dilemma. Checking transactions that involve running code inside a smart contract can be really expensive. So, the parties responsible for checking these transactions are stuck in a tricky situation. They might want to skip the thorough checks. This can lead to a situation where transactions are accepted without being carefully reviewed. This happens either because they think someone else will do the checks, or because they believe any mistakes won’t be caught due to the lack of thorough checks.

On the other hand, if all miners or validators do their checks diligently, a sneaky miner can take advantage of this. They can include a really complex computation that takes a long time to check. While others are busy verifying, this sneaky miner or validator can get ahead in mining the next block, which gives them a much better chance of getting the block reward. This whole issue happens because checking smart contract actions is very expensive.

In simple terms, this problem shows that there’s a tricky balance between how much it costs to do checks and what miners or validators want. The high cost of checking transactions can lead to situations where transactions are accepted without good checks, and it can even create opportunities for miners or validators to act smartly to get more rewards.

The Participation Dilemma

When trying to scale smart contract verification, one method involves participation games, encouraging a set number of parties to verify each contract’s execution. This faces the Participation Dilemma, which deals with preventing Sybil attacks. In a Sybil attack, a single party pretends to be multiple parties, potentially driving out real participants. It’s like someone faking multiple votes in a contest. The challenge is finding the right participation balance to prevent manipulation while ensuring genuine involvement.

The objective is to design a reward function (denoted as f(·)) that creates a scenario where no player has an incentive to Sybil (pretend to be multiple parties), and a desired number of players participate. In a blockchain context, the goal is to ensure that the apparent number of verifiers matches the actual number of distinct players who verified the computation.

However, the promise of participation games is complicated by the nature of smart contract verification being a repeated game. Repeated games introduce dynamics where players make decisions over multiple rounds, enabling strategies that may not project onto the Nash equilibrium of their one-shot counterparts.

Consider the analogy of the prisoner’s dilemma, wherein a single round, both players might defect. But in a repeated prisoner’s dilemma, revenge strategies come into play.

Repeated games enable players to sacrifice present gains for future benefits. This dynamic can lead to unique equilibria that diverge from the equilibria of one-shot games. Players may adopt strategies that evolve over rounds based on prior outcomes, introducing intricate decision-making patterns.

Why Nitro

Nitro is the culmination of the evolution of Arbitrum technology, building upon the initial release on the mainnet known as “Arbitrum Classic.” 

A defining feature of Nitro is its integration of WebAssembly (Wasm) and the Geth Ethereum implementation. In Arbitrum Classic, a custom virtual machine, the Arbitrum Virtual Machine (AVM), was used to emulate EVM execution. In Nitro, the Go code used for Arbitrum’s L2 state transitions is compiled into Wasm, and the Geth Ethereum implementation is incorporated as a sub-module. This architecture enables Nitro to natively execute Geth’s EVM implementation.

• Lower fees and Optimistic execution:  Unlike Arbitrum Classic, which compiled high-level code down to AVM bytecode for both execution and fraud proofs, Nitro compiles code into Wasm only when a dispute occurs. This design, known as “optimistic^2 execution,” allows Nitro to execute Go code natively in the common case, resulting in lower fees for users.

• Calldata Compression: Nitro’s integration of established compression libraries for calldata compression significantly reduces the cost of posting transaction batches on Ethereum. By leveraging Go’s flexibility, Nitro simplifies calldata compression and introduces mechanisms to ensure proper compensation for batch posters.

• Closer EVM Compatibility: Nitro’s integration of Geth offers closer compatibility with Ethereum’s L1 gas. In Arbitrum Classic, the AVM’s gas denomination (ArbGas) diverged from Ethereum L1 gas, requiring adjustments to contracts and client-side tooling. With Nitro, L1 and L2 gas units correspond 1:1, simplifying deployment and interaction.

• Simplicity: Nitro’s integration of Geth reduces complexity by inheriting a mature codebase for L2 execution. Unlike the classic stack, which required custom logic (ArbOS) implemented in a custom language (mini), Nitro’s use of Geth enables simpler, more accessible code. Leaner codebase, directly benefiting from Ethereum-Geth engineering, fosters greater security and ease of auditing.

Sector Outlook

Ethereum Layer 2 solutions like Arbitrum aim to address the scalability and high transaction fees of the Ethereum mainnet by offloading some of the computational load and transaction processing to secondary chains or networks. These solutions provide faster and more cost-effective transactions while maintaining the security and decentralization of the Ethereum network.

More specifically, Arbitbrum is an Optimistic Rollup. Optimistic Rollups are a specific type of Layer 2 scaling solution that aims to improve Ethereum’s scalability by batching transactions off-chain and then submitting compressed proofs of these transactions to the Ethereum mainnet. This approach benefits from the security guarantees of the Ethereum mainnet while significantly increasing transaction throughput and reducing gas fees. 

• Increasing Adoption: Optimistic Rollups have gained significant attention and adoption in the Ethereum ecosystem. Many projects and dApps are exploring the use of Optimistic Rollups to enhance the user experience and reduce costs.
• Projects and Platforms: Several projects are actively working on implementing Optimistic Rollup technology. Some of the prominent platforms include Arbitrum (developed by Offchain Labs), Optimism (formerly known as Plasma Group), and other L2 solutions that are built on the OP stack, such as Mantle, Base…
• Ecosystem Growth: Optimistic Rollups provide a seamless transition for Ethereum developers since they are compatible with the existing Ethereum Virtual Machine (EVM). This compatibility has led to a growing ecosystem of decentralized applications (dApps), DeFi protocols, and NFT marketplaces migrating or planning to deploy on Optimistic Rollups.
• Interoperability: Projects are exploring ways to enable interoperability between different Layer 2 solutions, allowing users and applications to move assets and data more freely between different chains while still benefiting from scalability and low fees.
• Challenges: While Optimistic Rollups offer numerous advantages, they are not without challenges. One of the main concerns is the “optimistic” nature of the solution, where fraud proofs are required to be submitted if malicious behavior is detected. Ensuring the security and efficiency of fraud proofs is essential.
• Competition and Diversification: Optimistic Rollups are one of several Layer 2 solutions, including zk-Rollups, Validium, and more. Competition among different solutions can lead to innovation and diversification within the Ethereum scaling ecosystem.

Why Use Arbitrum and Nitro

Arbitrum, along with its enhanced version Nitro, offers a compelling set of advantages that make it a promising solution for Ethereum scalability and efficiency:

• Trustless Security: Arbitrum ensures trustless security by anchoring its operations in Ethereum’s security model. Any party can verify the correctness of Layer 2 results, preventing any single entity from manipulating the system. This level of security provides users with confidence in the integrity of their transactions and smart contracts.
• Ethereum Compatibility: Arbitrum is designed to be fully compatible with Ethereum’s EVM (Ethereum Virtual Machine), allowing existing smart contracts and transactions to run without modification. This compatibility enables developers to leverage their existing codebase and infrastructure while benefiting from the improved scalability of Arbitrum.
• Scalability: One of Arbitrum’s main advantages is its scalability. By moving the computation and storage of smart contracts off the Ethereum main chain and onto Layer 2, Arbitrum significantly increases the throughput of transactions. This scalability is crucial for addressing the network congestion and high gas fees often experienced on the Ethereum main chain.
• Cost Efficiency: Arbitrum is engineered to minimize the gas footprint on the Ethereum main chain. This minimization of L1 gas usage leads to lower transaction costs for users. Nitro takes this efficiency a step further with advanced calldata compression, reducing the amount of data that needs to be posted to L1, thereby driving down transaction costs even more.
• Advanced Features in Nitro: Nitro builds upon the foundation of classic Arbitrum and introduces several enhancements that further improve the user experience and system performance:
  • Separate Contexts: Nitro introduces separate contexts for common execution and fault proving, enhancing the efficiency of L1 nodes and resulting in lower fees for users.
  • Ethereum L1 Gas Compatibility: Nitro aligns its pricing and accounting for EVM operations perfectly with Ethereum’s L1 gas model, ensuring consistency and familiarity for users.
  • L1 Interoperability: Nitro enhances interoperability with Ethereum’s L1 by synchronizing with L1 block numbers and fully supporting all Ethereum L1 precompiles, making it easier to interact between the two layers.
  • Safe Retryables: Nitro addresses a previous failure mode by ensuring that retryable transactions are created and executed safely, reducing the risk of transaction failures.
  • Geth Tracing: The addition of Geth Tracing improves debugging support for developers, making it easier to troubleshoot and optimize smart contracts.

Key Design Innovations

• Sequencing, Followed by Deterministic Execution: Nitro employs a two-phase processing strategy for transactions.
  • Firstly, transactions are ordered into a single, definitive sequence, and Nitro commits to this sequence. 
  • Then, these transactions are executed in the order they were sequenced, utilizing a deterministic state transition function. 
• Geth at the Core: Nitro leverages the core code of the widely used go-ethereum (“Geth”) Ethereum node software. By integrating Geth as a library, Nitro supports Ethereum’s data structures, formats, and virtual machines. This integration ensures a high degree of compatibility with the Ethereum ecosystem, allowing developers to work with familiar tools and environments.
• Separate Execution from Proving: Nitro compiles the same source code twice, enabling two distinct functionalities. 
  • The first compilation generates native code optimized for execution within a Nitro node. This code prioritizes speed for efficient transaction processing. 
  • The second compilation generates WebAssembly (WASM) code optimized for portability and security. This code is used for proving transactions, and facilitating the verification process while maintaining a balance between performance and safety.
• Optimistic Rollup with Interactive Fraud Proofs: Nitro settles transactions onto Ethereum’s Layer 1 chain using an optimistic rollup protocol. This approach involves committing to the validity of transactions on the Layer 2 chain while providing the ability to challenge and prove fraudulent behavior using interactive fraud proofs. This mechanism ensures that erroneous transactions can be identified and rectified, maintaining the security and trustworthiness of the system.

Using the Protocol

Bridge Funds Using the Arbitrum Bridge

Bridging funds requires users to have a Web3 wallet installed (e.g. Metamask). There are 3 steps involved in Depositing.

Deposit $ETH or ERC-20 Tokens (From Parent Chain to Child Chain)

Step 1: Get Some Native Currency

You’ll need the native currency of the parent chain to be able to bridge your assets from it to the destination chain. For example, if you want to bridge assets from Ethereum to Arbitrum One, you’ll need ETH on Ethereum to initiate the process.

There are several ways to obtain the native currency:

• Using a supported centralized exchange, which allows you to purchase ETH and withdraw it to your wallet.
• Using an on-ramp service, which allows you to purchase ETH and send it directly to your wallet.
• If you are using a testnet, requesting funds from a faucet for Sepolia, Goerli, or Arbitrum Sepolia.

Step 2: Add the Preferred Network to Your Wallet

You’ll also need to add the desired chain’s RPC endpoint to your wallet. Here we provide an example for doing this using MetaMask, although the process should be similar for other wallets. 

You need to first click on the MetaMask extension on your browser, click the network selector dropdown on the top-left corner, and then click the Add Network button at the bottom. Click “Add a network manually” and then provide the information corresponding to the chain you want to send your assets to.

You can find a list of common Arbitrum chains in this list.

Step 3: Initiate the Deposit

To bridge your ETH or ERC-20 tokens to a different chain, start by visiting bridge.arbitrum.io. Log in to the bridge with your wallet and make sure you are connected to the source network (from where you want to deposit your assets) at the top of the page. Then, select the destination network (where you want your assets to go), e.g., Arbitrum One or Arbitrum Nova.

Note that testnets like Arbitrum Sepolia or Arbitrum Goerli only appear if you are connected to the appropriate parent testnet network (Ethereum Sepolia or Ethereum Goerli).

Select the token you want to bridge in the token drop-down menu. You can also enable/disable the token lists by clicking the Manage token lists button on the bottom right corner of the drop-down menu.

Enter the amount of ETH or ERC-20 tokens you want to bridge over in the From box and then press Move funds. Follow the prompts on your web3 wallet.

After you submit the transaction through your web3 wallet you can expect your funds to arrive on the destination chain within roughly 15-30 minutes (depending on the chain congestion).

Also, make sure your wallet is set to the destination chain so you can see your funds when they arrive.

Withdraw ETH or ERC-20 Tokens (From Child Chain to Parent Chain)

To bridge your funds back to the parent chain, you’ll need to be logged in to the Arbitrum bridge with your wallet and make sure you are connected to the source network (from where you want to withdraw assets) at the top of the page. Then, select the destination network (where you want your assets to go), e.g., Ethereum mainnet.

Note that testnets like Ethereum Sepolia or Ethereum Goerli only appear if you are connected to the appropriate child testnet network (Arbitrum Sepolia or Arbitrum Goerli).

Select the token you want to bridge in the token drop-down menu. You can also enable/disable the token lists by clicking the Manage token lists button on the bottom right corner of the drop-down menu. Enter the amount of ETH or ERC-20 tokens you want to bridge over in the form box and then press Move funds. Follow the prompts on your web3 wallet.

A countdown will pop up stating that you’ll get your funds in 7-8 days.

You can check the status of your withdrawal by clicking on your profile on the top right, opening the Transactions tab, and claiming it there when it’s ready.

Once the countdown is done, switch to the destination network on your wallet and press the Claim button, which has now turned blue, to receive your funds.

Running an Arbitrum Full Node

• Transaction Validation and Security: Running a full node allows users to validate transactions and ensure the authenticity of the Arbitrum blockchain.
• Reduced Trust Requirements: Full nodes enable users to interact with the network without relying on third-party services, reducing centralized trust.
• Lower Resource Requirements: Full nodes require fewer resources compared to archive nodes, making them suitable for users with limited hardware capabilities.
• Detailed instructions: https://docs.arbitrum.io/node-running/how-tos/running-a-full-node 

Running an Arbitrum Archive Node

• Extensive Historical Data: Archive nodes store the complete history of the network, making them ideal for users needing access to historical data and advanced analytics.
• Resource Intensive: Archive nodes demand significant storage capacity and computational power due to the extensive data they store.
• Detailed instructions: https://docs.arbitrum.io/node-running/how-tos/running-an-archive-node 

Running an Arbitrum Classic Node

• Applicable for Specific Needs: Running a classic node is useful for individuals requiring archive nodes and access to classic-related commands.
• Detailed instructions 

Running a Feed Relay

• Benefits of Feed Relays: If you have multiple nodes, setting up a single feed relay per datacenter can enhance stability and reduce ingress fees.
• Compression Mandate: Future feed endpoints may require compression using a custom dictionary. Running a local feed relay ensures access to an uncompressed feed for optimal performance and compatibility.
• Detailed instructions 

Economics

• Unique depositors over time 
• Daily unique depositors 
• Arbitrum deposits from Ethereum 
• Daily accumulated users 
• Arbitrum One user txs 
• Weekly transactions count 
• Weekly active users 
• Weekly new users 
• Gas used daily 
• Historical transactions 
• Daily active users 
• Transaction success rate – Ethereum 
• Transaction success rate – Arbitrum 

Fee Breakdown

When a user submits a transaction in the Arbitrum ecosystem, there are two main parties involved that the user needs to pay:

• The Poster (L1 Component): This refers to the reimbursement for L1 (Layer 1) resources, specifically the L1 calldata needed to post the transaction. The cost associated with the L1 component of the transaction fee is determined by estimating the contribution of the transaction to the size of the batch it belongs to. This estimation is achieved using Brotli compression on the transaction itself. The L2 network’s view of the L1 data price, which adjusts dynamically over time, ensures that the batch poster is adequately compensated for the L1 resources used. 
• The Network Fee Account (L2 Component): The L2 (Layer 2) component of the transaction fee covers various resources that L2 nodes need to manage to process the transaction. This includes computation, storage, and other burdens associated with servicing the transaction on the Layer 2 network. Similar to how validators in a vanilla Layer 1 chain (like Ethereum) receive fees for their computational efforts, in Arbitrum, there are fees paid to validators for their contributions to the network. Additionally, ArbOS (the operating system of the Arbitrum Layer 2 chain) charges fees for executing its L2-specific precompiles. The fees for these precompiles are determined dynamically based on the resources used during the execution of the call.

Pricing L1 Costs

The L1 Pricing mechanism in Arbitrum is designed to ensure that the fees collected for L1 gas usage are adjusted dynamically over time to align with the actual costs that need to be covered by the network. This mechanism helps maintain fairness and efficiency in the pricing of L1 gas fees. 

L1 gas fees are charged only for transactions that are included in sequencer batches. A transaction is subject to L1 gas fees if it arrives as part of a sequencer batch, indicating that someone has already paid for L1 gas to post the transaction on the L1 chain.

The L1 gas fees collected from transactions are transferred to a specific account known as the L1PricerFundsPool account. The balance of this account represents the funds collected from L1 gas fees that are available to cover costs.

Estimated costs calculation

• The estimated cost of posting a transaction on L1 is determined by multiplying the transaction’s estimated size with the current L1 gas base fee. The result of this calculation is then divided by the current L2 gas basefee to obtain the amount of L2 gas that corresponds to the L1 operation.
• The estimated size of a transaction is measured in L1 gas units and is calculated by compressing the transaction’s data using the Brotli-Zero algorithm. The size of the compressed data is then multiplied by 16 (since L1 charges 16 gas per byte).

Breaking Down Transaction Fees

Transaction fees (TXFEES) = L2 Gas Price (P) * Gas Limit (G)

This Gas Limit includes the gas of the L2 computation and an additional buffer to cover the L1 gas to be paid by the Sequencer when posting the batch including this transaction on L1.

Gas Limit (G) = Gas used on L2 (L2G) + Extra Buffer for L1 cost (B)

This buffer takes into account the cost of posting the transaction, batched and compressed, on L1. The L1 estimated posting cost is calculated by multiplying these two values:

• L1S, which estimates the amount of data the transaction will take up in the batch by compressing the transaction with Brotli.
• L1P, which is the L2’s estimated view of the current L1’s price of data (per byte), which the L2 dynamically adjusts over time.

L1 Estimated Cost (L1C) = L1 price per byte of data (L1P) * Size of data in bytes (L1S)

To calculate the buffer, that estimated cost is divided by the L2 Gas Price.

Extra Buffer (B) = L1 Estimated Cost (L1C) / L2 Gas Price (P)

Finally, that results in the following: TXFEES = P * (L2G + ((L1P*L1S)/ P))

This information can be accessed at NodeInterface.

• P (L2 Gas Price): Price to pay for each gas unit. It starts at 0.1 gwei on Arbitrum One (0.01 gwei on Arbitrum Nova) and can increase depending on the demand for network resources.
• L2G (Gas used on L2): Gas is used to compute the transaction on L2. This does not include the “posting on L1” part of the calculations. The value of L2G will depend on the transaction itself. This can be calculated as follows:
  • Call NodeInterface.GasEstimateComponents() with the transaction data.
  • Subtract the second element (gasEstimateForL1, which estimates the L1 part of the fees) from the first (gasEstimate, which includes both the L1 and the L2 parts).
• L1P (L1 estimated price per byte of data): Estimated cost of posting 1 byte of data on L1. This can be calculated as follows:
  • Call NodeInterface.GasEstimateComponents().
  • Get the fourth element, l1BaseFeeEstimate.
  • Multiply it by 16.
• L1S (Size of data to be posted on L1, in bytes): This will depend on the data of the transaction. Keep in mind that Arbitrum adds a fixed amount to this number to make up for the static part of the transaction (140 bytes). You can calculate it as follows:
  • Call NodeInterface.GasEstimateComponents().
  • Take the first element, gasEstimateForL1 (equivalent to B in the formula).
  • Multiply it by P and divide it by L1P.

For Arbitrum Nova (AnyTrust), the size of the data is a fixed value, as only the Data Availability Certificate is posted on L1.

It’s important to note that these calculations involve interactions with the NodeInterface contract on the Arbitrum network and rely on the values returned from these contract calls. These formulas allow you to estimate the fees and costs associated with different aspects of using the Arbitrum network for transactions and data posting.

Operating Expenses

There are two types of L1 costs: batch posting costs and rewards.

• Batch posting costs represent the actual cost paid by a batch poster to post batch data on L1. When a batch is posted, the L1 contract reporting the batch sends a “batch posting report” message to L2 ArbOS. This message contains information about who paid for the batch and the L1 basefee at the time.
• Rewards are optional and can be configured per chain. They involve a reward paid to entities that handle transaction calldata. The reward is a fixed amount per data unit and is paid to a specified address.

When processing a batch posting report at the L2, the pricer allocates collected funds to cover costs. The allocation considers timestamps such as currentTime, updateTime (time of batch submission), and lastUpdateTime (time of previous batch submission).

The pricer computes an allocation fraction F and allocates a portion of the funds in the L1PricerFundsPool to the current report. The allocation accounts for the time interval between lastUpdateTime and currentTime.

The pricer then pays out allocated funds to cover rewards and amounts due to batch posters. If the allocated funds are insufficient to cover all dues, some dues will remain.

After allocating funds and making payments, the L1 Pricer adjusts the L1 Gas Basefee to ensure collected amounts match dues over time.

The algorithm computes a surplus (funds in L1PricerFundsPool minus total funds due) and adjusts the Basefee based on this surplus.

A second term is added to the L1 Gas Basefee, taking into account the derivative of the surplus to further stabilize the adjustments.

Tokenomics – The $ARB Token

The $ARB token is an ERC-20 governance token that grants its holders the authority to participate in voting on on-chain proposals that impact the direction and development of the Arbitrum DAO and its associated technologies. By holding $ARB tokens, you have the opportunity to democratically shape the future of the Arbitrum ecosystem in collaboration with other token holders who share aligned values and incentives.

• The $ARB token is an ERC-20 token that operates on the Ethereum blockchain.
• It is used for governance participation within the Arbitrum DAO’s on-chain governance mechanism.
• The token is minted through a smart contract on Arbitrum One, which is a Layer 2 Arbitrum rollup chain.

When you participate in voting on an on-chain proposal, your $ARB tokens are used to indicate your support or opposition. The weight of your vote is token-weighted, meaning the more $ARB tokens you hold, the more influence your vote carries.

The smart contracts governing the Arbitrum DAO are structured so that a vote’s power is determined directly by the number of tokens held by the voter’s wallet. However, token holders can delegate their voting power to other wallets. This implies that you can utilize your own $ARB tokens for voting, or you can use someone else’s tokens if they have delegated their voting authority to you.

Token Distribution

$ARB has a total supply of 10B. 

The token was distributed according to the table below:

Percentage of initial supply	Number of tokens	Allocated to
42.78%	4.278 billion	Arbitrum DAO treasury
26.94%	2.694 billion	Offchain Labs Team and Future Team + Advisors
17.53%	1.753 billion	Offchain Labs investors
11.62%	1.162 Billion	Users of the Arbitrum platform (via airdrop to user wallet addresses)
1.13%	113 million	DAOs building apps on Arbitrum (via airdrop to DAO treasury addresses)

Token Airdrop

The ArbERC-20 $ARB token is used to incentivize and reward various participants within the network. 

• User Airdrop: Approximately 1.162B ArbERC-20 $ARB tokens, constituting around 11.62% of the total token supply, were airdropped to wallet addresses on Arbitrum One on March 23, 2023. The number of tokens airdropped to an individual wallet was determined based on the actions taken by the wallet before February 6, 2023. Eligibility requirements for the airdrop were specified, and participants could refer to the detailed criteria for more information.
• DAO Airdrop: Around 113M ArbERC-20 ARB tokens, equivalent to 1.13% of the total token supply, were airdropped to various DAOs (Decentralized Autonomous Organizations) and protocols within the Arbitrum ecosystem. These airdrops aimed to provide incentives and rewards to projects and initiatives that contribute to the growth and development of the ecosystem. The allocation of tokens to specific DAOs and protocols was outlined and can be accessed for reference.
• Arbitrum DAO Treasury: Approximately 4.278 B ArbERC-20 $ARB tokens, accounting for roughly 42.78% of the total token supply, were allocated to the Arbitrum DAO Treasury. The Arbitrum DAO holds the authority to utilize and allocate these tokens in accordance with the governance mechanisms defined by the DAO. As of March 24, 2023, there were no active reward or grant programs funded by the tokens within the Arbitrum DAO treasury.

Regarding the ArbERC-20 ARB tokens on Ethereum and the ERC-20 Equivalent ARB tokens on Arbitrum Nova, there were no intended features identified for these tokens. 

It’s important to note that the features of these $ARB token contracts can be adjusted and modified as deemed appropriate through the Arbitrum DAO governance process. This flexibility allows the ecosystem to adapt and evolve based on changing needs and requirements.

Governance

The following parties play a critical role in Arbitrum Governance.

• $ARB tokenholders, who comprise the ArbitrumDAO, are crucial for decentralized governance within the Arbitrum ecosystem. They have the authority to propose, vote on, and execute on-chain AIPs related to the ArbitrumDAO-approved chains.
• Special grants can be issued by the Arbitrum Foundation from the Administrative Budget Wallet without undergoing a full on-chain AIP (Arbitrum Improvement Proposal). This mechanism is designed to streamline the process of granting funds while avoiding overwhelming the governance system.
• Directors are responsible for ensuring that AIPs do not compromise fiduciary duties, violate foundation documents, or breach any legal obligations.
  • The Arbitrum Foundation, as a Cayman Islands foundation, is required to have at least one director responsible for management and contractual decisions.
  • The ArbitrumDAO has the power to remove or elect directors through a Non-Constitutional AIP.
• The Security Council is a committee of 12 members with the ability to perform both Emergency and Non-Emergency Actions.
• The Data Availability Committee consists of authorized representatives from various entities. These members can be appointed or removed via a Constitutional AIP approved by the ArbitrumDAO. In case of removal or resignation of a Data Availability Committee member, the Security Council can execute an emergency action to appoint a replacement.

The Arbitrum DAO

The Constitution of the Arbitrum DAO

The original Constitution of the ArbitrumDAO took effect on the date upon which AIP-1 was posted, located here. 

The Amended Constitution of the Arbitrum DAO establishes the governance framework and procedures for decision-making within the ArbitrumDAO ecosystem. It outlines the rules, procedures, and guidelines for proposing, voting on, and implementing Arbitrum Improvement Proposals (AIPs), as well as the roles and responsibilities of various entities within the ecosystem. 

 Here’s a breakdown of the key sections and concepts outlined in the document:

Section 1 – Chain “Ownership”:

• Describes the decision-making framework for ArbitrumDAO governance and the authorization of ArbitrumDAO-approved chains.
• Authorizes the creation of additional Layer-2 chains using Arbitrum technology, subject to a corresponding AIP.
• Introduces the concept of “chain owners,” who have administrative power over chain protocol, code, and parameters.
• Explains that chain ownership has been given to both the ArbitrumDAO and the Security Council of The Arbitrum Foundation for Arbitrum One and Arbitrum Nova chains.

Section 2 – DAO Proposals and Voting Procedures:

• Describes the process of proposing, voting on, and implementing AIPs.
• Outlines different phases of the AIP process, including Temperature Check, Formal AIP, DAO votes on AIP, L2 Waiting Period, Initiation and Finalization of L2-to-L1 Message, L1 Waiting Period, and Implementation.
• Distinguishes between Constitutional and Non-Constitutional AIPs, specifying the content and requirements for each.
• Explains the role of Votable Tokens and voting thresholds for AIP approval.
• Recommends including specific sections in AIPs, such as Abstract, Motivation, Rationale, Specifications, and more.

Section 3 – The Security Council:

• Introduces the Security Council, a committee of 12 members responsible for certain emergency and non-emergency actions.
• Outlines the powers of the Security Council, including the ability to perform Emergency Actions and Non-Emergency Actions.
• Specifies the composition and election process for the Security Council, including September and March Cohorts.
• Details the process for Security Council elections, candidate eligibility, voting, and more.

Section 4 – Security Council Elections:

• Provides details about the composition, terms, and elections of the Security Council.
• Explains the timeline for candidate declarations, voting, and election results.
• Highlights guidelines to prevent overrepresentation and conflicts of interest among Security Council members.
• Discusses the potential for Security Council removal and unfilled seats.

Section 5 – Data Availability Committee:

• Explains the role of the Data Availability Committee (DAC) for Arbitrum Nova.
• Describes how transaction data batches are stored and posted by DAC members.
• Specifies the process for appointing and removing DAC members through Constitutional AIPs.
• Notes the possibility of Security Council intervention in DAC matters.

Section 6 – Community Values:

• Outlines the guiding values of the ArbitrumDAO and The Arbitrum Foundation.
• Emphasizes alignment with the Ethereum ecosystem, sustainability, security, inclusivity, user focus, technical accessibility, neutrality, and openness.

Arbitrum DAO Votes

The Arbitrum DAO’s governance structure is designed to empower $ARB token holders to actively participate in shaping the direction of the ecosystem. 

There are two types of votes:

• Temperature Check: This initial vote serves as a gauge of community interest in a proposal before it advances further. Temperature checks occur on the Snapshot platform and are accessible to $ARB token holders who possess or represent at least 0.01% of votable tokens.
• On-chain Vote: If a proposal successfully passes the temperature check, it proceeds to an on-chain vote managed by Tally. Token holders with a minimum of 5,000,000 votable tokens can initiate a “call for votes.” To be approved, more than 50% of the votable tokens that participated in the vote must be in favor of the proposal.
  • For constitutional proposals, votes must be received from at least 5% of all votable tokens in existence
  • For non-constitutional proposals, at least 3% of all votable tokens in existence must vote. 

The voting power you wield corresponds to the number of $ARB tokens you possess. Additionally, delegation is an option that lets you transfer your voting power to a delegate who votes on your behalf. This is beneficial for token holders who cannot actively engage in governance discussions. 

Arbitrum’s Approach to Progressive Decentralization

Arbitrum’s approach to progressive decentralization involves gradually increasing the decentralization of its ecosystem over time. This decentralization process includes various aspects, such as chain ownership, validator ownership, sequencer ownership, and ownership of the Data Availability Committee (DAC), which applies specifically to Arbitrum AnyTrust chains like Arbitrum Nova.

Chain Ownership

Chain ownership refers to the ability to make changes to the protocol, upgrade core smart contracts, set system parameters, and pause the system.

• Current Status: Chain ownership for both Arbitrum One and Arbitrum Nova is under the control of the Arbitrum DAO. The DAO is composed of $ARB token holders and delegates. The governance system can carry out chain-owner operations through governance votes. Additionally, there is a Security Council that can act quickly through a multi-sig wallet in emergency situations, and slowly for routine upgrades.
• Risks: Compromised or malicious Security Council members or a successful malicious proposal through DAO governance could compromise the system and user funds.
• Changes to Current Status: The governance system can modify governance processes itself.

Validator Ownership

Validators confirm the valid state of Arbitrum chains back on L1.

• Current Status: Permissioned validation is in place for both Arbitrum One and Arbitrum Nova. Validators are allow-listed to a committee of public entities. Governance can change this allow-list.
• Risks: If malicious validators propose an invalid state update and there is no honest validator, the system’s safety could be compromised.
• Changes to Current Status: The governance system can modify the validator allow-list.

List of allowlisted validators

Sequencer Ownership

The Sequencer collects and orders users’ transactions.

• Current Status: Sequencers for both Arbitrum One and Arbitrum Nova are maintained by the Arbitrum Foundation. Governance can select new sequencers.
• Risks: Sequencers have the power to delay transactions and reorder them within short time frames, but they cannot compromise the system’s safety.
• Changes to Current Status: The governance system can elect new sequencers.

Data Availability Committee (DAC) Ownership

This applies only to Arbitrum AnyTrust chains like Arbitrum Nova.

• Current Status: Arbitrum Nova relies on a 7-member DAC to store and provide data. Members can be added or removed by governance.
• Risks: Collusion of malicious DAC members with the sequencer could compromise the system’s safety.
• Changes to Current Status: The governance system can modify the DAC, including membership and power.

Creating New Arbitrum Chains

Multiple chains are essential to address scalability challenges by segregating activities into separate environments with independent resource management. This way, different chains can experiment with diverse security models and execution environments to achieve various trade-offs.

• For Layer 2 (L2) chains, the Arbitrum DAO is responsible for authorizing the creation of new chains through the constitutional governance proposal mechanism.
• If a proposal for a “new L2 chain” is approved by the DAO, a new L2 chain is established.
• The DAO can authorize L2 chains governed by the Arbitrum DAO or those governed by other means.
• In contrast, the creation of new Layer 3 (L3) chains doesn’t require authorization or approval.
• L3 chains (and higher layers) can be deployed permissionlessly on top of existing Arbitrum L2 chains.
• This includes L3 chains with unique governance structures, customized forks of the Arbitrum Nitro codebase, and more.

How to Submit a DAO Proposal

This section will guide you along the steps of submitting a DAO proposal, involving the following:

• Prerequisites
• Proposal types
• Proposal Structure
• Pre-proposal development
• Conduct temperature check & submit proposal

Prerequisites

To submit a temperature check using a Snapshot poll, you must have an Ethereum wallet address that represents at least 0.01% of votable tokens; to submit a proposal on-chain using Tally, you must have an Ethereum wallet address that represents at least 1,000,000 tokens (about 0.1% of votable tokens).

If you don’t have enough voting power, consider delegating your votes to a delegate who can create a proposal on your behalf.

Proposal Types

There are two types of AIPs: Constitutional and non-Constitutional:

• Constitutional AIPs are those that modify the text or procedures of the Constitution or AIP-1, install or modify software on any chain, or take any action that requires “chain owner” permission on any chain.
• Non-constitutional AIPs are all other AIPs, such as those that request funds/grants or provide general guidelines or information to the community.

Proposal Structure

The Constitution of the Arbitrum DAO encourages proposers to include the following sections within Arbitrum Improvement Proposals:

• Abstract – Two or three sentences that summarize the AIP.
• Motivation – A statement on why the Arbitrum community should implement the AIP.
• Rationale – An explanation of how the AIP aligns with the Arbitrum community’s mission and guiding values.
• Key Terms – Definitions of any terms within the proposal that are unique to the proposal, new to the Arbitrum community, and/or industry-specific. This section is optional, but recommended.
• Specifications – A detailed breakdown of the platforms and technologies that will be used. This is where you can elaborate on the “why” of your design decisions. You can also use this section to describe alternate designs that were considered and related work, e.g. how similar specifications have been successfully (or unsuccessfully) implemented in other chains or languages.
• Steps to Implement – The steps to implement the AIP, including associated costs, manpower, and other resources for each step where applicable. AIPs that involve transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included.
• Timeline – Relevant timing details, including but not limited to start date, milestones, and completion dates.
• Overall Cost – The total cost to implement the AIP. The overall cost section should include a breakdown of the total cost of the AIP, including any associated costs for each step where applicable. Consider both fixed costs and recurring costs.

Sometimes, AIPs aren’t passed on the first try. If an AIP is not passed, the proposer may resubmit the AIP after addressing the concerns of the community. The proposer should include the following additional sections in the resubmitted AIP:

• A link to the previous AIP – The link to the previous AIP should be included in the resubmitted AIP.
• Reasons why the AIP was not passed – The reasons why the AIP was not passed should be included in the resubmitted AIP.
• Changes made to the AIP – The changes made to the AIP should be included to address the concerns raised during the previous AIP submission.
• Additional information – More detailed intentions, specifics, and implication details can help the community understand the revised AIP, increasing the chances of it being passed.

Pre-Proposal Development

Proposals that require code changes should include the code that will be executed when the proposal is passed. This code should handle the data structures, logic, executable data, and execution of the proposal.

Step 1: Conduct a Formal Temperature Check With a Snapshot Poll

The DAO governance forum facilitates discussions about Arbitrum DAO and governance proposals that are submitted by eligible token delegates. To submit your proposal:

Go to the DAO governance forum.

• Create a new post with your proposal using the template located here. You can add additional fields to this template to provide more context for your proposal if you’d like.
• Whenever you’re ready, navigate to Snapshot to create a poll that will gauge the community’s interest in your proposal.
  • Connect your wallet.
  • Open the Arbitrum DAO Snapshot space if it isn’t already open.
  • Create a poll that points to your forum post. The poll should run for one week and should be decided by a simple majority.
  • Navigate back to your forum post and share the link to your Snapshot poll with the community.
• Allow at least one week for discussion and debate. Iterate on your proposal based on feedback from the community.
  

If your proposal doesn’t pass the temperature check, you shouldn’t submit it for an on-chain vote. Instead, head back to your forum post and engage with the community to address any concerns that they have.

If your proposal passes the temperature check, then you can move to the second and final step: an on-chain vote facilitated by Tally. Ensure that you’ve incorporated feedback brought up during relevant forum discussions and temperature checks before proceeding.

Step 2: Submit Your On-Chain Proposal Using Tally

If your wallet can represent at least 1,000,000 tokens (about 0.1% of votable $ARB tokens), you can create an on-chain proposal using Tally.

To submit your proposal on Tally:

• Log in to Tally using the wallet that represents the $ARB tokens.
• Navigate to the “explore DAOs” section or click on “My DAOs” within your Tally profile and select Arbitrum DAO’s page.
• Select “Create new proposal”
• Choose which governor you are targeting:
  • Arbitrum Core: For Constitutional Proposals
  • Arbitrum Treasury: For non-constitutional Proposals
• Give the proposal a name and description (preview image is optional). Ensure that you’re submitting the correct type of proposal to the right DAO page in Tally.
• Add proposal actions to be executed if passed. For example, “transfer  ETH to 0x address”.
• Preview your proposal and either save it as a draft or submit it on-chain.

A proposal passes if two conditions are met:

• More votes are cast in favor than against
• The total number of votes cast in favor is at least the following percentage of the votable tokens:
  • 5%, for a Constitutional AIP
  • 3%, for a non-Constitutional AIP
    

If the proposal passes, congratulations! After a delay, the proposal’s actions will be executed on-chain.

If the proposal doesn’t pass, but there’s interest in improving and resubmitting it, you can resubmit a proposal.

How to Delegate Voting Power

Delegating your voting power is an essential part of participating in the Arbitrum DAO. As a token holder, you have the ability to vote on governance proposals and to elect members of the Security Council.

If you don’t have the time or resources to actively participate in the DAO’s governance, you can still make your voice heard by delegating your voting power to a delegate. This how-to will walk you through the process of evaluating and selecting a delegate.

Before you delegate your voting power, it’s important to understand that by delegating your voting power, you’re entrusting someone else to vote on your behalf. So it’s really important to choose a delegate who aligns with your values and who you trust to make decisions in the best interest of the Arbitrum DAO and its community.

To delegate your voting power, you’ll need an Ethereum wallet that holds $ARB tokens, such as MetaMask. Once you have your wallet set up, you can follow these steps:

• Go to the Arbitrum DAO page on Tally, the decentralized governance tool that the Arbitrum DAO uses.
• Connect your wallet to Tally by clicking on “Connect Wallet” and selecting the address that holds your $ARB tokens.
• Click on the “Delegate” tab on the top menu.
• Search for the delegate you want to vote for by typing their Ethereum address or their name in the search bar.
• Click on the “Delegate” button next to the delegate you’ve chosen.
• Confirm the delegation by clicking on the “Delegate” button on the pop-up window that appears.
• Wait for the transaction to be confirmed on the Arbitrum One network.
• Once your transaction is confirmed, your voting power will be transferred to the delegate you’ve chosen. You can also check your delegation by going to the “Votes” tab on Tally and looking for the delegate you’ve chosen.

When selecting a delegate, it’s important to consider the following:

• The delegate’s values, as outlined in the Constitution, and their position on the proposals.
• The delegate’s track record, if they have one.
• The delegate’s level of engagement with the community and their willingness to listen and respond to feedback.
• The delegate’s level of technical expertise and their experience in the space.

By following these steps and considering these factors, you can ensure that you’re delegating your voting power to a trustworthy and competent delegate who will work to further the goals of the Arbitrum DAO and its community.

How to Become a Delegate

To become a delegate, create a profile on Tally and begin building your delegate platform. To make it easy for voters to learn more about you, submit a delegate statement using the template on the Arbitrum DAO governance forum.

Best Practices

Before deciding to become a delegate, it’s important to understand the responsibilities and expectations of the role. Review the following guidelines to ensure that you’re prepared to become a delegate for the Arbitrum DAO:

• Delegates are expected to actively participate in the decision-making process and to act in the best interests of the network. They should also be familiar with The Constitution of the Arbitrum DAO and each of the documents within this content set.
• Review The Constitution of the Arbitrum DAO and each of the documents within this content set to ensure that you understand the scope of delegate responsibilities and the mechanisms by which the Arbitrum DAO operates.
• Review the comprehension check to self-assess your understanding of the Arbitrum DAO governance protocol.
• Prepare to build a strong delegate platform. This includes establishing an online presence that outlines your qualifications, experience, and vision for the Arbitrum DAO. You can use your platform to demonstrate your understanding of the protocol and the highest-priority challenges that the community is facing.
• Submit a delegate statement using the template posted in the delegate application template thread. Although delegate applications aren’t required now that the airdrop has occurred, the application template gives community members a standardized way to learn more about your qualifications and platform.
  

Becoming a delegate is a significant responsibility and should not be taken lightly. Delegates should have a solid foundational technical understanding of the Arbitrum protocol, a sense of the Ethereum ecosystem at large, and a desire to continuously engage with the Arbitrum community as it grows and evolves.

How to Build a Strong Delegate Platform

As a delegate of the Arbitrum DAO, you play a vital role in the governance and decision-making process used to govern both the DAO’s protocol and its technologies. Your role is to represent the interests of token holders who have delegated their voting power to you and to make informed decisions on their behalf. Whether you’re a first-time delegate or a seasoned pro, building a strong delegate platform that’s aligned with the interests and values of Ethereum at large is of critical importance. 

The following tips will help you build a strong, incentives-aligned delegate platform:

Tip 1: Understand the Constitution

The first step in building a strong delegate platform is to develop a thorough understanding of The Constitution of the Arbitrum DAO. The Constitution outlines the governance structure of the DAO, including the roles and responsibilities of delegates, as well as the decision-making process. Review the comprehension check to test your knowledge of the Constitution.

Tip 2: Communicate with Token Holders

As a delegate, it’s important to maintain an open and transparent line of communication with the token holders you represent. This can include creating a website or social media presence where you can provide updates on your activities, answer questions, and solicit feedback. Ensure that your voters are informed of any important developments or changes related to the DAO by staying tuned in to the Arbitrum DAO governance forum and Discord. Continuously relaying important information to the token holders that you represent can help you build trust and credibility while positioning yourself as a valuable representative of the Arbitrum DAO community.

Tip 3: Stay Active in the Community

Another key aspect of building a strong delegate platform is staying active in the community. This can include participating in discussions on the Arbitrum DAO governance forum, attending community events, participating in online discussions wherever relevant conversations are happening on social media, and contributing to the development of the DAO.

Tip 4: Be Transparent and Accountable

Transparency and accountability are crucial for building a strong delegate platform. As a delegate, you have a responsibility to be transparent about your motivations and decisions, and to be accountable to the token holders you represent. This can include being open to feedback and criticism and being willing to answer questions and address concerns.

Tip 5: Build a Strong Support System

Building a strong support system is essential for success as a delegate. This can include building relationships with key members of the community and developing a team to assist you with research, analysis, and decision-making. A strong support system can help you stay informed, make better decisions, and build a more effective delegate platform.

How to Vote on Arbitrum DAO Governance Proposals

As a member of the Arbitrum DAO, it’s important to be an active participant in the DAO’s decision-making process by voting on governance proposals that other DAO members submit. The voting process can vary depending on the given proposal’s stage; in this how-to, you’ll learn how to locate, evaluate, and vote on proposals at each of the possible stages.

Proposals in the “Temperature Check” Stage

Proposals are first submitted to the Arbitrum DAO governance forum for community discussion and debate. These forum submissions are usually accompanied by a Snapshot poll that gauges the community’s interest in the proposal. As an $ARB token holder (or delegate) you can participate in these Snapshot polls and “temperature check” discussions:

• Go to the DAO governance forum.
• Locate the proposal you’d like to vote on and read through the proposal and the discussion thread.
• Provide feedback and participate in the discussion to help shape the proposal.

The forum submission for any given proposal will usually include a link to a Snapshot poll that allows you to vote on the proposal:

• Navigate to Snapshot.
• Connect your wallet.
• Open the Arbitrum DAO Snapshot space and locate the proposal you’d like to vote on (or click the Snapshot link in the forum submission).
• Cast your vote by following the prompts within Snapshot’s UI.

Proposals in the “On-Chain Vote” Stage

If the proposal passes the temperature check, it will move on to an on-chain vote facilitated by Tally. To pass this stage, the proposal must meet two thresholds:

• The proposal must receive more votes in favor than against; and
• Constitutional AIPs must receive votes from at least 5% of votable tokens; non-constitutional AIPs must receive votes from at least 3% of votable tokens.

To vote on proposals in the “on-chain vote” stage:

• Log in to Tally using a wallet that has been delegated voting power. $ARB tokens must be delegated to the wallet address before the voting period begins to vote on the proposal.
• Navigate to the “explore DAOs” section or click on “My DAOs” within your Tally profile and select the page for either Constitutional or non-constitutional AIPs.
• Locate the proposal you’d like to vote on and cast your vote.

On Proposal Evaluation

It’s important to evaluate proposals based on their alignment with the values and goals of the Arbitrum DAO as outlined in the Constitution. Remember that the ultimate goal of the DAO is to create a decentralized and transparent platform that benefits all members, including those who aren’t yet members.

On Delegation

You can grant your voting power to a delegate if you don’t have the time to actively participate in the governance process. If you decide to delegate your voting power to someone else, be sure to select a delegate who demonstrates the values enshrined within the Constitution. If you’re looking for guidance on how to delegate, or how to select a delegate, refer to How to delegate your voting power.

Lifecycle and Anatomy of an Arbitrum Improvement Proposal

Overview

The proposal submission process has the following structure:

• Starts with a temperature check, where the AIP is suggested on the Arbitrum DAO governance forum along with a Snapshot poll. It’s discussed/debated for 1 week. 
• If the AIP passes the temperature check, it moves on to the next phase, which is the formal AIP, and calls for voting. In this phase, the AIP is submitted via governance contracts on Arbitrum One via Tally’s user interface. 
• After 3 days, a voter distribution snapshot is taken and the voting period begins.

Each AIP must be labeled as Constitutional or non-constitutional, and must also clearly specify which Arbitrum DAO-governed chain(s) it will affect. If the AIP passes, it moves through a series of phases that include L2 and L1 waiting periods, and eventually, the implementation of the proposal. This process typically takes 34 days for a Constitutional AIP or 21 days for a Non-Constitutional AIP but may take longer if specified by the AIP.

There are 7 phases involved in the process, which are:

• Phase 1: Temperature check
• Phase 2: Formal AIP and call for voting
• Phase 3: On-chain DAO vote
• Phase 4: L2 waiting period
• Phase 5: L2-to-L1 message
• Phase 6: L1 waiting period
• Option waiting period
• Phase 7: Implementation

Phase 1: Temperature check (Optional But Recommended)

This is the first phase of the Arbitrum Improvement Proposal (AIP) process:

• The proposed AIP is submitted following the procedure outlined within How to submit a DAO proposal.
• A discussion is initiated on the Arbitrum DAO governance forum.
• A Snapshot poll is created to help gauge the interest of Arbitrum DAO members – either at the same time as the forum post or after the forum post has facilitated initial discussion. This poll can be initiated only by an address that can represent at least 0.01% of the votable tokens.
• The poll runs for 7 days and is decided by a simple majority with no required participation threshold.

This is an optional step, but it’s recommended as a due diligence governance best practice. If an AIP fails this temperature check, the original AIP author is encouraged to refrain from proceeding, and voters are encouraged to reject it if the author proceeds. If an AIP proposer decides to skip this step, voters should consider this as a factor in their vote.

Phase 2: Formal AIP and Call for Voting

In this phase, the AIP is officially submitted via governance smart contracts on the Arbitrum One chain. The proposer of the AIP must have an address that can represent at least 1,000,000 votable tokens. After the AIP is submitted, there’s a 3-day period for interested parties to discuss the proposal and gather votes before a voter distribution snapshot is taken. During this phase, the AIP must be labeled as either Constitutional or Non-Constitutional. Additionally, the AIP must clearly specify which Arbitrum DAO-governed chain(s) it will affect. This phase is important as it defines a clear, formal protocol for proposing and voting on AIPs.

Phase 3: On-chain DAO Vote

During this phase, members of the Arbitrum DAO can vote directly on-chain for (or against) a submitted AIP. For the AIP to pass, more Votable Tokens must vote in favor than against, and a certain percentage of all Votable Tokens must vote in favor. This percentage is 5% for Constitutional AIPs and 3% for Non-Constitutional AIPs and is referred to as “Threshold 2” within the Constitution.

The voting period for an AIP ends 14 days after it starts. However, if Threshold 2 is reached within the last 2 days of the voting period, the voting period is extended by 2 days. If the AIP fails to pass, the process ends after Phase 3. If it does pass, Constitutional AIPs move on to Phases 4 through 7, while Non-Constitutional AIPs skip Phases 4 through 6 and go straight to Phase 7.

Phase 4: L2 Waiting Period

After an AIP passes Phase 3 of the voting process, there is a 3-day waiting period known as Phase 4. During this time, people who do not agree with the AIP have the chance to withdraw their funds or take other action on L2. This period is meant to give everyone time to consider the decision and make any necessary adjustments to their investments or actions.

Once the 3-day waiting period is over, the AIP will move on to the next phase of the voting process, as long as no major issues arise. This waiting period is important because it ensures that everyone has an opportunity to voice their concerns and recalibrate their participation before the AIP is finalized.

Phase 5: L2-to-L1 Message

Once the 3-day waiting period of Phase 4 has passed and an AIP has been approved, Phase 5 of the voting process begins. In this phase, an L2-to-L1 message is sent indicating that the AIP has passed. This message is sent to L1, which is the main Ethereum blockchain. Once the message is finalized on L1 (this takes at least 1 week), anyone can redeem it to complete this step and move on to the next step of the process. This ensures that the completion of the L2 waiting period will be recognized on L1 after any withdrawals initiated during or soon after the voting period have been recognized on L1.

This phase is important because it connects the Arbitrum blockchain, which is a Layer 2 (or L2) blockchain, to the main Ethereum blockchain, which is the L1 chain. This connection gives DAO members a guarantee that the DAO’s decision (and its members’ votes) is immutably recorded. This is an important step in the process of decentralized decision-making because it ensures that everyone can trust-but-verify the outcome of the voting process.

Phase 6: L1 Waiting Period

After Phase 5 of the voting process, where the decision is recorded on the Ethereum mainnet, the process enters Phase 6, which is a 3-day waiting period. This waiting period ensures that in-progress transactions have enough time to finalize on mainnet before the AIP is implemented.

This waiting period is important because it minimizes the risk of an AIP negatively impacting transactions that were initiated prior to the DAO’s approval of the AIP. Once this waiting period is over, the AIP takes effect.

Phase 7: Implementation

Phase 7 is the final step in the voting process in which an approved AIP is fully executed and implemented. An AIPs implementation can happen in one of two ways. It can happen directly on Ethereum mainnet, or via a transaction sent from L1 to one or more of the Layer 2 chains that are governed by the Arbitrum DAO. This L1-to-L2 mechanism ensures that changes made by an approved AIP are recognized and supported on both L1 and L2 chains. Once the AIP has been fully executed and implemented, its changes will be active until another AIP is passed to make further changes.

Additional Waiting Periods (Optional)

When an AIP is passed, it means that changes are going to be made to the Arbitrum DAO’s governance system. These changes can be “breaking changes” – changes that cause other parts of the governance system (or third-party systems) to stop working or behave differently.

To ensure that the owners of these downstream dependencies have enough time to adjust to these types of changes, proposal submitters may optionally specify an extra waiting period that needs to be honored before the AIP’s changes take effect. This is recommended for AIPs that require Arbitrum DAO’s stakeholders to spend some time preparing for the AIP’s proposed changes. This mechanism helps ensure that both Arbitrum DAO’s systems and third-party systems can remain available and stable during and after any given AIP’s implementation.

Conclusion

The entire AIP voting process, including all seven phases, typically takes 34 days to complete for Constitutional AIPs, or 21 days for Non-Constitutional AIPs, from the start of the temperature check in Phase 1. This process is designed to allow for thorough consideration and voting, ensuring that everyone has a fair chance to voice their opinions and concerns.

Risks

• State of progressive decentralization: Currently the Arbitrum DAO system retains ownership of both Arbitrum One and Arbitrum AnyTrust chains, such as Arbitrum Nova.However, the process of progressive decentralization involves gradually transferring ownership and control of various components of the system to a distributed network of participants. 

• Perpetual auditing: The protocol is perpetually audited by multiple independent audit firms. To enhance security, Offchain Labs maintains a substantial bug bounty program, offering significant rewards to individuals or groups who responsibly disclose critical bugs.

Security

Security Council

The Security Council is tasked with addressing urgent risks and threats to the Arbitrum protocol and its wider ecosystem. This involves making swift decisions through both emergency and non-emergency actions to safeguard the interests of the DAO, its members, and the broader Arbitrum community. It operates under the oversight of the DAO’s members, who retain the authority to remove Security Council members if their actions don’t align with the best interests of the DAO.

Security Council elections are pivotal as they democratically select individuals entrusted with safeguarding the Arbitrum DAO’s security. Regular elections ensure the Council is composed of representatives aligned with the DAO’s values.

Moreover, elections allow for the dismissal of Council members not acting in the DAO’s best interests, ensuring continuous vigilance.

Election Process

• The Security Council consists of 12 members divided into two groups, with elections taking place every six months to fill these seats.
• Candidates must be Arbitrum DAO members and secure support from at least 0.2% of all votable tokens to be considered.
• Voting is open to all Arbitrum DAO members, who cast their votes for their preferred candidates. The top 6 candidates receiving the most votes are elected to the Security Council.
• Additional guidelines and procedures for fair and transparent elections may be established by the Arbitrum Foundation.

Criteria for Council Members

• No more than 3 candidates from the same organization can be elected to the Security Council to ensure diverse representation.
• Candidates must be free from conflicts of interest that could hinder their ability to act in the best interests of the DAO.

Modifications and Removals

• The rules governing Security Council elections are subject to change by the Arbitrum DAO members. However, these changes cannot occur during an ongoing election.
• Security Council members can be removed from their positions before their term ends if a removal vote garners participation from at least 10% of all votable tokens and 5/6 of the votes are in favor of removal. Removal can also occur if at least 9 Security Council members vote for removal.

Audits

The following audits have been completed:

• Arbitrum Smart Contracts – ConsenSys – November 2021
  • Critical – 1
  • Major – 4
• Arbitrum Nitro Smart Contracts – ConsenSys – May 2022
  • Major – 2
  • Medium – 4
• Arbitrum Nitro – Trail of Bits – October 10, 2022
  • High – 3
  • Medium – 2
  • Low – 8
  • Information – 4
  • Undetermined – 1
• Arbitrum Governance – Trail of Bits – January 6. 2023
  • High – 1
  • Medium – 8
  • Low – 3
  • Informational – 5
  • Undetermined – 2

Bug Bounty

Arbitrum has an existing bug bounty program with Immunefi.

The bug bounty program is focused on the mainnet Arbitrum chains, Arbitrum One, and Arbitrum Nova and their underlying technologies, Arbitrum Rollup and Arbitrum AnyTrust respectively.

Rewards include:

• Critical: Up to $2M
• High: $30K
• Medium: $5K
• Low: $1K

Team

Offchain Labs

Core Team Members

• Ed Felten – Co-Founder, Chief Scientist of Offchain Labs (LinkedIn | Twitter | GitHub)
  • Ed has been a professor at Princeton since 1993 and began blockchain-related research in 2014.
  • Felten served as the Deputy United States Chief Technology Officer during President Obama’s
  • administration from 2015 to 2017.
• Steven Goldfeder – Co-Founder, CEO of Offchain Labs (LinkedIn | Twitter | GitHub)
  • Steven had no professional experience working in the blockchain industry before co-founding Offchain Labs. 
  • Goldfeder previously conducted blockchain-related research as a Ph.D. student with Ed Felten
• Harry Kalodner – Co-Founder, CTO of Offchain Labs (LinkedIn | Twitter | GitHub)
  • Harry had no professional experience working in the blockchain industry before co-founding Offchain Labs. 
  • Kalodner also previously conducted blockchain-related research as a Ph.D. student with Ed Felten.
• AJ Warner – CSO of Offchain Labs (LinkedIn | Twitter)
  • AJ was previously a Law Clerk and then an Associate at Paul Hastings.
• Samuel Friedman – Director of Marketing (LinkedIn)
  • Samuel was previously an Account Director at Bankrobber.
• Ryan De Souza – Partnerships (LinkedIn)
  • Ryan previously co-founded Stablecoin Standard, an industry body of fiat-backed stablecoin issuers globally.

The Arbitrum Foundation

The establishment of The Arbitrum Foundation, a Cayman Islands foundation company, was a critical first step in the establishment of the DAO. The Arbitrum Foundation serves the ArbitrumDAO community and is governed by it, aiming to foster the growth and development of the Arbitrum ecosystem while remaining accountable to the community.

Arbitrum Foundation Directors

As a Cayman Islands foundation, The Arbitrum Foundation is required to have at least 1 director responsible for the management and operation of The Arbitrum Foundation, in particular approving and entering into contractual arrangements on behalf of The Arbitrum Foundation (i.e., the parties actually approving and signing agreements). These directors were required to be appointed as part of the initial set-up of the Foundation.

The directors are as follows:

• Campbell Law 
  • Campbell was previously the founder of Silverside Ltd and co-founder of Provenance Ltd.
• Edward Noyons (LinkedIn)
  • Edward previously worked as a Director of Marfire, a Web3 services firm, and co-founded Autonomous, a DAO services firm.
• Ani Banerjee (LinkedIn)
  • Ani had no professional experience working in the blockchain industry before joining the Arbitrum Foundation as a Director. 
  • Ani Banerjee is also the Chief Human Resources Officer at KnowBe4.

Initial Set-up Costs and Operating Funds

The Arbitrum Foundation incurred pre-launch costs to set up the Arbitrum DAO and governance. The work included careful consideration and guidance of legal structures and technical expertise and development. This was done in the spirit of providing a safe, legal and technical framework to allow the DAO to self-govern on a trusted platform, and to allow for the safe transfer of the Arbitrum One and Arbitrum Nova networks to the DAO from both a technical and legal perspective.

With the launch of the ArbitrumDAO, the responsibility for the operation of the Arbitrum network was transferred to the ArbitrumDAO. As part of its responsibilities to the DAO, the Foundation has assumed the costs of paying for operations, blockchain operation, infrastructure, service contracts, and ongoing improvements to the Arbitrum ecosystem. In addition, the net on-chain fee revenue (the net difference between fees collected by on-chain operations and L1 fees paid by the Sequencer) from the Arbitrum One and Arbitrum Nova chains is now being sent to the ArbitrumDAO treasury. As such, the ArbitrumDAO will need to ensure The Arbitrum Foundation is adequately funded going forward to continue operating core infrastructure for the Arbitrum network including the Sequencer and public RPC interface.

In total, 7.5% of the token supply was distributed to the Foundation when the token supply was generated. 0.5% of $ARB tokens were needed to complete the initiation of the DAO. Of the 0.5%, 0.4% of $ARB tokens were provided as a loan as previously disclosed. The other 0.1% was sold to meet the obligations of initial governance setup and initial and near-term operating funds. This has been distributed to the Foundation in order to satisfy these upfront and near-term costs on behalf of the DAO.

These tokens were intended to fund the following expenses:

• DAO administration setup and registration fees
• Legal costs
• Chain service provider fees
• Director fees
• Fund near-term operating costs
• Contracts with third parties

Aside from the distribution to the Administrative Budget Wallet, 35.27% of the token supply was distributed to the on-chain DAO treasury, 11.62% to individual wallets, and 1.13% have been allocated to DAOs in the Arbitrum ecosystem.

The Arbitrum DAO

The Arbitrum DAO is a decentralized autonomous organization (DAO) built on the Ethereum blockchain. At its core, the Arbitrum DAO is a community-driven governance mechanism that allows $ARB token holders to propose and vote on changes to the organization and the technologies it governs.

The worldwide community of $ARB token holders and delegates governs the Arbitrum One chain, the Arbitrum Nova chain, The Constitution of the Arbitrum DAO, and the Security Council.

The Arbitrum DAO’s governance smart contracts are implemented on the Arbitrum One rollup chain, which is a Layer 2 scaling solution for the Ethereum blockchain. These smart contracts include the DAO’s governance token, $ARB. DAO members use $ARB tokens to vote on Arbitrum DAO proposals (AIPs). The weight of any given voter’s vote is proportional to the amount of $ARB they hold (or represent).

The Arbitrum DAO has a built-in treasury system (implemented as a smart contract); the DAO’s treasury is used to fund ongoing development and maintenance of the organization and its technologies. Token holders can propose and vote on how to use the treasury’s funds.

The Arbitrum DAO also has a built-in security mechanism called the Security Council. The Security Council is a group of entities that are responsible for ensuring the security and integrity of the DAO and its chains. The council can bypass the slow voting process and take fast action in the case of security emergency, as outlined in the Constitution. The members of the Security Council are elected by the DAO via semiannual elections.

Overall, the Arbitrum DAO is a powerful tool that facilitates decentralized governance and community-driven management of the Arbitrum ecosystem. By holding $ARB tokens and participating in the governance process, individuals can have a direct impact on the future of Arbitrum and, by extension, Ethereum.

Project Investors

Arbitrum raised funds through its supporting centralized entity, Offchain Labs. In total, ~$123.7M was raised across three separate rounds.

Additionally, a notable allocation of approximately 1.753 billion ArbERC-20 ARB tokens, equivalent to around 17.53% of the total token supply, was allocated to “Offchain Labs Investors.” This allocation is subject to a four-year monthly vesting schedule, with the first monthly unlocking event set to take place on March 23, 2024. While this allocation was disclosed, the breakdown of this token distribution across the different funding rounds has not been publicly specified.

Seed Round

Offchain Labs conducted a seed round on April 3, 2019, securing approximately $3.7 million in funding. The round was led by Pantera Capital and included participation from Compound VC, Raphael Ouzan, Jake Seid, as well as other undisclosed investors. However, the information regarding whether equity or tokens were exchanged in this round has not been publicly disclosed.

Series A Round

Offchain Labs successfully completed a Series A funding round in April 2021, raising around $20M. However, as of available information, Offchain Labs has not publicly revealed the list of participants who contributed to this round, nor has it disclosed whether the exchange involved equity or tokens.

Series B Round

Offchain Labs announced the completion of a Series B funding round on August 31, 2021, amassing approximately $10M. Lightspeed Venture Partners led this round, and other notable participants included Polychain Capital, Ribbit Capital, Redpoint Ventures, Pantera Capital, Alameda Research, and Mark Cuban. Similar to the previous rounds, it has not been made clear whether this funding involved equity or tokens.

Additional Information

Glossary of Arbitrum terms

Active Validator

A staked Validator makes disputable assertions to advance the state of an Arbitrum chain or to challenge the validity of others’ assertions. (Not to be confused with the Sequencer ).

Address Alias

An address deterministically generated from an L1 contract address is used on L2 to safely identify the source of an L1 to L2 message.

Arb Token Bridge

A series of contracts on an Arbitrum chain and its underlying chain facilitate trustless movement of ERC-20 tokens between the two layers.

Arbitrum

A suite of Ethereum layer-2 scaling technologies built with the Arbitrum Nitro tech stack that includes Arbitrum One (a live implementation of the Arbitrum Rollup Protocol) and Arbitrum Nova (a live implementation of the Arbitrum AnyTrust Protocol).

Arbitrum AnyTrust Chain

An Arbitrum chain that implements the Arbitrum AnyTrust Protocol.

Arbitrum AnyTrust Protocol

An Arbitrum protocol that manages data availability with a permissioned set of parties known as the Data Availability Committee (DAC). This protocol reduces transaction fees by introducing an additional trust assumption for data availability in lieu of Ethereum’s Trustless data availability mechanism. Arbitrum Nova is an example of an AnyTrust chain; Arbitrum One is an alternative chain that implements the purely trustless (and more L1-gas intensive) Arbitrum Rollup Protocol.

Arbitrum Chain

A blockchain that runs on the Arbitrum protocol. Arbitrum chains are EVM compatible and use an underlying EVM chain (e.g., Ethereum) for settlement and for succinct fraud-proofs (as needed). Arbitrum chains come in two forms: Arbitrum Rollup Chains and Arbitrum AnyTrust Chains.

Arbitrum Classic

Old Arbitrum stack that used a custom virtual machine (“AVM”); no public Arbitrum chain uses the classic stack as of 8/31/2022 (they instead use Arbitrum Nitro ).

Arbitrum Full Node

A party who keeps track of the state of an Arbitrum chain and receives remote procedure calls (RPCs) from clients. Analogous to a non-staking L1 Ethereum node.

Arbitrum Nitro

Current Arbitrum tech stack; runs a fork of Geth and uses WebAssembly as its underlying VM for fraud proofs.

Arbitrum Nova

The first Arbitrum AnyTrust Chain running on Ethereum mainnet. Introduces cheaper transactions; great for gaming and social use cases. Implements the Arbitrum AnyTrust Protocol, not the Arbitrum Rollup Protocol protocol.

Arbitrum One

The first Arbitrum Rollup Chain running on Ethereum mainnet. Fully trustless; inherits Ethereum’s base-layer security guarantees without introducing additional trust assumptions; great for decentralized finance and other use-cases that demand L1-level trustlessness.

Arbitrum Orbit

Arbitrum Orbit refers to the ability for anyone to permissionlessly deploy Layer 3 (L3) chains on top of Arbitrum Layer 2 (L2) chains.

Arbitrum Rollup Chain

An Arbitrum chain that implements the Arbitrum Rollup Protocol.

Arbitrum Rollup Protocol

A trustless, permissionless Arbitrum protocol that uses its underlying base layer for data availability and inherits its security. This protocol is implemented by our Arbitrum One chain.

ArbOS

Arbitrum’s “operating system” that trustlessly handles system-level operations; includes the ability to emulate the EVM.

Assertion

A staked claim by an Arbitrum Validator. An assertion may, e.g., propose a new RBlock, or may be a step in a Challenge.

Batch

A group of Arbitrum transactions posted in a single transaction on the Underlying Chain into the Fast Inbox by the Sequencer.

Blockchain

A distributed digital ledger that is used to record transactions and store data in a secure, transparent, and tamper-resistant way, notably in cryptocurrency protocols.

BOLD

Short for “Bounded Liquidity Delay”; the latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more). BOLD is not currently on mainnet.

CAP Finance

Widely considered the most degen community on Arbitrum.

CAP is a decentralized trading protocol. It’s designed to be fast and easy to use by anyone.

Chain State

A particular point in the history of an Arbitrum chain. A chain’s state is determined by applying the Arbitrum state-transition function to the sequence of transactions (i.e., the chain’s history).

Challenge

When two Stakers disagree about the correct verdict on an Assertion, those stakers can be put in a challenge. The challenge is referred to by the contracts on the underlying chain. Eventually, one staker wins the challenge. The protocol guarantees that an honest party will always win a challenge; the loser forfeits their stake.

Challenge Period

Window of time (1 week on Arbitrum One) over which an asserted RBlock can be challenged, and after which the RBlock can be confirmed.

Challenge Protocol

The protocol by which RBlocks are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid RBlocks will be confirmed provided that there is at least one honest Active Validator.

Child Chain

An Arbitrum Chain that settles to an underlying Parent Chain. For example, Arbitrum One and Arbitrum Nova are child chains of Ethereum.

Client

A program running on a user’s machine, often in the user’s browser, interacts with contracts on an Arbitrum chain and provides a user interface.

Confirmation

The decision by an Arbitrum chain to finalize an RBlock as part of the chain’s history. Once an RBlock is confirmed its L2 to L1 Messages (e.g., withdrawals) can be executed.

Cross-Chain Message

An action taken on some chain A which asynchronously initiates an additional action on chain B.

Custom Arb-Token

Any L2 token contract registered to the Arb Token Bridge that isn’t a standard arb-token (i.e., a token that uses any gateway other than the StandardERC20 gateway ).

Custom Gateway

Any Token Gateway that isn’t the StandardERC20 gateway.

dApp

Short for “decentralized application.” A dApp typically consists of smart contracts as well as a user interface for interacting with them.

Data Availability Certificate

Signed promise from a Data Availability Committee (DAC) attesting to the availability of a batch of data for an Arbitrum AnyTrust Chain.

Data Availability Committee (DAC)

A permissioned set of parties responsible for enforcing data availability in an Arbitrum AnyTrust Protocol chain. See Introducing AnyTrust Chains: Cheaper, Faster L2 Chains with Minimal Trust Assumptions to learn more.

Defensive Validator

A Validator that watches an Arbitrum chain and takes action (i.e., stakes and challenges) only when and if an invalid Assertion occurs.

Delayed Inbox

A contract that holds Parent chain initiated messages to be eventually included in the Fast Inbox. Inclusion of messages doesn’t depend on the Sequencer.

Dissection

A step in the Challenge protocol in which two challenging parties interactively narrow down their disagreement until they reach a One Step Proof.

Ethereum Wallet

A software application used for transacting with the Ethereum Blockchain.

Fair Ordering Algorithm

BFT algorithm in which a committee comes to consensus on transaction ordering; current single-party Sequencer on Arbitrum may eventually be replaced by a fair-ordering committee.

Fast Exit / Liquidity Exit

A means by which a user can bypass an Arbitrum chain’s Challenge Period when withdrawing fungible assets (or more generally, executing some “fungible” L2 to L1 operation); for trustless fast exits, a liquidity provider facilitates an atomic swap of the asset on L2 directly to L1.

Fast Inbox

Contract that holds a sequence of messages sent by clients to an Arbitrum Chain; a message can be put into the fast Inbox directly by the Sequencer or indirectly through the Delayed Inbox.

Force-Inclusion

Censorship resistant path for including a message into an Arbitrum chain via the Delayed Inbox on its Parent chain; bypasses any Sequencer involvement.

Fraud proof

The means by which an Active Validator proves to its underlying chain that an invalid state transition has taken place.

Gas Price Floor

Protocol-enforced minimum gas price on an Arbitrum chain; currently 0.1 gwei on Arbitrum One and 0.01 gwei on Arbitrum Nova.

Gateway Router

Contracts in the Arb Token Bridge responsible for mapping tokens to their appropriate Token Gateway.

Generic-Custom Gateway

A particular Custom gateway via which an L1 token contract can be registered to a token contract deployed to L2. A useful alternative to the StandardERC20 gateway for projects that wish to control the address of their L2 token contract, maintain L2 token contract upgradability, and for various other use cases.

Geth

An execution-layer client that defines the Ethereum state transition function and handles network-layer logic like transaction memory pooling. Arbitrum Nitro utilizes a fork of Geth to implement Arbitrum’s state transition function.

L2 Block

Data structure that represents a group of L2 transactions (analogous to L1 blocks).

L2 to L1 Message

A message initiated from within an Arbitrum chain to be eventually executed on Layer 1 (L1) (e.g., token or Ether withdrawals). On Rollup chains like Arbitrum One, the Challenge Period must pass before an L2 to L1 message is executed.

Layer 1 (L1)

The base protocol and underlying blockchain of the Ethereum network. Responsible for maintaining the integrity of the distributed ledger and executing smart contracts. Contains both Ethereum’s execution layer and consensus layer.

Layer 2 (L2)

Trustless scaling solutions built on top of Ethereum’s Layer 1 (L1) base protocol, such as state channels, plasma chains, optimistic rollups, and ZK-rollups. Layer 2 solutions aim to increase scalability and reduce the cost of transactions on Ethereum’s Layer 1 without introducing additional trust assumptions.

Layer 3 (L3)

An Arbitrum chain whose core contract resides on an Arbitrum Layer 2 (L2) chain.

One-Step Proof

Final step in a challenge; a single operation of the Arbitrum VM (WASM ) is executed on the underlying chain, and the validity of its state transition is verified.

Outbox

An L1 contract responsible for tracking L2 to L1 Messages, including withdrawals, which can be executed once they are confirmed. The outbox stores a Merkle Root of all outgoing messages.

Parent Chain

EVM compatible chain that acts as the settlement layer for one or more Arbitrum Chains (aka Child chain ). E.g., Ethereum is the parent chain of both Arbitrum One and Arbitrum Nova. Parent chain is synonymous with “underlying chain.”

RBlock

An assertion by an Arbitrum Validator that represents a claim about an Arbitrum chain’s state.

Retryable Autoredeem

The “automatic” (i.e., requiring no additional user action) execution of a Retryable Ticket on an Arbitrum chain.

Retryable Redeem

The execution of a Retryable Ticket on L2; can be automatic (see Retryable Autoredeem) or manual via a user-initiated L2 transaction.

Retryable Ticket

An L1 to L2 cross-chain message initiated by an L1 transaction sent to an Arbitrum chain for execution (e.g., a token deposit).

Reverse Token Gateway

A Token Gateway in which the Child chain gateway contract escrows and releases tokens, which the Parent chain Gateway contract mints and burns tokens. This is the inverse to how “typical” gateways work.

Sequencer

An entity (currently a single-party on Arbitrum One) given rights to reorder transactions in the Fast Inbox over a fixed window of time, who can thus give clients sub-blocktime Soft Confirmations. (Not to be confused with a Validator).

Sequencer Feed

Off chain data feed published by the Sequencer which clients can subscribe to for Soft Confirmations of transactions before they are posted in Batches.

Smart Contract

A computer program whose operations are defined and executed within a blockchain consensus protocol.

Soft Confirmation

A semi-trusted promise from the Sequencer to post a user’s transaction in the near future; soft-confirmations happen prior to posting on the Parent chain, and thus can be given near-instantaneously (i.e., faster than the parent chain’s block times)

Speed Limit

Target computation limit for an Arbitrum chain. Arbitrum One and Arbitrum Nova currently target 7,000,000 gas / second. When computation exceeds this limit, fees rise, ala EIP-1559.

Staker

A Validator who deposits a stake (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular RBlock in an Arbitrum Chain. A validator who stakes on a false RBlock can expect to lose their stake. An honest staker can recover their stake once the RBlock they are staked on has been confirmed.

Standard Arb-Token

A token contract on an Arbitrum chain deployed via the StandardERC20 gateway; offers basic ERC20 functionality in addition to deposit/withdrawal affordances.

StandardERC20 Gateway

Token Gateway via which any underlying chain’s ERC20 token can permissionlessly bridge; the StandrardERC20 gateway contracts deploy a Standard Arb-Token on the Child chain for each bridged token.

Stylus

Upgrade to the Arbitrum Nitro virtual machine that allows smart contract support for languages like Rust and C++ by taking advantage of Nitro’s use of WASM. Currently on testnet (read more).

Time Boost

A proposed (not currently live) transaction policy in which users can pay a fee to the Sequencer for a small ordering advantage. See [here](https://medium.com/offchainlabs/time-boost-a-new-transaction-ordering-policy-for-arbitrum-5b3066382d62) for more.

Token Gateway

A pair of contracts in the token bridge — one on the Parent chain, one on the Child chain — that provide a particular mechanism for handling the transfer of tokens between layers. Token gateways currently active in the bridge include the StandardERC20 gateway, the Generic-Custom Gateway, and the WETH Gateway.

Transaction

A user-initiated interaction with a Blockchain. Transactions are typically signed by users via wallets and are paid for via transaction fees.

Trustless

In the context of Ethereum, trustless refers to the ability of a system to operate without reliance on a central authority or intermediary. Instead, users place their trust in math and protocols.

This is achieved through the use of cryptographic techniques and decentralized consensus mechanisms that let users verify the integrity of network transactions using open-source software. Trustless systems are considered to be more secure and resistant to fraud or tampering because they don’t rely on a single point of failure that can be exploited by attackers.

Underlying Chain

Synonymous with the Parent chain.

Validator

An Arbitrum Full Node that tracks the status of the chains’ Assertions. A validator may be a Watchtower Validator, a Defensive Validator, or an Active Validator.

WASM

Widely supported binary code format for executable programs. Used by Arbitrum Nitro for Fraud proofs , and more broadly used by Stylus to support performant smart contracts in a wide variety of languages.

Watchtower Validator

A Validator that never stakes / never takes on chain action, who raises the alarm (by whatever off-chain means it chooses) if it witnesses an invalid assertion.

WETH Gateway

Token Gateway for handling the bridging of wrapped Ether (WETH). WETH is unwrapped on L1 and rewrapped on L1 upon depositing (and vice-versa upon withdrawing), ensuring WETH on L2 always remains collateralized.

FAQ

Why does Ethereum need help to “scale”? Is there something wrong with Ethereum?

• Ethereum has limitations. Ethereum’s transaction throughput is limited to about 20-40 transactions per second (TPS). When the limit is reached, users compete for inclusion, driving up fees.

Why does Ethereum have such low TPS?

• Ethereum requires nodes to process every transaction in its history for consensus. The design aims for decentralization, making it possible to run nodes. These factors cap Ethereum’s TPS.

How does Arbitrum and Rollup fix this?

• Arbitrum Rollups run as a sub-module within Ethereum. Ethereum initially assumes correct activity on Arbitrum. If a violation occurs, the claim is disputed on Ethereum (L1), proving fraud and penalizing malicious parties.

Can we be sure to prove fraud on Arbitrum?

• Yes, we can. Data fed into Arbitrum Rollup is posted on Ethereum. Anyone can detect and prove fraud as long as Ethereum runs securely.

Who checks for fraud and how?

• Validators move Arbitrum’s state forward on Ethereum. They make claims, dispute others’, etc. If one validator is honest, the chain remains secure. Fraud is proven through interactive games between validators.

How does the dispute game work?

• Validators play an interactive game to narrow disputes to a single step, executed on Ethereum. This proves the honest party’s claim.

Does the dispute game cause delays?

• Withdrawals from Arbitrum to Ethereum face a delay (1 week). Using a fast bridge app can bypass this. Other actions like deposits and using dApps have no delay.

So Arbitrum offers low fees through optimistic execution?

• Yes, primarily. Batched transactions and compressed data further reduce costs. The experience of using Arbitrum is similar to Ethereum.

Is Arbitrum Rollup a universal solution?

• Arbitrum Rollup is awesome, but not a one-size-fits-all solution. It prioritizes decentralization. Different tools in the Arbitrum suite suit various needs. Arbitrum AnyTrust chains, like Nova, offer different security considerations.

What’s an AnyTrust chain?

• AnyTrust chains have lower fees but different security. Data is managed off-chain, assuming 2 honest committee members. It’s ideal for high throughput and applications not requiring full decentralization.

There’s more than one Arbitrum chain?

• Yes, currently, there’s Arbitrum One (Rollup) and Nova (AnyTrust). Users can choose based on their security and cost preferences.

What’s the difference between Arbitrum Rollup and Arbitrum AnyTrust?

• Arbitrum Rollup is an Optimistic Rollup protocol; it is trustless and permissionless. Part of how these properties are achieved is by requiring all chain data to be posted on layer 1. This means the availability of this data follows directly from the security properties of Ethereum itself, and, in turn, that any party can participate in validating the chain and ensuring its safety.
• By contrast, Arbitrum AnyTrust introduces a trust assumption in exchange for lower fees; data availability is managed by a Data Availability Committee (DAC), a fixed, permissioned set of entities. We introduce some threshold, K, with the assumption that at least K members of the committee are honest. For simplicity, we’ll hereby assume a committee of size 20 and a K value of 2:
• If 19 out of the 20 committee members and the Sequencer are malicious and colluding together, they can break the chain’s safety (and, e.g., steal users’ funds); this is the new trust assumption.
• If anywhere between 2 and 18 of the committee members are well-behaved, the AnyTrust chain operates in “Rollup mode”; i.e., data gets posted on L1.
• In what should be the common and happy case, however, in which at least 19 of the 20 committee members are well-behaved, the system operates without posting the L2 chain’s data on L1, and thus, users pay significantly lower fees. This is the core upside of AnyTrust chains over rollups.
• Variants of the AnyTrust model in which the new trust assumption is minimized are under consideration; stay tuned.

Is the project sponsored or supported by a centralized entity?

• Arbitrum is supported by Offchain Labs, which was founded in 2018, registered in Delaware (United States), and operates at the following address: 252 Nassau St, Fl 2 Princeton, NJ 08542-4600.
• On March 24, 2023, on-chain ownership of the Arbitrum One and Arbitrum Nova blockchains was transferred from Offchain Labs to the Arbitrum DAO. 
• Nowadays the Arbitrum DAO governs the Arbitrum protocol. At the same time, the Arbitrum Foundation is an entity governed by the Arbitrum DAO. Its goal is to foster the growth and development of the Arbitrum ecosystem.” The foundation was founded in March 2023 and operates at the following address: 3119 9 Forum Ln., Camana Bay, P.O. Box 144, Grand Cayman KY1-9006, Cayman Islands

Do users or token holders earn fees, additional tokens, or any form of compensation by interacting with the network or in relation to holding the token (such as dividends, interest, liquidity rewards, or similar distributions)?

• $ARB token holders on Ethereum, Arbitrum One, and Arbitrum Nova do not earn fees, additional tokens, or any form of compensation associated with holding the token. 

Are there contributors outside of the project team who are compensated for working on the project? If so, how are they compensated (from a central entity, grant programs, on-chain treasury spends, etc.)? Are there any contributors that are not compensated for their work?

• Yes, contributors outside of the Arbitrum project team have been involved in contributing to certain aspects of the project. 
• Arbitrum’s GitHub repository consists of 47 repositories, including both publicly available and archived repositories. Out of these, 42 repositories were created by the Arbitrum project team, while five were forked from other projects. Within the 42 repositories created by the project team, 19 have open-source licenses that allow external contributors to participate.
• Within the 19 open-source repositories, numerous contributors who are not directly affiliated with Offchain Labs or the Arbitrum Foundation have made significant contributions, often defined by a minimum of 10 commits. Some of these contributors include individuals with usernames such as tsahee, magicxyyz, fredlacs, amsanghi, DZGoldman, yahgwai, and others. However, as of the information available up to March 16, 2023, it had not been publicly disclosed whether these unaffiliated contributors were compensated for their contributions.
• The establishment of the Arbitrum DAO and the Arbitrum Foundation on March 16, 2023, introduced new possibilities for the compensation of unaffiliated contributors. Community governance, facilitated through the Arbitrum DAO, has the authority to allocate treasury funds for grant programs or other forms of compensation to contributors who are not part of the project team.

Did the project team allocate a share of tokens to themselves? Are employees, directors, or advisors compensated in whole or in part with tokens or based on the price of tokens?

• Yes, the project team allocated approximately 2.694B ArbERC-20 ARB tokens, equivalent to around 26.94% of the total token supply, to the “Offchain Labs Team and Future Team + Advisors” associated wallet.
• This allocation is subject to a four-year monthly lockup vesting schedule, with the first monthly unlocking event set to occur on March 23, 2024. As of the available information, Offchain Labs has not disclosed whether employees or advisors are compensated, in whole or part, with the token or based on its price. It’s worth noting that no other token allocations are under the project team’s control.

Do I need to pay a tip/Priority fee for my Arbitrum transactions?

• Since transactions are processed in the order that the Sequencer receives them, no priority fee is necessary for Arbitrum transactions; if a transaction does include a priority fee, it will be refunded to the transaction’s origin address at the end of the execution.

What happens if I send my funds to an exchange that does not support Arbitrum?

• If you send the funds and the receiving wallet/exchange does not support the Arbitrum network you are sending funds through, there is unfortunately nothing that we can do to recover your funds. You would need to contact the wallet/exchange support and see if they can do anything to help you retrieve the funds.

Does Arbitrum have a mempool?

• The Arbitrum Sequencer orders transactions on a first-come, first-served basis; the Sequencer inserts transactions into a queue based on the order they are received and executes them accordingly. This queue thus exists in lieu of a mempool. The Sequencer’s queue has no space limit; transactions on the queue will eventually timeout and be discarded if not executed in time. Under normal conditions, the queue is empty, since transactions are executed near-instantaneously.

If there is a dispute, can my L2 transaction get re-orged/thrown out/”yeeted”?

• Nope; once an Arbitrum transaction is included on L1, there is no way it can be reorged (unless the L1 itself reorgs, of course). A “dispute” involves Validators disagreeing over execution, i.e., the output state of a chain. The inputs, however, can’t be disputed; they are determined by the Inbox on L1. (See Transaction Lifecycle)

…okay but if there’s a dispute, will my transaction get delayed?

• The only thing that a dispute can add delay to is the confirmation of L2-to-L1 messages. All other transactions continue to be processed, even while a dispute is still ongoing. (Additionally: in practice, most L2-to-L1 messages represent withdrawals of fungible assets; these can be trustlessly completed even during a dispute via trustless fast “liquidity exit” applications. See L2-to-L1 Messages).

Why was “one week” chosen for Arbitrum One’s dispute window?

• Generally, some amount of time is necessary for the Arbitrum validators to dispute an invalid assertion.
• A week is expected to be more than enough time for validators to carry out an interactive dispute, assuming they don’t encounter difficulty in getting their transactions included on L1. One week was chosen following the general consensus among the Ethereum research community — as well as other layer 2 projects — to provide enough time for the community to socially coordinate in the case of a coordinated Ethereum-staker censorship attack.

Will transactions with a higher “gas price bid” be confirmed first?

• There is no notion of mempool on Arbitrum, transactions are processed on a first come first served basis by the Sequencer. Thus, the gas price bid parameter does not influence the order in which a transaction is processed.

Where can I find a list of the current validators of the Arbitrum chains?

• Validation on both Arbitrum One and Arbitrum Nova is currently allow-listed to a committee of public entities. You can see the list of validators here. Governance currently has the power to change this status.

Where can I find the current Data Availability Committee members?

• The Arbitrum Nova chain has a 7-party DAC, whose members can be seen here. Governance has the ability to remove or add members to the committee.

Community Links

• Arbitrum
• Arbitrum Nova
• Docs
• Arbitrum One Whitepaper
• Arbitrum Nitro Whitepaper
• Arbitrum Nitro Github
• Twitter
• Discord
• Telegram
• Coingecko
• DefiLlama