c3835bcd (main)
and
6a48dfc7 (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 sequecencer 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.",
"description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequecencer 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/0xaa5b13609Fd0a48b3B20202B25494F58F3Ff89f4#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/0xaa5b13609Fd0a48b3B20202B25494F58F3Ff89f4#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xaa5b13609Fd0a48b3B20202B25494F58F3Ff89f4#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/0xaa5b13609Fd0a48b3B20202B25494F58F3Ff89f4#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"
}
]
},
{
"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 2s right before the last depth. The maximum clock extension that a top level claim can get is therefore 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"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 2,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/2",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.02
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+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.",
"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/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"
}
]
},
{
"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)).",
"references": [
{
"title": "Fraud Proof Wars: OPFP",
"url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 7,
"requiredMembers": 5
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "5/7",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -2.1e-9
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain",
"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. \n 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).",
"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/0xff00000000000000000000000000000001111111#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x387422038358EE160aC57Dcd7aF73F9CC9401749#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 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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x387422038358EE160aC57Dcd7aF73F9CC9401749#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x387422038358EE160aC57Dcd7aF73F9CC9401749#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0xf31575705C047eC4D3Eb05F0917B9aA404179e3A#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x387422038358EE160aC57Dcd7aF73F9CC9401749#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0xf31575705C047eC4D3Eb05F0917B9aA404179e3A#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0xf31575705C047eC4D3Eb05F0917B9aA404179e3A#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0xf31575705C047eC4D3Eb05F0917B9aA404179e3A#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "B3",
"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.",
"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://basescan.org/address/0xFc536AB2Cc1e784Ae181ca8A23b3E9C828B934A8#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://basescan.org/address/0x602267995C801D85b4b854817D0a2231f64C3D7D#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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://basescan.org/address/0x602267995C801D85b4b854817D0a2231f64C3D7D#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://basescan.org/address/0x602267995C801D85b4b854817D0a2231f64C3D7D#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://basescan.org/address/0x0167E10be3293266c7F0f1b42E1a8906E638d0cb#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://basescan.org/address/0x602267995C801D85b4b854817D0a2231f64C3D7D#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://basescan.org/address/0x0167E10be3293266c7F0f1b42E1a8906E638d0cb#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://basescan.org/address/0x0167E10be3293266c7F0f1b42E1a8906E638d0cb#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://basescan.org/address/0x0167E10be3293266c7F0f1b42E1a8906E638d0cb#code"
}
]
}
]
},
"warning": "Fraud proof system is currently under development. Users need to trust the block proposer to submit correct L1 state roots."
}+1 -1
+1 -1
{
"dac": {
"membersCount": 3,
"requiredMembers": 2
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "2/3",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.00030000000000000003
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+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 sequecencer 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.",
"description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequecencer 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/0xff00000000000000000000000000000000042220#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x215A5fF85308A72A772F09B520dA71D3520e9aC7#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/0x215A5fF85308A72A772F09B520dA71D3520e9aC7#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x215A5fF85308A72A772F09B520dA71D3520e9aC7#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/0x215A5fF85308A72A772F09B520dA71D3520e9aC7#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"
}
]
},
{
"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)).",
"references": [
{
"title": "Fraud Proof Wars: OPFP",
"url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"architectureImage": "opstack-dachallenge",
"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. \n 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).",
"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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xACfD93B4887cef4F05cF3440d150D2cE97339142#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 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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xACfD93B4887cef4F05cF3440d150D2cE97339142#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xACfD93B4887cef4F05cF3440d150D2cE97339142#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x93E1c0D8ef27930130fb809CE18ca681A8C32F85#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xACfD93B4887cef4F05cF3440d150D2cE97339142#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x93E1c0D8ef27930130fb809CE18ca681A8C32F85#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x93E1c0D8ef27930130fb809CE18ca681A8C32F85#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x93E1c0D8ef27930130fb809CE18ca681A8C32F85#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 3,
"requiredMembers": 2
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "2/3",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.00030000000000000003
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+18 -0
+18 -0
{
"dataAvailability": [
{
"name": "Data is posted to Celestia",
"description": "\nEclipse uses Celestia for data availability.\n\nThere is no automatic fallback mechanism to Ethereum for data availability. If Celestia becomes unavailable, the chain relies entirely on Celestia for transaction data recovery.",
"references": [
{
"title": "Eclipse Celestia Integration",
"url": "https://docs.eclipse.xyz/architecture/eclipse-architecture/modular-components-of-eclipse#data-availability-celestia"
}
],
"risks": [
{
"category": "Funds can be frozen if",
"text": "celestia becomes unavailable and transaction data cannot be retrieved."
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "Eclipse implements a custom permissioned bridge. Withdrawals need to be actively authorized by a Multisig. Moreover, there is no mechanism to send arbitrary messages from Eclipse back to Ethereum. There is a 7d delay for withdrawals.",
"references": [
{
"title": "CanonicalBridge.sol - Etherscan source code, authorizeWithdraw() function",
"url": "https://etherscan.io/address/0x2B08D7cF7EafF0f5f6623d9fB09b080726D4be11#code#F1#L183"
},
{
"title": "Mailbox.sol - Etherscan source code, receiveMessage() function calls CanonicalBridge",
"url": "https://etherscan.io/address/0x4cef0fa54dc06ce0ea198dab2f57d28a9dee712b#code#F1#L199"
},
{
"title": "Treasury.sol - Etherscan source code, emergencyWithdraw() function",
"url": "https://etherscan.io/address/0xF1F7a359C3f33EE8A66bdCbf4c897D25Caf90978#code"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "the bridge operators decide not to mint tokens after observing a deposit."
},
{
"category": "Funds can be stolen if",
"text": "the Treasury owner decides to transfer the funds locked on L1."
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 2,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/2",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.02
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 2,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/2",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.02
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 2,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/2",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.02
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain",
"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.",
"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/0xA77F057914FdC5473dc03dC88E4B84302FA1EEb6#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xbdD90485FCbcac869D5b5752179815a3103d8131#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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xbdD90485FCbcac869D5b5752179815a3103d8131#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xbdD90485FCbcac869D5b5752179815a3103d8131#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x19652082F846171168Daf378C4fD3ee85a0D4A60#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xbdD90485FCbcac869D5b5752179815a3103d8131#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x19652082F846171168Daf378C4fD3ee85a0D4A60#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x19652082F846171168Daf378C4fD3ee85a0D4A60#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x19652082F846171168Daf378C4fD3ee85a0D4A60#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain",
"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. \n 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).",
"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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x90b82d6EFBA56Dcc0f1B55B8d50952c2eB9640e0#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 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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x90b82d6EFBA56Dcc0f1B55B8d50952c2eB9640e0#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x90b82d6EFBA56Dcc0f1B55B8d50952c2eB9640e0#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0xA3facd35d9a0BD9Df1603E00F10D7b0f9Ee5f587#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x90b82d6EFBA56Dcc0f1B55B8d50952c2eB9640e0#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0xA3facd35d9a0BD9Df1603E00F10D7b0f9Ee5f587#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0xA3facd35d9a0BD9Df1603E00F10D7b0f9Ee5f587#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0xA3facd35d9a0BD9Df1603E00F10D7b0f9Ee5f587#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 3,
"requiredMembers": 2
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "2/3",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.00030000000000000003
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+2 -2
+1 -1
{
"architectureImage": "opstack-dachallenge",
"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. \n 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/op-node%2Fv1.7.5).",
"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 a DA challenge is successful and the preimage data is not published, the chain reorgs to the last fully derivable state, falling back to Ethereum. 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/op-node%2Fv1.7.5).",
"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/0xFf00000000000000000000000000000000000aD9#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x03783fe183B68De1Ae3673Cb098039F58Ca49BaF#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 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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x03783fe183B68De1Ae3673Cb098039F58Ca49BaF#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x03783fe183B68De1Ae3673Cb098039F58Ca49BaF#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x8a9f35a100B11B71b79969c0527e1d3Cec8A24d5#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x03783fe183B68De1Ae3673Cb098039F58Ca49BaF#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x8a9f35a100B11B71b79969c0527e1d3Cec8A24d5#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x8a9f35a100B11B71b79969c0527e1d3Cec8A24d5#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x8a9f35a100B11B71b79969c0527e1d3Cec8A24d5#code"
}
]
}
]
}
}+1 -1
{
"challengeMechanism": "DA Challenges",
"description": "GM Network DA is a data availability solution using data availability challenges (DA Challenges).",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"name": "GM Network DA",
"risks": {
"economicSecurity": {
"value": {
"value": "DA Challenges",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack. However, there is a mechanism that allows users to challenge unavailability of data. The system is not secure if the malicious sequencer is able to outspend the altruistic challengers, and there is no pool of funds onchain to incentivize challengers."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
},
"committeeSecurity": {
"value": "None",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -1
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
}
},
"technology": {
"description": "\n## Architecture\n\n\n## Data Availability Challenges\nGM Network relies on DA challenges for data availability. \nThe DA Provider submits an input commitment on Ethereum, and users can request the data behind the commitment off-chain from the DA Provider.\nIf a DA challenger finds that the data behind a tx data commitment is not available, they can submit a challenge which requires locking a bond within 12h. \nA challenge can be resolved by publishing the preimage data within an additional 12h.\nIn such 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, meaning that the resolver and challenger will approximately lose the same amount of funds.\nThe system is not secure if the malicious sequencer is able to outspend the altruistic challengers. \nIf instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state.\n\n## DA Bridge\nOnly hashes of data batches are posted as DA commitments to an EOA on Ethereum.\nHowever, there is a mechanism that allows users to challenge unavailability of data.\n ",
"description": "\n## Architecture\n\n\n## Data Availability Challenges\nGM Network relies on DA challenges for data availability. \nThe DA Provider submits an input commitment on Ethereum, and users can request the data behind the commitment off-chain from the DA Provider.\nIf a DA challenger finds that the data behind a tx data commitment is not available, they can submit a challenge which requires locking a bond within 12h. \nA challenge can be resolved by publishing the preimage data within an additional 12h.\nIn such 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, meaning that the resolver and challenger will approximately lose the same amount of funds.\nThe system is not secure if the malicious sequencer is able to outspend the altruistic challengers.\nIf instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state.\n\n## DA Bridge\nOnly hashes of data batches are posted as DA commitments to an EOA on Ethereum.\nHowever, there is a mechanism that allows users to challenge unavailability of data.\n ",
"references": [
{
"title": "Alt-DA Specification",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md"
},
{
"title": "Security Considerations - Ethresear.ch ",
"url": "https://ethresear.ch/t/universal-plasma-and-da-challenges/18629"
}
],
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an invalid data availability certificate and there are no challengers."
},
{
"category": "Funds can be lost if",
"text": "the sequencer posts an invalid data availability certificate, and they are able to outspend the challengers."
}
]
},
"type": "DA Challenges"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium",
"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.",
"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/0x0C57B7f3bAc278bE091431B52470fBAdBc4240E6#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xC3fE3e0Ea967B2878faB2fEc7e1067b32aDf1C03#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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xC3fE3e0Ea967B2878faB2fEc7e1067b32aDf1C03#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xC3fE3e0Ea967B2878faB2fEc7e1067b32aDf1C03#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x2246d85AC397d289d49a92C804201738C4Bd2d73#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xC3fE3e0Ea967B2878faB2fEc7e1067b32aDf1C03#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x2246d85AC397d289d49a92C804201738C4Bd2d73#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x2246d85AC397d289d49a92C804201738C4Bd2d73#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x2246d85AC397d289d49a92C804201738C4Bd2d73#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium",
"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.",
"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/0xff00000000000000000000000000000000002410#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x3fe449Ef47228F03f979F9D955196494243cdf7E#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 takes a challenge period of 3d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x3fe449Ef47228F03f979F9D955196494243cdf7E#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x3fe449Ef47228F03f979F9D955196494243cdf7E#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x394317B191f5c7A371e74594776B1EfDc33d10D6#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x3fe449Ef47228F03f979F9D955196494243cdf7E#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x394317B191f5c7A371e74594776B1EfDc33d10D6#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x394317B191f5c7A371e74594776B1EfDc33d10D6#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x394317B191f5c7A371e74594776B1EfDc33d10D6#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+18 -0
+18 -0
{
"dataAvailability": [
{
"name": "Data is posted to Celestia",
"description": "\nLightLink uses Celestia for data availability. Transaction data is posted to Celestia, and block headers containing Celestia data pointers are posted to the CanonicalStateChain contract on Ethereum L1.\n\nThere is no automatic fallback mechanism to Ethereum for data availability. If Celestia becomes unavailable, the chain relies entirely on Celestia for transaction data recovery.",
"references": [
{
"title": "LightLink Celestia Integration",
"url": "https://docs.lightlink.io/lightlink-protocol/achitecture-and-design/lightlink-protocol-deep-dive#id-2-data-availability-layer"
}
],
"risks": [
{
"category": "Funds can be frozen if",
"text": "celestia becomes unavailable and transaction data cannot be retrieved."
}
]
}
],
"stateValidation": {
"description": "The project implements an incomplete and non-functional proof system.",
"categories": [
{
"title": "Challenges",
"description": "\n LightLink chain state roots are periodically posted to Ethereum through a CanonicalStateChain contract on L1 as block headers that also contain Celestia data pointers. After the challenge window of 5d, the published state root is assumed to be correct. During the challenge window, anyone can challenge a block header against some basic validity checks. The challenge fee required is 1.5 ETH.\n Once challenged, the permissioned defender can respond within 2d to the challenge, by providing the L2 header and the previous L2 header. If the defender does not respond,\n the block header is considered invalid, the canonical state chain is rolled back to the previous state root, and the challenger can claim back the challenge fee. If the defender successfully responds, the challenger loses the challenge fee to the defender.\n Since only the block header can be challenged and not the state transition, the system is vulnerable to invalid state roots. Moreover, state roots are not used for ERC20 withdrawals from the LightLinkERC20Bridge.\n Users can deposit tokens on the LightLink chain by sending them to the L1BridgeRegistry contract on Ethereum L1. On the LightLink chain, ERC20 token minting is then authorized by a permissioned set of signers providing signatures as input to the syncDeposit() function on the L2ERC20Predicate contract.\n Users can withdraw their funds by submitting a withdraw() transaction to the L2ERC20Predicate contract, which will burn the tokens on the LightLink chain. To then unlock tokens from the bridge on L1, a validator multisig needs to validate the withdrawal based on off-chain validity checks. \n Users can exit the network once enough validators have signed off on the withdrawal.\n Currently, a minimum of 2 validators is required to sign off on a withdrawal. To deposit the gas token, i.e. ETH, the LightLinkPortal is used which uses the CanonicalStateChain as the source for the state root, and withdrawals follow the usual OP stack process.",
"references": [
{
"title": "LightLink L2 syncDeposit() - L2ERC20Predicate.sol",
"url": "https://phoenix.lightlink.io/address/0x63105ee97BfB22Dfe23033b3b14A4F8FED121ee9?tab=contract_code"
},
{
"title": "LightLink L1 syncWithdraw()- L1ERC20Predicate.sol",
"url": "https://etherscan.io/address/0xa8372d6ff00d48a25baa1af16d6a86c936708f4e#code"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "validators 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 relay a withdraw request that wasn't originated on the source chain."
},
{
"category": "Funds can be stolen if",
"text": "the publisher posts an invalid block header on Ethereum."
}
]
}
]
}
}+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.",
"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/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"
}
]
},
{
"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)).",
"references": [
{
"title": "Fraud Proof Wars: OPFP",
"url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "mantapacific",
"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.",
"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/0xAEbA8e2307A22B6824a9a7a39f8b016C357Cd1Fe#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x4fEee20712abF5724C2BC0476BD87CBf1F1eE388#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 takes a challenge period of 3d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x4fEee20712abF5724C2BC0476BD87CBf1F1eE388#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x4fEee20712abF5724C2BC0476BD87CBf1F1eE388#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x0e874B9acD8d284B9bF6f6c6CC95BCE6F66E5441#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x4fEee20712abF5724C2BC0476BD87CBf1F1eE388#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x0e874B9acD8d284B9bF6f6c6CC95BCE6F66E5441#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x0e874B9acD8d284B9bF6f6c6CC95BCE6F66E5441#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x0e874B9acD8d284B9bF6f6c6CC95BCE6F66E5441#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"requiredMembers": 5,
"membersCount": 6,
"knownMembers": [
{
"external": true,
"name": "ConsenSys Software Inc.",
"href": "https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members"
},
{
"external": true,
"name": "QuickNode, Inc.",
"href": "https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members"
},
{
"external": true,
"name": "P2P.org",
"href": "https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members"
},
{
"external": true,
"name": "Google Cloud",
"href": "https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members"
},
{
"external": false,
"name": "Offchain Labs, Inc.",
"href": "https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members"
},
{
"external": true,
"name": "Opensea Innovation Labs Private Limited",
"href": "https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members"
}
]
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"risks": {
"committeeSecurity": {
"value": "5/6",
"sentiment": "warning",
"description": "The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment.\n There are at least 5 external actors in the committee, but entry or exit of members is partially controlled by a centralized entity.",
"orderHint": -6.000000000000001e-10
},
"upgradeability": {
"value": "17d 8h",
"sentiment": "warning",
"description": "For regular updates, there is a 17d 8h delay before the bridge implementation update is completed. The Security Council can upgrade the DA bridge without delay."
},
"relayerFailure": {
"value": "Governance",
"sentiment": "warning",
"description": "The relayer role is permissioned, but the DA bridge has a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge liveness can be restored by proposing a new relayer after a delay of 17d 8h via governance upgrade, or through a Security Council without delay."
},
"economicSecurity": {
"value": {
"value": "Public committee",
"sentiment": "warning",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack. However, there is indirect economic security derived by the committee members being publicly known, and their reputation is at stake should they behave maliciously."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nNova is a data availability solution for Arbitrum rollups built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nIn Nova architecture, the DA commitments are posted to the L1 through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the L1 chain inbox (the DA bridge), achieving L2 transaction ordering finality in a single onchain transaction.\n\n## DA Bridge Upgradeability\n\n\nThe Arbitrum DAO controls Arbitrum Nova through upgrades and modifications to their smart contracts on Layer 1 Ethereum and the Layer 2s. \nRegular upgrades, Admin- and Owner actions originate from either the Arbitrum DAO or the non-emergency (proposer-) Security Council on Arbitrum One and pass through multiple delays and timelocks before being executed at their destination. Contrarily, the three Emergency Security Council multisigs (one on each chain: Arbitrum One, Ethereum, Arbitrum Nova) can skip delays and directly access all admin- and upgrade functions of all smart contracts. These two general paths have the same destination: the respective UpgradeExecutor smart contract.\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 CoreGovernor-enforced 5% threshold of the votable tokens. The L2 Timelock queues the transaction for a 3d delay and then sends it to the Outbox contract on Ethereum. This incurs another delay (the challenge period) of 6d 8h. When that has passed, the L1 Timelock delays for additional 3d. Both timelocks serve as delays during which the transparent transaction contents can be audited, and even cancelled by the Emergency Security Council. Finally, the transaction can be executed, calling Admin- or Owner functions of the respective destination smart contracts through the UpgradeExecutor on Ethereum. If the predefined transaction destination is Arbitrum One or -Nova, this last call is executed on L2 through the canonical bridge and the aliased address of the L1 Timelock.\nOperator roles like the Sequencers and Validators are managed using the same paths. Sequencer changes can be delegated to a Batch Poster Manager.\n"
"description": "\n## Architecture\n\n\nNova is a data availability solution for Arbitrum rollups built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nIn Nova architecture, the DA commitments are posted to the L1 through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the L1 chain inbox (the DA bridge), achieving L2 transaction ordering finality in a single onchain transaction.\n\n## DA Bridge Upgradeability\n\n\nThe Arbitrum DAO controls Arbitrum Nova through upgrades and modifications to their smart contracts on Layer 1 Ethereum and the Layer 2s. \nRegular upgrades, Admin- and Owner actions originate from either the Arbitrum DAO or the non-emergency (proposer-) Security Council on Arbitrum One and pass through multiple delays and timelocks before being executed at their destination. Contrarily, the three Emergency Security Council multisigs (one on each chain: Arbitrum One, Ethereum, Arbitrum Nova) can skip delays and directly access all admin- and upgrade functions of all smart contracts. These two general paths have the same destination: the respective UpgradeExecutor smart contract.\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 CoreGovernor-enforced 5% threshold of the votable tokens. The L2 Timelock queues the transaction for a 3d delay and then sends it to the Outbox contract on Ethereum. This incurs another delay (the challenge period) of 6d 8h. When that has passed, the L1 Timelock delays for additional 3d. Both timelocks serve as delays during which the transparent transaction contents can be audited, and even cancelled by the Emergency Security Council. Finally, the transaction can be executed, calling Admin- or Owner functions of the respective destination smart contracts through the UpgradeExecutor on Ethereum. If the predefined transaction destination is Arbitrum One or -Nova, this last call is executed on L2 through the canonical bridge and the aliased address of the L1 Timelock.\nOperator roles like the Sequencers and Validators are managed using the same paths. Sequencer changes can be delegated to a Batch Poster Manager.\n"
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+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.",
"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/0xB443Da3e07052204A02d630a8933dAc05a0d6fB4#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/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"
}
]
},
{
"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)).",
"references": [
{
"title": "Fraud Proof Wars: OPFP",
"url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
}
]
}
]
}
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain",
"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.",
"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/0x3276053cb5C0fEb1825678e6D9441ddc935FE12e#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xdAc90BD578f229D33D68735B398b544027E3285e#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 takes a challenge period of 1d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xdAc90BD578f229D33D68735B398b544027E3285e#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xdAc90BD578f229D33D68735B398b544027E3285e#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x1Fd1be2e1c65F136020d2CcC073ED8A7269aE53f#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xdAc90BD578f229D33D68735B398b544027E3285e#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x1Fd1be2e1c65F136020d2CcC073ED8A7269aE53f#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x1Fd1be2e1c65F136020d2CcC073ED8A7269aE53f#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x1Fd1be2e1c65F136020d2CcC073ED8A7269aE53f#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 2,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/2",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.02
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium",
"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.",
"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/0xC1B90E1e459aBBDcEc4DCF90dA45ba077d83BFc5#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x75A2AAc09C8A51Bdde7303B06F1aD2fFFcCf8c09#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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x75A2AAc09C8A51Bdde7303B06F1aD2fFFcCf8c09#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x75A2AAc09C8A51Bdde7303B06F1aD2fFFcCf8c09#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x76983dfED43C7ae7ebB592A92Be2BE972cAE4348#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x75A2AAc09C8A51Bdde7303B06F1aD2fFFcCf8c09#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x76983dfED43C7ae7ebB592A92Be2BE972cAE4348#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x76983dfED43C7ae7ebB592A92Be2BE972cAE4348#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"
}
]
}
],
"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/v0.1.1/superchain/configs/mainnet/pgn.yaml).",
"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": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x76983dfED43C7ae7ebB592A92Be2BE972cAE4348#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 2,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/2",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.02
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+2 -2
+1 -1
{
"architectureImage": "opstack-dachallenge",
"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. \n 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/latticexyz/redstone).",
"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 a DA challenge is successful and the preimage data is not published, the chain reorgs to the last fully derivable state, falling back to Ethereum. 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/latticexyz/redstone).",
"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/0xff00000000000000000000000000000000000690#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xD0e1065F2A941Dd723F800C34D2D4282C3158A00#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 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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xD0e1065F2A941Dd723F800C34D2D4282C3158A00#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xD0e1065F2A941Dd723F800C34D2D4282C3158A00#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0xB78071f03F4D7601129773070F2Dde6184e1BD87#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xD0e1065F2A941Dd723F800C34D2D4282C3158A00#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0xB78071f03F4D7601129773070F2Dde6184e1BD87#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0xB78071f03F4D7601129773070F2Dde6184e1BD87#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0xB78071f03F4D7601129773070F2Dde6184e1BD87#code"
}
]
}
]
}
}+1 -1
{
"challengeMechanism": "DA Challenges",
"description": "RedstoneDA is a data availability solution using data availability challenges (DA Challenges).",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"name": "RedstoneDA",
"risks": {
"economicSecurity": {
"value": {
"value": "DA Challenges",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack. However, there is a mechanism that allows users to challenge unavailability of data. The system is not secure if the malicious sequencer is able to outspend the altruistic challengers, and there is no pool of funds onchain to incentivize challengers."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
},
"committeeSecurity": {
"value": "None",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -1
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
}
},
"technology": {
"description": "\n## Architecture\n\n\n## Data Availability Challenges\nRedstone relies on DA challenges for data availability. \nThe DA Provider submits an input commitment on Ethereum, and users can request the data behind the commitment off-chain from the DA Provider.\nIf a DA challenger finds that the data behind a tx data commitment is not available, they can submit a challenge which requires locking a bond within 12h. \nA challenge can be resolved by publishing the preimage data within an additional 12h.\nIn such 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, meaning that the resolver and challenger will approximately lose the same amount of funds.\nThe system is not secure if the malicious sequencer is able to outspend the altruistic challengers. \nIf instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state. \n\n## DA Bridge\nOnly hashes of data batches are posted as DA commitments to an EOA on Ethereum.\nHowever, there is a mechanism that allows users to challenge unavailability of data.\n ",
"description": "\n## Architecture\n\n\n## Data Availability Challenges\nRedstone relies on DA challenges for data availability. \nThe DA Provider submits an input commitment on Ethereum, and users can request the data behind the commitment off-chain from the DA Provider.\nIf a DA challenger finds that the data behind a tx data commitment is not available, they can submit a challenge which requires locking a bond within 12h. \nA challenge can be resolved by publishing the preimage data within an additional 12h.\nIn such 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, meaning that the resolver and challenger will approximately lose the same amount of funds.\nThe system is not secure if the malicious sequencer is able to outspend the altruistic challengers.\nIf instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state. \n\n## DA Bridge\nOnly hashes of data batches are posted as DA commitments to an EOA on Ethereum.\nHowever, there is a mechanism that allows users to challenge unavailability of data.\n ",
"references": [
{
"title": "Alt-DA Specification",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md"
},
{
"title": "Security Considerations - Ethresear.ch ",
"url": "https://ethresear.ch/t/universal-plasma-and-da-challenges/18629"
}
],
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an invalid data availability commitment and there are no challengers."
},
{
"category": "Funds can be lost if",
"text": "the sequencer posts an invalid data availability commitment, and he is able to outspend the challengers."
}
]
},
"type": "DA Challenges"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 2,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/2",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.02
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain",
"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.",
"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/0x9BE0c82d5bA973a9e6861695626D4F9983e80C88#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xCEa36be2e9724d88cB107C552c602a8025DB88bA#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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xCEa36be2e9724d88cB107C552c602a8025DB88bA#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xCEa36be2e9724d88cB107C552c602a8025DB88bA#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x19652082F846171168Daf378C4fD3ee85a0D4A60#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xCEa36be2e9724d88cB107C552c602a8025DB88bA#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x19652082F846171168Daf378C4fD3ee85a0D4A60#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x19652082F846171168Daf378C4fD3ee85a0D4A60#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x19652082F846171168Daf378C4fD3ee85a0D4A60#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 3,
"requiredMembers": 2
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "2/3",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.00030000000000000003
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"architectureImage": "opstack-optimium-superchain",
"dataAvailability": [
{
"name": "Data is posted to EigenDA",
"description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequecencer 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.",
"description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequecencer 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/0xfF000000000000000000000000000000000000FF#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x24331B68bea70c2b086BC883EEEA551BAF80C2BA#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 takes a challenge period of 1d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x24331B68bea70c2b086BC883EEEA551BAF80C2BA#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x24331B68bea70c2b086BC883EEEA551BAF80C2BA#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x240d0038d87b5A27e4Fb7FB0c27F9b45D89b2C4F#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x24331B68bea70c2b086BC883EEEA551BAF80C2BA#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x240d0038d87b5A27e4Fb7FB0c27F9b45D89b2C4F#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x240d0038d87b5A27e4Fb7FB0c27F9b45D89b2C4F#code"
}
]
},
"otherConsiderations": [
{
"name": "Solana Virtual Machine is supported",
"description": "OP stack chains are usually pursuing the EVM Equivalence model. But Soon implements the rust-based Solana virtual machine (SVM) which uses parallel processing.",
"risks": [],
"references": [
{
"title": "Soon Docs - Decoupled SVM",
"url": "https://docs.soo.network/introduction/decoupled-svm"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x240d0038d87b5A27e4Fb7FB0c27F9b45D89b2C4F#code"
}
]
}
]
}
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 2,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/2",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.02
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 5,
"requiredMembers": 3,
"knownMembers": [
{
"external": false,
"name": "Xai",
"href": "https://xai-foundation.gitbook.io/xai-network/about-xai/xai-protocol/anytrust-revolutionizing-blockchain-infrastructure/data-availability-servers-das"
},
{
"external": true,
"name": "Ex Populus",
"href": "https://xai-foundation.gitbook.io/xai-network/about-xai/xai-protocol/anytrust-revolutionizing-blockchain-infrastructure/data-availability-servers-das"
},
{
"external": true,
"name": "Alt Layer",
"href": "https://xai-foundation.gitbook.io/xai-network/about-xai/xai-protocol/anytrust-revolutionizing-blockchain-infrastructure/data-availability-servers-das"
},
{
"external": true,
"name": "LayerZero",
"href": "https://xai-foundation.gitbook.io/xai-network/about-xai/xai-protocol/anytrust-revolutionizing-blockchain-infrastructure/data-availability-servers-das"
},
{
"external": true,
"name": "Team Secret",
"href": "https://xai-foundation.gitbook.io/xai-network/about-xai/xai-protocol/anytrust-revolutionizing-blockchain-infrastructure/data-availability-servers-das"
},
{
"external": true,
"name": "Offchain Labs",
"href": "https://xai-foundation.gitbook.io/xai-network/about-xai/xai-protocol/anytrust-revolutionizing-blockchain-infrastructure/data-availability-servers-das"
}
]
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "3/5",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.000010000000000000003
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "Public committee",
"sentiment": "warning",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack. However, there is indirect economic security derived by the committee members being publicly known, and their reputation is at stake should they behave maliciously."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+1 -1
+1 -1
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain as calldata. \n\n\nA DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}+2 -2
+1 -1
{
"architectureImage": "opstack-dachallenge",
"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. \n 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/op-node%2Fv1.7.5).",
"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 a DA challenge is successful and the preimage data is not published, the chain reorgs to the last fully derivable state, falling back to Ethereum. 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/op-node%2Fv1.7.5).",
"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/0xfF00000000000000000000000000000000293b30#code"
},
{
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xEdE953bab7C50B2e5150316Ae0574F0cbA4068a9#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 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 takes a challenge period of 7d to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xEdE953bab7C50B2e5150316Ae0574F0cbA4068a9#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xEdE953bab7C50B2e5150316Ae0574F0cbA4068a9#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER check",
"url": "https://etherscan.io/address/0x48Ef83Cf812f291EDB00C2D48440Ee90cD12be1a#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xEdE953bab7C50B2e5150316Ae0574F0cbA4068a9#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": [
{
"title": "L2OutputOracle.sol - source code, CHALLENGER address",
"url": "https://etherscan.io/address/0x48Ef83Cf812f291EDB00C2D48440Ee90cD12be1a#code"
},
{
"title": "L2OutputOracle.sol - source code, PROPOSER address",
"url": "https://etherscan.io/address/0x48Ef83Cf812f291EDB00C2D48440Ee90cD12be1a#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"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "OP Stack projects can use the OP fault proof system, already being deployed on some. This project though is not using fault proofs yet and is relying on the honesty of the permissioned Proposer and Challengers to ensure state correctness. The smart contract system permits invalid state roots.",
"risks": [
{
"category": "Funds can be stolen if",
"text": "an invalid state root is submitted to the system.",
"isCritical": true
}
],
"references": [
{
"title": "L2OutputOracle.sol - source code, deleteL2Outputs function",
"url": "https://etherscan.io/address/0x48Ef83Cf812f291EDB00C2D48440Ee90cD12be1a#code"
}
]
}
]
},
"warning": "Deposited/Forced transactions are disabled, a permissioned admin can withdraw all ETH. Xterio chain on ethereum is sunset and funds [are being transferred to Xterio Chain (BNB)](https://info.xter.io/xterio-chain-migration)."
}+1 -1
{
"challengeMechanism": "DA Challenges",
"description": "XterioDA is a data availability solution using data availability challenges (DA Challenges).",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"name": "XterioDA",
"risks": {
"economicSecurity": {
"value": {
"value": "DA Challenges",
"sentiment": "bad",
"description": "There are no onchain assets at risk of being slashed in case of a data withholding attack. However, there is a mechanism that allows users to challenge unavailability of data. The system is not secure if the malicious sequencer is able to outspend the altruistic challengers, and there is no pool of funds onchain to incentivize challengers."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
},
"committeeSecurity": {
"value": "None",
"sentiment": "bad",
"description": "The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.",
"orderHint": -1
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
}
},
"technology": {
"description": "\n## Architecture\n\n\n## Data Availability Challenges\nXterio relies on DA challenges for data availability. \nThe DA Provider submits an input commitment on Ethereum, and users can request the data behind the commitment off-chain from the DA Provider.\nIf a DA challenger finds that the data behind a tx data commitment is not available, they can submit a challenge which requires locking a bond within 12h. \nA challenge can be resolved by publishing the preimage data within an additional 12h.\nIn such 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, meaning that the resolver and challenger will approximately lose the same amount of funds.\nThe system is not secure if the malicious sequencer is able to outspend the altruistic challengers. \nIf instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state.\n\n## DA Bridge\nOnly hashes of data batches are posted as DA commitments to an EOA on Ethereum. However, there is a mechanism that allows users to challenge unavailability of data.\n ",
"description": "\n## Architecture\n\n\n## Data Availability Challenges\nXterio relies on DA challenges for data availability. \nThe DA Provider submits an input commitment on Ethereum, and users can request the data behind the commitment off-chain from the DA Provider.\nIf a DA challenger finds that the data behind a tx data commitment is not available, they can submit a challenge which requires locking a bond within 12h. \nA challenge can be resolved by publishing the preimage data within an additional 12h.\nIn such 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, meaning that the resolver and challenger will approximately lose the same amount of funds.\nThe system is not secure if the malicious sequencer is able to outspend the altruistic challengers.\nIf instead, after a challenge, the preimage data is not published, the chain reorgs to the last fully derivable state.\n\n## DA Bridge\nOnly hashes of data batches are posted as DA commitments to an EOA on Ethereum. However, there is a mechanism that allows users to challenge unavailability of data.\n ",
"references": [
{
"title": "Alt-DA Specification",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md"
},
{
"title": "Security Considerations - Ethresear.ch ",
"url": "https://ethresear.ch/t/universal-plasma-and-da-challenges/18629"
}
],
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an invalid data availability certificate and there are no challengers."
},
{
"category": "Funds can be lost if",
"text": "the sequencer posts an invalid data availability certificate, and he is able to outspend the challengers."
}
]
},
"type": "DA Challenges"
}