{
"architectureImage": "orbit-optimium",
"dataAvailability": [
{
"name": "Data is not stored on chain",
"description": "Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will \"fall back to rollup\" mode and by posting the full data directly to the L1 chain. The current DAC threshold is 5 out of 6.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the external data becomes unavailable.",
"isCritical": true
},
{
"category": "Users can be censored if",
"text": "the committee restricts their access to the external data."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum documentation",
"url": "https://developer.offchainlabs.com/inside-anytrust"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
"risks": [],
"references": [
{
"title": "Transaction lifecycle - Arbitrum documentation",
"url": "https://developer.offchainlabs.com/tx-lifecycle"
},
{
"title": "L2 to L1 Messages - Arbitrum documentation",
"url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging"
},
{
"title": "Mainnet for everyone - Arbitrum Blog",
"url": "https://offchain.medium.com/mainnet-for-everyone-27ce0f67c85e"
}
]
},
{
"name": "Autonomous exit",
"description": "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.",
"risks": [],
"references": []
}
],
"forceTransactions": {
"name": "Users can force any transaction",
"description": "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.",
"risks": [],
"references": [
{
"title": "SequencerInbox.sol - source code, forceInclusion function",
"url": "https://etherscan.io/address/0x98a58ADAb0f8A66A1BF4544d804bc0475dff32c7#code"
},
{
"title": "Sequencer Isn't Doing Its Job - Arbitrum documentation",
"url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job"
}
]
},
"operator": {
"name": "The system has a centralized sequencer",
"description": "While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": [
{
"title": "Sequencer - Arbitrum documentation",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#the-sequencer"
}
]
},
"otherConsiderations": [
{
"name": "EVM compatible and Stylus smart contracts are supported",
"description": "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](https://github.com/OffchainLabs/wasmer) inside the Nitro node, and can be proven with the onchain WASM VM.",
"risks": [],
"references": [
{
"title": "Inside Arbitrum Nitro",
"url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/"
},
{
"title": "A gentle introduction: Stylus",
"url": "https://docs.arbitrum.io/stylus/stylus-gentle-introduction"
}
]
},
{
"name": "Arbitrum DAO is in charge of upgrades",
"description": "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 2d 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 11d 8h), with an additional 8d if a challenge has been present in the state root that relays the message. The Security Council can upgrade the contracts without any delay. It can also cancel any upgrades initiated by the DAO.",
"risks": [],
"references": [
{
"title": "Arbitrum DAO",
"url": "https://docs.arbitrum.foundation/concepts/arbitrum-dao"
}
]
}
],
"sequencing": {
"name": "Buffered forced transactions",
"description": "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 1h 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 1h.",
"references": [
{
"title": "Sequencer and censorship resistance - Arbitrum documentation",
"url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
}
],
"risks": []
},
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
"categories": [
{
"title": "State root proposals",
"description": "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 1.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.",
"risks": [],
"references": [
{
"title": "BoLD paper",
"url": "https://arxiv.org/pdf/2404.10491"
}
]
},
{
"title": "Challenges",
"description": "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 1.0 ETH, level 2 requires a stake of 1.0 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an attacker successfully performs a resource exhaustion attack."
}
],
"references": [
{
"title": "Fraud Proof Wars: Arbitrum BoLD",
"url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
}
]
}
]
},
"stateValidationImage": "bold",
"upgradesAndGovernance": {
"content": "All critical system smart contracts are upgradeable (can be arbitrarily changed). This permission is governed by the Arbitrum Decentralized Autonomous Organization (DAO)\nand 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.\nWhile the DAO governs through token-weighted governance in their associated ARB token, the Security Council can directly act through\nmultisigs on all three chains. Although they are technically separate and connect to different target permissions,\ntheir member- and threshold configuration is kept in sync by a manager contract on Arbitrum One sending crosschain transactions.\n\nRegular upgrades, Admin- and Owner actions originate from either the Arbitrum DAO or the non-emergency (Proposer-) Security Council on Arbitrum One\nand pass through multiple delays and timelocks before being executed at their destination. Contrarily, the three Emergency Security Council multisigs\n(one on each chain: Arbitrum One, Ethereum, Arbitrum Nova) can skip delays and directly access all admin- and upgrade functions of all smart contracts.\nThese two general paths have the same destination: the respective UpgradeExecutor smart contract.\n\nRegular 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\nCoreGovernor-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 period) of 6d 8h, which is extended by an additional 2d if the top-level assertion has been challenged.\nWhen that has passed, the L1 Timelock delays for additional 3d. Both timelocks serve as delays during which the transparent transaction contents can be audited,\nand, 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\nthrough 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.\n\nOperator roles like the Sequencers and Validators are managed using the same paths.\nSequencer changes can be delegated to a Batch Poster Manager role.\n\nTransactions targeting the Arbitrum DAO Treasury can be scheduled in the 3d\nTreasury Timelock by meeting a TreasuryGovernor-enforced 40% threshold of votable ARB tokens. The Security Council cannot regularly cancel\nthese transactions or schedule different ones but can overwrite them anyway by having upgrade permissions for all the underlying smart contracts."
}
},
"warning": "The Arbitrum DAO voted to minimize Arbitrum Nova and transition it to maintenance state. Developers and users are encouraged to migrate to Arbitrum One. See the [Minimizing Arbitrum Nova FAQs](https://forum.arbitrum.foundation/t/minimizing-arbitrum-nova-faqs/30955) for details."
}
sophon+2-1
scalingTechnology+2-1
{
"architectureImage": "zkstack-validium-vector",
"dataAvailability": [
{
"name": "Data is posted to Avail",
"description": "Transactions roots are posted onchain and the full data is posted on Avail. The vector bridge is used to verify attestations from the Avail validator set that the data is indeed available.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an unavailable transaction root.",
"isCritical": true
},
{
"category": "Funds can be lost if",
"text": "the data is not available on the external provider.",
"isCritical": true
}
],
"references": [
{
"title": "AvailL1DAValidator - checkDA() function",
"url": "https://etherscan.io/address/0x8f50d93B9955B285f787043B30B5F51D09bE0120#code#F1#L16"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.",
"risks": [],
"references": [
{
"title": "Withdrawing funds - ZKsync documentation",
"url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
}
]
},
{
"name": "Forced messaging",
"description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
"risks": [],
"references": []
}
],
"forceTransactions": {
"name": "Users can't force all transactions",
"description": "If a user is censored by the L2 Sequencer, they cannot by default force their transaction via the L1 queue. An active TransactionFilterer contract which allows only whitelisted accounts to enqueue, prevents it. Even if a user was specifically whitelisted, there is no mechanism that forces the L2 Sequencer to include transactions from the queue in an L2 block, as they have the choice to process the queue in order or not at all. The L2AssetRouter contract is currently whitelisted as a target in the TransactionFilterer which allows users to queue withdrawals that use the canonical bridge from L1.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
},
{
"category": "Users can be censored if",
"text": "the Operator does not specifically whitelist them in the TransactionFilterer."
}
],
"references": [
{
"title": "L1 - L2 interoperability - Developer's documentation",
"url": "https://docs.zksync.io/zksync-protocol/rollup/l1_l2_communication#priority-operations-1"
},
{
"title": "Mailbox facet",
"url": "https://etherscan.io/address/0x1e34aB39a9682149165ddeCc0583d238A5448B45#code#F1#L405"
},
{
"title": "TransactionFilterer",
"url": "https://etherscan.io/address/0x9D06B34adc3026eF876e4DABb859C424DbDA3063#code#F1#L34"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"stateValidation": {
"description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
"categories": [
{
"title": "Prover Architecture",
"description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
},
{
"title": "ZK Circuits",
"description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
}
]
},
"upgradesAndGovernance": {
"content": "There are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
"image": "zkstack"
}
},
"warning": "Sophon will be sunsetting in late 2026. See the [announcement](https://x.com/sophon/status/2070192257295335800) and the [migration guide](https://sophon.com/content/) for details."
}