Ethereum Mainnet.

Of the contracts that are in scope for this contest, the only token integrated directly is a modified version of WETH9 called DelayedWETH. The DelayedWETH contract is directly in the scope of this contest.

N/A (no external integrations).

Two roles exist for contracts in scope of this contest.

The Proxy Admin Owner is a TRUSTED role that can:

• Upgrade all smart contracts that sit behind a Proxy contract.
• Set the implementation contract for any dispute game type within the DisputeGameFactory.
• Modify the initial bond cost for any dispute game type within the DisputeGameFactory.
• Remove ETH from the DelayedWETH contract.

The Proxy Admin Owner is assumed to be honest and responsive with an SLA of 72 hours.

The Guardian is a RESTRICTED role that can ONLY be permitted to:

• Trigger the SuperchainConfig.pause function to pause withdrawals from several system contracts.
• Trigger the SuperchainConfig.unpause function to unpause withdrawals from several system contracts.
• Trigger the OptimismPortal2.blacklistDisputeGame function to block a specific FaultDisputeGame for withdrawals.
• Trigger the OptimismPortal2.setRespectedGameType function to change which game type can be used for withdrawals.

The Guardian must not be able to:

• Remove ETH from the DelayedWETH contract.
• Remove ETH from the OptimismPortal2 contract.
• Cause an invalid message to be executed by the OptimismPortal2 contract.

The Guardian is assumed to be honest and responsive with an SLA of 24 hours.

Permissioned functions can be used in any situation.

N/A.

Off-chain mechanisms exist as part of the system but are not in scope for this competition. Assume that comprehensive monitoring exists that will detect most obviously detectable malicious activity.

N/A.

N/A.

Yes, but this should be limited to the OptimismPortal2 contract. Contracts other than the OptimismPortal2 contract are not intended for external integrations and risks for future integrations into these contracts will likely not be considered valid.

For the OptimismPortal2, the following high-level invariants must hold:

• Users must not be able to execute messages that have not actually been sent and included in the state of the L2ToL1MessagePasser contract on the L2 blockchain.
• Users must be able to execute messages that have actually been sent and included in the state of the L2ToL1MessagePasser contract on the L2 blockchain. Users must not be permanently prevented from executing a valid message.
• Users must not be able to cause a transfer of ETH out of the OptimismPortal2 except during the execution of a valid message sent from the L2 blockchain.
• Users must not be able to execute the same message more than once.
• Users should not be able to modify the content, sender, or target of a message once it has been sent.

• IMPORTANT NOTE: OptimismPortal2 is included in this contest but OptimismPortal is not. OptimismPortal is the current implementation of the contract that would be replaced to the new implementation defined in OptimismPortal2. Review OptimismPortal2, not OptimismPortal!

• Our design philosophy has been to focus on fundamental safety mechanisms first. We acknowledge that gaining certainty in the correctness of the complex logic found within the FaultDisputeGame contract, its dependencies, and the offchain op-challenger software will take time. Therefore, we have included a number of fallback mechanisms designed to maintain the safety of the system even in the event of a complete failure of those complex components. Our primary goal with this particular contest is to gain confidence in the correctness of these safety mechanisms so that we can safely work on gaining total confidence in the more complex components over time.

• DelayedWETH includes a mapping that associates attempts to withdraw bonded ETH with specific recipient addresses. However, these specific recipient addresses are not actually required to participate in the process of claiming these withdrawals from the DelayedWETH contract. The FaultDisputeGame is written to be restrained in such a way that this "soft" accounting (no real restriction that forces users to make use of the accounting system) is actually "hard" accounting and cannot be circumvented by users (other than by a bug in the FaultDisputeGame). This decision was made so that users would not have to interact with the DelayedWETH contract directly and the contract could therefore be removed at a later date without impacting challenger software.

• DelayedWETH and the DisputeGameFactory contract both have "owner" addresses. For simplicity, these owner addresses are set during the initialization process instead of being pulled from a specific contract to guarantee that they are the same as the Proxy Admin Owner. However, for the sake of this contest, you should assume that these owner addresses are the same as the Proxy Admin Owner.

• FaultDisputeGame resolution logic is not included in the scope of this contest. Participants should assume that the FaultDisputeGame can resolve incorrectly (i.e.g, can resolve to DEFENDER_WINS when it should resolve to CHALLENGER_WINS or vice versa). Reports that demonstrate an incorrect resolution of the FaultDisputeGame are appreciated but will not be considered valid rewardable findings for this specific contest. However, there should be no function in the FaultDisputeGame that can cause an airgap breach (up to High). Additionally there should be no function that can cause valid withdrawals to not be finalizable (at most Medium) except for the case that the “resolve” function sets the result to CHALLENGER_WINS (invalid proposal) when it should be DEFENDER_WINS. Finally, it should not be possible to change the game result after it has been set once.

N/A (no override).

Of the contracts in scope for this contest, only the OptimismPortal contract has been previously audited.

References to audits that include the OptimismPortal can be found below:

• https://github.com/ethereum-optimism/optimism/blob/a039f5a7c1fadd680e95d53e315d8fca2cff39a6/docs/security-reviews/2022_05-Bedrock_Contracts-Zeppelin.pdf
• https://github.com/ethereum-optimism/optimism/blob/a039f5a7c1fadd680e95d53e315d8fca2cff39a6/docs/security-reviews/2022_09-Bedrock_and_Periphery-Zeppelin.pdf
• https://github.com/ethereum-optimism/optimism/blob/a039f5a7c1fadd680e95d53e315d8fca2cff39a6/docs/security-reviews/2023_01-Bedrock_Updates-TrailOfBits.pdf
• https://github.com/sherlock-protocol/sherlock-reports/blob/61e3689eee4d74bcfedbb2a5b7bb60da6e76a707/audits/2023.03.03%20-%20Final%20-%20Optimism%20Bedrock%20Audit%20Report.pdf

• https://specs.optimism.io
• https://docs.optimism.io

A detailed contest handbook can be found here: https://oplabs.notion.site/Public-OP-Stack-Fault-Proofs-Sherlock-Competition-Handbook-e4cfdf210a5c45c79230af19653163cc

Please note that this Q&A takes precedence over the contest handbook. If discrepancies exist, information in this Q&A supersedes the runbook. Feedback about any discrepancies is much appreciated.