The first open source, permissionless, feature-complete fault proof system in the Ethereum ecosystem.
Scope
Contest Results
On what chains are the smart contracts going to be deployed?
Ethereum Mainnet.
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
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.
Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED? If these integrations are trusted, should auditors also assume they are always responsive, for example, are oracles trusted to provide non-stale information, or VRF providers to respond within a designated timeframe?
N/A (no external integrations).
Are there any protocol roles? Please list them and provide whether they are TRUSTED or RESTRICTED, or provide a more comprehensive description of what a role can and can't do/impact.
Two roles exist for contracts in scope of this contest.
The Proxy Admin Owner is a TRUSTED role that can:
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:
The Guardian must not be able to:
The Guardian is assumed to be honest and responsive with an SLA of 24 hours.
For permissioned functions, please list all checks and requirements that will be made before calling the function.
Permissioned functions can be used in any situation.
Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
N/A.
Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?
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.
Are there any hardcoded values that you intend to change before (some) deployments?
N/A.
If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?
N/A.
Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?
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:
Please discuss any design choices you made.
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.
Please list any known issues/acceptable risks that should not result in a valid finding.
We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
N/A (no override).
Please provide links to previous audits (if any).
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:
Please list any relevant protocol resources.
Additional audit information.
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.
Total Rewards
Contest Pool
Lead Senior Watson
Lead Judge
200,000 USDC
14,000 USDC
6,000 USDC
Status
Scope
Start Time
End Time
Finished
768 nSLOC
Mar 27, 2024, 3:00 PM
Apr 4, 2024, 3:00 PM
Reserved Auditors