Search
Search for projects by name
Arbitrum One
Badges
About
Arbitrum One is a general-purpose Optimistic Rollup built by Offchain Labs and governed by the Arbitrum DAO.
Badges
About
Arbitrum One is a general-purpose Optimistic Rollup built by Offchain Labs and governed by the Arbitrum DAO.
2024 Jul 14 — 2025 Jul 14
2024 Jul 14 — 2025 Jul 13
The section shows the operating costs that L2s pay to Ethereum.
2024 Jul 14 — 2025 Jul 13
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.
2025 Jun 14 — Jul 14
Funds can be stolen if
MEV can be extracted if
Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve.
All of the data needed for proof construction is published on Ethereum L1.
Non-emergency upgrades are initiated on L2 and go through a 8d delay on L2 and a 3d delay on L1. Since there is a 1d delay to force a tx (forcing the inclusion in the following state update), users have 10d to exit.
Arbitrum One is a 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 blobs or calldata. This ensures that it will be available for enough time.
- Sequencing followed by deterministic execution - Arbitrum documentation
- SequencerInbox.sol - source code, addSequencerL2BatchFromOrigin function
EthereumThe rollup node (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 2 functionalities such as decompressing data batches, accounting for Layer 1 gas costs, and supporting cross-chain bridge functionalities. The top layer consists of node software, primarily from Geth, that handles client connections (i.e., regular RPC node). View Code
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.
Nitro supports Ethereum’s data structures and formats by incorporating the core code of the popular go-ethereum (“Geth”) Ethereum node software. The batch is composed of a header and a compressed blob, which results from compressing concatenated RLP-encoded transactions using the standard RLP encoding.
Updates to the system state can be proposed and challenged by anyone who has sufficient funds. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.
Validators propose state roots 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 node 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 proof. 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 period 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.
A challenge can be started between two siblings, i.e. two different state roots 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 blocks, 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.
The system has a centralized sequencer
While forcing transaction is open to anyone the system employs a privileged sequencer 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.
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 Sequencer 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.
Buffered forced transactions
To force transactions from the host chain, users must first enqueue “delayed” messages in the “delayed” inbox of the 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.
Regular messaging
Autonomous exit
Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.
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 node, and can be proven with the onchain WASM VM.
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 rollup chain. The DAO can upgrade the Arbitrum One contracts on L2 with 8d delay and - using L2 --> L1 Governance Relay, update contracts on L1 with additional 3d delay + 6d 8h delay for all L2 --> L1 messages (in total a delay of 17d 8h). The Security Council can upgrade the contracts without any delay. It can also cancel any upgrades initiated by the DAO.
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 Council. The Arbitrum DAO controls Arbitrum One and Arbitrum Nova through upgrades and modifications to their smart contracts on Layer 1 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 (Proposer-) 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 L2 Timelock. The proposer Security Council can do this directly and the Arbitrum DAO (ARB token holders and delegates) must meet a CoreGovernor-enforced 5% 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 period) of 6d 8h. 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 bridge and the aliased address of the L1 Timelock.
Operator roles like the Sequencers and Validators are managed using the same paths. Sequencer 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 3% 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.
Ethereum
Roles:
Can submit transaction batches or commitments to the SequencerInbox contract on the host chain.
Actors:
A Multisig with 4/6 threshold.
- Can interact with SequencerInbox
- Add/remove batchPosters (Sequencers)
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 UpgradeExecutor → ArbitrumProxyAdmin
- SequencerInbox UpgradeExecutor → ArbitrumProxyAdmin
- UpgradeExecutor UpgradeExecutor → UpgradeExecutorAdmin
- Inbox UpgradeExecutor → ArbitrumProxyAdmin
- RollupProxy UpgradeExecutor
- RollupEventInbox UpgradeExecutor → ArbitrumProxyAdmin
- OutboxV0 UpgradeExecutor → ArbitrumProxyAdmin
- GatewayRouter UpgradeExecutor → GatewaysAdmin
- OutboxV1 UpgradeExecutor → ArbitrumProxyAdmin
- Bridge UpgradeExecutor → ArbitrumProxyAdmin
- L1ERC20Gateway UpgradeExecutor → GatewaysAdmin
- EdgeChallengeManager UpgradeExecutor → ArbitrumProxyAdmin
- L1CustomGateway UpgradeExecutor → GatewaysAdmin
- L1Timelock UpgradeExecutor → UpgradeExecutorAdmin
- Can interact with RollupProxy
- Pause and unpause and set important roles and parameters in the system contracts: Can delegate Sequencer management to a BatchPosterManager address, manage data availability and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes UpgradeExecutor
- Can interact with L1Timelock
- cancel queued transactions UpgradeExecutor
- update the minimum delay and manage all access control roles of the timelock UpgradeExecutor
Participants (12):
fred - Arbitrum 2Michael Lewellen - blockaidCertora 2DennisonBertram-TallyJohnMorrow-GauntletGoncaloMagalhaes-Immunefigzeon-OffchainLabsEmilianoBonassi-ConduitGriffGreen-GivethStevenThornton-OpenZeppelinbartek.eth-L2BEATyoav.eth-EFArbitrum One
Actors:
A Multisig with 9/12 threshold. It uses the following modules: L2UpgradeExecutor (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)).
- Can upgrade with no delay
- L2ERC20Gateway L2UpgradeExecutor → L2GatewaysProxyAdmin
- L2Timelock L2UpgradeExecutor → L2ProxyAdmin
- SecurityCouncilMemberElectionGovernor L2UpgradeExecutor → L2ProxyAdmin
- L2GatewayRouter L2UpgradeExecutor → L2GatewaysProxyAdmin
- L2WethGateway L2UpgradeExecutor → L2GatewaysProxyAdmin
- SecurityCouncilMemberRemovalGovernor L2UpgradeExecutor → L2ProxyAdmin
- TreasuryGovernor L2UpgradeExecutor → L2ProxyAdmin
- SecurityCouncilNomineeElectionGovernor L2UpgradeExecutor → L2ProxyAdmin
- L2ArbitrumToken L2UpgradeExecutor → L2ProxyAdmin
- TreasuryTimelock L2UpgradeExecutor → L2ProxyAdmin
- L2ARBGateway L2UpgradeExecutor → L2ProxyAdmin
- L2UpgradeExecutor L2UpgradeExecutor → L2ProxyAdmin
- SecurityCouncilManager L2UpgradeExecutor → L2ProxyAdmin
- CoreGovernor L2UpgradeExecutor → L2ProxyAdmin
- Can interact with L2Timelock
- manage all access control roles and change the minimum delay with 8d delay L2UpgradeExecutor with 8d delay
- Can interact with SecurityCouncilManager
- manage all access control roles L2UpgradeExecutor
Token governance contract for the Security Council member elections.
- Can interact with SecurityCouncilManager
- schedule a proposal to replace a Security Council member cohort
Token governance contract for the Security Council member removals.
- Can interact with SecurityCouncilManager
- schedule a proposal to remove a Security Council member
A Multisig with 9/12 threshold. It uses the following modules: L2UpgradeExecutor (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)).
- Can upgrade with 17d 8h delay
- Outbox L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- SequencerInbox L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- UpgradeExecutor L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → UpgradeExecutorAdmin
- Inbox L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- RollupProxy L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor
- RollupEventInbox L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- OutboxV0 L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- GatewayRouter L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → GatewaysAdmin
- OutboxV1 L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- Bridge L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- L1ERC20Gateway L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → GatewaysAdmin
- EdgeChallengeManager L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- L1CustomGateway L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → GatewaysAdmin
- L1Timelock L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → UpgradeExecutorAdmin
- Can interact with L2Timelock
- propose transactions
- Can interact with SecurityCouncilManager
- schedule a proposal to add a new member to the Security Council
- schedule a proposal to remove a Security Council member
- schedule a proposal to replace a Security Council member
- schedule a proposal to rotate a Security Council member (same member, new address)
- Can interact with RollupProxy
- Pause and unpause and set important roles and parameters in the system contracts: Can delegate Sequencer management to a BatchPosterManager address, manage data availability and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes with 17d 8h delay L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor
- Can interact with L1Timelock
- cancel queued transactions with 17d 8h delay L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor
- propose transactions with 14d 8h delay L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge
- update the minimum delay and manage all access control roles of the timelock with 17d 8h delay L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor
Token governance contract accepting and managing constitutional Arbitrum Improvement Proposals (AIPs, core proposals) and, among other formal parameters, enforcing the 5% quorum for proposals.
- Can upgrade with 17d 8h delay
- Outbox L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- SequencerInbox L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- UpgradeExecutor L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → UpgradeExecutorAdmin
- Inbox L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- RollupProxy L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor
- RollupEventInbox L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- OutboxV0 L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- GatewayRouter L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → GatewaysAdmin
- OutboxV1 L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- Bridge L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- L1ERC20Gateway L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → GatewaysAdmin
- EdgeChallengeManager L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → ArbitrumProxyAdmin
- L1CustomGateway L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → GatewaysAdmin
- L1Timelock L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor → UpgradeExecutorAdmin
- 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 Sequencer management to a BatchPosterManager address, manage data availability and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes with 17d 8h delay L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor
- Can interact with L1Timelock
- cancel queued transactions with 17d 8h delay L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor
- propose transactions with 14d 8h delay L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge
- update the minimum delay and manage all access control roles of the timelock with 17d 8h delay L2Timelock with 8d delay → Outbox with 6d 8h delay → Bridge → L1Timelock with 3d delay → UpgradeExecutor
A Multisig with 3/5 threshold.
- Can upgrade with no delay
- L2ERC20Gateway L2UpgradeExecutor → L2GatewaysProxyAdmin
- L2Timelock L2UpgradeExecutor → L2ProxyAdmin
- SecurityCouncilMemberElectionGovernor L2UpgradeExecutor → L2ProxyAdmin
- L2GatewayRouter L2UpgradeExecutor → L2GatewaysProxyAdmin
- L2WethGateway L2UpgradeExecutor → L2GatewaysProxyAdmin
- SecurityCouncilMemberRemovalGovernor L2UpgradeExecutor → L2ProxyAdmin
- TreasuryGovernor L2UpgradeExecutor → L2ProxyAdmin
- SecurityCouncilNomineeElectionGovernor L2UpgradeExecutor → L2ProxyAdmin
- L2ArbitrumToken L2UpgradeExecutor → L2ProxyAdmin
- TreasuryTimelock L2UpgradeExecutor → L2ProxyAdmin
- L2ARBGateway L2UpgradeExecutor → L2ProxyAdmin
- L2UpgradeExecutor L2UpgradeExecutor → L2ProxyAdmin
- SecurityCouncilManager L2UpgradeExecutor → L2ProxyAdmin
- CoreGovernor L2UpgradeExecutor → L2ProxyAdmin
- Can interact with L2Timelock
- manage all access control roles and change the minimum delay with 8d delay L2UpgradeExecutor with 8d delay
- Can interact with SecurityCouncilManager
- manage all access control roles L2UpgradeExecutor
Ethereum
A sequencer (registered in this contract) can submit transaction batches or commitments here.
- Roles:
- admin: ArbitrumProxyAdmin; ultimately Arbitrum Security Council
- batchPosterManager: Arbitrum Multisig 1
- batchPosters: EOA 1, EOA 2, EOA 3
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).
- Roles:
- admin: UpgradeExecutor; ultimately Arbitrum Security Council
- owner: UpgradeExecutor; ultimately Arbitrum Security Council
Escrow contract for the project’s gas token (can be different from ETH). Keeps a list of allowed Inboxes and Outboxes for canonical bridge messaging.
- Roles:
- admin: ArbitrumProxyAdmin; ultimately Arbitrum Security Council
- mainOutboxAddress: Outbox
- This contract stores the following tokens: ETH.
Contract that implements the main challenge protocol logic of the fraud proof system.
- Roles:
- admin: ArbitrumProxyAdmin; ultimately Arbitrum Security Council
Central contract defining the access control permissions for upgrading the system contract implementations.
- Roles:
- admin: UpgradeExecutorAdmin; ultimately Arbitrum Security Council
- executors: Arbitrum Security Council, L1Timelock
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 Council
- canceller: UpgradeExecutor; ultimately Arbitrum Security Council
- proposer: Bridge
- timelockAdmin: UpgradeExecutor; ultimately Arbitrum Security Council
Facilitates L2 to L1 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 Council
Facilitates sending L1 to L2 messages like depositing ETH, but does not escrow funds.
- Roles:
- admin: ArbitrumProxyAdmin; ultimately Arbitrum Security Council
Escrows deposited ERC-20 assets for the canonical 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 Council
- This contract can store any token.
This contract stores the following tokens: wstETH.
This contract stores the following tokens: LPT.
This routing contract maps tokens to the correct escrow (gateway) to be then bridged with canonical messaging.
- Roles:
- admin: GatewaysAdmin; ultimately Arbitrum Security Council
Simple escrow that accepts tokens and allows to configure permissioned addresses that can access the tokens.
- This contract stores the following tokens: DAI, USDS, sUSDS.
Escrows deposited assets for the canonical bridge that are externally governed or need custom token contracts with e.g. minting rights or upgradeability.
- Roles:
- admin: GatewaysAdmin; ultimately Arbitrum Security Council
- This contract can store any token.
One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
Collects the excess stake when rival nodes are created and allows to send them to the L2 treasury.
One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
Helper contract sending configuration data over the bridge during the systems initialization.
- Roles:
- admin: ArbitrumProxyAdmin; ultimately Arbitrum Security Council
- Roles:
- admin: ArbitrumProxyAdmin; ultimately Arbitrum Security Council
- Roles:
- admin: ArbitrumProxyAdmin; ultimately Arbitrum Security Council
One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
One of the modular contracts used for the last step of a fraud proof, which is simulated inside a WASM virtual machine.
Arbitrum One
Delays constitutional AIPs from the CoreGovernor by 8d.
- Roles:
- admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
- canceller: CoreGovernor
- proposer: CoreGovernor, L2SecurityCouncilPropose, SecurityCouncilManager
- timelockAdmin: L2UpgradeExecutor; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
Token governance contract used for creating non-constitutional AIPs, or “treasury proposals”, e.g., transferring founds out of the DAO Treasury. Also enforces the 3% quorum for proposals.
- Roles:
- admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
Token governance contract for the Security Council nominee elections.
- Roles:
- admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
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
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).
- Roles:
- admin: L2ProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
- executors: L1Timelock_l2alias, L2SecurityCouncilEmergency
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
Router managing token <–> gateway mapping on L2.
- Roles:
- admin: L2GatewaysProxyAdmin; ultimately L1Timelock_l2alias, L2SecurityCouncilEmergency
Keeps the current hash of the ArbitrumDAO Constitution. Settable by the L2UpgradeExecutor.
This contract receives all SurplusFees: Transaction fee component that covers the cost beyond that covered by the L2 Base Fee during chain congestion. They are withdrawable to a configurable set of recipients.
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
Contract used by the security council management system to sync SecurityCouncil members between the L1 and the L2.
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.
- Roles:
- owner: L2UpgradeExecutor
- Roles:
- owner: L2UpgradeExecutor
Value Secured is calculated based on these smart contracts and tokens:
Main entry point for users depositing ERC20 tokens that require minting custom tokens on L2.
Main entry point for users depositing ERC20 tokens. Upon depositing, on L2 a generic, “wrapped” token will be minted.
Maker/Sky-controlled vault for DAI, USDS and sUSDS bridged with canonical messaging.
Contract managing Inboxes and Outboxes. It escrows ETH sent to L2.
wstETH Vault for custom wstETH Gateway. Fully controlled by Lido governance.
LPT Vault for custom Livepeer Token Gateway.
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.