Arbitrum One
Badges
About
Arbitrum One is a general-purpose Optimistic Rollup built by Offchain Labs and governed by the Arbitrum DAO.
$17.11 B
3.74%
- Fraud proof submission is open only to whitelisted actors.
- Upgrades unrelated to on-chain provable bugs provide less than 30d to exit.
- The Security Council's actions are not confined to on-chain provable bugs.
Badges
About
Arbitrum One is a general-purpose Optimistic Rollup built by Offchain Labs and governed by the Arbitrum DAO.
...
Choose token
Arbitrum (ARB)
USD Coin (USDC)
GMX (GMX)
LayerZero (ZRO)
Radiant (RDNT)
Xai (XAI)
Gains Network (GNS)
DMT (DMT)
Frax (FRAX)
TapToken (TAP)
MXC Token (MXC)
Camelot token (GRAIL)
Frax Ether (frxETH)
MOR (MOR)
WINR (WINR)
Graph Token (GRT)
Renzo Restaked ETH (ezETH)
KelpDao Restaked ETH (rsETH)
USDe (USDe)
ether.fi governance token (ETHFI)
JoeToken (JOE)
StargateToken (STG)
SmarDex Token (SDEX)
Gho Token (GHO)
beefy.finance (BIFI)
Bitcoin (BTC.b)
Staked USDe (sUSDe)
Ether (ETH)
Tether USD (USDT)
Wrapped BTC (WBTC)
Wrapped eETH (weETH)
Wrapped liquid staked Ether 2.0 (wstETH)USD Coin (USDC.e)
MAGIC (MAGIC)
Vertex (VRTX)
Livepeer Token (LPT)
Pendle (PENDLE)
ChainLink Token (LINK)
Dai Stablecoin (DAI)
Marlin POND (POND)
Rocket Pool ETH (rETH)
MUX Protocol (MCB)...
...
Nitro Upgrade
2022 Aug 31st
Upgrade is live, introducing new architecture, increased throughput and lower fees.
Odyssey paused
2022 Jun 29th
Due of the heavy load being put on the chain, Odyssey program got paused.
Mainnet for everyone
2021 Aug 31st
Whitelist got removed, there are no restrictions on who can transact with the network.
Funds can be stolen if
- none of the whitelisted verifiers checks the published state. Fraud proofs assume at least one honest and able validator (CRITICAL),
- a contract receives a malicious code upgrade. There is a 12d 8h delay on code upgrades,
- a contract receives a malicious code upgrade. There is a 12 days delay on code upgrades unless upgrade is initiated by the Security Council in which case there is no delay.
Funds can be lost if
MEV can be extracted if
State validation
Fraud proofs (INT)Fraud proofs allow 14 WHITELISTED actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve. There is a 6d 8h challenge period.
Exit window
2dUpgrades are initiated on L2 and have to go first through a 3d delay. Since there is a 1d to force a tx, users have only 2d to exit. If users post a tx after that time, they would need to self propose a root with a 6d 8h delay and then wait for the 6d 8h challenge window, while the upgrade would be confirmed just after the 6d 8h challenge window and the 3d L1 timelock.
Sequencer failure
Self sequenceProposer failure
Self proposeAnyone can become a Proposer after 6d 8h of inactivity from the currently whitelisted Proposers.
Arbitrum One is a - The project calls itself a rollup.
- L2 state roots are posted to Ethereum L1.
- Inputs for the state transition function are posted to L1.
- A source-available node exists that can recreate the state from L1 data. Please note that the L2BEAT team has not verified the validity of the node source code. View code
- A complete and functional proof system is deployed.
- There are at least 5 external actors who can submit fraud proofs.
- Users are able to exit without the help of the permissioned operators.
- In case of an unwanted upgrade by actors more centralized than a Security Council, users have at least 7d to exit.
- The Security Council is properly set up.
- Fraud proof submission is open only to whitelisted actors.
- Upgrades unrelated to on-chain provable bugs provide less than 30d to exit.
- The Security Council’s actions are not confined to on-chain provable bugs.
Fraud proofs ensure state correctness
After some period of time, the published state root is assumed to be correct. For a certain time period, one of the whitelisted actors can submit a fraud proof that shows that the state was incorrect. The challenge protocol can be subject to delay attacks.
Funds can be stolen if none of the whitelisted verifiers checks the published state. Fraud proofs assume at least one honest and able validator (CRITICAL).
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.
The rollup node (Arbitrum Nitro) consists of three 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. 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.
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-chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract directly. Anyone can become a Proposer after approximately 6d 8h (45818 blocks) of inactivity from the currently whitelisted Proposers.
Regular exit
The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. The process of block finalization usually takes several days to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.
Tradeable Bridge Exit
When a user initiates a regular withdrawal a third party verifying the chain can offer to buy this withdrawal by paying the user on L1. The user will get the funds immediately, however the third party has to wait for the block to be finalized. This is implemented as a first party functionality inside Arbitrum’s token bridge.
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 smart contracts are supported
Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.
Funds can be lost if there are mistakes in the highly complex Nitro and WASM one-step prover implementation.
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 3d 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 12d 8h). The Security Council can upgrade the contracts without any delay. It can also cancel any upgrades initiated by the DAO.
Funds can be stolen if a contract receives a malicious code upgrade. There is a 12d 8h delay on code upgrades.
The system uses the following set of permissioned addresses:
Central actors allowed to submit transaction batches to L1.
They can submit new state roots and challenge state roots. Some of the operators perform their duties through special purpose smart contracts.
The admin of all contracts in the system, capable of issuing upgrades without notice and delay. This allows it to censor transactions and to upgrade the bridge implementation, potentially gaining access to all funds stored in the bridge and change the sequencer or any other system component (unlimited upgrade power). It is also the admin of the special purpose smart contracts used by validators. This is a Gnosis Safe with 9 / 12 threshold. It uses the following modules: UpgradeExecutor.
Used in:
Those are the participants of the SecurityCouncil.
It can update whether an address is authorized to be a batch poster at the sequencer inbox. The UpgradeExecutor retains the ability to update the batch poster manager (along with any batch posters). This is a Gnosis Safe with 4 / 6 threshold.
Used in:
Those are the participants of the BatchPosterManagerMultisig.
It gives the DAO participants on the L2 the ability to upgrade the system. Only the L2 counterpart of this contract can execute the upgrades.
Used in:
The system consists of the following permissions on Arbitrum One:
The elected signers for the Arbitrum SecurityCouncil can act through this multisig on Layer2, permissioned to upgrade all system contracts without delay. This is a Gnosis Safe with 9 / 12 threshold. It uses the following modules: L2UpgradeExecutor.
Those are the participants of the L2SecurityCouncilEmergency.
The elected signers for the Arbitrum SecurityCouncil can act through this multisig on Layer2 to propose transactions in the L2CoreTimelock (e.g. upgrade proposals). This is a Gnosis Safe with 9 / 12 threshold. It uses the following modules: L2UpgradeExecutor.
Those are the participants of the L2SecurityCouncilPropose.
The system consists of the following smart contracts on the host chain (Ethereum):
Main contract implementing Arbitrum One Rollup. Manages other Rollup components, list of Stakers and Validators. Entry point for Validators creating new Rollup Nodes (state commits) and Challengers submitting fraud proofs.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Implementation used in:
Contract managing Inboxes and Outboxes. It escrows ETH sent to L2. This contract stores the following tokens: ETH.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Implementation used in:
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Implementation used in:
This contract can upgrade the system’s contracts. The upgrades can be done either by the Security Council or by the L1ArbitrumTimelock.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Proxy used in:
Timelock contract for Arbitrum DAO Governance. It gives the DAO participants the ability to upgrade the system. Only the L2 counterpart of this contract can execute the upgrades.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Proxy used in:
Router managing token <–> gateway mapping.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Implementation used in:
Contract that allows challenging invalid state roots. Can be called through the RollupProxy.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Implementation used in:
Contract used to perform the last step of a fraud proof.
Implementation used in:
Contract used to perform the last step of a fraud proof.
Implementation used in:
Contract used to perform the last step of a fraud proof.
Implementation used in:
Contract used to perform the last step of a fraud proof.
Implementation used in:
Contract used to perform the last step of a fraud proof.
Implementation used in:
The system consists of the following smart contracts on Arbitrum One:
Governance contract accepting and managing constitutional Arbitrum Improvement Proposals (AIPs, core proposals) and, among other formal parameters, enforcing the 5% quorum for proposals.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Delays constitutional AIPs from the CoreGovernor by 3d.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
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.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Delays treasury proposals from the TreasuryGovernor by 3d.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
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 L1ArbitrumTimelock (via its alias on L2).
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
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.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Keeps the current hash of the ArbitrumDAO Constitution. Settable by the L2UpgradeExecutor.
The owner (UpgradeExecutor) can upgrade proxies’ implementations of all L2 system contracts through this contract.
The owner (UpgradeExecutor) can upgrade proxies’ implementations of all L2 bridging gateway contracts through this contract.
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.
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%.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Router managing token <–> gateway mapping on L2.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Value Locked is calculated based on these smart contracts and tokens:
Main entry point for users depositing ERC20 tokens that require minting custom token on L2.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Main entry point for users depositing ERC20 tokens. Upon depositing, on L2 a generic, “wrapped” token will be minted.
Upgrade delay: 12d 8h or 0 if overridden by the Security Council
Contract managing Inboxes and Outboxes. It escrows ETH sent to L2.
Upgrade delay: No delay
Implementation used in:
DAI Vault for custom DAI Gateway. Fully controlled by MakerDAO governance.
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 12 days delay on code upgrades unless upgrade is initiated by the Security Council in which case there is no delay.
