2af5f3bc (main)
and
b19f528b (PR)
+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain-opfp",
"dataAvailability": [
{
"name": "Data is posted to EigenDA",
"description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequencer is publishing data to EigenDA v2. Since the DACert Verifier is not used, availability of the data is not verified against EigenDA operators, meaning that the Sequencer can single-handedly publish unavailable commitments. If EigenDA becomes unavailable, the sequencer falls back to Ethereum.",
"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": "EigenDA Docs - Overview",
"url": "https://docs.eigenda.xyz/overview"
},
{
"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/0x253887577420Cb7e7418cD4d50147743c8041b28#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xBf3C31c8C0325Bf8E70D3A7D463A715D3CD114b7#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 30m. Withdrawal inclusion can be proven before state root settlement, but a 1h period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 30m 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/0xBf3C31c8C0325Bf8E70D3A7D463A715D3CD114b7#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xBf3C31c8C0325Bf8E70D3A7D463A715D3CD114b7#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/0xBf3C31c8C0325Bf8E70D3A7D463A715D3CD114b7#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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 30m. 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 10m, it generally gets extended by 10m with the exception of 20m right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 1d 12h. 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)).",
"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 0.00 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 30m. 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)), an inherited clock with too little time remaining is generally extended by 10m. The extension is 20m when the next claim is immediately before split depth 30, and 1d (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 1d 12h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the op-program superchain registry, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain-opfp",
"dataAvailability": [
{
"name": "Data is posted to Celestia",
"description": "Transactions roots are posted onchain and the full data is posted on Celestia. Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots. If Celestia becomes unavailable, the sequencer falls back to Ethereum.",
"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": "Introducing Blobstream: streaming modular DA to Ethereum",
"url": "https://blog.celestia.org/introducing-blobstream/"
},
{
"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/0xd5df46c580fD2FBdaEE751dc535E14295C0336F3#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the op-program superchain registry, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
}+76 -4
+76 -4
{
"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.",
"name": "Transactions are ordered by a centralized sequencer",
"description": "Arbitrum One uses a single centralized sequencer for fast confirmations. Users can bypass it by first enqueueing a message on Ethereum. If the sequencer does not include it before the message-specific delay expires, anyone can submit a second Ethereum transaction to force the delayed queue into the canonical order.\n\n### Buffered forced transactions\n\nTo 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.",
"sequencingSpec": {
"type": "centralized",
"trustedPreconfirmation": {
"value": "250 ms",
"secondLine": "250 ms L2 block time",
"description": "The sequencer feed provides a trusted soft confirmation with no protocol enforcement or slashing. While a Timeboost express lane controller is active, non-express transactions are delayed by 200 ms before ordering.",
"orderHint": 0.25
},
"trustedOrdering": {
"value": "Timeboost",
"secondLine": "Auctioned express lane",
"description": "The express lane controller, selected by auction for each round, receives a 200 ms advantage over regular transactions. Transactions are otherwise ordered based on arrival time. This policy is operated by the centralized sequencer and is not enforced by the L1 contracts."
},
"sequencer": {
"value": "Centralized",
"secondLine": "Redis HA",
"sentiment": "bad",
"description": "The Arbitrum operator controls the real-time sequencer feed. Their documented production HA architecture runs redundant sequencer replicas and selects one active instance through shared Redis state. This improves availability but is not BFT consensus and does not create independent operators or censorship resistance.",
"orderHint": 1
},
"realtimeCensorshipResistance": {
"value": "No",
"sentiment": "bad",
"description": "The centralized sequencer can censor transactions submitted through the normal L2 path."
},
"forcedInclusion": {
"value": "Permissionless call",
"secondLine": "2 L1 txs: enqueue + force",
"sentiment": "good",
"description": "The first Ethereum transaction enqueues the message in the delayed inbox. After the delay expires, anyone can submit a second transaction calling forceInclusion, which advances all delayed messages through the selected message."
},
"inclusionDelay": {
"value": "1 day",
"secondLine": "150-7,200 L1 blocks",
"sentiment": "good",
"description": "The message-specific delay is the lower of delayBlocks and the delay buffer. The current buffer gives the maximum delay. The force call becomes valid in the following Ethereum block.",
"orderHint": 7200
},
"inclusionMechanics": {
"value": "2 L1 Tx",
"secondLine": "Address alias",
"description": "Forced inclusion creates an L1-originated L2 message rather than submitting the original signed L2 transaction. The full delayed-inbox message is capped at 117,964 bytes, so the available call data is slightly smaller. L1 contract callers use an aliased address on L2. The rollup owner can pause the Inbox or enable its allowlist, preventing new submissions."
},
"exitDelay": {
"value": "15 days 18 hours",
"secondLine": "1d inclusion + 14d 18h state",
"description": "After successful L2 inclusion (forced or sequencer), the user can propose the assertion needed to exit by posting the assertion bond. The assertion cadence can add up to 15 minutes. A maximally delayed BoLD challenge can take up to twice the 45,818-block edge challenge period, followed by a 14,400-block grace period.",
"orderHint": 1359732
},
"exitEconomics": {
"value": "3,600 WETH",
"secondLine": "Favors defender 6.49×",
"description": "Self-proposing the assertion needed for an exit requires a 3,600 WETH bond. If challenged, the user must defend it through BoLD and post additional refundable bonds of 555 WETH and 79 WETH to enter the lower challenge levels."
}
},
"censorshipResistance": "The centralized sequencer provides no real-time censorship resistance. The delayed inbox provides eventual censorship resistance, assuming Ethereum includes both the enqueue transaction and, when needed, the force-inclusion transaction.",
"references": [
{
"title": "Sequencer and censorship resistance - Arbitrum documentation",
"url": "https://docs.arbitrum.io/how-arbitrum-works/sequencer"
"title": "Arbitrum documentation - Sequencer and censorship resistance",
"url": "https://docs.arbitrum.io/how-arbitrum-works/deep-dives/sequencer"
},
{
"title": "Arbitrum - Timeboost launch",
"url": "https://blog.arbitrum.io/gattaca-titan-timeboost-live-on-arbitrum/"
},
{
"title": "Arbitrum documentation - High-availability sequencer",
"url": "https://docs.arbitrum.io/launch-arbitrum-chain/run-a-node/high-availability-sequencer"
},
{
"title": "SequencerInbox - source code",
"url": "https://etherscan.io/address/0x98a58ADAb0f8A66A1BF4544d804bc0475dff32c7#code"
},
{
"title": "Inbox - source code",
"url": "https://etherscan.io/address/0x7C058ad1D0Ee415f7e7f30e62DB1BCf568470a10#code"
}
],
"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.",
"governanceInfo": {
"securityCouncil": {
"Composition": "**9/12** — 12 members across two 6-seat cohorts, 1-year staggered terms. DAO-elected via on-chain vote with Foundation eligibility screening.",
"Members public": "**Mapped** — 12 entities + addresses [published by the Arbitrum Foundation](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."
}
}
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x00f9BCEe08DCe4F0e7906c1f6cFb10c77802EEd0#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/arena-z.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/arena-z.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+69 -63
+69 -63
{
"dataAvailability": [
{
"name": "All transaction results (state diffs) are published in Ethereum blobs",
"description": "Each checkpoint proposal includes EIP-4844 blob commitments for state diffs, checked against the blob hashes in the proposing transaction. The epoch proof revalidates the accumulated commitments before finalization. Public transaction bodies and client CHONK proofs propagate offchain; withholding them can prevent permissionless proving, causing the pending checkpoint to expire and be pruned rather than finalized.",
"references": [
{
"title": "Rollup.sol - propose() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Rollup.sol - validateBlobs() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
],
"risks": []
}
],
"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. Once the epoch root proof has been verified, the rollup inserts the epoch root into the Outbox, from which withdrawals and other L2->L1 messages can be consumed on Ethereum. Withdrawals can be initiated privately on L2, revealing only the L1-facing portion of the transaction. There is no canonical bridge escrow: only the canonical messaging layer is immutable, while each token bridged through a locking escrow may introduce additional trust assumptions tied to that specific escrow.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Outbox.sol - consume() on Etherscan",
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
}
]
}
],
"forceTransactions": {
"name": "Bonded, probabilistic self-sequencing",
"description": "There is no L1 forced-transaction queue. A censored user must wait for an honest regular committee or for an honest, sufficiently capitalized escape-hatch candidate to enroll, become eligible, be selected, include the transaction, and produce a valid proof.",
"risks": [
{
"category": "Users can be censored if",
"text": "no honest regular proposer or eligible bonded escape-hatch proposer includes and proves their transactions."
}
],
"references": [
{
"title": "EscapeHatch.sol on Etherscan",
"url": "https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code"
}
]
},
"operator": {
"name": "There is no central operator",
"description": "There is no privileged sequencer. Anyone can stake 200.00 K AZTEC to join the sequencer queue, and anyone can call flushEntryQueue() to activate queued sequencers once the queue rules allow it.",
"risks": [],
"references": [
{
"title": "Rollup.sol - deposit() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Rollup.sol - flushEntryQueue() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
]
},
"otherConsiderations": [
{
"name": "Upgrades replace the canonical rollup",
"description": "The core contracts are immutable, but Governance owns the Registry and GSE and can register a new rollup version as canonical after the governance delay.",
"references": [
{
"title": "Registry.sol - addRollup() on Etherscan",
"url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
},
{
"title": "Governance.sol - execute() on Etherscan",
"url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e#code"
}
],
"risks": []
},
{
"name": "No canonical bridge escrow",
"description": "There is no default canonical escrow. The rollup is deployed only with an immutable canonical messaging bridge, which can be used by any escrow. As a result, each token bridged to Aztec via Ethereum lock-mint must be assessed individually by examining its specific locking escrow. The trust assumptions of a given escrow may differ from those of the immutable rollup itself. Gas tokens are bridged through the FeeJuicePortal, an immutable one-way portal that only supports bridging to public L2 addresses. Although the rollup and its canonical messaging bridge are immutable, an upgradeable escrow could migrate its funds to a new rollup version without requiring users to migrate, effectively trading immutability for convenience.",
"references": [
{
"title": "FeeJuicePortal.sol - on Etherscan",
"url": "https://etherscan.io/address/eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
},
{
"title": "Outbox.sol - on Etherscan",
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
}
],
"risks": []
},
{
"name": "Inclusion is probabilistic",
"description": "All protocol-level censorship-resistance tools are probabilistic. Unlike an L1 forced-transaction queue, they do not guarantee inclusion after a fixed delay. The launch-era decentralized-sequencer model estimated 20d to reach its target exit probability under its stated assumptions; it is not a current protocol guarantee and does not model validator-set changes, the escape hatch, or adversarial queue saturation. Private transactions and the bonded escape hatch can improve inclusion probability, but neither creates a deterministic deadline.",
"references": [
{
"title": "CRsim - Simulated inclusion probability on Aztec",
"url": "https://sekuba.github.io/crsim"
}
],
"risks": []
}
],
"sequencing": {
"name": "Transactions are ordered by a staked validator committee",
"description": "Joining the sequencer set is permissionless and requires staking 200.00 K AZTEC. For each epoch, the Rollup samples a 48-member committee from the active set of 3237 and selects one proposer per slot. The proposer for slot N builds the checkpoint and collects attestations during slot N-1, then submits the assembled checkpoint to Ethereum in slot N. More than two-thirds of the sampled committee must attest; the proof path verifies the attestation data before the checkpoint can become final.",
"sequencerSetSpec": {
"sequencingSpec": {
"type": "sequencer-set",
"blockTime": {
"value": "6s",
"description": "Current expected interval between L2 block proposals. Multiple blocks can be produced by the same proposer within one slot, so this interval can differ from the proposer rotation interval."
},
"proposerRotationTime": {
"value": "1m 12s"
},
"committeeRotationTime": {
"value": "38m 24s",
"description": "A random committee is sampled from the sequencer set for each epoch, a random block producer is sampled from the committee for each slot in the epoch"
},
"sequencerCount": {
"value": "3237 sequencers"
"value": "3237 sequencers",
"secondLine": "586.92 M AZTEC"
},
"blockProductionAccess": {
"value": "Open",
"sentiment": "good"
},
"stakePerValidator": {
"value": "200.00 K AZTEC, constant"
},
"rateLimit": {
"value": "Up to 4 sequencers per epoch (current)",
"value": "4 sequencers / epoch",
"description": "Can be changed by onchain Governance, but the contract requires nonzero minimum, divisor, and maximum queue-flush parameters."
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "Bonded escape hatch, private transactions",
"sentiment": "good"
}
"secondLine": "332.00 M AZTEC; every 2d 23h",
"sentiment": "good",
"description": "Escape hatch: 332.00 M AZTEC bond to enter a set from which one proposer is periodically selected every 2d 23h to bypass the regular committee, include transactions, and prove the resulting checkpoints. 1.66 M AZTEC proposal tax. Private transactions: allow users to cheaply resist censorship based on transaction content while the chain is live."
},
"inclusionDelayChart": {
"type": "committeelike",
"validatorCount": 3237,
"committeeSize": 48,
"epochSlots": 32,
"slotSeconds": 72,
"blockingThreshold": 15,
"target": 0.99,
"maxCensorFraction": 0.5,
"stakeDistribution": {
"stakeToken": "AZTEC",
"dateType": "fetched",
"date": "2026-08-06T08:48:58.509Z",
"totalStake": 586930000,
"entities": [
{
"name": "Nethermind",
"stake": 106400000
},
{
"name": "Nansen | Stake to Stack Points",
"stake": 72000000
},
{
"name": "Sigma Prime",
"stake": 64600000
},
{
"name": "P2P.org",
"stake": 38250000
},
{
"name": "snoopfear|PON",
"stake": 37200000
},
{
"name": "ZKV",
"stake": 30816000
},
{
"name": "Wonderland",
"stake": 27308000
},
{
"name": "GabbexNodes",
"stake": 27000000
},
{
"name": "Nightwolf Labs",
"stake": 23000000
},
{
"name": "DCG",
"stake": 22600000
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship only. It does not model the escape hatch, validator-set changes, validator-set lag, and blanket-censorship resistance gadgets."
},
"inclusionDelayChart": {
"type": "committeelike",
"validatorCount": 3237,
"committeeSize": 48,
"epochSlots": 32,
"slotSeconds": 72,
"blockingThreshold": 15,
"target": 0.99,
"maxCensorFraction": 0.5,
"stakeDistribution": {
"stakeToken": "AZTEC",
"totalStake": 610642000,
"entities": [
{
"name": "Nethermind",
"stake": 113600000
},
{
"name": "Nansen | Stake to Stack Points",
"stake": 75800000
},
{
"name": "Sigma Prime",
"stake": 66800000
},
{
"name": "P2P.org",
"stake": 41600000
},
{
"name": "snoopfear|PON",
"stake": 37200000
},
{
"name": "ZKV",
"stake": 30816000
},
{
"name": "GabbexNodes",
"stake": 27400000
},
{
"name": "Wonderland",
"stake": 26600000
},
{
"name": "Nightwolf Labs",
"stake": 22800000
},
{
"name": "01node",
"stake": 21600000
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship only. It does not model the escape hatch, validator-set changes, validator-set lag, and blanket-censorship resistance gadgets.",
"censorshipResistance": "The regular committee can be circumvented by the escape hatch, which uses RANDAO to designate a previously enrolled bonded candidate that may publish checkpoints without committee attestations. Enrollment requires 332.00 M AZTEC, a high bond intended to protect the single-proof system while providing a last-resort path around the regular sequencer set. Aztec's private execution environment can also make selective censorship harder because transaction contents are hidden.\n\n### Selective censorship\n\nOn a live network with some censoring sequencers, users can submit private transactions or wait for an honest committee and proposer to include their public transaction.\n\n### Blanket censorship\n\nIf the entire active set censors or stops producing checkpoints, a new sequencer can join through the permissionless staking queue, subject to its churn limits. A sufficiently capitalized account can instead enroll for the escape hatch, but enrollment, candidate-set snapshots, eligibility, and RANDAO selection are lagged. Specialized proving hardware is still required. Adversaries can also saturate the entry queue or candidate set and reduce an honest user's inclusion probability.\n\n### Walkaway\n\nHatch opportunities occur approximately every 2d 23h, but the candidate set can be empty and selection, proposal, and proving can fail. The protocol therefore provides no deterministic maximum inclusion delay; permissionless validator entry and the bonded hatch only improve the probability that the chain eventually recovers.",
"censorshipResistance": "The regular committee can be circumvented by the escape hatch, which uses RANDAO to designate a previously enrolled bonded candidate that may publish checkpoints without committee attestations. Enrollment requires 332.00 M AZTEC, a high bond intended to protect the single-proof system while providing a last-resort path around the regular sequencer set. A designated candidate that fails to propose and prove loses 9.60 M AZTEC from their bond. Aztec's private execution environment can also make selective censorship harder because transaction contents are hidden.\n\n### Selective censorship\n\nOn a live network with some censoring sequencers, users can submit private transactions or wait for an honest committee and proposer to include their public transaction.\n\n### Blanket censorship\n\nIf the entire active set censors or stops producing checkpoints, a new sequencer can join through the permissionless staking queue, subject to its churn limits. A sufficiently capitalized account can instead enroll for the escape hatch, but enrollment, candidate-set snapshots, eligibility, and RANDAO selection are lagged. Specialized proving hardware is still required. Adversaries can also saturate the entry queue or candidate set and reduce an honest user's inclusion probability.\n\n### Walkaway\n\nHatch opportunities occur approximately every 2d 23h, but the candidate set can be empty and selection, proposal, and proving can fail. The protocol therefore provides no deterministic maximum inclusion delay; permissionless validator entry and the bonded hatch only improve the probability that the chain eventually recovers.",
"references": [
{
"title": "Aztec docs - Privacy considerations",
"url": "https://github.com/AztecProtocol/aztec-packages/blob/next/docs/docs-developers/docs/resources/considerations/privacy_considerations.md#function-fingerprints-and-tx-fingerprints"
},
{
"title": "Rollup.sol - getProposerAt() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "EscapeHatch.sol - selectCandidates() on Etherscan",
"url": "https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code"
}
],
"risks": []
},
"stateValidation": {
"description": "Each epoch root proof is verified by the HonkVerifier smart contract on Ethereum before the proven checkpoint number is advanced and the epoch outbox state root is inserted into the Outbox. Proving is permissionless, and a single proof can cover one Checkpoint (1m 12s) to one epoch (38m 24s). The current maximum proof window is 1h 16m; checkpoints later in an epoch have less time, and unproven checkpoints are pruned.",
"categories": [
{
"title": "State root proposals",
"description": "The rollup only advances the proven chain after submitEpochRootProof() succeeds. That call verifies the epoch proof and then inserts the epoch outbox state root for L2->L1 messaging.",
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
],
"risks": []
},
{
"title": "Validity proofs",
"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.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "HonkVerifier.sol - verify() on Etherscan",
"url": "https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code"
}
]
},
{
"title": "Slashing",
"description": "Each 200.00 K AZTEC stake used to join the sequencer set and vote in governance can be slashed. The designated proposer for each slot can submit one separate signed ballot on L1. Ballots are grouped into rounds spanning 4 epochs (2h 33m).\n\nSlashing conditions are implemented in sequencer-node software and can change when operators update or modify that software. The onchain `SlashingProposer` enforces the voting and execution rules:\n\n* Ballots in a round target committee members from 2 rounds earlier.\n* Quorum is evaluated separately for each validator position and penalty level, not for the round as a whole. At least 65 matching ballots out of up to 128 slots are required. Votes for a higher penalty also count toward every lower level, and each validator is slashed once at the highest level that reaches quorum.\n* A round becomes executable after more than 28 rounds (approximately 2d 23h) and expires at age 34 rounds, leaving a 6-round execution window.\n* Anyone can call `executeRound()` during that window. It verifies committee commitments, skips escape-hatch epochs, deploys a deterministic payload for the approved actions, and asks the authorized Slasher to execute it.\n\nThe current onchain penalty levels are large (5.00 K AZTEC), medium (5.00 K AZTEC), and small (2.00 K AZTEC). Offenses that node software can ballot for include:\n\n* **Inactivity:** a sequencer fails to attest or propose when selected.\n* **Data withholding:** a sequencer publishes state-diff blobs but withholds public transaction bodies or CHONK proofs needed for permissionless proving.\n* **Invalidity or equivocation:** a sequencer attests to an invalid proposal, signs conflicting proposals or attestations, or uses an invalid signature.\n\nThis list and the mapping of offenses to penalty levels are not exhaustive or defined by the L1 contracts; they depend on the software each sequencer runs.\n\nThe SlashVeto Council is a 5/9 Multisig. It can permanently veto a specific payload, repeatedly renew a global 3d pause, or re-enable slashing before a pause expires. Governance can submit Slasher payloads without ballot approval, but it cannot bypass these veto and pause checks.",
"references": [
{
"title": "SlashingProposer.sol on Etherscan",
"url": "https://etherscan.io/address/eth:0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA#code"
},
{
"title": "Slasher.sol on Etherscan",
"url": "https://etherscan.io/address/eth:0xCD6855470A01aBcd989126A1183Fb50673952548#code"
},
{
"title": "SlashVeto Council - Github",
"url": "https://github.com/aztec-slash-veto/council"
},
{
"title": "slashveto.me - Monitor Slashing",
"url": "https://slashveto.me"
}
],
"risks": []
}
]
},
"upgradesAndGovernance": {
"content": "# Standard path (sequencer signaling)\n\nSequencers stake AZTEC to secure the L2 and also participate in protocol governance. Every proposal is a smart contract payload on Ethereum. The public proposal flow takes at least 12d before execution, after which Governance can change the bounded parameters described below or deploy and register a new canonical rollup version.\n\n## 1. Signaling (`GovernanceProposer`)\n\nAztec uses an onchain \"Empire\" signaling system. The designated proposer for each slot on the canonical rollup can separately signal support for one payload on L1. A round consists of 1,000 slots. A payload that receives at least 600 signals wins the round and can be submitted to `Governance`.\n\n## 2. Token voting (`Governance`)\n\nOnce submitted, a proposal passes through these states:\n\n* **Pending (3d):** voting power is snapshotted at the end of this delay.\n* **Active (7d):** AZTEC holders vote. The snapshot must contain at least 100.00 M AZTEC of total voting power, at least 20% of that power must vote, and `yea` must be strictly greater than 66.5% of votes cast (the configured `yea`-minus-`nay` margin is 33%).\n* **Queued (2d):** a successful proposal waits before it can be executed. This final phase alone is shorter than the validator withdrawal delay, but the complete public process provides at least 12d of notice. Initiating an exit immediately removes a validator from the active set, while its stake becomes withdrawable after 4d.\n* **Executable (7d):** anyone can execute the proposal during this grace period; otherwise it expires.\n\n## Emergency proposal path\n\nIf sequencer signaling is unavailable, anyone can call `proposeWithLock()` directly on `Governance`. The proposer must lock **258.75 M AZTEC**, roughly 2.5% of the total supply, for 3mo. The payload then follows the same pending, voting, queued, and executable phases as a signaled proposal.\n\n## Immutable deployments and bounded ownership\n\nThe `Rollup`, verifier, `Inbox`, `Outbox`, and installed `EscapeHatch` code cannot be upgraded in place. Feature upgrades deploy a new stack and use Governance to register its Rollup in the `Registry` and GSE. Validators staked to the bonus instance (`0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8`) follow the newest GSE Rollup automatically; validators explicitly bound to an older Rollup remain associated with it.\n\nGovernance owns the Rollup, but its setter surface is intentionally constrained: it can change the sequencer/prover reward split and checkpoint reward, only increase the mana target, change proving cost delayed and within bounds, and update validator-entry rate within non-zero values. It can queue a replacement Slasher with a 2mo delay. The outgoing Slasher then remains active for 1mo. The EscapeHatch, the reward distributor and reward-booster addresses are fixed for the deployment.\n\nGovernance also owns the GSE and can register a new latest Rollup or set the proof-of-possession gas limit too low for new validator deposits. These powers can move incentives and bonus-instance validators away from the current version, but they do not mutate this deployment's verifier, messaging contracts, or installed EscapeHatch.\n\n## Slashing and the SlashVeto Council\n\nAztec's onchain slashing path uses `SlashingProposer` ballots and the `Slasher`. Governance can bypass the proposer and submit a payload directly to the Slasher, and can rotate the authorized Slasher through the delayed Rollup process described above. Both the ballot and direct-governance paths remain subject to payload vetoes and global pauses by the SlashVeto Council.\n\nThe **Vetoer** role is held by the SlashVeto Council. It cannot upgrade the protocol or relay arbitrary calls. It can:\n\n* veto a specific payload permanently; and\n* disable all slashing for 3d. Calling the function again renews the pause, while the Council can also re-enable slashing early.\n\n## Economics and treasury\n\n* **CoinIssuer:** the owner can mint AZTEC within an annual cap of 20% of the current total supply.\n* **ProtocolTreasury:** the DAO's treasury is gated until approximately Nov 2026 and is additionally subject to an ATP-derived activation timestamp and proposal-ordering checks. Once every gate is satisfied, a Governance proposal can relay arbitrary calls and value through the treasury."
},
"warning": "Aztec v5 has a [known critical proving-system vulnerability](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) that puts funds, applications, and contract state at risk. A fix is planned for v6."
}+87 -0
+87 -0
{
"architectureImage": "opstack-rollup-superchain-opfp-aggverifier",
"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/0xFf00000000000000000000000000000000008453#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x66d94eE8F529b683ED6013729784e8bb44697A64#code"
}
]
}
],
"exitMechanisms": [
{
"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/0x66d94eE8F529b683ED6013729784e8bb44697A64#code"
}
]
},
"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"
}
]
}
],
"sequencing": {
"name": "Transactions are ordered by a centralized sequencer",
"description": "Base uses a single centralized sequencer for fast confirmations. Users can bypass it with one Ethereum transaction to the OptimismPortal. Base nodes derive the deposited transaction from Ethereum, including it after at most one sequencing window.",
"sequencingSpec": {
"type": "centralized",
"trustedPreconfirmation": {
"value": "200 ms",
"secondLine": "2 s L2 block time",
"description": "The centralized builder streams cumulative Flashblock preconfirmations about every 200 ms while sealing regular L2 blocks every 2 seconds. Flashblocks are out of protocol: the promise has no protocol enforcement or slashing, and a preconfirmation can be absent or reorged.",
"orderHint": 0.2
},
"trustedOrdering": {
"value": "Dynamic priority auction",
"secondLine": "Fee order per Flashblock",
"description": "For each 200 ms build loop, the centralized builder selects available transactions by priority fee. Transactions committed to an earlier Flashblock are not reordered when a higher-fee transaction arrives later, so arrival time also affects ordering. This policy is not enforced by the derivation rules."
},
"sequencer": {
"value": "Centralized",
"secondLine": "5-instance Raft HA",
"sentiment": "bad",
"description": "The Base operator controls real-time ordering. They document five sequencer instances coordinated by op-conductor using Raft leader election, with only the leader producing blocks. The replicas improve availability but do not create independent operators or censorship resistance.",
"orderHint": 1
},
"realtimeCensorshipResistance": {
"value": "No",
"sentiment": "bad",
"description": "The centralized sequencer can censor transactions submitted through the normal L2 path."
},
"forcedInclusion": {
"value": "Automatic derivation",
"secondLine": "1 L1 tx: portal deposit",
"sentiment": "good",
"description": "The user submits one Ethereum transaction to the OptimismPortal which is automatically derived by conforming nodes."
},
"inclusionDelay": {
"value": "12 hours",
"secondLine": "3,600 L1 blocks",
"sentiment": "good",
"description": "The static sequencing window is measured in Ethereum blocks.",
"orderHint": 3600
},
"inclusionMechanics": {
"value": "1 L1 Tx",
"secondLine": "Address alias",
"description": "Forced inclusion creates an L1-originated deposit transaction rather than submitting the original signed L2 transaction. Its calldata is capped at 120,000 bytes, its minimum L2 gas limit is 21,000 plus 40 gas per calldata byte, and deposits share a metered 20,000,000 gas resource limit per Ethereum block. L1 contract callers use an aliased address on L2."
},
"exitDelay": {
"value": "5 days 12 hours",
"secondLine": "12h inclusion + 20m + 5d state",
"description": "After successful L2 inclusion (forced or sequencer), a permissionless ZK proof is needed to finalize the state and exit on L1. Without the centralized TEE proof, the game waits 5 days, followed by the currently 0 seconds finality air gap. The 1 day withdrawal-proof maturity period runs concurrently.",
"orderHint": 476400
},
"exitEconomics": {
"value": "0.05 ETH",
"secondLine": "ZK proof required",
"description": "Self-proposing the state needed for an exit requires a valid ZK proof and a 0.05 ETH bond for one 600-block checkpoint."
}
},
"censorshipResistance": "The centralized sequencer provides no real-time censorship resistance. The Ethereum deposit path provides eventual censorship resistance, assuming the deposit is included on Ethereum.",
"references": [
{
"title": "Base documentation - Flashblocks",
"url": "https://docs.base.org/base-chain/flashblocks/faq"
},
{
"title": "Base engineering - Sequencer architecture",
"url": "https://blog.base.dev/flashblocks-deep-dive"
},
{
"title": "Base source code - Mainnet chain configuration",
"url": "https://github.com/base/base/blob/5761d838af8ae52e4904a74af2f3d8b490f56fec/crates/common/chains/src/config.rs#L402-L409"
},
{
"title": "Base Beryl - Reduced withdrawal delay",
"url": "https://blog.base.dev/introducing-base-beryl"
},
{
"title": "OptimismPortal2 - source code",
"url": "https://etherscan.io/address/0x66d94eE8F529b683ED6013729784e8bb44697A64#code"
},
{
"title": "AggregateVerifier - source code",
"url": "https://etherscan.io/address/0xeE303bA054c5F1E14A8EF87f1C7E285af45A1ba2#code"
}
],
"risks": []
},
"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/base.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://raw.githubusercontent.com/base-org/node/refs/tags/v0.8.4/mainnet/genesis-l2.json).",
"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": {
"categories": [
{
"title": "State root proposals",
"description": "State roots are proposed by calling `DisputeGameFactory.create` with the AggregateVerifier game type, posting a bond of 0.05 ETH. Each proposal must include an initial proof (TEE attestation or ZK proof) over the range of 600 L2 blocks split into sub-ranges of 30 blocks. With a single proof, the game resolves after 5d; if both proof arms commit, the window collapses to 1d.",
"references": []
},
{
"title": "Challenges",
"description": "Any party that produces a valid ZK proof of an incorrect intermediate root can call `AggregateVerifier.challenge`, contradicting a TEE-only proposal. The challenger's proof is verified onchain via the SP1 verifier gateway. If the challenge stands until the resolution window closes, the original proposer's bond is awarded to the challenger and the game resolves CHALLENGER_WINS. Soundness contradictions within a single proof arm are caught by `AggregateVerifier.nullify`, which permanently disables that arm's verifier contract for all games.",
"references": []
}
]
},
"stateValidationImage": "aggverifier",
"upgradesAndGovernance": {
"content": "All contracts are upgradable by a `ProxyAdmin` contract controlled by a nested 2/2 `Base Governance Multisig` composed of the `Base Coordinator Multisig` and the `Base Security Council`. Upgrades require approval from both parties. There is no delay on upgrades. The Guardian role for the SuperchainConfig is assigned to the Base Governance Multisig, which can pause and unpause withdrawals. `Base Multisig 1` serves as Incident Responder and can pause withdrawals but cannot unpause or extend pauses. Each pause automatically expires after 3 months if not extended by the Guardian. The single Sequencer actor can be modified by `Base Multisig 1` via the SystemConfig contract. The Base Governance multisig can also recover dispute bonds in case of bugs that would distribute them incorrectly.\n\nState validation runs through the `AggregateVerifier` game type (621), which accepts either an AWS Nitro TEE attestation or an SP1 ZK proof. The TEE prover allowlist in the `TEEProverRegistry` is managed solely by the `Base Coordinator Multisig` (without Base Security Council approval), and a separate Manager EOA can register or deregister enclave signers. The ZK arm routes through a Base-owned SP1 verifier gateway; the Base Governance Multisig can add or freeze verifier routes. The Base Governance Multisig can swap the AggregateVerifier implementation, change the respected game type, blacklist individual games, or retire all in-flight games via the AnchorStateRegistry.",
"governanceInfo": {
"securityCouncil": {
"Composition": "**8/11**, nested as one of two signers in the 2/2 `Base Governance Multisig` alongside Coinbase's 3/6 `Base Coordinator Multisig`. Base counts this as 9 of 12 entities, or 75%; the Council Safe on its own is 72.7%. Members serve staggered cohort terms and are appointed against published criteria, not elected.",
"Members public": "**Mapped (10 of 11)** — [Base publishes](https://docs.base.org/base-chain/security/security-council) Aerodrome (JP), Moonwell (BR), Blackbird (US), ChainSafe (CA), Talent Protocol (PT) and Moshicam (US) as entities, plus Seneca (US), Juan Suarez (US), Toady Hawk (CA), Roberto Bayardo (US) and Yele Bademosi (UK) as individuals. One address is unpublished, as are the people who sign for each entity. Five of the six entities are Base-ecosystem projects and two of the individuals are former Coinbase or Base contributors.",
"Charter": "**None** — the [docs page](https://docs.base.org/base-chain/security/security-council) sets out selection criteria, cohort terms and member duties, but no removal procedure, quorum-loss fallback or conflict-of-interest enforcement. Coinbase's [Neutrality Principles](https://www.coinbase.com/blog/coinbases-neutrality-principles-for-base) cover transaction ordering, user assets and exit rights, and do not bind the Council.",
"Can Coinbase bypass the Council?": "**Not for upgrades** — every `ProxyAdmin` action needs the 2/2. Elsewhere Coinbase acts alone: the 3/12 `Base Multisig 1` owns `SystemConfig` (sequencer, gas configuration) and is Incident Responder, and the Coordinator Multisig owns `TEEProverRegistry` and `NitroEnclaveVerifier`, so it can change the TEE prover allowlist, one of the two proof arms, without the Council.",
"Who can override the Council?": "**Nobody — it administers itself.** Seats are changed by the Council Safe calling itself, so 8 of the 11 sitting members decide who joins or leaves. There is no token, DAO or veto body. The 2/2 blocks both ways: neither side can upgrade alone. Below 8 available signers upgrades stall, and there is no liveness module handing control to a fallback."
},
"upgrades": {
"Normal upgrade path": "Task published in [base/contract-deployments](https://github.com/base/contract-deployments) → **8/11 Security Council approval** → **3/6 Coordinator Multisig approval** → execution through the 2/2 `Base Governance Multisig`. No timelock, and no Safe carries a delay module. Beryl verifier-hash update, June 2026: Council approved 22 Jun, Coinbase 23 Jun, executed 43 minutes later.",
"Emergency upgrade path": "**None** — the normal path executes as soon as both Safes sign, so there is no lower emergency threshold. The fastest lever is a pause: the 3/12 `Base Multisig 1` can pause withdrawals alone as Incident Responder, but only once per identifier, since the pause expires after 3mo 1d and it cannot pause again until the Guardian unpauses. The Guardian is the 2/2 `Base Governance Multisig` itself, which can also blacklist dispute games, set the respected game type and retire all in-flight games.",
"Exit window": "**None** — nothing separates the second signature from the upgrade taking effect, so users cannot withdraw ahead of an unwanted change. Tasks are published before signing and Base targets six hard forks a year, but neither is enforced onchain."
},
"tokenGovernance": {
"Governance token": "**None** — Base has no token, so no token-weighted vote enters the upgrade path. Coinbase has said it is exploring one.",
"Voting venue": "**None** — no DAO, governor contract, Snapshot space or forum vote gates an upgrade. Coordination happens in [base/contract-deployments](https://github.com/base/contract-deployments).",
"Proposal rights": "**Coinbase only** — upgrade tasks are Coinbase-authored, and no route exists for a third party to put an upgrade to the Council.",
"Execution model": "**Two Safes sign, a facilitator executes.** No permissionless `execute()`, and no delay for the public to act inside."
}
}
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0xfFF0000000000000000000000000000000000288#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the superchain registry snapshot embedded in the op-program release that the dispute games commit to, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
}+1 -1
+1 -1
{
"host": {
"stateValidation": {
"value": "Fraud proofs (INT)",
"description": "Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve.",
"executionDelay": 302400,
"challengeDelay": 302400,
"sentiment": "good",
"orderHint": null,
"initialBond": {
"value": "0.08"
},
"permissioned": false,
"defenderAdvantage": {
"multiplier": 0.9133003936324697,
"multiplier": 0.9133045034463422,
"shape": "linear"
},
"secondLine": "3d 12h challenge period\n+ 3d 12h execution delay"
},
"exitWindow": {
"value": "None",
"description": "There is no exit window for users to exit in case of unwanted upgrades as they are initiated by the Security Council with instant upgrade power and without proper notice.",
"sentiment": "bad",
"orderHint": -604800
},
"proposerFailure": {
"value": "Self propose",
"description": "Anyone can be a Proposer and propose new roots to the L1 bridge.",
"sentiment": "good",
"orderHint": 0
},
"dataAvailability": {
"value": "Onchain",
"description": "All of the data needed for proof construction is published on Ethereum L1.",
"sentiment": "good",
"orderHint": null
},
"sequencerFailure": {
"value": "Self sequence",
"description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There can be up to a 12h delay on this operation.",
"sentiment": "good",
"orderHint": 43200,
"secondLine": "12h delay"
}
},
"self": {
"stateValidation": {
"value": "None",
"description": "Currently the system permits invalid state roots. More details in project overview.",
"sentiment": "bad",
"orderHint": null
},
"dataAvailability": {
"value": "Onchain",
"description": "All of the data needed for proof construction is published on Ethereum L1.",
"sentiment": "good",
"orderHint": null
},
"exitWindow": {
"value": "None",
"description": "There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.",
"sentiment": "bad",
"orderHint": 0
},
"sequencerFailure": {
"value": "Self sequence",
"description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There is no delay on this operation.",
"sentiment": "good",
"orderHint": 0
},
"proposerFailure": {
"value": "Cannot withdraw",
"description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
"sentiment": "bad",
"orderHint": null
}
},
"stacked": {
"stateValidation": {
"value": "None",
"description": "Currently the system permits invalid state roots. More details in project overview.",
"sentiment": "bad",
"orderHint": null
},
"dataAvailability": {
"value": "Onchain",
"description": "All of the data needed for proof construction is published on the base chain, which ultimately gets published on Ethereum.",
"sentiment": "good",
"orderHint": null
},
"exitWindow": {
"value": "None",
"description": "There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.",
"sentiment": "bad",
"orderHint": 0
},
"sequencerFailure": {
"value": "Self sequence",
"description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There can be up to a 12h delay on this operation.",
"sentiment": "good",
"orderHint": 43200
},
"proposerFailure": {
"value": "Cannot withdraw",
"description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
"sentiment": "bad",
"orderHint": null
}
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp-preu16",
"dataAvailability": [
{
"name": "Data required to compute fraud proof is published offchain without onchain attestations",
"description": "The project relies on DA challenges for data availability. If a DA challenger finds that the data behind a tx data commitment is not available,\n they can submit a challenge which requires locking a bond within 12h. A challenge can be resolved by publishing the preimage data within an additional 12h.\n In such a case, a portion of the challenger bond is burned, with the exact amount estimated as the cost incurred by the resolver to publish the full data,\n meaning that the resolver and challenger will approximately lose the same amount of funds. The system is not secure if the malicious sequencer is able to outspend the altruistic challengers. If instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state. This mechanism fully depends on the derivation rule of the L2 node and can only be verified in its source code, which [can be reviewed here](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.4).",
"references": [
{
"title": "OP Plasma specification",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md"
},
{
"title": "Universal Plasma and DA Challenges - Ethresear.ch",
"url": "https://ethresear.ch/t/universal-plasma-and-da-challenges/18629"
},
{
"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/0xfF00000000000000000000000000000000001d88#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "the sequencer is malicious and is able to economically outspend the altruistic challengers."
},
{
"category": "Funds can be stolen if",
"text": "there is no challenger willing to challenge unavailable data commitments."
}
]
}
],
"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/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#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/0xe2F826324b2faf99E513D16D266c3F80aE87832B#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The dispute game commits to the placeholder absolute prestate from the OP Stack deployment template rather than to a reproducible op-program build for this chain. Security relies entirely on the permissioned proposer and challengers."
}+130 -1
+130 -1
null
{
"sequencing": {
"name": "Transactions are ordered by Ethereum validators and builders",
"description": "Ethereum uses proof-of-stake with 12-second slots. In each slot, one validator index is pseudo-randomly selected to propose a block, with selection probability proportional to effective stake. The proposer can construct and order the execution payload locally or outsource construction to specialized builders through off-protocol software such as MEV-Boost. With outsourced construction, a builder chooses the transactions and their ordering inside a candidate payload, while the proposer chooses among the bids it receives and signs the winning block.\n\nValidators attest to blocks and apply fork choice, but the attestation committees do not co-produce or pre-approve the transactions in a block. Block-building rights are permissionless: anyone can deposit at least 32 ETH and enter the activation queue, subject to the protocol's effective-balance churn limit.",
"sequencingSpec": {
"type": "sequencer-set",
"blockTime": {
"value": "12 seconds"
},
"proposerRotationTime": {
"value": "12 seconds",
"description": "One validator index is selected for every slot with probability proportional to its effective balance. A missed proposal leaves the slot empty."
},
"sequencerCount": {
"value": "895,669 validator indices",
"secondLine": "41.52 M ETH",
"description": "This snapshot is generated from Dune validator-day summaries and curated staking attribution. Lido stake is split among its node operators. Validator indices are not independent operators, and compounding validators can have different effective balances."
},
"blockProductionAccess": {
"value": "Open",
"sentiment": "good",
"description": "Anyone can deposit the minimum stake and join the activation queue without governance approval. Activation remains subject to protocol churn limits."
},
"stakePerValidator": {
"value": "32 ETH minimum, variable",
"description": "Compounding validators can have an effective balance of up to 2,048 ETH. Proposal probability is weighted by effective balance."
},
"rateLimit": {
"value": "256 ETH per epoch",
"description": "Validator activation is limited by an effective-balance churn cap. An epoch contains 32 slots and lasts 6m 24s."
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning",
"description": "Ethereum mainnet does not currently enforce a forced-transaction queue or inclusion list. Inclusion-list proposals such as FOCIL are not live on mainnet."
},
"additionalCrGadgets": {
"value": "Local block building, diverse operators",
"sentiment": "warning",
"description": "A proposer can build locally to include public-mempool transactions instead of accepting an external builder bid. This bypasses censoring builders and relays, but users cannot compel the proposer to use the fallback. Combining a highly decentralized operator set with per-slot proposer rotation results in short inclusion delays under selective censorship."
},
"inclusionDelayChart": {
"type": "ethereumlike",
"validatorCount": 895669,
"slotSeconds": 12,
"target": 0.99,
"maxCensorFraction": 0.5,
"stakeDistribution": {
"stakeToken": "ETH",
"dateType": "snapshot",
"date": "2026-08-05",
"validatorCount": 895669,
"totalStake": 41527609,
"entities": [
{
"name": "Binance",
"stake": 3286314
},
{
"name": "ether.fi",
"stake": 1670699
},
{
"name": "Coinbase",
"stake": 1611518
},
{
"name": "Figment",
"stake": 1603374
},
{
"name": "Kraken",
"stake": 1382551
},
{
"name": "Blockdaemon",
"stake": 1293324
},
{
"name": "Everstake",
"stake": 944352
},
{
"name": "Kiln",
"stake": 722755
},
{
"name": "Upbit",
"stake": 611168
},
{
"name": "P2P.org",
"stake": 572913
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship as independent stake-weighted proposer opportunities. It assumes an honest proposer can include the transaction, whether through an external builder or local block production. It excludes validator and builder concentration, finality, validator-set changes, inactivity leaks, and a full halt."
},
"censorshipResistance": "Ethereum has no deterministic forced-inclusion mechanism on mainnet. Its live-chain censorship resistance comes from rotating stake-weighted proposers and from a selected proposer retaining the option to construct a block locally instead of using an external builder.\n\n### Selective censorship\n\nA user can broadcast a transaction to the public mempool and wait for a proposer, or a builder selected by that proposer, that is willing to include it. Each non-censoring stake-weighted proposer slot is another probabilistic inclusion opportunity. An honest proposer can use local block production if its connected builders or relays censor the transaction, but the user cannot force this choice and there is no bounded protocol delay.\n\n### Blanket censorship\n\nIf the active proposer set continues producing blocks while coordinating to censor a transaction, Ethereum has no protocol queue or live inclusion list that the user can invoke to bypass it. Depositing 32 ETH only enters the activation queue and does not grant immediate proposal rights.\n\n### Walkaway\n\nIf enough validators go offline to stop finality while some blocks are still produced, inactivity penalties reduce the weight of offline validators until the remaining online stake can finalize again. If all block production stops, the chain cannot process new validator deposits or activations. Ethereum has no external settlement layer to exit to, so recovery from a complete halt requires existing validators to return or social coordination around a client restart or fork.",
"references": [
{
"title": "Ethereum.org - Block proposal",
"url": "https://ethereum.org/developers/docs/consensus-mechanisms/pos/block-proposal/"
},
{
"title": "Ethereum consensus specifications - Electra",
"url": "https://ethereum.github.io/consensus-specs/electra/beacon-chain/"
},
{
"title": "EIP-7251 - Increase the MAX_EFFECTIVE_BALANCE",
"url": "https://eips.ethereum.org/EIPS/eip-7251"
},
{
"title": "MEV-Boost",
"url": "https://github.com/flashbots/mev-boost"
},
{
"title": "Ethereum.org - Proof-of-stake rewards and penalties",
"url": "https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "proposers or their selected builders keep excluding their transactions, or block production halts and requires social recovery."
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp-preu16",
"dataAvailability": [
{
"name": "Data required to compute fraud proof is published offchain without onchain attestations",
"description": "The project relies on DA challenges for data availability. If a DA challenger finds that the data behind a tx data commitment is not available,\n they can submit a challenge which requires locking a bond within 12h. A challenge can be resolved by publishing the preimage data within an additional 12h.\n In such a case, a portion of the challenger bond is burned, with the exact amount estimated as the cost incurred by the resolver to publish the full data,\n meaning that the resolver and challenger will approximately lose the same amount of funds. The system is not secure if the malicious sequencer is able to outspend the altruistic challengers. If instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state. This mechanism fully depends on the derivation rule of the L2 node and can only be verified in its source code, which [can be reviewed here](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7).",
"references": [
{
"title": "OP Plasma specification",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md"
},
{
"title": "Universal Plasma and DA Challenges - Ethresear.ch",
"url": "https://ethresear.ch/t/universal-plasma-and-da-challenges/18629"
},
{
"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/0xfF00000000000000000000000000000084BB84Bb#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "the sequencer is malicious and is able to economically outspend the altruistic challengers."
},
{
"category": "Funds can be stolen if",
"text": "there is no challenger willing to challenge unavailable data commitments."
}
]
}
],
"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/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#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/0xe2F826324b2faf99E513D16D266c3F80aE87832B#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The dispute game commits to the placeholder absolute prestate from the OP Stack deployment template rather than to a reproducible op-program build for this chain. Security relies entirely on the permissioned proposer and challengers."
}+22 -12
+22 -12
{
"dataAvailability": [
{
"name": "Transaction data is stored on Gnosis Chain",
"description": "Gnosis Chain transaction data is published to Gnosis Chain and propagated by its validator and node network. The Ethereum bridge contracts do not verify data availability and only process bridge messages after bridge-validator signatures are submitted.",
"references": [
{
"title": "Gnosis specifications",
"url": "https://docs.gnosischain.com/about/specs/"
}
],
"risks": [
{
"category": "Funds can be frozen if",
"text": "transaction data is unavailable and bridge validators cannot reconstruct or sign the messages needed to exit."
}
]
}
],
"detailedDescription": "Gnosis chain in its current form does not derive or benefit from Ethereum's decentralisation apart from being developed as a close fork to re-use Ethereum tooling and infrastructure. Its censorship resistance relies on an open validator set with over 100 thousand diverse validators, although the clustering and stake distribution among entities is intransparent. Users who are censored selectively on an otherwise live network benefit from the fast 5s block time and non-committee-gated, stake-weighted proposer rotation, resulting in an inclusion probability of 99% in less than a minute even if up to 50% of the Gnosis stake is censoring them. There are also a few thousand validators who run custom 'shutter network' nodes that support threshold-encrypted transactions. For a case of active blanket censorship (>50% stake) by all current validators, users have no way apart from a hardfork to get their transactions included or save the chain. In the operator walkaway scenario, new sequencers could stake and join the set permissionlessly.",
"detailedDescription": "Gnosis chain in its current form does not derive or benefit from Ethereum's decentralisation apart from being developed as a close fork to re-use Ethereum tooling and infrastructure. Its censorship resistance relies on an open set of 52,352 active validator indices, although the clustering and stake distribution among entities is intransparent. Users who are censored selectively on an otherwise live network benefit from the fast 5s block time and non-committee-gated, stake-weighted proposer rotation, resulting in an inclusion probability of 99% in less than a minute even if up to 50% of the Gnosis stake is censoring them. There are also a few thousand validators who run custom 'shutter network' nodes that support threshold-encrypted transactions. For a case of active blanket censorship (>50% stake) by all current validators, users have no way apart from a hardfork to get their transactions included or save the chain. In the operator walkaway scenario, new sequencers could stake and join the set permissionlessly.",
"otherConsiderations": [
{
"name": "Encrypted mempool (Shutter Network Beta)",
"description": "A subset of Gnosis Chain validators is currently running a modified node version that supports threshold-encrypted transaction payloads. This allows to 'encrypt the mempool' and protect against malicious MEV and censorship with significant caveats. To encrypt the transaction, users have to either use custom wallets or a trusted encrypting rpc proxy. Decryption is handled by participating validators sharing their decryption key shares at the target block, allowing the proposer to decrypt the transaction and include and execute (or censor) it.",
"references": [
{
"title": "Shutterized Gnosis Chain Beta Release",
"url": "https://blog.shutter.network/shutterized-gnosis-chain-is-now-live/"
},
{
"title": "Gnosis Docs: Shutterized Gnosis Chain",
"url": "https://docs.gnosischain.com/shutterized-gc/"
}
],
"risks": []
},
{
"name": "Destination tokens can be upgradeable",
"description": "Omnibridge uses token factories to deploy wrapped ERC20 representations for assets native to the other chain. The token factory owner can change the implementation used for newly deployed wrapped tokens.",
"references": [
{
"title": "Omnibridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/omnibridge"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "a malicious or vulnerable wrapped token implementation is configured for newly bridged assets."
}
]
}
],
"sequencing": {
"name": "Transactions are ordered by Gnosis Chain validators",
"description": "Gnosis Chain uses a permissionless proof-of-stake validator set with stake-weighted proposer rotation and a 5 second slot time. The Ethereum-like committee-free block production architecture combined with the short block time lead to fast theoretical inclusion times, even with high rates of censorship. In contrast to Ethereum, blocks on Gnosis chain are usually built *locally*, meaning that validators do not delegate block production to specialised builders. There is no public information on the decentralisation of the Gnosis validator set.",
"sequencerSetSpec": {
"sequencingSpec": {
"type": "sequencer-set",
"blockTime": {
"value": "5s"
},
"proposerRotationTime": {
"value": "5s",
"description": "Block production is not committee-based, sequencers rotate every block (epochs do not affect sequencer rotation)"
},
"sequencerCount": {
"value": "100,000 validators"
"value": "52,352 validator indices",
"secondLine": "300.64 K GNO",
"description": "The active-ongoing validator count and effective stake snapshot are generated from the corresponding Gnosis Analytics endpoints for the same date. Validator indices are not independent operators."
},
"blockProductionAccess": {
"value": "Open",
"sentiment": "good"
},
"stakePerValidator": {
"value": "1 GNO minimum, variable",
"description": "stake-weighted block production rights, no maximum"
},
"rateLimit": {
"value": "~1-2 GNO per epoch",
"description": "defined by the consensus clients"
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "Shutter encrypted mempool beta",
"sentiment": "warning"
}
},
"inclusionDelayChart": {
"type": "ethereumlike",
"validatorCount": 52352,
"slotSeconds": 5,
"target": 0.99,
"maxCensorFraction": 0.5,
"stakeDistribution": {
"stakeToken": "GNO",
"dateType": "snapshot",
"date": "2026-08-05",
"validatorCount": 52352,
"totalStake": 300643
}
},
"inclusionDelayChartDescription": "The chart uses the Ethereum-style single-proposer formula with Gnosis-specific constants. It excludes finality, inactivity leaks, validator-set changes, hard forks, and blanket-censorship resistance gadgets."
},
"inclusionDelayChart": {
"type": "ethereumlike",
"validatorCount": 100000,
"slotSeconds": 5,
"target": 0.99,
"maxCensorFraction": 0.5
},
"inclusionDelayChartDescription": "The chart uses the Ethereum-style single-proposer formula with Gnosis-specific constants. It excludes finality, inactivity leaks, validator-set changes, hard forks, and blanket-censorship resistance gadgets.",
"censorshipResistance": "Gnosis Chain does not have dedicated censorship resistance gadgets, but the sequencer set is open and there are no committees that can block inclusion.\n### Selective censorship\nEven with high percentages of stake censoring, users have very fast inclusion times. There are also initial tests of an out-of-protocol solution for encrypting transactions in the mempool (Shutterized Gnosis Chain).\n### Blanket censorship\nThere is no way to circumvent the validator set from Ethereum in a case of active censorship by all (or a majority of) validators.\n### Walkaway\nSince the validator set is open, new validators can join it in case validators passively stop block production. If all validators stop at the same time, a social recovery and hard fork would be necessary.",
"references": [
{
"title": "Gnosis Chain specifications",
"url": "https://docs.gnosischain.com/about/specs/"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "at least half of the active stake censors them, or if current validators coordinate blanket censorship and the chain requires social recovery."
}
]
},
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "Gnosis Chain is an independent proof-of-stake chain. Ethereum contracts do not check whether Gnosis state transitions are valid. Cross-chain messages are executed when the relevant bridge contract receives enough validator signatures: 4/7 for the xDAI bridge and 4/7 for AMB and Omnibridge.",
"references": [
{
"title": "xDAI Bridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/xdai-bridge"
},
{
"title": "Omnibridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/omnibridge"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "bridge validators sign fraudulent messages that release more assets on Ethereum than were burned or locked on Gnosis."
},
{
"category": "Funds can be stolen if",
"text": "the Gnosis validator set finalizes an invalid chain state and the bridge validators sign messages derived from it."
},
{
"category": "Funds can be frozen if",
"text": "bridge validators stop signing messages or Gnosis Chain stops finalizing blocks."
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp-preu16",
"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/0x0004cb44C80b6Fbf8ceb1d80AF688C9f7C0b2aB5#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x18A7868ECe35A45aC9138108E5b6e021aD1038d1#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 3d 12h 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/0x18A7868ECe35A45aC9138108E5b6e021aD1038d1#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x18A7868ECe35A45aC9138108E5b6e021aD1038d1#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/0x18A7868ECe35A45aC9138108E5b6e021aD1038d1#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/hashkeychain.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/hashkeychain.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the superchain registry snapshot embedded in the op-program release that the dispute games commit to, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
}+2 -2
+1 -1
{
"self": {
"stateValidation": {
"value": "Fraud proofs (INT)",
"description": "Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve.",
"executionDelay": 302400,
"challengeDelay": 302400,
"sentiment": "good",
"orderHint": null,
"initialBond": {
"value": "0.08"
},
"permissioned": false,
"defenderAdvantage": {
"multiplier": 0.9133003936324697,
"multiplier": 0.9133045034463422,
"shape": "linear"
},
"secondLine": "3d 12h challenge period\n+ 3d 12h execution delay"
},
"exitWindow": {
"value": "None",
"description": "There is no exit window for users to exit in case of unwanted upgrades as they are initiated by the Security Council with instant upgrade power and without proper notice.",
"sentiment": "bad",
"orderHint": -604800
},
"proposerFailure": {
"value": "Self propose",
"description": "Anyone can be a Proposer and propose new roots to the L1 bridge.",
"sentiment": "good",
"orderHint": 0
},
"dataAvailability": {
"value": "Onchain",
"description": "All of the data needed for proof construction is published on Ethereum L1.",
"sentiment": "good",
"orderHint": null
},
"sequencerFailure": {
"value": "Self sequence",
"description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There can be up to a 12h delay on this operation.",
"sentiment": "good",
"orderHint": 43200,
"secondLine": "12h delay"
}
}
}+1 -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/0x005969bf0EcbF6eDB6C47E5e94693b1C3651Be97#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/ink.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/ink.json.zst).",
"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)).",
"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.23 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp-preu16",
"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/0xFf00000000000000000000000000000000001135#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#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/0xe2F826324b2faf99E513D16D266c3F80aE87832B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B#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/0xe2F826324b2faf99E513D16D266c3F80aE87832B#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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 32, 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 32, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the superchain registry snapshot embedded in the op-program release that the dispute games commit to, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain-opfp",
"dataAvailability": [
{
"name": "Data is posted to Celestia",
"description": "Transactions roots are posted onchain and the full data is posted on Celestia. Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots. If Celestia becomes unavailable, the sequencer falls back to Ethereum.",
"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": "Introducing Blobstream: streaming modular DA to Ethereum",
"url": "https://blog.celestia.org/introducing-blobstream/"
},
{
"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/0x5f7f7f6DB967F0ef10BdA0678964DBA185d16c50#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The dispute game commits to an op-program release that predates the Jovian hardfork active on the chain, so it cannot derive current blocks and no dispute can be resolved correctly by execution. Security relies entirely on the permissioned proposer and challengers."
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0xc83f7D9F2D4A76E81145849381ABA02602373723#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/metal.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/metal.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The permissioned dispute game commits to a placeholder absolute prestate (0xdead…) set by OP Stack Upgrade 19, so no dispute can be resolved by execution. Security relies entirely on the permissioned proposer and challenger."
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp-preu16",
"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/0x4e31448a098393727b786e25B54E59DcA1b77FE1#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x8953eCB2AAbB9260662241eC505250A1C63eF776#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/0x8953eCB2AAbB9260662241eC505250A1C63eF776#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x8953eCB2AAbB9260662241eC505250A1C63eF776#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/0x8953eCB2AAbB9260662241eC505250A1C63eF776#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://api.conduit.xyz/file/v1/optimism/rollup/mint-mainnet-0).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://api.conduit.xyz/file/v1/optimism/genesis/mint-mainnet-0).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x24E59d9d3Bd73ccC28Dc54062AF7EF7bFF58Bd67#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/mode.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/mode.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The permissioned dispute game commits to a placeholder absolute prestate (0xdead…) set by OP Stack Upgrade 19, so no dispute can be resolved by execution. Security relies entirely on the permissioned proposer and challenger."
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain-opfp",
"dataAvailability": [
{
"name": "Data is posted to Celestia",
"description": "Transactions roots are posted onchain and the full data is posted on Celestia. Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots.",
"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": "Introducing Blobstream: streaming modular DA to Ethereum",
"url": "https://blog.celestia.org/introducing-blobstream/"
},
{
"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/0x00F57326D44451ea7Cd8aDBb2B27573C81BD060b#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the op-program superchain registry, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
}+89 -2
+1 -1
{
"self": {
"stateValidation": {
"value": "Fraud proofs (INT)",
"description": "Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve.",
"executionDelay": 302400,
"challengeDelay": 302400,
"sentiment": "good",
"orderHint": null,
"initialBond": {
"value": "0.08"
},
"permissioned": false,
"defenderAdvantage": {
"multiplier": 0.9133003936324697,
"multiplier": 0.9133045034463422,
"shape": "linear"
},
"secondLine": "3d 12h challenge period\n+ 3d 12h execution delay"
},
"exitWindow": {
"value": "None",
"description": "There is no exit window for users to exit in case of unwanted upgrades as they are initiated by the Security Council with instant upgrade power and without proper notice.",
"sentiment": "bad",
"orderHint": -604800
},
"proposerFailure": {
"value": "Self propose",
"description": "Anyone can be a Proposer and propose new roots to the L1 bridge.",
"sentiment": "good",
"orderHint": 0
},
"dataAvailability": {
"value": "Onchain",
"description": "All of the data needed for proof construction is published on Ethereum L1.",
"sentiment": "good",
"orderHint": null
},
"sequencerFailure": {
"value": "Self sequence",
"description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There can be up to a 12h delay on this operation.",
"sentiment": "good",
"orderHint": 43200,
"secondLine": "12h delay"
}
}
}+88 -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"
}
]
}
],
"sequencing": {
"name": "Transactions are ordered by a centralized sequencer",
"description": "OP Mainnet uses a single centralized sequencer for fast confirmations. Users can bypass it with one Ethereum transaction to the OptimismPortal. Rollup nodes derive the deposited transaction from Ethereum, including it after at most one sequencing window.",
"sequencingSpec": {
"type": "centralized",
"trustedPreconfirmation": {
"value": "250 ms",
"secondLine": "2 s L2 block time",
"description": "The centralized sequencer streams cumulative Flashblock preconfirmations every 250 ms while sealing regular L2 blocks every 2 seconds. Flashblocks are out of protocol: the promise has no protocol enforcement or slashing, and 250 ms is a target that can vary with execution load.",
"orderHint": 0.25
},
"trustedOrdering": {
"value": "Dynamic priority auction",
"secondLine": "Fee order per Flashblock",
"description": "For each 250 ms build loop, the centralized builder selects available transactions by priority fee. Transactions committed to an earlier Flashblock are not reordered when a higher-fee transaction arrives later, so arrival time also affects ordering. This policy is not enforced by the derivation rules."
},
"sequencer": {
"value": "Centralized",
"secondLine": "Raft HA",
"sentiment": "bad",
"description": "The OP Mainnet operator controls real-time ordering. They run redundant sequencer instances coordinated by op-conductor using Raft leader election, with only the leader producing blocks. op-conductor explicitly assumes all nodes are honest and is not Byzantine fault tolerant, so the replicas do not create independent operators or censorship resistance.",
"orderHint": 1
},
"realtimeCensorshipResistance": {
"value": "No",
"sentiment": "bad",
"description": "The centralized sequencer can censor transactions submitted through the normal L2 path."
},
"forcedInclusion": {
"value": "Automatic derivation",
"secondLine": "1 L1 tx: portal deposit",
"sentiment": "good",
"description": "The user submits one Ethereum transaction to the OptimismPortal which is automatically derived by conforming nodes."
},
"inclusionDelay": {
"value": "12 hours",
"secondLine": "3,600 L1 blocks",
"sentiment": "good",
"description": "The static sequencing window is measured in Ethereum blocks.",
"orderHint": 3600
},
"inclusionMechanics": {
"value": "1 L1 Tx",
"secondLine": "Address alias",
"description": "Forced inclusion creates an L1-originated deposit transaction rather than submitting the original signed L2 transaction. Its calldata is capped at 120,000 bytes, its minimum L2 gas limit is 21,000 plus 40 gas per calldata byte, and deposits share a metered 20,000,000 gas resource limit per Ethereum block. L1 contract callers use an aliased address on L2."
},
"exitDelay": {
"value": "21 days 3 hours",
"secondLine": "12h inclusion + 20d 15h state",
"description": "After successful L2 inclusion (forced or sequencer), the user can propose the state needed to exit by creating a permissionless fault dispute game. A maximally delayed challenge path can take up to 17 days 3 hours: both teams' 3 days 12 hours chess clocks plus up to 10 days 3 hours of cumulative clock extensions. This is followed by the 3 days 12 hours finality air gap. Parallel branches increase the transactions and gas needed to defend and resolve the game. The 7 days withdrawal-proof maturity period runs concurrently.",
"orderHint": 1825200
},
"exitEconomics": {
"value": "0.08 ETH",
"secondLine": "Favors attacker 1.09×",
"description": "Self-proposing the state needed for an exit starts with a 0.08 ETH bond. If challenged, the user must defend it with progressively larger bonds: each counterclaim costs 1.09 times the claim it counters, favoring the attacker in a capital-exhaustion attack."
}
},
"censorshipResistance": "The centralized sequencer provides no real-time censorship resistance. The Ethereum deposit path provides eventual censorship resistance, assuming the deposit is included on Ethereum.",
"references": [
{
"title": "OP Stack specification - sequencing window",
"url": "https://specs.optimism.io/protocol/overview.html#epochs-and-the-sequencing-window"
},
{
"title": "OP Mainnet documentation - Flashblocks",
"url": "https://docs.optimism.io/op-stack/features/flashblocks"
},
{
"title": "OP Stack documentation - Conductor",
"url": "https://docs.optimism.io/chain-operators/tools/op-conductor"
},
{
"title": "OP Mainnet documentation - transaction fees",
"url": "https://docs.optimism.io/op-stack/transactions/fees"
},
{
"title": "OptimismPortal2 - source code",
"url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
},
{
"title": "OP Stack specification - fault dispute game resolution",
"url": "https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html#resolution"
}
],
"risks": []
},
"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)).",
"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.23 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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.",
"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()`."
}
}
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain-opfp",
"dataAvailability": [
{
"name": "Data is posted to Celestia",
"description": "Transactions roots are posted onchain and the full data is posted on Celestia. Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots. If Celestia becomes unavailable, the sequencer falls back to Ethereum.",
"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": "Introducing Blobstream: streaming modular DA to Ethereum",
"url": "https://blog.celestia.org/introducing-blobstream/"
},
{
"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/0x08aA34cC843CeEBcC88A627F18430294aA9780be#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xe89F13c5ee4033B2D3cD76C9d6958eFBfe26D3C2#code"
}
]
}
],
"detailedDescription": "While ETH deposited to Orderly is using an OP Stack canonical bridge, the multichain USDC escrows are sending / receiving their deposit / withdrawal messages through the external LayerZero v1 AMB.",
"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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The dispute game commits to an op-program release that predates the Jovian hardfork active on the chain, so it cannot derive current blocks and no dispute can be resolved correctly by execution. Security relies entirely on the permissioned proposer and challengers."
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x5A2a0698355D06cd5c4e3872D2Bc6B9f6a89d39B#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the superchain registry snapshot embedded in the op-program release that the dispute games commit to, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
}+63 -58
+63 -58
{
"otherConsiderations": [
{
"name": "Destination tokens are upgradeable",
"description": "Tokens transferred end up as wrapped ERC20 proxies, some of them are upgradable. The contract is named UChildERC20Proxy.",
"references": [],
"risks": [
{
"category": "Funds can be stolen if",
"text": "destination token contract is maliciously upgraded."
}
],
"isIncomplete": true
}
],
"sequencing": {
"name": "Transactions are ordered by Polygon PoS validators",
"description": "Polygon PoS is operated by a closed proof-of-stake validator set with 105 active validators. Block production rights are given to validators randomly (stake-weighted) for the duration of a *span*. In practice, validators delegate the block production further to centralised validator-elected block producers (VeBloPs). Ethereum smart contracts accept checkpoints signed by more than two thirds of Polygon PoS validator stake.",
"sequencerSetSpec": {
"sequencingSpec": {
"type": "sequencer-set",
"blockTime": {
"value": "2s"
},
"proposerRotationTime": {
"value": "3h 33m",
"description": "Randomly sampled validators delegate block production for the duration of a span: 6400 blocks"
},
"sequencerCount": {
"value": "105 validators"
"value": "105 validators",
"secondLine": "3.56 B POL"
},
"blockProductionAccess": {
"value": "Closed and capped",
"sentiment": "bad",
"description": "The current validator cap is 105. Joining the set is permissioned (Multisig)."
},
"stakePerValidator": {
"value": "100,000 POL minimum, variable",
"description": "stake-weighted block production rights, no maximum"
},
"rateLimit": {
"value": "No (permissioned)"
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "No",
"sentiment": "bad"
}
},
"inclusionDelayChart": {
"type": "spanlike",
"validatorCount": 105,
"spanBlocks": 6400,
"blockSeconds": 2,
"target": 0.99,
"maxCensorFraction": 0.33,
"stakeDistribution": {
"stakeToken": "POL",
"dateType": "fetched",
"date": "2026-08-06T08:48:58.389Z",
"validatorCount": 105,
"totalStake": 3568595994,
"entities": [
{
"name": "Upbit Staking",
"stake": 417333126
},
{
"name": "Coinbase",
"stake": 367924777
},
{
"name": "Luganodes",
"stake": 257764644
},
{
"name": "Anonymous 194",
"stake": 245101958
},
{
"name": "Binance Node",
"stake": 228831375
},
{
"name": "Figment",
"stake": 226258957
},
{
"name": "Matic Power",
"stake": 207786330
},
{
"name": "Blockdaemon",
"stake": 181198908
},
{
"name": "Kraken",
"stake": 164408175
},
{
"name": "Anonymous 95",
"stake": 150542747
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship only. Since proposing is stake-weighted, the x-axis represents the censoring POL stake, and does not cover validator-set changes, or blanket-censorship resistance gadgets."
},
"inclusionDelayChart": {
"type": "spanlike",
"validatorCount": 105,
"spanBlocks": 6400,
"blockSeconds": 2,
"target": 0.99,
"maxCensorFraction": 0.33,
"stakeDistribution": {
"stakeToken": "POL",
"totalStake": 3578982515,
"entities": [
{
"name": "Upbit Staking",
"stake": 417333126
},
{
"name": "Coinbase",
"stake": 366375736
},
{
"name": "Luganodes",
"stake": 258378187
},
{
"name": "Anonymous 194",
"stake": 244531424
},
{
"name": "Binance Node",
"stake": 236806959
},
{
"name": "Figment",
"stake": 226257073
},
{
"name": "Matic Power",
"stake": 207786330
},
{
"name": "Blockdaemon",
"stake": 181375563
},
{
"name": "Kraken",
"stake": 158562769
},
{
"name": "Anonymous 95",
"stake": 146004660
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship only. Since proposing is stake-weighted, the x-axis represents the censoring POL stake, and does not cover validator-set changes, or blanket-censorship resistance gadgets.",
"censorshipResistance": "The validator set (on Polygon PoS, validators are both proposers and sequencers) is closed and capped, but includes a diverse set of known entities who share block production rights. There are no specific censorship resistance gadgets built into the protocol.\n### Selective censorship\nAs long as the Polygon PoS blockchain is producing blocks, users can expect to include their transactions due to the rotating, diverse block producers, even if they are censored by some of them. Unfortunately, the rotation is very slow (see *span* time) and even just a few entities censoring can cause long inclusion delays.\n### Blanket censorship\nValidators holding more than 1/3 of Polygon PoS stake among them can censor users if they actively refuse to attest to blocks with their transactions. Polygon Multisig controls the core smart contracts on Ethereum and can administer the validator set (including malicious changes) as a consequence.\n### Walkaway\nIf validators holding more than 1/3 of the stake on Polygon PoS stop block production, the chain stops and there is no way for users to include any transactions. As the validator set is currently closed by a permissioned smart contract setting on ethereum, walkaway of the permissioned actor would require social coordination and a hard fork to progress the chain.",
"references": [
{
"title": "Polygon PoS architecture documentation",
"url": "https://docs.polygon.technology/pos/architecture/"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "the active span proposer censors them, or if at least one third of Polygon PoS stake refuses to attest blocks that include their transactions."
}
]
},
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "State updates are settled on Ethereum if signed by at least 2/3+1 of the Polygon PoS validators stake. Contracts on Ethereum do not check whether the state transitions are valid.",
"references": [],
"risks": [
{
"category": "Users can be censored if",
"text": "validators on Polygon decide to not mint tokens after observing an event on Ethereum."
},
{
"category": "Funds can be stolen if",
"text": "validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum."
},
{
"category": "Funds can be stolen if",
"text": "validators submit a fraudulent checkpoint allowing themselves to withdraw all locked funds."
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x0bd57e83B5E0f9eCD84d559bB58e1EcFEEdD2565#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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://api.conduit.xyz/file/v1/optimism/rollup/polynomial-mainnet-0).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://api.conduit.xyz/file/v1/optimism/genesis/polynomial-mainnet-0).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x003E40D3125591bD722aB1bB880c78e4D74d0977#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0xfF00000000000000000000000000000000000360#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/shape.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/shape.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain-opfp-preu16",
"dataAvailability": [
{
"name": "Data is not stored on chain",
"description": "The transaction data is not recorded on the Ethereum main chain.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the external data becomes unavailable.",
"isCritical": true
}
],
"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/0x00a7a8fDb9A61f85DD8F926f4e1723927a18c9F3#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x2D7e764a0D9919e16983a46595CfA81fc34fa7Cd#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/0x2D7e764a0D9919e16983a46595CfA81fc34fa7Cd#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x2D7e764a0D9919e16983a46595CfA81fc34fa7Cd#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/0x2D7e764a0D9919e16983a46595CfA81fc34fa7Cd#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": [],
"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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp-preu16",
"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/0xFeC57BD3729a5F930d4Ee8ac5992Fdc8988426e4#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#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/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#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/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#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/snax.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/snax.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x008dC74CecC9dedA8595B2Fe210cE5979F0BfA8e#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/soneium.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/soneium.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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",
"warning": "The fault proof system is deployed but is not functional. The permissioned dispute game commits to a placeholder absolute prestate (0xdead…) set by OP Stack Upgrade 19, so no dispute can be resolved by execution. Security relies entirely on the permissioned proposer and challenger."
}+119 -1
+1 -1
{
"missing": {
"nextStage": "Stage 2",
"requirements": [
"Upgrades unrelated to onchain provable bugs provide less than 30d to exit.",
"The Security Council's actions are not confined to onchain provable bugs."
]
},
"stage": "Stage 1",
"stage1PrincipleDescription": "While Starknet is considered Stage 1, the Security Council minority is employed to enforce censorship resistance in case the permissioned operator fails to include transactions. The process through which a censored user can contact the Security Council is not defined and currently unclear.",
"stage1PrincipleDescription": "While Starknet is considered Stage 1, the Security Council minority provides a discretionary fallback when the permissioned operator fails to include transactions. The process through which a censored user can contact the Security Council is not defined, and the council has no protocol deadline to respond.",
"summary": [
{
"stage": "Stage 0",
"requirements": [
{
"satisfied": true,
"description": "A complete and functional proof system is deployed."
},
{
"satisfied": true,
"description": "The project calls itself a rollup."
},
{
"satisfied": true,
"description": "State roots are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "Inputs for the state transition function are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "A source-available node exists that can recreate the state from Ethereum L1 data. Please note that the L2BEAT team has not verified the validity of the node source code. [View code](https://github.com/eqlabs/pathfinder)"
}
]
},
{
"stage": "Stage 1",
"requirements": [
{
"satisfied": true,
"description": "Users are able to exit without the help of the permissioned operators."
},
{
"satisfied": true,
"description": "In case of an unwanted upgrade by actors more centralized than a Security Council, users have at least 7d to exit."
},
{
"satisfied": true,
"description": "The Security Council is properly set up [(List of members)](https://docs.starknet.io/learn/protocol/security-council)."
},
{
"satisfied": true,
"description": "The proof system meets the minimum trusted setup requirements defined in the L2BEAT [trusted setup assessment framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381)."
},
{
"satisfied": true,
"description": "Prover source code is published."
},
{
"satisfied": true,
"description": "Onchain verifiers' smart contracts can be independently regenerated from the verifier source code."
},
{
"satisfied": true,
"description": "The sources of all programs used are public and program hashes can be independently regenerated."
}
],
"principle": {
"satisfied": true,
"description": "Compromising ≥75% of the Security Council is the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window."
}
},
{
"stage": "Stage 2",
"requirements": [
{
"satisfied": false,
"description": "Upgrades unrelated to onchain provable bugs provide less than 30d to exit."
},
{
"satisfied": false,
"description": "The Security Council's actions are not confined to onchain provable bugs."
}
]
}
]
}+118 -0
{
"dataAvailability": [
{
"name": "All data required to reconstruct rollup state is published on chain",
"description": "State diffs are publish onchain as blob or calldata on every state update. The state diffs contain information on every contact whose storage was updated, and additional information on contract deployments. From diffs full system state can be recovered. Contracts' code is not published on L1, but can be trustlessly verified if available elsewhere.",
"risks": [],
"references": [
{
"title": "On-Chain Data - Starknet documentation",
"url": "https://docs.starknet.io/architecture/data-availability/"
}
]
}
],
"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. Note that the message request can be censored by the Sequencer.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the operator censors withdrawal transaction."
}
],
"references": [
{
"title": "Withdrawing is based on l2 to l1 messages - Starknet documentation",
"url": "https://book.cairo-lang.org/ch16-04-L1-L2-messaging.html#sending-messages-from-starknet-to-ethereum"
}
]
},
{
"name": "Emergency exit",
"risks": [],
"description": "There is no generic escape hatch mechanism as Starknet cannot be forced by users into a frozen state. Note that a freezing mechanism on L2, to be secure, requires anti-censorship protection.",
"references": []
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "Censorship resistance of Starknet - Forum Discussion",
"url": "https://community.starknet.io/t/censorship-resistance/196"
}
]
},
"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. Typically, the Operator is the hot wallet of the Starknet service submitting state updates for which proofs have been already submitted and verified.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"sequencing": {
"name": "Transactions are ordered by centralized sequencers",
"description": "Starknet v0.14.3 uses 5 equal-weight, permissioned consensus sequencers controlled by StarkWare. A proposer is selected in deterministic round-robin order and builds from its own peer-to-peer synchronized mempool. The current deployment uses an honest-majority Tendermint configuration, requiring 3/5 votes to decide a block. This provides process-level redundancy, but no independence from StarkWare for ordering or preconfirmations.\n\nState advancement on Ethereum is a separate, also permissioned pipeline. Starknet OS execution tasks are proved and recursively aggregated through StarkWare's SHARP service, using Stwo for proving tasks and Stone for the roots of the recursive tree. After the resulting proof fact is registered on Ethereum, only the 2 Starknet Operators can update the canonical state: the service Operator and the Security Council minority.\n\nThere is no user-callable forced-inclusion function. A censored user can post an L1-to-L2 message and ask the Security Council minority to bypass consensus by including it in a valid, proven state update, but the contact and response process has no protocol deadline.",
"sequencingSpec": {
"type": "centralized",
"trustedPreconfirmation": {
"value": "500 ms",
"secondLine": "1.5s L2 block time",
"description": "The current proposer targets a PRE_CONFIRMED receipt in about 500 ms. It is a trusted promise before consensus decides the block, with no onchain enforcement or slashing, and can be reverted if the proposal does not become the consensus block. The 1.5-second L2 block time is a target: a block can close earlier when it reaches a resource limit or later while transactions are still executing or consensus takes longer.",
"orderHint": 0.5
},
"trustedOrdering": {
"value": "Priority gas auction",
"secondLine": "Higher explicit tips first",
"description": "The active proposer selects eligible transactions from its peer-to-peer synchronized mempool in descending tip order, with the transaction hash breaking equal-tip ties. Transactions whose gas-price bound is below the current threshold remain pending. This offchain policy is not enforced by Ethereum."
},
"sequencer": {
"value": "Centralized",
"secondLine": "5-node Tendermint",
"sentiment": "bad",
"description": "StarkWare controls 5 equal-weight, permissioned proposers selected in deterministic round-robin order. The deployment assumes no malicious validators and requires more than half of the voting weight (3/5). The replicas can tolerate process outages, but do not create independent operators or censorship resistance.",
"orderHint": 1
},
"realtimeCensorshipResistance": {
"value": "No",
"sentiment": "bad",
"description": "The permissioned sequencer committee is controlled by one operator, StarkWare, which can censor transactions submitted through the normal L2 path."
},
"forcedInclusion": {
"value": "Discretionary fallback",
"secondLine": "Security Council minority",
"sentiment": "bad",
"description": "There is no user-callable forced-inclusion function. A user can log an L1-to-L2 message with one Ethereum transaction and contact the Security Council minority. The council can then bypass sequencer consensus by participating in a valid, proven state update, but whether and when it does so is discretionary."
},
"inclusionDelay": {
"value": "Unbounded",
"secondLine": "No protocol deadline",
"sentiment": "bad",
"description": "The contracts impose no deadline for the Security Council minority to respond, for SHARP to prove the state transition, or for an Operator to post the state update.",
"orderHint": 9007199254740991
},
"inclusionMechanics": {
"value": "L1 log of intent",
"secondLine": "Permissioned inclusion",
"sentiment": "warning",
"description": "Logging a message creates an L1-originated L1-handler transaction rather than submitting the original signed L2 transaction. It does not automatically enter the canonical L2 order and has no other effect than recording the intent. The Security Council path must produce Starknet OS execution, data availability and an accepted SHARP proof before posting the state update. An unconsumed message can be cancelled through a two-call L1 process after a 5 days 1 minute 40 seconds delay."
},
"exitDelay": {
"value": "Unbounded",
"secondLine": "Council response + proving",
"sentiment": "bad",
"description": "Under operator failure, a user cannot independently advance the state needed for an exit. There is no deadline for the Security Council minority to act or for SHARP to produce the required proof. Once an accepted fact and valid state update reach Ethereum, there is no additional state-finalization delay.",
"orderHint": 9007199254740991
},
"exitEconomics": {
"value": "No self-service",
"secondLine": "STARK proof + council action",
"sentiment": "bad",
"description": "A user cannot self-propose state. Progress requires the recursive STARK proving pipeline and cooperation from a whitelisted Operator or the Security Council minority."
}
},
"censorshipResistance": "The permissioned sequencer committee provides no real-time censorship resistance. The Security Council minority can conditionally bypass consensus with a valid, proven state update, but because users cannot invoke this path and it has no deadline, Starknet provides no deterministic eventual censorship-resistance guarantee.",
"references": [
{
"title": "Starknet documentation - Transaction lifecycle",
"url": "https://docs.starknet.io/learn/protocol/transactions"
},
{
"title": "Starknet documentation - SHARP architecture",
"url": "https://docs.starknet.io/learn/protocol/sharp"
},
{
"title": "Starknet documentation - Current consensus centralization",
"url": "https://docs.starknet.io/learn/protocol/staking"
},
{
"title": "Starknet v0.14 - Tendermint and preconfirmations",
"url": "https://community.starknet.io/t/snip-30-v0-14-0/115756"
},
{
"title": "Starknet v0.14.3 - More frequent blocks",
"url": "https://community.starknet.io/t/snip-40-more-frequent-blocks/116203"
},
{
"title": "Apollo - Mainnet consensus committee configuration",
"url": "https://github.com/starkware-libs/sequencer/blob/5114457ad4b5d6d1764b520dfa40b9e826f48854/deployments/sequencer/configs/overlays/hybrid/mainnet/services/core.yaml#L13"
},
{
"title": "Apollo - Consensus runtime configuration",
"url": "https://github.com/starkware-libs/sequencer/blob/5114457ad4b5d6d1764b520dfa40b9e826f48854/crates/apollo_deployments/resources/app_configs/consensus_manager_config.json#L1-L3"
},
{
"title": "Apollo - L2 block-time target",
"url": "https://github.com/starkware-libs/sequencer/blob/5114457ad4b5d6d1764b520dfa40b9e826f48854/crates/apollo_batcher_config/src/config.rs#L318-L344"
},
{
"title": "Apollo - Deterministic proposer rotation",
"url": "https://github.com/starkware-libs/sequencer/blob/5114457ad4b5d6d1764b520dfa40b9e826f48854/crates/apollo_staking/src/staking_manager.rs#L475-L517"
},
{
"title": "Apollo - Mempool fee ordering",
"url": "https://github.com/starkware-libs/sequencer/blob/5114457ad4b5d6d1764b520dfa40b9e826f48854/crates/apollo_mempool/src/fee_transaction_queue.rs#L231-L250"
},
{
"title": "Starknet documentation - L1-L2 messaging",
"url": "https://docs.starknet.io/learn/protocol/messaging"
},
{
"title": "Starknet - Decentralization roadmap",
"url": "https://www.starknet.io/blog/decentralized-starknet-2025/"
},
{
"title": "Starknet core contract - source code",
"url": "https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4#code"
}
],
"risks": []
},
"stateDerivation": {
"nodeSoftware": "The [Juno](https://github.com/NethermindEth/juno) node software can be used to reconstruct the L2 state entirely from L1. The feature has not been released yet, but can be found in this [PR](https://github.com/NethermindEth/juno/pull/1335).",
"compressionScheme": "Starknet uses [stateful compression since v0.13.4](https://docs.starknet.io/architecture/data-availability/#v0_13_4).",
"genesisState": "There is no non-empty genesis state.",
"dataFormat": "The data format has been updated with different versions, and the full specification can be found [here](https://docs.starknet.io/architecture/data-availability/)."
},
"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": "Proven Program",
"description": "The current Starknet OS and aggregator sources are published in the [Starknet sequencer repository](https://github.com/starkware-libs/sequencer/tree/APOLLO-0.14.3-RC.11/crates/apollo_starknet_os_program/src/cairo/starkware/starknet/core), and the bootloader sources are published in [cairo-lang](https://github.com/starkware-libs/cairo-lang/tree/1c5dace6fbd1dc9d1ae2eb878dc1dd85f23512ab/src/starkware/cairo/bootloaders). The exact 1,166-felt outer bootloader stored onchain has been reproduced from [this source revision](https://github.com/starkware-libs/cairo-lang/tree/56407b69f3f19f69302a8623baa8c5f71f967eed/src/starkware/cairo/bootloaders/bootloader). However, SHARP also commits to an ordered allowlist of recursive Cairo verifier programs whose active preimages and source-to-hash mappings have not been published, so the complete proven program is not independently reproducible.",
"risks": []
},
{
"title": "Validity proofs",
"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.",
"risks": [],
"references": [
{
"title": "What is Starknet",
"url": "https://starkware.co/starknet/"
}
]
}
]
},
"upgradesAndGovernance": {
"content": "The Starknet zk Rollup shares its SHARP verifier with other StarkEx and SN Stack Layer 2s. Governance of the main Starknet rollup contract and its core bridge escrows (ETHBridge, STRKBridge) is currently split between two distinct signer groups: the 2/6 Starkware Multisig 1, which forms the normal upgrade path by routing all actions through the DelayedExecutor timelock with a 8d onchain delay, and the 9/12 Security Council, which can upgrade instantly and is intended for emergencies only. The delay window on the normal path gives the community time to observe queued actions and allows the Security Council to counteract a malicious action with its instant rights. The 2/4 Starkware Multisig 2 governs most other bridge escrows with instant upgradeability. The shared SHARP verifier used for state validation can be changed by the 2/4 SHARP Multisig with and a 8d delay, affecting all rollups like Starknet that are sharing it. \n\nThe Operator role in the Starknet contract is permissioned to update the state of the Starknet rollup by supplying valid (zk) state transition proofs. Since this role is not permissionless, Starknet implements a StarknetSCMinorityMultisig with the Operator role, which allows a 3/12 minority of the StarknetSecurityCouncil to enforce censorship resistance by including transactions that are not included by regular Operators.\n\nAll bridge escrows allow enabling a withdrawal throttle of 5% of the locked funds per 24h period. Enabling it is permissioned to a Multisig while disabling it in the core bridge escrows (STRKBridge, ETHBridge) can be done by a 3/12 minority of the Security Council.",
"governanceInfo": {
"securityCouncil": {
"Composition": "**9/12** onchain Safe multisig — 12 members, geographically and organizationally diverse (<50% from one country, <4 from one organization). The Starknet Foundation appoints and can administratively remove members. No fixed term length and no live tokenholder election mechanism.",
"Members public": "**Not mapped**, SNIP-25 and Foundation announcements publish only composition criteria (technical reputation, KYC/AML, diversity limits, conflict-of-interest rules).",
"Charter": "[SNIP-25](https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-25.md) defines duties (security-only mandate), vetting-failure reports, eligibility and the code of conduct.",
"Can bypass DAO?": "**Yes** — 9/12 can approve and execute an emergency upgrade immediately. The same instant rights let it counteract a malicious action queued in the DelayedExecutor during its 8d window.",
"DAO can override SC?": "**No**, the community can only dispute the emergency upgrades after the fact in advisory way."
},
"upgrades": {
"Major upgrade path": "Release announcement (≥1 SNIP + specific GitHub commit) → 2-week community deliberation → 1-week final review → 1-week STRK vote on the [Governance Hub on L2](https://governance.starknet.io/) → Security Council vetting → deployment queued in the DelayedExecutor by the 2/6 Starkware Multisig 1, whose 8d onchain delay covers the procedural ≥7-day freeze → execution. Minimum wall-clock ≈ **5 weeks** (8d onchain-enforced if executed via DelayedExecutor).",
"Minor upgrade path": "Announcement (SNIP may be submitted in parallel) → 1-week review → 1-week STRK vote on L2 → deployment queued in the DelayedExecutor, whose 8d onchain delay covers the procedural ≥5-day freeze → execution. No Security Council approval required. Minimum wall-clock ≈ **22 days** (8d onchain-enforced if executed via DelayedExecutor).",
"Emergency upgrade path": "**9/12 Security Council, instant**.",
"Exit window": "**8d** enforced onchain by the DelayedExecutor on the normal upgrade path (procedurally ≥7 days after the vote for major releases, ≥5 days for minor). **0** for emergency upgrades by the Security Council."
},
"tokenGovernance": {
"Governance token": "`STRK` — ~10.15B total supply, not permanently capped. Users can vote with L1 STRK, natively staked STRK or L2 vSTRK tokens, each gives 1 vote. In 2025 the Starknet Foundation [delegated ~1.7B STRK](https://www.starknet.io/blog/starknet-foundation-delegation-program/) to ~180 ecosystem delegates.",
"Voting venue": "[Starknet Governance Hub](https://governance.starknet.io/) using Snapshot X — proposals, space configuration and results are recorded and verified on Starknet, with relayed gasless signed votes.",
"Proposal threshold": "**None**, but proposal admission is curated, not triggered permissionlessly by an onchain token threshold.",
"Quorum": "**No protocol-wide quorum rule published.** Historical votes used a simple majority with no minimum quorum.",
"Execution model": "**Vote as onchain record, permissioned deployment** — passed proposals are queued in the DelayedExecutor by the 2/6 Starkware Multisig 1 and execute after 8d."
}
}
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp-preu16",
"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/0xA12Cf34001e553dc254D131105364351f5174d75#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#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/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#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/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x8612014a343089F1ddBACfD42baf4Afbf9133593#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://api.conduit.xyz/file/v1/optimism/rollup/superseed-mainnet-0).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://api.conduit.xyz/file/v1/optimism/genesis/superseed-mainnet-0).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The dispute game commits to an op-program release that predates the Jovian hardfork active on the chain, so it cannot derive current blocks and no dispute can be resolved correctly by execution. Security relies entirely on the permissioned proposer and challengers."
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x005dE5857e38dFD703a1725c0900E9C6f24cbdE0#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/swell.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/swell.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+2 -2
+1 -1
{
"self": {
"stateValidation": {
"value": "Fraud proofs (INT)",
"description": "Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve.",
"executionDelay": 302400,
"challengeDelay": 302400,
"sentiment": "good",
"orderHint": null,
"initialBond": {
"value": "0.08"
},
"permissioned": false,
"defenderAdvantage": {
"multiplier": 0.9133003936324697,
"multiplier": 0.9133045034463422,
"shape": "linear"
},
"secondLine": "3d 12h challenge period\n+ 3d 12h execution delay"
},
"exitWindow": {
"value": "None",
"description": "There is no exit window for users to exit in case of unwanted upgrades as they are initiated by the Security Council with instant upgrade power and without proper notice.",
"sentiment": "bad",
"orderHint": -604800
},
"proposerFailure": {
"value": "Self propose",
"description": "Anyone can be a Proposer and propose new roots to the L1 bridge.",
"sentiment": "good",
"orderHint": 0
},
"dataAvailability": {
"value": "Onchain",
"description": "All of the data needed for proof construction is published on Ethereum L1.",
"sentiment": "good",
"orderHint": null
},
"sequencerFailure": {
"value": "Self sequence",
"description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There can be up to a 12h delay on this operation.",
"sentiment": "good",
"orderHint": 43200,
"secondLine": "12h delay"
}
}
}+1 -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/0xFf00000000000000000000000000000000000130#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/unichain.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/unichain.json.zst).",
"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)).",
"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.23 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0xff00000000000000000000000000000000000480#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/worldchain.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/genesis/mainnet/worldchain.json.zst).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "zircuit",
"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://explorer.zircuit.com/address/0xFF00000000000000000000000000000000048900#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://explorer.zircuit.com/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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://explorer.zircuit.com/address/0x7Cf803296662e8C72A6C1d6450572209aCF7f202#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"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The chain ID is not included in the superchain registry snapshot embedded in the op-program release that the dispute games commit to, causing the dispute game to panic during execution. Security relies entirely on the permissioned proposer and challengers."
}+1 -1
+1 -1
{
"architectureImage": "opstack-rollup-superchain-opfp",
"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/0x6F54Ca6F6EdE96662024Ffd61BFd18f3f4e34DFf#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/zora.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://github.com/ethereum-optimism/superchain-registry/tree/main/superchain/extra/genesis/mainnet).",
"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 permissioned operators only. 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.0 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": [
{
"category": "Funds can be stolen if",
"text": "no whitelisted challenger disputes an invalid state root before the challenge window expires.",
"isCritical": true
}
]
},
{
"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 0.00 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)).",
"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 0.00 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)), an inherited clock with too little time remaining is generally extended by 3h. The extension is 6h when the next claim is immediately before split depth 30, and 1d 3h (the standard extension plus the 1d oracle challenge period) immediately before the last depth. Along a full-depth path, cumulative extensions can therefore add up to 10d 3h. 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"
}
]
}
]
},
"warning": "The fault proof system is deployed but is not functional. The permissioned dispute game commits to a placeholder absolute prestate (0xdead…) set by OP Stack Upgrade 19, so no dispute can be resolved by execution. Security relies entirely on the permissioned proposer and challenger."
}