{
"architectureImage": "arbitrumwithbold",
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "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.",
"risks": [],
"references": [
{
"title": "Sequencing followed by deterministic execution - Arbitrum documentation",
"url": "https://developer.offchainlabs.com/inside-arbitrum-nitro/#sequencing-followed-by-deterministic-execution"
},
{
"title": "SequencerInbox.sol - source code, addSequencerL2BatchFromOrigin function",
"url": "https://etherscan.io/address/0x98a58ADAb0f8A66A1BF4544d804bc0475dff32c7#code"
}
]
}
],
"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 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.",
"references": [
{
"title": "Sequencer and censorship resistance - Arbitrum documentation",
"url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
}
],
"risks": []
},
"stateDerivation": {
"nodeSoftware": "The 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](https://github.com/OffchainLabs/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](https://github.com/OffchainLabs/nitro/)",
"compressionScheme": "The Sequencer's batches are compressed using a general-purpose data compression algorithm known as [Brotli](https://github.com/google/brotli), configured to its highest compression setting.",
"genesisState": "They performed a regenesis from Classic to Nitro, and that file represents the [last Classic state](https://snapshot.arbitrum.foundation/arb1/nitro-genesis.tar). To sync from the initial Classic state, instructions can be found [here](https://docs.arbitrum.io/migration/state-migration).",
"dataFormat": "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."
},
"stateValidation": {
"description": "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.",
"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 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.",
"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 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.",
"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."
"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.",
"governanceInfo": {
"securityCouncil": {
"Composition": "**9/12** — 12 members across two 6-seat cohorts, 1-year staggered terms. DAO-elected via Tally with Foundation eligibility screening.",
"Members public": "**Mapped** — 12 entities + addresses [published by the Arbitrum Foundation](https://docs.arbitrum.foundation/security-council-members). Mix of individuals (gzeon, zachxbt, Bartek, Yoav, Griff Green, \"fred\", Emiliano, Michael Lewellen) and orgs (Gauntlet, Immunefi, Certora, OpenZeppelin).",
"Charter": "[Arbitrum DAO Constitution §3](https://docs.arbitrum.foundation/dao-constitution) — 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 L2 + 3d L1 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 L1 and L2 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) → L2 Timelock (8d) → L2→L1 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 window. E.g. KelpDAO freeze (21 Apr 2026), Stylus stack-depth fix (13 Oct 2025).",
"Exit window": "**~17.4d** non-emergency · **0** emergency. L2 Timelock + L2→L1 outbox + L1 Timelock provide the non-emergency window; emergency actions skip all three."
},
"tokenGovernance": {
"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](https://www.tally.xyz/gov/arbitrum) — 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 · Permissionless execute.** The Governor stores the proposal's `(targets[], values[], calldatas[])` at submission. Once the vote passes and the L2/L1 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."
}
}
}
}
optimism+22-1
scalingTechnology+22-1
{
"architectureImage": "opstack-rollup-superchain-opfp-permissionless",
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "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.",
"risks": [],
"references": [
{
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
},
{
"title": "BatchInbox - address",
"url": "https://etherscan.io/address/0xFF00000000000000000000000000000000000010#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular exits",
"description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
"risks": [],
"references": [
{
"title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
}
]
},
{
"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, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
"risks": [],
"references": [
{
"title": "Forced withdrawal from an OP Stack blockchain",
"url": "https://docs.optimism.io/stack/transactions/forced-transaction"
}
]
}
],
"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.",
"risks": [],
"references": [
{
"title": "Sequencing Window - OP Mainnet Specs",
"url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
}
]
},
"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": []
},
"otherConsiderations": [
{
"name": "EVM compatible smart contracts are supported",
"description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
"risks": [],
"references": [
{
"title": "Introducing EVM Equivalence",
"url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/op.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "Since OP Mainnet has migrated from the OVM to Bedrock, a node must be synced using a data directory that can be found [here](https://docs.optimism.io/builders/node-operators/management/snapshots). To reproduce the migration itself, see this [guide](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock).",
"dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
},
"stateValidation": {
"description": "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.",
"categories": [
{
"title": "State root proposals",
"description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.08 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
"references": [
{
"title": "OP stack specification: Fault Dispute Game",
"url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
}
],
"risks": []
},
{
"title": "Challenges",
"description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 691.43 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
"references": [
{
"title": "Fraud Proof Wars: OPFP",
"url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
}
]
}
]
},
"stateValidationImage": "opfp",
"upgradesAndGovernance": {
"content": "All contracts are upgradable by the `SuperchainProxyAdmin` which is controlled by a 2/2 multisig composed by the Optimism Foundation and a Security Council. The Guardian role is assigned to the Security Council multisig, with a Safe Module that limits the Optimism Foundation to act through it to stop withdrawals in the whole Superchain or specific individual chains. Each pause automatically expires after 3 months if not extended or unpaused by the Security Council. The Security Council can remove the module if the Foundation becomes malicious. The single Sequencer actor can be modified by the `OpFoundationOperationsSafe` via the `SystemConfig` contract. The SuperchainProxyAdminOwner can recover dispute bonds in case of bugs that would distribute them incorrectly. \n\nAt the moment, for regular upgrades, the DAO signals its intent by voting on upgrade proposals, but has no direct control over the upgrade process."
"content": "All contracts are upgradable by the `SuperchainProxyAdmin` which is controlled by a 2/2 multisig composed by the Optimism Foundation and a Security Council. The Guardian role is assigned to the Security Council multisig, with a Safe Module that limits the Optimism Foundation to act through it to stop withdrawals in the whole Superchain or specific individual chains. Each pause automatically expires after 3 months if not extended or unpaused by the Security Council. The Security Council can remove the module if the Foundation becomes malicious. The single Sequencer actor can be modified by the `OpFoundationOperationsSafe` via the `SystemConfig` contract. The SuperchainProxyAdminOwner can recover dispute bonds in case of bugs that would distribute them incorrectly. \n\nAt the moment, for regular upgrades, the DAO signals its intent by voting on upgrade proposals, but has no direct control over the upgrade process.",
"governanceInfo": {
"securityCouncil": {
"Composition": "**10/13** — Gnosis Safe with cohorts of 7 + 6, 12-month staggered terms. Token-House-elected via Agora with Optimism Foundation eligibility screening (KYC/AML, geographic and organisational diversity).",
"Members public": "**Entities only** — elected entity names are public; 1:1 entity-to-address mapping deliberately not published (Foundation privacy policy). Current Cohort A (Feb 2026 – Feb 2027): Agora, Velodrome, Cyfrin, pablito.eth, Mariano, Uniswap Foundation, Emiliano. Cohort B's initial slate (Feb 2025): L2BEAT, OP Labs PBC, Coinbase Technologies, Test in Prod, Ink Foundation/Kraken, World Foundation.",
"Charter": "[Security Council Charter v0.1](https://github.com/ethereum-optimism/OPerating-manual/blob/main/Security%20Council%20Charter%20v0.1.md) — defines 75% threshold, emergency response, Token House removal, LivenessModule failsafe (control reverts to Foundation Upgrade Safe if signers drop below 8).",
"Can bypass DAO?": "**Yes** — emergency response measures may be taken without specific Governance approval (Charter v0.1). The SC + Foundation Upgrade Safe (2/2 SuperchainProxyAdminOwner) hold the actual upgrade keys and can execute at any time.",
"DAO can override SC?": "**Veto, plus member removal** — Token House and Citizens' House can veto DAB-approved upgrades during the 7-day veto window (subject to participation thresholds). Token House can remove SC members by simple majority within one voting cycle (≤3 weeks) for Code of Conduct violations. LivenessModule auto-removes signers inactive ≥3 months 8 days; if signer count drops below 8, control reverts to the Foundation Upgrade Safe."
},
"upgrades": {
"Normal upgrade path": "Technical review by the 7-member elected Developer Advisory Board (DAB, 5/7 quorum for approval) → release on Sepolia → **7-day veto window** during which Token House and/or Citizens' House can veto a DAB-approved upgrade or override a DAB rejection if participation thresholds are met (17% with two groups, 14% with three, 11% with four) → if not vetoed, SC + Foundation Upgrade Safe (2/2 SuperchainProxyAdminOwner) co-sign the L1 transaction → execute. Maintenance upgrades use a shortened path. Live since Aug 1, 2025.",
"Emergency upgrade path": "**SC + Foundation Upgrade Safe (2/2), instant** — \"may preemptively address actual or anticipated bugs, defects, or stability issues without specific Governance approval\" (Charter v0.1). No DAB review, no veto window. Mandatory after-the-fact public retrospective.",
"Exit window": "**None** — upgrades take effect as soon as they are co-signed by the 2/2 SuperchainProxyAdminOwner, with no onchain delay or prior notice, so users cannot exit ahead of an unwanted upgrade."
},
"tokenGovernance": {
"Governance token": "`OP` — ~4.29B initial supply, up to 2%/yr inflation (cap fixed in the Operating Manual; changes require a 76% Inflation proposal). 1 OP = 1 vote, delegated.",
"Voting venue": "[Agora](https://vote.optimism.io/) for binding on-chain Token House votes. [Snapshot](https://snapshot.org/#/opcollective.eth) for Citizens' House signaling, Protocol Upgrade vetoes, and some Reflection Period votes. Forum stage: [gov.optimism.io](https://gov.optimism.io).",
"Proposal threshold": "**No OP minimum** — submission requires explicit approval from 4 of the top-100 delegates on the discussion thread (Operating Manual). Citizens' House analog: 4 Citizens. Foundation-initiated proposals require no approvals. Note: protocol upgrades since Aug 2025 originate from the DAB rather than the Token House.",
"Quorum": "**30%** for Token House proposals. Veto-window participation thresholds for protocol upgrades: 17% (two groups voting), 14% (three groups), 11% (four groups).",
"Execution model": "**DAB-gated approval + 2/2 Safe signs** — DAB approves, veto window passes, then SC + Foundation Upgrade Safe co-sign the L1 transaction. Token House and Citizens' House signal/veto on-chain via Agora and Snapshot but do not directly trigger the L1 state change. No permissionless `execute()`."
}
}
}
}