Search

Search for projects by name or address

SummaryValue SecuredVolume and flowsActivityOnchain costsData postedLivenessMilestones & IncidentsRisk summaryRisk analysisStageData availabilityState derivationState validationUpgrades & GovernanceUpdatesOperatorSequencingWithdrawalsOther considerationsPermissionsSmart contracts

Arbitrum One logo
Arbitrum One

1 recent update

Badges

About

Arbitrum One is a general-purpose Optimistic Rollup built by Offchain Labs and governed by the Arbitrum DAO.

  • Bridge
  • Total Value SecuredTVS
    $11.42 B3.52%
  • Past day UOPSDaily UOPS
    18.6617.7%
  • Stage
    Stage 1
    Limited training wheels
    The project passes the walkaway test: users can exit in the presence of malicious operators even if the Security Council disappears.
    Items missing for Stage 2
    • Upgrades unrelated to onchain provable bugs provide less than 30d to exit.
    • The Security Council's actions are not confined to onchain provable bugs.
    Please mind, stages do not reflect project security
  • Gas token
    ETH
  • Type
    Optimistic Rollup
  • Purpose
    Universal
  • Chain ID
    42161

    • Tokens breakdown

    Last 24h cross-chain volume$552.80 MLast 24h cross-chain transfers42.65 K

    Interop protocols used

    HyperliquidCCTP v2LayerZero
    +21 more

    Tokens by volume

    USDCETHSUSDAI
    +376 more
    Sequencer failureState validationData availabilityExit windowProposer failure
    Explore more in Discovery UI

    Badges

    About

    Arbitrum One is a general-purpose Optimistic Rollup built by Offchain Labs and governed by the Arbitrum DAO.

    Value Secured

    CompareView TVS breakdown
    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal
    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other
    View TVS breakdown
    Compare with other projects

    Volume and flows

    Explore Interop
    Chain stats
    Transfer size
    Under $100
    $100-$1K
    $1K-$10K
    $10K-$100K
    Over $100K
    Transfer type distribution

    Explore Interop

    Activity

    Compare
    Past Day UOPS
    Past Day Ops count
    Max. UOPS
    Past day UOPS/TPS Ratio
    Compare with other projects

    Onchain costs

    Compare

    The section shows the operating costs that L2s pay to Ethereum.

    Total cost
    Avg cost per L2 UOP
    Avg cost per day
    Compare with other projects

    Data posted

    Compare

    This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data toEthereumEthereum.

    Data posted
    Avg size per day
    Avg size per L2 UOP
    Compare with other projects

    Liveness

    This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.

    No ongoing anomalies detected
    Avg. tx data subs. interval
    Avg. state updates interval
    Past 30 days anomalies
    100% normal uptime

    Milestones & Incidents

    Timeboost replaced by Priority Gas Auctions

    2026 Sep 23rd

    Transactions are ordered by priority fee in short rounds. A paid Fast Feed is introduced.

    Learn more

    Bridge emergency upgrade

    2026 May 24th

    Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. patches L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. governance-DoS (BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. renounces PROPOSER_ROLE). No funds at risk.

    Learn more

    Risk summary

    Funds can be stolen if

    1. a contract receives a malicious code upgrade. There is a 17d 8h delay on code upgrades unless upgrade is initiated by the Security Council in which case there is no delay,
    2. an attacker successfully performs a resource exhaustion attack.

    MEV can be extracted if

    1. the operator exploits their centralized position and frontruns user transactions.

    Risk analysis

    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Self sequence

    In the event of a sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. failure, users can force transactions to be included in the project’s chain by sending them to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. There can be up to a 1d delay on this operation.

    State validation
    Fraud proofs (INT)

    Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve.

    Data availability
    Onchain

    All of the data needed for proof construction is published on Ethereum L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..

    Exit window
    None (emergency upgrade path)
    10d (regular upgrade path)

    Non-emergency upgrades are initiated on L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. and go through a 8d delay on L2 and a 3d delay on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. Since there is a 1d delay to force a tx (forcing the inclusion in the following state updateA mechanism that allows to update the claimed state of a project. It usually involves verifying a state transition proof, but it can also be done in a trusted manner by a permissioned actor.), users have 10d to exit.

    There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

    Proposer failure
    Self propose

    Anyone can be a ProposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. and propose new roots to the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge..

    Stage

    Arbitrum One
    Arbitrum One is a
    Stage 1
    Optimistic Rollup.
    The project passes the walkaway test: users can exit in the presence of malicious operators even if the Security Council disappears.
    Learn more about Stages
    Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

    Data availability

    All data required for proofs is published on chain

    All the data that is used to construct the system state is published on chain in the form of cheap blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. or calldata. This ensures that it will be available for enough time.

    1. Sequencing followed by deterministic execution - Arbitrum documentation
    2. SequencerInbox.sol - source code, addSequencerL2BatchFromOrigin function
    Learn more about the DA layer here: Ethereum logoEthereum

    State derivation

    Node software

    The rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. nodeA software client that participates in the network. (Arbitrum Nitro) consists of four parts. The base layer is the core Geth server (with minor modifications to add hooks) that emulates the execution of EVM contracts and maintains Ethereum’s state and a fork of wasmer that is used for native WASM execution. The middle layer, ArbOS, provides additional Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. functionalities such as decompressing data batches, accounting for Layer 1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. costs, and supporting cross-chain bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. functionalities. The top layer consists of node software, primarily from Geth, that handles clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. connections (i.e., regular RPC node). View Code

    Compression scheme

    The SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs.’s batches are compressed using a general-purpose data compression algorithm known as Brotli, configured to its highest compression setting.

    Genesis state

    They performed a regenesis from Classic to Nitro, and that file represents the last Classic state. To sync from the initial Classic state, instructions can be found here.

    Data format

    Nitro supports Ethereum’s data structures and formats by incorporating the core code of the popular go-ethereum (“Geth”) Ethereum nodeA software client that participates in the network. software. The batch is composed of a header and a compressed blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally., which results from compressing concatenated RLP-encoded transactions using the standard RLP encoding.

    State validation

    A diagram of the state validation
    A diagram of the state validation

    Updates to the system state can be proposed and challenged by anyone who has sufficient funds. If a state rootA cryptographic hash succinctly representing a state using a Merkle tree. passes the challenge periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled., it is optimistically considered correct and made actionable for withdrawals.

    State root proposals

    ValidatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier propose state rootsA cryptographic hash succinctly representing a state using a Merkle tree. as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as “assertions” within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new nodeA software client that participates in the network. or withdraw it. The function used to propose a new assertion is the stakeOnNewAssertion function. The stake is currently set to 3600.0 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system.. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without “rivals” can be confirmed after the challenge periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled. has passed, currently set to 6d 8h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.

    1. BoLD paper
    Challenges

    A challenge can be started between two siblings, i.e. two different state rootsA cryptographic hash succinctly representing a state using a Merkle tree. that share the same parent, by calling the createLayerZeroEdge function in the ChallengeManager contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent “history root” that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 6d 8h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 12d 17h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over., the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 555.0 ETH, level 2 requires a stake of 79.0 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.

    • Funds can be stolen if an attacker successfully performs a resource exhaustion attack.

    1. Fraud Proof Wars: Arbitrum BoLD

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0xc10c...dc97
    Github
    Arbitrum One logoRobinhood Chain logoArbitrum Nova logo

    Upgrades & Governance

    A diagram of the upgrades and governance
    A diagram of the upgrades and governance

    All critical system smart contracts are upgradeable (can be arbitrarily changed). This permission is governed by the Arbitrum Decentralized Autonomous Organization (DAO) and their elected Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.. The Arbitrum DAO controls Arbitrum One and Arbitrum Nova through upgrades and modifications to their smart contracts on Layer 1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. Ethereum and the Layer 2s. While the DAO governs through token-weighted governance in their associated ARB token, the Security Council can directly act through multisigs on all three chains. Although they are technically separate and connect to different target permissions, their member- and threshold configuration is kept in sync by a manager contract on Arbitrum One sending crosschain transactions.

    Regular upgrades, Admin- and Owner actions originate from either the Arbitrum DAO or the non-emergency (ProposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.-) Security Council on Arbitrum One and pass through multiple delays and timelocks before being executed at their destination. Contrarily, the three Emergency Security Council multisigs (one on each chain: Arbitrum One, Ethereum, Arbitrum Nova) can skip delays and directly access all admin- and upgrade functions of all smart contracts. These two general paths have the same destination: the respective UpgradeExecutor smart contract.

    Regular upgrades are scheduled in the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Timelock. The proposer Security Council can do this directly and the Arbitrum DAO (ARB token holders and delegates) must meet a CoreGovernor-enforced 50% threshold of the votable tokens. The L2 Timelock queues the transaction for a 8d delay and then sends it to the Outbox contract on Ethereum. This incurs another delay (the challenge periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled.) of 6d 8h, which is extended by an additional 2d if the top-level assertion has been challenged. When that has passed, the L1 Timelock delays for additional 3d. Both timelocks serve as delays during which the transparent transaction contents can be audited, and, in the case of the final L1 timelock, cancelled by the Emergency Security Council. Finally, the transaction can be executed, calling Admin- or Owner restricted functions of the respective destination smart contracts through the UpgradeExecutor on Ethereum. If the predefined transaction destination is Arbitrum One or -Nova, this last call is executed on L2 through the canonical bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. and the aliased address of the L1 Timelock.

    OperatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. roles like the Sequencers and ValidatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier are managed using the same paths. SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. changes can be delegated to a Batch Poster Manager role.

    Transactions targeting the Arbitrum DAO Treasury can be scheduled in the 3d Treasury Timelock by meeting a TreasuryGovernor-enforced 40% threshold of votable ARB tokens. The Security Council cannot regularly cancel these transactions or schedule different ones but can overwrite them anyway by having upgrade permissions for all the underlying smart contracts.

    Governance profile

    Security Council

    Composition

    9/12 — 12 members across two 6-seat cohorts, 1-year staggered terms. DAO-elected via on-chain vote with Foundation eligibility screening.

    Members public

    Mapped — 12 entities + addresses published by the Arbitrum Foundation. Mix of individuals (gzeon, zachxbt, Bartek, Yoav, Griff Green, “fred”, Emiliano, Michael Lewellen) and orgs (Gauntlet, Immunefi, Certora, OpenZeppelin).

    Charter

    Arbitrum DAO Constitution §3 — defines 9/12 threshold, transparency reports, conflict-of-interest, removal mechanics, ≤3-per-org cap.

    Can bypass DAO?

    Yes — emergency (9/12, instant) and non-emergency (9/12, still subject to 8d L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. + 3d L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. timelocks). Non-emergency bypass skips AIP Phases 1–3 only.

    DAO can override SC?

    No — although DAO Constitution §3 gives the DAO authority to modify or eliminate the SC, an active 9/12 SC holds Canceller on both L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. and L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Timelocks and can execute emergency upgrades during the ~17.4d execution window. If the SC is inactive or cooperative, the DAO can replace it through normal governance.

    Upgrades

    Normal upgrade path

    Forum temp-check → On-chain vote (14d) → L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Timelock (8d) → L2→L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. outbox (~6.4d) → L1 Timelock (3d) → execute. Total wall-clock ≈ 41 days for Constitutional AIPs (≈ 34d onchain-enforced), ≈ 27 days for Treasury AIPs.

    Emergency upgrade path

    9/12 SC, instant — no timelock, no exit windowThe amount of time that users have to exit a system before an unwanted upgrade. It takes into account upgrade delays, forced transaction delays and other time factors. To be considered Stage 1, a rollup needs to have an exit window of at least 7d if upgrades are initiated by a permissioned actor less decentralized than a Security Council. For Stage 2, a rollup needs at least 30d in all cases outside of onchain provable bugs.. E.g. KelpDAO freeze (21 Apr 2026), Stylus stack-depth fix (13 Oct 2025).

    Exit window

    ~17.4d non-emergency · 0 emergency. L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Timelock + L2→L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. outbox + L1 Timelock provide the non-emergency window; emergency actions skip all three.

    Token governance

    Governance token

    ARB — 10,000,000,000 total · ~6.15B circulating · ~3.5B in DAO treasury. 1 token = 1 vote, delegated. Foundation tokens excluded from Votable Tokens.

    Voting venue

    Tally — two on-chain governors on Arbitrum One: Core (Constitutional) 0xf07DeD9d… · Treasury (Non-Constitutional) 0x789fC990….

    Proposal threshold

    1,000,000 ARB delegated to submit on-chain. 500k ARB delegated to post a Snapshot temperature check.

    Quorum

    50% of Delegated Voting Power Constitutional · 40% Treasury, with floor/ceiling bounds of 150–450M ARB (Const) / 100–300M ARB (Treasury). Counts “For” + “Abstain”.

    Execution model

    On-chain payload · PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execute. The Governor stores the proposal’s (targets[], values[], calldatas[]) at submission. Once the vote passes and the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups./L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. Timelocks expire, anyone can call execute() — the same bytes that were voted on are what runs. No multisig signing, no team discretion, no off-chain step between vote and effect.

    Past upgrades

    The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

    Count of upgrades
    66
    Last upgrade
    28d 5h ago
    Avg upgrade interval
    1y

    Updates

    2026 September 28, 13:20 UTC
    High severity
    8changes

    Timeboost is replaced by Priority Gas Auctions (Constitutional AIP). Tips are paid to the network fee account (L2SurplusFee). The TipCollectionToggler is immutable and can only call setCollectTips . Config related: the ArbOS chain owners are now discovered via ArbOwnerPublic.getAllChainOwners() on the L2UpgradeExecutor. This adds the time-limited, single-purpose chain owner contracts TipCollectionToggler, BaseFeeManager and ResourceConstraintManager with new templates, and their manager multisig.

    Timeboost is replaced by Priority Gas Auctions (Constitutional AIP). Tips are paid to the network fee account (L2SurplusFee). The TipCollectionToggler is immutable and can only call setCollectTips.

    Config related: the ArbOS chain owners are now discovered via ArbOwnerPublic.getAllChainOwners() on the L2UpgradeExecutor. This adds the time-limited, single-purpose chain owner contracts TipCollectionToggler, BaseFeeManager and ResourceConstraintManager with new templates, and their manager multisig.

    contract L2UpgradeExecutor (arb1:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827) [orbitstack/layer2/L2UpgradeExecutor] {
    +++ description: This contract can upgrade the L2 system's contracts through the L2ProxyAdmin. The upgrades can be done either by the Security Council or by the L1Timelock (via its alias on L2).
    +++ severity: HIGH
    values.chainOwners.2:
    + "arb1:0x4323dAb775cc15e386FDAC591a39420db6226a63"
    }
    contract Arbitrum L2 Multisig 1 (arb1:0xe128a8100d1b543dE82d04450B3406d57aBF553b) [GnosisSafe] {
    +++ description: None
    receivedPermissions.0:
    + {"permission":"interact","from":"arb1:0x4323dAb775cc15e386FDAC591a39420db6226a63","description":"toggle the collection of priority fees (tips).","role":".tipCollectionManagers"}
    }
    contract L1Timelock (eth:0xE6841D92B0C345144506576eC13ECf5103aC7f49) [orbitstack/Timelock] {
    +++ description: A timelock with access control. The current minimum delay is 3d. Proposals that passed their minimum delay can be executed by the anyone.
    values.scheduledTransactions.144:
    + {"id":"0x59470daae279ebdcaae1733764314be84996e57ad3d3fb40a2dab57aec6e7178","decoded":{"chain":"arbitrum","contractName":"","function":"0x481f8dbf","inputs":[{"name":"calldata","value":"0x481f8dbf0000000000000000000000004323dab775cc15e386fdac591a39420db6226a63"}],"address":"arb1:0x0000000000000000000000000000000000000070","calldata":"0x481f8dbf0000000000000000000000004323dab775cc15e386fdac591a39420db6226a63","executor":"eth:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827","inboxOnEthereum":"eth:0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3f"},"raw":{"target":"eth:0xa723C008e76E379c55599D2E4d93879BeaFDa79C","value":0,"data":"0x0000000000000000000000004dbd4fc535ac27206064b68ffcf827b0a60bab3f000000000000000000000000cf57572261c7c2bcf21ffd220ea7d1a27d40a82700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000a4bca8c7b5000000000000000000000000000000000000000000000000000000000000007000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000024481f8dbf0000000000000000000000004323dab775cc15e386fdac591a39420db6226a630000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","delay":259200}}
    values.scheduledTransactions.145:
    + {"id":"0x59470daae279ebdcaae1733764314be84996e57ad3d3fb40a2dab57aec6e7178","decoded":{"chain":"arbitrum","contractName":"TipCollectionToggler","function":"activate","inputs":[],"address":"arb1:0x4323dAb775cc15e386FDAC591a39420db6226a63","calldata":"0x0f15f4c0","executor":"eth:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827","inboxOnEthereum":"eth:0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3f"},"raw":{"target":"eth:0xa723C008e76E379c55599D2E4d93879BeaFDa79C","value":0,"data":"0x0000000000000000000000004dbd4fc535ac27206064b68ffcf827b0a60bab3f000000000000000000000000cf57572261c7c2bcf21ffd220ea7d1a27d40a82700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000084bca8c7b50000000000000000000000004323dab775cc15e386fdac591a39420db6226a63000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000040f15f4c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","delay":259200}}
    }
    + Status: CREATED
    contract TipCollectionToggler (arb1:0x4323dAb775cc15e386FDAC591a39420db6226a63) [orbitstack/layer2/TipCollectionToggler]
    +++ description: ArbOS chain owner that can only toggle the collection of priority fees (tips), which enables PGA transaction ordering. Anyone can remove it from the chain owners after the expiry timestamp.

    New and verified contracts

    + Status: CREATED
    contract BaseFeeManager (arb1:0x6e031B6e9f667Ed6953E627276fBbEfa4c28529A) [orbitstack/layer2/BaseFeeManager]
    +++ description: ArbOS chain owner that can only set the L2 base fee and minimum base fee within 0.01-0.1 gwei. Anyone can remove it from the chain owners after the expiry timestamp.
    + Status: CREATED
    contract ResourceConstraintManager (arb1:0x8F59C7A53b883563B34cbBb6fF021B03973e823a) [orbitstack/layer2/ResourceConstraintManager]
    +++ description: ArbOS chain owner that can only set the gas pricing constraints of the L2 base fee model within hardcoded bounds. Anyone can remove it from the chain owners after the expiry timestamp.
    + Status: CREATED
    contract Arbitrum L2 Multisig 1 (arb1:0xe128a8100d1b543dE82d04450B3406d57aBF553b) [GnosisSafe]
    +++ description: None
    2026 September 18, 10:24 UTC
    3changes

    arbitrum: critical contracts and severities for the ossification perimeter

    arbitrum: critical contracts and severities for the ossification perimeter

    New and verified contracts

    + Status: CREATED
    contract L2WETH (arb1:0x82aF49447D8a07e3bd95BD0d56f35241523fBab1) [N/A]
    +++ description: Canonical upgradeable WETH token burned by L2WethGateway when withdrawing against the L1 WETH escrow.
    + Status: CREATED
    contract L1ARBGateway (eth:0xbbcE8aA77782F13D4202a230d978F361B011dB27) [N/A]
    +++ description: Canonical reverse gateway for ARB transfers between Ethereum and Arbitrum One.
    + Status: CREATED
    contract L1WethGateway (eth:0xd92023E9d9911199a6711321D1277285e6d4e2db) [N/A]
    +++ description: Canonical WETH gateway escrowing L1 WETH and releasing it for withdrawals proven through the Arbitrum bridge.
    2026 September 07, 22:08 UTC
    High severity
    30changes

    Security Council Election Process Improvements AIP, executed 2026-08-31 20:52 UTC (L1Timelock scheduled tx 143 → SecurityCouncilUpgradeAction.perform() ). Both governance contracts were upgraded: - SecurityCouncilManager : adds member self-rotation and a minimum 44-day rotation period, gated by a new MIN ROTATION PERIOD SETTER role held by the L2UpgradeExecutor. - SecurityCouncilNomineeElectionGovernor : election cadence set to 12 months, qualification quorum lowered from 0.2% to 0.1%. - ConstitutionHash updated.

    Security Council Election Process Improvements AIP, executed 2026-08-31 20:52 UTC (L1Timelock scheduled tx #143 → SecurityCouncilUpgradeAction.perform()). Both governance contracts were upgraded:

    • SecurityCouncilManager: adds member self-rotation and a minimum 44-day rotation period, gated by a new MIN_ROTATION_PERIOD_SETTER role held by the L2UpgradeExecutor.
    • SecurityCouncilNomineeElectionGovernor: election cadence set to 12 months, qualification quorum lowered from 0.2% to 0.1%.
    • ConstitutionHash updated.
    contract ConstitutionHash (arb1:0x1D62fFeB72e4c360CcBbacf7c965153b00260417) [orbitstack/layer2/ConstitutionHash] {
    +++ description: Keeps the current hash of the ArbitrumDAO Constitution. Settable by the L2UpgradeExecutor.
    values.constitutionHash:
    - "0x263080bed3962d0476fa84fbb32ab81dfff1244e2b145f9864da24353b2f3b05"
    + "0x310d1c0495cf8ff7b5e89c26fbca91b230ce6dd2b9b8bde8c1a8605545f25063"
    }
    contract L2SecurityCouncilEmergency (arb1:0x423552c0F05baCCac5Bfa91C6dCF1dc53a0A1641) [orbitstack/layer2/L2SecurityCouncilEmergency] {
    +++ description: None
    receivedPermissions.2:
    + {"permission":"interact","from":"arb1:0xD509E5f5aEe2A205F554f36E8a7d56094494eDFC","description":"set the minimum period between Security Council member key rotations.","role":".minRotationPeriodSetterAC","via":[{"address":"arb1:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827"}]}
    }
    contract SecurityCouncilNomineeElectionGovernor (arb1:0x8a1cDA8dee421cD06023470608605934c16A05a0) [orbitstack/layer2/SecurityCouncilNomineeElectionGovernor] {
    +++ description: Token governance contract for the Security Council nominee elections.
    sourceHashes.1:
    - "0x467a6d321abaf3adf3783b74c4ab2cb9712f8c21a21696fde01fc236733df050"
    + "0x2c28a185d54c18615d4892e1c62fd8df740411c245e0a4b2adc39bc22365a4d5"
    values.$implementation:
    - "arb1:0xd3Ae921B220bedC2f94a5968E25535a476A9518C"
    + "arb1:0xB4Fd52807d5856B4CfF85d53D53d1Dc714C4D482"
    values.$pastUpgrades.2:
    + ["2026-08-31T20:52:09.000Z","0x48468a996d2e64c1b0f067518eb050e1863eb04e59da19d4652910835d00fe26",["arb1:0xB4Fd52807d5856B4CfF85d53D53d1Dc714C4D482"]]
    values.$upgradeCount:
    - 2
    + 3
    values.firstNominationStartDate.year:
    - 2023
    + 2021
    values.firstNominationStartDate.month:
    - 9
    + 3
    values.quorumNumerator:
    - 20
    + 10
    values.cadenceInMonths:
    + 12
    values.ROTATION_CUT_OFF_BLOCKS:
    + 21600
    implementationNames.arb1:0xd3Ae921B220bedC2f94a5968E25535a476A9518C:
    - "SecurityCouncilNomineeElectionGovernor"
    implementationNames.arb1:0xB4Fd52807d5856B4CfF85d53D53d1Dc714C4D482:
    + "SecurityCouncilNomineeElectionGovernor"
    }
    contract L2UpgradeExecutor (arb1:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827) [orbitstack/layer2/L2UpgradeExecutor] {
    +++ description: This contract can upgrade the L2 system's contracts through the L2ProxyAdmin. The upgrades can be done either by the Security Council or by the L1Timelock (via its alias on L2).
    directlyReceivedPermissions.4:
    + {"permission":"interact","from":"arb1:0xD509E5f5aEe2A205F554f36E8a7d56094494eDFC","description":"set the minimum period between Security Council member key rotations.","role":".minRotationPeriodSetterAC"}
    }
    contract SecurityCouncilManager (arb1:0xD509E5f5aEe2A205F554f36E8a7d56094494eDFC) [orbitstack/layer2/SecurityCouncilManager] {
    +++ description: This contract enforces the rules for changing members and cohorts of the SecurityCouncil and creates crosschain messages to Ethereum and Arbitrum Nova to keep the configuration in sync.
    sourceHashes.1:
    - "0xf2eeba703974bbc2cb02cd7d24845f71be941a764f033493e85fba52b3d6de28"
    + "0x91ac856c76d1dece40ddd75f96a4c2f01abea4b57cea64f43b24149466105b4f"
    values.$implementation:
    - "arb1:0x468dA0eE5570Bdb1Dd81bFd925BAf028A93Dce64"
    + "arb1:0x01B370d9b1ed1591C64C9a4b0FAFF193AF5Fa928"
    values.$pastUpgrades.1:
    + ["2026-08-31T20:52:09.000Z","0x48468a996d2e64c1b0f067518eb050e1863eb04e59da19d4652910835d00fe26",["arb1:0x01B370d9b1ed1591C64C9a4b0FAFF193AF5Fa928"]]
    values.$upgradeCount:
    - 1
    + 2
    values.DOMAIN_TYPE_HASH:
    + "0x8b73c3c69bb8fe3d512ecc4cf759cc79239f7b179b0ffacaa9a75d522b39400f"
    values.MIN_ROTATION_PERIOD_SETTER_ROLE:
    + "0xdca740b6747d464c97988ea224a1c2afa5d593dea6c130c887834cb139bbe3cd"
    values.minRotationPeriod:
    + 3801600
    values.minRotationPeriodSetterAC:
    + ["arb1:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827"]
    values.NAME_HASH:
    + "0xf935788d54266c928db40f457ef3948e98c56fe8d272b38ba9d240bf19b3fcf5"
    values.ROTATE_MEMBER_TYPE_HASH:
    + "0x680519cfd93b36ad1cb2f56839eef9e22266c5109fac35adee21f6f49b248260"
    values.VERSION_HASH:
    + "0xc89efdaa54c0f20c7adf612882df0950f5a951637e0307cdcb4c672f298b8bc6"
    errors:
    - {"minRotationPeriodSetterAC":"Processing error occurred."}
    implementationNames.arb1:0x468dA0eE5570Bdb1Dd81bFd925BAf028A93Dce64:
    - "SecurityCouncilManager"
    implementationNames.arb1:0x01B370d9b1ed1591C64C9a4b0FAFF193AF5Fa928:
    + "SecurityCouncilManager"
    }
    EOA L1Timelock_l2alias (arb1:0xf7951D92B0C345144506576eC13Ecf5103aC905a) {
    +++ description: None
    receivedPermissions.2:
    + {"permission":"interact","from":"arb1:0xD509E5f5aEe2A205F554f36E8a7d56094494eDFC","description":"set the minimum period between Security Council member key rotations.","role":".minRotationPeriodSetterAC","via":[{"address":"arb1:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827"}]}
    }
    contract L1Timelock (eth:0xE6841D92B0C345144506576eC13ECf5103aC7f49) [orbitstack/Timelock] {
    +++ description: A timelock with access control. The current minimum delay is 3d. Proposals that passed their minimum delay can be executed by the anyone.
    values.scheduledTransactions.143:
    + {"id":"0xbf93fbef0a1274cf00bfcbdff101bdc83b9924f9711879d284d6495728356e85","decoded":{"chain":"arbitrum","contractName":"SecurityCouncilUpgradeAction","function":"perform","inputs":[],"address":"arb1:0xeF98Fc7A7F08De47Ed01f3F11f07319c22106445","calldata":"0xb147f40c","executor":"eth:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827","inboxOnEthereum":"eth:0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3f"},"raw":{"target":"eth:0xa723C008e76E379c55599D2E4d93879BeaFDa79C","value":0,"data":"0x0000000000000000000000004dbd4fc535ac27206064b68ffcf827b0a60bab3f000000000000000000000000cf57572261c7c2bcf21ffd220ea7d1a27d40a82700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000841cff79cd000000000000000000000000ef98fc7a7f08de47ed01f3f11f07319c2210644500000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000004b147f40c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","delay":259200}}
    }
    2026 August 27, 14:18 UTC
    7changes

    ArbFilteredTransactionsManager (ArbOS 61 transaction-filtering precompile) now tracked; no filterers registered.

    ArbFilteredTransactionsManager (ArbOS 61 transaction-filtering precompile) now tracked; no filterers registered.

    contract ArbFilteredTransactionsManager (arb1:0x0000000000000000000000000000000000000074) [orbitstack/ArbFilteredTransactionsManager] {
    +++ description: ArbOS 61 transaction-filtering precompile (0x..74). An authorized filterer registers tx hashes here; the state transition function then forcibly fails those transactions, including force-included ones, without delay. Available from ArbOS 61 onwards. On chains where the feature is not enabled (e.g. Arbitrum One and Nova) it has no filterers and no filtered transactions, but is tracked so any future activation is caught immediately. Compare Robinhood, where this precompile is active.
    type:
    - "EOA"
    + "Contract"
    proxyType:
    - "EOA"
    + "immutable"
    values.transactionFilterers:
    - "EXPECT_REVERT"
    + []
    values.$immutable:
    + true
    sourceHashes:
    + ["0xc92ac7c82ac0ae6811eb5889bb19d300f3f59cc6c21e25d1be2dcc6c4a9db41a"]
    implementationNames:
    + {"arb1:0x0000000000000000000000000000000000000074":""}
    }
    contract L2ArbitrumToken (arb1:0x912CE59144191C1204E64559FE8253a0e49E6548) [orbitstack/layer2/L2ArbitrumToken] {
    +++ description: The ARB token contract. Supply can be increased by the owner once per year by a maximum of 2%.
    values.totalSupply:
    - "9999998977630224104158908096"
    + "9999998977610261816650915825"
    }
    2026 August 19, 12:45 UTC
    8changes

    RollupProxy: wasmModuleRoot updated to the ArbOS v61 root. L1Timelock records the accompanying scheduled transactions: SetWasmModuleRootAction on Ethereum, UpgradeArbOSVersionAtTimestampAction and ArbOS61SettingsAction on Arbitrum One, and the matching Nova actions.

    RollupProxy: wasmModuleRoot updated to the ArbOS v61 root. L1Timelock records the accompanying scheduled transactions: SetWasmModuleRootAction on Ethereum, UpgradeArbOSVersionAtTimestampAction and ArbOS61SettingsAction on Arbitrum One, and the matching Nova actions.

    contract RollupProxy (eth:0x4DCeB440657f21083db8aDd07665f8ddBe1DCfc0) [orbitstack/RollupProxyBoLD] {
    +++ description: Central contract for the project's configuration like its execution logic hash (`wasmModuleRoot`) and addresses of the other system contracts. Entry point for Proposers creating new assertions (state commitments) and Challengers submitting fraud proofs (In the Orbit stack, these two roles are both called Validators).
    +++ description: ArbOS version derived from known wasmModuleRoots.
    values.arbOsFromWmRoot:
    - "ArbOS v51 wasmModuleRoot"
    + "ArbOS v61 wasmModuleRoot"
    +++ description: Root hash of the WASM module used for execution, like a fingerprint of the L2 logic. Can be associated with ArbOS versions.
    values.wasmModuleRoot:
    - "0x8a7513bf7bb3e3db04b0d982d0e973bcf57bf8b88aef7c6d03dba3a81a56a499"
    + "0xc10cd7ec6acaf1c441a3f6bd0900ad20f15855ba775a96f1939118cbc629dc97"
    }
    contract L1Timelock (eth:0xE6841D92B0C345144506576eC13ECf5103aC7f49) [orbitstack/Timelock] {
    +++ description: A timelock with access control. The current minimum delay is 3d. Proposals that passed their minimum delay can be executed by the anyone.
    values.scheduledTransactions.137:
    + {"id":"0xf60ffd47f050d5cd5ed97b0225a01845d0bca8471dc0dc0e07f9968a4cf88901","decoded":{"chain":"ethereum","contractName":"SetWasmModuleRootAction","function":"perform","inputs":[],"address":"eth:0x114637D5cB4BaE22c94F822c984F5cA6013284Da","calldata":"0xb147f40c","executor":"eth:0x3ffFbAdAF827559da092217e474760E2b2c3CeDd"},"raw":{"target":"eth:0x3ffFbAdAF827559da092217e474760E2b2c3CeDd","value":0,"data":"0x1cff79cd000000000000000000000000114637d5cb4bae22c94f822c984f5ca6013284da00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000004b147f40c00000000000000000000000000000000000000000000000000000000","delay":259200}}
    values.scheduledTransactions.138:
    + {"id":"0xf60ffd47f050d5cd5ed97b0225a01845d0bca8471dc0dc0e07f9968a4cf88901","decoded":{"chain":"ethereum","contractName":"SetWasmModuleRootAction","function":"perform","inputs":[],"address":"eth:0x36E3BbEF91D182b47DAb09E8AC3a4EA9C524fBab","calldata":"0xb147f40c","executor":"eth:0x3ffFbAdAF827559da092217e474760E2b2c3CeDd"},"raw":{"target":"eth:0x3ffFbAdAF827559da092217e474760E2b2c3CeDd","value":0,"data":"0x1cff79cd00000000000000000000000036e3bbef91d182b47dab09e8ac3a4ea9c524fbab00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000004b147f40c00000000000000000000000000000000000000000000000000000000","delay":259200}}
    values.scheduledTransactions.139:
    + {"id":"0xf60ffd47f050d5cd5ed97b0225a01845d0bca8471dc0dc0e07f9968a4cf88901","decoded":{"chain":"arbitrum","contractName":"UpgradeArbOSVersionAtTimestampAction","function":"perform","inputs":[],"address":"arb1:0xF93353c1Fe24225B6C82B284b2B6DBB924690515","calldata":"0xb147f40c","executor":"eth:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827","inboxOnEthereum":"eth:0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3f"},"raw":{"target":"eth:0xa723C008e76E379c55599D2E4d93879BeaFDa79C","value":0,"data":"0x0000000000000000000000004dbd4fc535ac27206064b68ffcf827b0a60bab3f000000000000000000000000cf57572261c7c2bcf21ffd220ea7d1a27d40a82700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000841cff79cd000000000000000000000000f93353c1fe24225b6c82b284b2b6dbb92469051500000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000004b147f40c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","delay":259200}}
    values.scheduledTransactions.140:
    + {"id":"0xf60ffd47f050d5cd5ed97b0225a01845d0bca8471dc0dc0e07f9968a4cf88901","decoded":{"chain":"nova","address":"eth:0x6bE7bA57Dd831A7D0AeDA1fB87C3c206C38098fF","calldata":"0xb147f40c","executor":"eth:0x86a02dD71363c440b21F4c0E5B2Ad01Ffe1A7482","inboxOnEthereum":"eth:0xc4448b71118c9071Bcb9734A0EAc55D18A153949"},"raw":{"target":"eth:0xa723C008e76E379c55599D2E4d93879BeaFDa79C","value":0,"data":"0x000000000000000000000000c4448b71118c9071bcb9734a0eac55d18a15394900000000000000000000000086a02dd71363c440b21f4c0e5b2ad01ffe1a748200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000841cff79cd0000000000000000000000006be7ba57dd831a7d0aeda1fb87c3c206c38098ff00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000004b147f40c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","delay":259200}}
    values.scheduledTransactions.141:
    + {"id":"0xf60ffd47f050d5cd5ed97b0225a01845d0bca8471dc0dc0e07f9968a4cf88901","decoded":{"chain":"arbitrum","contractName":"ArbOS61SettingsAction","function":"perform","inputs":[],"address":"arb1:0x9625eE87a85cF1D5EE31f0883df27A5c8770312E","calldata":"0xb147f40c","executor":"eth:0xCF57572261c7c2BCF21ffD220ea7d1a27D40A827","inboxOnEthereum":"eth:0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3f"},"raw":{"target":"eth:0xa723C008e76E379c55599D2E4d93879BeaFDa79C","value":0,"data":"0x0000000000000000000000004dbd4fc535ac27206064b68ffcf827b0a60bab3f000000000000000000000000cf57572261c7c2bcf21ffd220ea7d1a27d40a82700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000841cff79cd0000000000000000000000009625ee87a85cf1d5ee31f0883df27a5c8770312e00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000004b147f40c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","delay":259200}}
    values.scheduledTransactions.142:
    + {"id":"0xf60ffd47f050d5cd5ed97b0225a01845d0bca8471dc0dc0e07f9968a4cf88901","decoded":{"chain":"nova","address":"eth:0xd489C8512e3E82060873950c835f5ed1f06aBF84","calldata":"0xb147f40c","executor":"eth:0x86a02dD71363c440b21F4c0E5B2Ad01Ffe1A7482","inboxOnEthereum":"eth:0xc4448b71118c9071Bcb9734A0EAc55D18A153949"},"raw":{"target":"eth:0xa723C008e76E379c55599D2E4d93879BeaFDa79C","value":0,"data":"0x000000000000000000000000c4448b71118c9071bcb9734a0eac55d18a15394900000000000000000000000086a02dd71363c440b21f4c0e5b2ad01ffe1a748200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000841cff79cd000000000000000000000000d489c8512e3e82060873950c835f5ed1f06abf8400000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000004b147f40c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","delay":259200}}
    }

    Operator

    The system has a centralized sequencer

    While forcing transaction is open to anyone the system employs a privileged sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. that has priority for submitting transaction batches and ordering transactions.

    • MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

    1. Sequencer - Arbitrum documentation

    Users can force any transaction

    Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.

    1. SequencerInbox.sol - source code, forceInclusion function
    2. Sequencer Isn't Doing Its Job - Arbitrum documentation

    Sequencing

    Transactions are ordered by a centralized sequencer

    Arbitrum One uses a single centralized sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. for fast confirmations. Users can bypass it by first enqueueing a message on Ethereum. If the sequencer does not include it before the message-specific delay expires, anyone can submit a second Ethereum transaction to force the delayed queue into the canonical order.

    Buffered forced transactions

    To force transactions from the host chain, users must first enqueue “delayed” messages in the “delayed” inbox of the BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the sendMessage or sendMessageFromOrigin functions. If the centralized sequencer doesn’t process the request within some time bound, users can call the forceInclusion function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn’t timely process a message. Only messages processed with a delay greater than 30m consume the buffer. The buffer is capped at 2d. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 30m.

    Centralized sequencing spec sheet
    Trusted preconfirmation
    250 ms L2 block time
    Trusted ordering
    Fee order per 125 ms round
    Sequencer
    Redis HA
    Real-time censorship resistance
    Forced inclusion
    2 L1 txs: enqueue + force
    Inclusion delay
    150-7,200 L1 blocks
    Inclusion mechanics
    Address alias
    Exit delay
    1d inclusion + 14d 18h state
    Exit economics
    Favors defender 6.49×

    Censorship resistance

    The centralized sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. provides no real-time censorship resistance. The delayed inbox provides eventual censorship resistance, assuming Ethereum includes both the enqueue transaction and, when needed, the force-inclusion transaction.

    1. Arbitrum documentation - Sequencer and censorship resistance
    2. Arbitrum documentation - Priority Gas Auctions
    3. Arbitrum documentation - Fast Feed
    4. Arbitrum documentation - High-availability sequencer
    5. SequencerInbox - source code
    6. Inbox - source code

    Withdrawals

    Regular messaging

    The user initiates L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. messages by submitting a regular transaction on this chain. When the blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.

    1. Transaction lifecycle - Arbitrum documentation
    2. L2 to L1 Messages - Arbitrum documentation
    3. Mainnet for everyone - Arbitrum Blog

    Autonomous exit

    Users can (eventually) exit the system by pushing the transaction on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. and providing the corresponding state rootA cryptographic hash succinctly representing a state using a Merkle tree.. The only way to prevent such withdrawal is via an upgrade.

    Other considerations

    EVM compatible and Stylus smart contracts are supported

    Arbitrum One supports smart contracts written in Solidity and other programming languages (Rust, C++) that compile to WASM. Such smart contracts are executed by nodes using either a geth fork or a fork of wasmer inside the Nitro nodeA software client that participates in the network., and can be proven with the onchain WASM VM.

    1. Inside Arbitrum Nitro
    2. A gentle introduction: Stylus

    Arbitrum DAO is in charge of upgrades

    Arbitrum DAO allows $ARB token holders to propose and vote on changes to the organization and the technologies it governs. The governance smart contracts are implemented on Arbitrum One rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. chain. The DAO can upgrade the Arbitrum One contracts on L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. with 2d delay and - using L2 --> L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. Governance Relay, update contracts on L1 with additional 3d delay + 6d 8h delay for all L2 --> L1 messages (in total a delay of 11d 8h), with an additional 8d if a challenge has been present in the state rootA cryptographic hash succinctly representing a state using a Merkle tree. that relays the message. The Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. can upgrade the contracts without any delay. It can also cancel any upgrades initiated by the DAO.

    1. Arbitrum DAO

    Permissions

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Arbitrum One

    Actors:

    L2SecurityCouncilPropose0xADd6…a941

    A Multisig with 9/12 threshold. It uses the following modules: L2UpgradeExecutor (This contract can upgrade the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. system’s contracts through the L2ProxyAdmin. The upgrades can be done either by the Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. or by the L1Timelock (via its alias on L2)).

    • Can upgrade with 17d 8h delay
      • Outbox
      • SequencerInbox
      • UpgradeExecutor
      • Inbox
      • RollupProxy
      • RollupEventInbox
      • OutboxV0
      • GatewayRouter
      • OutboxV1
      • Bridge
      • L1ERC20Gateway
      • EdgeChallengeManager
      • L1ARBGateway
      • L1CustomGateway
      • L1WethGateway
      • L1Timelock
    • Can interact with L2Timelock
      • propose transactions
    • Can interact with SecurityCouncilManager
    • Can interact with RollupProxy
      • Pause and unpause and set important roles and parameters in the system contracts: Can delegate SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. management to a BatchPosterManager address, manage data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes with 17d 8h delay
    • Can interact with L1Timelock
      • cancel queued transactions with 17d 8h delay
      • propose transactions with 14d 8h delay
      • update the minimum delay and manage all access control roles of the timelock with 17d 8h delay

    Participants (12):

    0xEEFF…7C1E0xeEB8…8398DZack23PabloSabbatella-OpsekzachxbtImmunefiMichael Lewellen - blockaidgzeon-OffchainLabsEmilianoBonassi-ConduitGriffGreen-Givethbartek.eth-L2BEATyoav.eth-EF
    CoreGovernor0xf07D…95B9

    Token governance contract accepting and managing constitutional Arbitrum Improvement Proposals (AIPs, core proposals). Uses DVP-based quorum (percentage of Delegated Voting Power with floor and ceiling bounds).

    • Can upgrade with 17d 8h delay
      • Outbox
      • SequencerInbox
      • UpgradeExecutor
      • Inbox
      • RollupProxy
      • RollupEventInbox
      • OutboxV0
      • GatewayRouter
      • OutboxV1
      • Bridge
      • L1ERC20Gateway
      • EdgeChallengeManager
      • L1ARBGateway
      • L1CustomGateway
      • L1WethGateway
      • L1Timelock
    • Can interact with L2Timelock
      • cancel queued transactions
      • propose transactions
    • Can interact with RollupProxy
      • Pause and unpause and set important roles and parameters in the system contracts: Can delegate SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. management to a BatchPosterManager address, manage data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes with 17d 8h delay
    • Can interact with L1Timelock
      • cancel queued transactions with 17d 8h delay
      • propose transactions with 14d 8h delay
      • update the minimum delay and manage all access control roles of the timelock with 17d 8h delay
    L2SecurityCouncilEmergency0x4235…1641

    A Multisig with 9/12 threshold. It uses the following modules: L2UpgradeExecutor (This contract can upgrade the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. system’s contracts through the L2ProxyAdmin. The upgrades can be done either by the Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. or by the L1Timelock (via its alias on L2)).

    • Can upgrade with no delay
      • L2ERC20Gateway
      • L2Timelock
      • SecurityCouncilMemberElectionGovernor
      • L2GatewayRouter
      • L2WethGateway
      • SecurityCouncilMemberRemovalGovernor
      • TreasuryGovernor
      • L2WETH
      • SecurityCouncilNomineeElectionGovernor
      • L2ArbitrumToken
      • TreasuryTimelock
      • L2ARBGateway
      • L2UpgradeExecutor
      • SecurityCouncilManager
      • CoreGovernor
    • Can interact with L2Timelock
      • manage all access control roles and change the minimum delay with 8d delay
    • Can interact with SecurityCouncilManager
      • manage all access control roles
      • set the minimum period between Security Council member key rotations

    Participants (12):

    0xEEFF…7C1E0xeEB8…8398DZack23PabloSabbatella-OpsekzachxbtImmunefiMichael Lewellen - blockaidgzeon-OffchainLabsEmilianoBonassi-ConduitGriffGreen-Givethbartek.eth-L2BEATyoav.eth-EF
    SecurityCouncilMemberElectionGovernor0x4679…712C

    Token governance contract for the Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. member elections.

    • Can interact with SecurityCouncilManager
    SecurityCouncilMemberRemovalGovernor0x6f3a…15Ad

    Token governance contract for the Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. member removals.

    • Can interact with SecurityCouncilManager
    Arbitrum L2 Multisig 10xe128…553b

    A Multisig with 4/6 threshold.

    • Can interact with TipCollectionToggler
      • toggle the collection of priority fees (tips)
    • Can interact with BaseFeeManager
      • set the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. base fee and minimum base fee within 0.01-0.1 gwei
    • Can interact with ResourceConstraintManager
      • set the gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. pricing constraints of the L2 base fee model within hardcoded bounds

    Participants (6):

    0x3759…9Fe10xfE2b…158B0x6437…0Ee70x290A…14280x4d9A…f49C0x79D3…9fCe
    GnosisSafeL20xc610…380C

    A Multisig with 3/5 threshold.

    Participants (5):

    0xf3b0…07F60xa982…D57E0xc43a…44B10x0adc…50350xdE82…35C2
    L1Timelock_l2alias0xf795…905a
    • Can upgrade with no delay
      • L2ERC20Gateway
      • L2Timelock
      • SecurityCouncilMemberElectionGovernor
      • L2GatewayRouter
      • L2WethGateway
      • SecurityCouncilMemberRemovalGovernor
      • TreasuryGovernor
      • L2WETH
      • SecurityCouncilNomineeElectionGovernor
      • L2ArbitrumToken
      • TreasuryTimelock
      • L2ARBGateway
      • L2UpgradeExecutor
      • SecurityCouncilManager
      • CoreGovernor
    • Can interact with L2Timelock
      • manage all access control roles and change the minimum delay with 8d delay
    • Can interact with SecurityCouncilManager
      • manage all access control roles
      • set the minimum period between Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. member key rotations

    Ethereum

    Actors:

    Arbitrum Security Council0xF06E…3F85

    A Multisig with 9/12 threshold. It uses the following modules: UpgradeExecutor (Central contract defining the access control permissions for upgrading the system contract implementations).

    • Can upgrade with no delay
      • Outbox
      • SequencerInbox
      • UpgradeExecutor
      • Inbox
      • RollupProxy
      • RollupEventInbox
      • OutboxV0
      • GatewayRouter
      • OutboxV1
      • BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.
      • L1ERC20Gateway
      • EdgeChallengeManager
      • L1ARBGateway
      • L1CustomGateway
      • L1WethGateway
      • L1Timelock
    • Can interact with RollupProxy
      • Pause and unpause and set important roles and parameters in the system contracts: Can delegate SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. management to a BatchPosterManager address, manage data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes
    • Can interact with L1Timelock
      • cancel queued transactions
      • update the minimum delay and manage all access control roles of the timelock

    Participants (12):

    0xEEFF…7C1E0xeEB8…8398DZack23PabloSabbatella-OpsekzachxbtImmunefiMichael Lewellen - blockaidgzeon-OffchainLabsEmilianoBonassi-ConduitGriffGreen-Givethbartek.eth-L2BEATyoav.eth-EF
    Used in:
    1. Security Council members - Arbitrum Foundation Docs
    Arbitrum Multisig 10xd0FD…679B

    A Multisig with 4/6 threshold.

    • Can interact with SequencerInbox
      • Add/remove batchPosters (Sequencers)

    Participants (6):

    0x3759…9Fe10xfE2b…158B0x6437…0Ee70x290A…14280x4d9A…f49C0x79D3…9fCe
    Used in:
    3 EOAs
    EOA 1EOA 2EOA 3
    • Can interact with SequencerInbox
      • Can submit transaction batches or commitments to the SequencerInbox contract on the host chain

    Smart contracts

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    SequencerInbox0x1c47…82B6Implementation (Upgradable)Admin

    A sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. (registered in this contract) can submit transaction batches or commitments here.

    • Roles:
      • admin: ArbitrumProxyAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
      • batchPosterManager: Arbitrum Multisig 1
      • batchPosters: EOA 1, EOA 2, EOA 3
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    RollupProxy0x4DCe…Cfc0Implementation #1 (Upgradable)Implementation #2 (Upgradable)Admin

    Central contract for the project’s configuration like its execution logic hashA fixed-length fingerprint of variable-size input, produced by a hash function. (wasmModuleRoot) and addresses of the other system contracts. Entry point for Proposers creating new assertions (state commitments) and Challengers submitting fraud proofs (In the Orbit stack, these two roles are both called ValidatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier).

    • Roles:
      • admin: UpgradeExecutor; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
      • owner: UpgradeExecutor; ultimately Arbitrum Security Council, CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    Bridge
    Escrow
    0x8315…ed3aImplementation (Upgradable)Admin

    Escrow contract for the project’s gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. token (can be different from ETH). Keeps a list of allowed Inboxes and Outboxes for canonical bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. messaging.

    • Roles:
      • admin: ArbitrumProxyAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
      • mainOutboxAddress: Outbox
    The following tokens are included in the value secured calculation:
    ETH token logo
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    EdgeChallengeManager0xA556…9fB0Implementation (Upgradable)Admin

    Contract that implements the main challenge protocol logic of the fraud proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

    • Roles:
      • admin: ArbitrumProxyAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    UpgradeExecutor0x3ffF…CeDdImplementation (Upgradable)Admin

    Central contract defining the access control permissions for upgrading the system contract implementations.

    • Roles:
      • admin: UpgradeExecutorAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
      • executors: Arbitrum Security Council, L1Timelock
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Proxy used in:
    L1Timelock0xE684…7f49Implementation (Upgradable)Admin

    A timelock with access control. The current minimum delay is 3d. Proposals that passed their minimum delay can be executed by the anyone.

    • Roles:
      • admin: UpgradeExecutorAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
      • canceller: UpgradeExecutor; ultimately Arbitrum Security Council, CoreGovernor, L2SecurityCouncilPropose
      • proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.: BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.; ultimately CoreGovernor, L2SecurityCouncilPropose
      • timelockAdmin: UpgradeExecutor; ultimately Arbitrum Security Council, CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Used in:
    Outbox0x0B98…4840Implementation (Upgradable)Admin

    Facilitates L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. contract calls: Messages initiated from L2 (for example withdrawal messages) eventually resolve in execution on L1. Is also used to relay governance action messages from Arbitrum One to Ethereum, allowing the L2Timelock and its Governance actors on L2 to act as this address and inherit all its listed permissions.

    • Roles:
      • admin: ArbitrumProxyAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    Inbox0x4Dbd…AB3fImplementation (Upgradable)Admin

    Facilitates sending L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. messages like depositing ETH, but does not escrow funds.

    • Roles:
      • admin: ArbitrumProxyAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    L1ERC20Gateway
    Escrow
    0xa3A7…0EeCImplementation (Upgradable)Admin

    Escrows deposited ERC-20 assets for the canonical BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.. Upon depositing, a generic token representation will be minted at the destination. Withdrawals are initiated by the Outbox contract.

    • Roles:
      • admin: GatewaysAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose

    All supported tokens in this escrow are included in the value secured calculation.

    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    L1ARBGateway0xbbcE…dB27Implementation (Upgradable)Admin

    Canonical reverse gateway for ARB transfers between Ethereum and Arbitrum One.

    • Roles:
      • admin: UpgradeExecutorAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    L1WethGateway0xd920…e2dbImplementation (Upgradable)Admin

    Canonical WETH gateway escrowing L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. WETH and releasing it for withdrawals proven through the Arbitrum bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge..

    • Roles:
      • admin: GatewaysAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    wstETHEscrow
    Escrow
    0x0F25…8E5aImplementation (Upgradable)Admin
    The following tokens are included in the value secured calculation:
    wstETH token logo
    LPTL1Escrow
    Escrow
    0x6A23…210A
    The following tokens are included in the value secured calculation:
    LPT token logo
    GatewayRouter0x72Ce…31efImplementation (Upgradable)Admin

    This routing contract maps tokens to the correct escrow (gateway) to be then bridged with canonical messaging.

    • Roles:
      • admin: GatewaysAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    L1Escrow
    Escrow
    0xA10c…9400

    Simple escrow that accepts tokens and allows to configure permissioned addresses that can access the tokens.

    The following tokens are included in the value secured calculation:
    DAI token logo
    L1CustomGateway
    Escrow
    0xcEe2…180dImplementation (Upgradable)Admin

    Escrows deposited assets for the canonical bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. that are externally governed or need custom token contracts with e.g. minting rights or upgradeabilityThe ability for rollup smart contracts and parameters used in a rollup to be updated by holders of an admin key. Upgradeability represents a vector of risk for users, and should be decentralized and combined with time delays for greater security guarantees..

    • Roles:
      • admin: GatewaysAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose

    All supported tokens in this escrow are included in the value secured calculation.

    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    L1DaiGateway0xD3B5…3011

    Counterpart of the L2DaiGateway. Allows for bridging DAI from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..

    OneStepProver00x35FB…F731

    One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

    ParentToChildRewardRouter0x40Cd…C999

    Collects the excess stake when rival nodes are created and allows to send them to the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. treasury.

    OneStepProofEntry0x4397…42d6

    One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

    Implementation used in:
    RollupEventInbox0x57Bd…01B1Implementation (Upgradable)Admin

    Helper contract sending configuration data over the bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. during the systems initialization.

    • Roles:
      • admin: ArbitrumProxyAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    Implementation used in:
    OutboxV00x667e…337aImplementation (Upgradable)Admin
    • Roles:
      • admin: ArbitrumProxyAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    OutboxV10x7607…1A40Implementation (Upgradable)Admin
    • Roles:
      • admin: ArbitrumProxyAdmin; ultimately Arbitrum Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., CoreGovernor, L2SecurityCouncilPropose
    Can be upgraded by:
    L2SecurityCouncilPropose with 17d 8h delayCoreGovernor with 17d 8h delayArbitrum Security Council with no delay
    OneStepProverHostIo0xa07c…71Cf

    One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

    OneStepProverMath0xaB95…F921

    One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

    OneStepProverMemory0xe0ba…C48b

    One of the modular contracts used for the last step of a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system., which is simulated inside a WASM virtual machine.

    Arbitrum One

    L2Timelock0x34d4…98f0Implementation (Upgradable)Admin

    Delays constitutional AIPs from the CoreGovernor by 8d.

    • Roles:
      • admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
      • canceller: CoreGovernor
      • proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.: CoreGovernor, L2SecurityCouncilPropose, SecurityCouncilManager
      • timelockAdmin: L2UpgradeExecutor; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    TreasuryGovernor0x789f…e5a4Implementation (Upgradable)Admin

    Token governance contract used for creating non-constitutional AIPs (treasury proposals), e.g., transferring funds out of the DAO Treasury. Uses DVP-based quorum (percentage of Delegated Voting Power with floor and ceiling bounds).

    • Roles:
      • admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    SecurityCouncilNomineeElectionGovernor0x8a1c…05a0Implementation (Upgradable)Admin

    Token governance contract for the Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. nominee elections.

    • Roles:
      • admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    TreasuryTimelock0xbFc1…EF58Implementation (Upgradable)Admin

    Delays treasury proposals from the TreasuryGovernor by 259200 seconds. Is used as the main recipient for the ETH from L2SurplusFee and L2BaseFee contracts.

    • Roles:
      • admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    L2UpgradeExecutor0xCF57…A827Implementation (Upgradable)Admin

    This contract can upgrade the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. system’s contracts through the L2ProxyAdmin. The upgrades can be done either by the Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. or by the L1Timelock (via its alias on L2).

    • Roles:
      • admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
      • executors: L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    SecurityCouncilManager0xD509…eDFCImplementation (Upgradable)Admin

    This contract enforces the rules for changing members and cohorts of the SecurityCouncil and creates crosschain messages to Ethereum and Arbitrum Nova to keep the configuration in sync.

    • Roles:
      • admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
      • cohortReplacer: SecurityCouncilMemberElectionGovernor
      • defaultAdmin: L2UpgradeExecutor; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
      • memberAdder: L2SecurityCouncilPropose
      • memberRemover: L2SecurityCouncilPropose, SecurityCouncilMemberRemovalGovernor
      • memberReplacer: L2SecurityCouncilPropose
      • memberRotator: L2SecurityCouncilPropose
      • minRotationPeriodSetter: L2UpgradeExecutor; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    L2ERC20Gateway0x09e9…1EEeImplementation (Upgradable)Admin

    Counterpart to the L1ERC20Gateway. Can mint (deposit to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.) and burn (withdraw to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.) ERC20 tokens on L2.

    • Roles:
      • admin: L2GatewaysProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    L2GatewayRouter0x5288…F933Implementation (Upgradable)Admin

    Router managing token <–> gateway mapping on L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..

    • Roles:
      • admin: L2GatewaysProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    L2WethGateway0x6c41…623BImplementation (Upgradable)Admin

    Counterpart to the BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. Mints and burns WETH on L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..

    • Roles:
      • admin: L2GatewaysProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    L2WETH0x82aF…Bab1Implementation (Upgradable)Admin

    Canonical upgradeable WETH token burned by L2WethGateway when withdrawing against the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. WETH escrow.

    • Roles:
      • admin: L2GatewaysProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    L2ARBGateway0xCaD7…4D8EImplementation (Upgradable)Admin

    ARB sent from L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. is escrowed in this contract and minted on L1.

    • Roles:
      • admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    L2DAIGateway0x4671…6C65

    Counterpart to the L1DaiGateway. Can mint (deposit to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.) and burn (withdraw to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.) DAI tokens on L2.

    L2LPTGateway0x6D24…D318

    Counterpart to the L1LPTGateway. Can mint (deposit to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.) and burn (withdraw to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.) LPT on L2.

    ArbFilteredTransactionsManager0x0000…0074

    ArbOS 61 transaction-filtering precompile (0x…74). An authorized filterer registers tx hashes here; the state transition function then forcibly fails those transactions, including force-included ones, without delay. Available from ArbOS 61 onwards. On chains where the feature is not enabled (e.g. Arbitrum One and Nova) it has no filterers and no filtered transactions, but is tracked so any future activation is caught immediately. Compare Robinhood, where this precompile is active.

    1. Source Code
    ConstitutionHash0x1D62…0417

    Keeps the current hashA fixed-length fingerprint of variable-size input, produced by a hash function. of the ArbitrumDAO Constitution. Settable by the L2UpgradeExecutor.

    L2SurplusFee0x32e7…6b1d

    This contract receives all SurplusFees: Transaction fee component that covers the cost beyond that covered by the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Base Fee during chain congestion. It also receives the priority fees (tips) collected while ArbOS tip collection is enabled. They are withdrawable to a configurable set of recipients.

    StandardArbERC200x3f77…aD46
    BeaconProxyFactory0x3fE3…000f
    TipCollectionToggler0x4323…6a63

    ArbOS chain owner that can only toggle the collection of priority fees (tips), which enables PGA transaction ordering. Anyone can remove it from the chain owners after the expiry timestamp.

    • Roles:
      • tipCollectionManagers: Arbitrum L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Multisig 1
    BaseFeeManager0x6e03…529A

    ArbOS chain owner that can only set the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. base fee and minimum base fee within 0.01-0.1 gwei. Anyone can remove it from the chain owners after the expiry timestamp.

    • Roles:
      • baseFeeManagers: Arbitrum L2 Multisig 1
    UpgradeExecRouteBuilder0x7481…4C0a
    ResourceConstraintManager0x8F59…823a

    ArbOS chain owner that can only set the gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. pricing constraints of the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. base fee model within hardcoded bounds. Anyone can remove it from the chain owners after the expiry timestamp.

    • Roles:
      • resourceConstraintManagers: Arbitrum L2 Multisig 1
    L2ArbitrumToken0x912C…6548Implementation (Upgradable)Admin

    The ARB token contract. Supply can be increased by the owner once per year by a maximum of 2%.

    • Roles:
      • admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
    Can be upgraded by:
    L2SecurityCouncilEmergency with no delayL1Timelock_l2alias with no delay
    SecurityCouncilMemberSyncAction0x9BF7…297a

    Contract used by the security councilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. management system to sync SecurityCouncil members between the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. and the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..

    L2BaseFee0xbF50…b649

    This contract receives all BaseFees: The transaction fee component that covers the minimum cost of Arbitrum transaction execution. They are withdrawable to a configurable set of recipients.

    L2GatewaysProxyAdmin0xd570…2a86
    • Roles:
      • owner: L2UpgradeExecutor
    L2ProxyAdmin0xdb21…961e
    • Roles:
      • owner: L2UpgradeExecutor
    UpgradeableBeacon0xE72b…7333

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is a 17d 8h delay on code upgrades unless upgrade is initiated by the Security Council in which case there is no delay.

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0xc10c...dc97
    Github
    Arbitrum One logoRobinhood Chain logoArbitrum Nova logo