# \[FINAL\] Protocol Upgrade #7: Fault Proofs **URL:** \ **Category:** Protocol Upgrade\ **Created:** [May 16, 2024, 11:14pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161 "2024-05-16T23:14:18Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ajsutton](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/ajsutton/32/9024_2.png) [@ajsutton](https://gov.optimism.io/u/ajsutton)\ **Post date:** [May 16, 2024, 11:14pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/1 "2024-05-16T23:14:19Z")
### **Executive Summary** Hi I’m Adrian, a protocol engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not represent or speak on behalf of, the Optimism Foundation. This protocol upgrade reduces the trust assumptions for users of OP Mainnet by enabling permissionless output proposals and a permissionless fault proof system. As part of a responsible and safe rollout of Fault Proofs, it preserves the ability for the guardian to override if necessary to maintain security. As a result, withdrawals no longer depend on the privileged proposer role posting an output root, allowing the entire withdrawal process to be completed without any privileged actions. The trust assumption is reduced to requiring only that the guardian role does not act to intervene. Combined with the [Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes](https://gov.optimism.io/t/upgrade-proposal-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157) proposal, we believe this satisfies the criteria to have OP Chains reach Stage 1 status. If this vote passes and becomes the new governance-approved version of the OP Stack, the upgrade will be deployed to OP Mainnet by the Security Council (currently in Phase 0, which is a joint 2/2 multisig between the Security Council Safe and the Foundation’s Safe) shortly after the end of the veto period. ### **Motivation** Securing withdrawals with a Fault Proof system is a key requirement for meeting the [stage 1](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) decentralization milestone with the ultimate goal of enhancing the security of user assets. This upgrade enables a permissionless Fault Proof system which allows anyone to propose output roots and participate in the dispute system. As a result, users will be able to withdraw assets from L2 to L1 without relying on the sequencer or any other centralized infrastructure. As part of a responsible and safe rollout of Fault Proofs, it is required that at this stage, the existing [Guardian role](https://docs.optimism.io/chain/security/privileged-roles#guardian) capabilities are carried over to this new version, meaning that the Guardian can disable the Fault Proof system in the event of emergency. While this means the system is still not fully trustless - as is the nature of Stage 1 designation - it reduces the trust assumption to requiring only that the Guardian role does not act maliciously, rather than requiring a single permissioned proposer to actively propose. This proposed upgrade extends the Guardian role’s pause ability to be able to disable the fault proof system, an extension of its existing capabilities in the fault proofs context. For more info on how the Guardian role is expected to be permissioned, see [this post](https://gov.optimism.io/t/upgrade-proposal-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157). This upgrade also includes a smart contract framework that provides a solid basis for a future multi-proof system, allowing additional proof systems to easily be added. This will further reduce trust assumptions in later upgrades as the OP Stack moves towards achieving Stage 2 decentralization. ### **Specifications** The full specifications for the fault dispute system are available [from the specs repo](https://specs.optimism.io/experimental/fault-proof/index.html). If this proposal is approved, the fault dispute system specs will be promoted from the experimental section of specs, to be part of the canonical spec. **Technical Details** This upgrade does not affect the node or execution client software. Prior to the upgrade, the fault dispute system contracts have been deployed: 1. `DisputeGameFactory` (implementation: [`0xc641A33cab81C559F2bd4b21EA34C290E2440C2B`](https://etherscan.io/address/0xc641A33cab81C559F2bd4b21EA34C290E2440C2B) proxy: [`0xe5965Ab5962eDc7477C8520243A95517CD252fA9`](https://etherscan.io/address/0xe5965Ab5962eDc7477C8520243A95517CD252fA9)) - a factory for creating dispute games that can be used by the upgraded `OptimismPortal` as the source of proposed output roots. 2. `FaultDisputeGame` ([`0x4146DF64D83acB0DcB0c1a4884a16f090165e122`](https://etherscan.io/address/0x4146DF64D83acB0DcB0c1a4884a16f090165e122)) - an implementation of a dispute game that uses permissionless, interactive bi-section of the chain state - This is initialized with an `ABSOLUTE_PRESTATE` of `0x037ef3c1a487960b0e633d3e513df020c43432769f41a634d18a9595cbf53c55`. This is the initial state for the Cannon MIPS VM to run `op-program` tagged in the optimism repo at commit `a6d4eeda11477adfcd106e03131625a40334e3a6`(tagged as release `op-program/v1.0.0`). This prestate can be rebuilt using the `make reproducible-prestate` command ([docs](https://github.com/ethereum-optimism/optimism/tree/op-program/v1.0.0/op-program#generating-the-absolute-prestate)) 1. `PermissionedFaultDisputeGame` ([`0xE9daD167EF4DE8812C1abD013Ac9570C616599A0`](https://etherscan.io/address/0xE9daD167EF4DE8812C1abD013Ac9570C616599A0)) - extends `FaultDisputeGame` to restrict participation to privileged roles. This can be used as a fallback in the event of failure of the fault dispute game. 2. `AnchorStateRegistry` (implementation: [`0x6B7da1647Aa9684F54B2BEeB699F91F31cd35Fb9`](https://etherscan.io/address/0x6B7da1647Aa9684F54B2BEeB699F91F31cd35Fb9) proxy: [`0x18DAc71c228D1C32c99489B7323d441E1175e443`](https://etherscan.io/address/0x18DAc71c228D1C32c99489B7323d441E1175e443)) - stores the latest “anchor” state for each available `FaultDisputeGame` type. By using stored anchor states, new FaultDisputeGame instances can be initialized with a more recent starting state which reduces the amount of required offchain computation. - This is initialized with the starting anchor for `CANNON` and `PERMISSIONED_CANNON` games set to block number 120059863 and output root `0x2694ac14dcf54b7a77363e3f60e6462dc78da0d43d1e2f058dbb6a1488814977`. - As the fault dispute system contracts are deployed ahead of time and are permissionless, it is possible for dispute games to be created prior to `OptimismPortal` being upgraded. If these games resolve that the output root is valid, the `AnchorStateRegistry` will be updated with the new value. The validity of the current value of the `AnchorStateRegistry` will be manually verified as part of the upgrade process. 1. `DelayedWETH` (implementation: [`0x97988d5624F1ba266E1da305117BCf20713bee08`](https://etherscan.io/address/0x97988d5624F1ba266E1da305117BCf20713bee08) proxy: [`0xE497B094d6DbB3D5E4CaAc9a14696D7572588d14`](https://etherscan.io/address/0xE497B094d6DbB3D5E4CaAc9a14696D7572588d14)) - an extension to WETH9 that allows for delayed withdrawals. This introduces a time delay before bonds posted as part of a `FaultDisputeGame` can be withdrawn, allowing the Guardian role to change the allocation of bonds if there is a bug in the `FaultDisputeGame` to preserve incentive compatibility. 2. `PreimageOracle` ([`0xD326E10B8186e90F4E2adc5c13a2d0C137ee8b34`](https://etherscan.io/address/0xD326E10B8186e90F4E2adc5c13a2d0C137ee8b34)) - stores validated pre-images that can be retrieved by hash. This is used by `op-program` and other fault proof programs to retrieve data required to perform the derivation process and validate the output root. 3. `MIPS` ([`0x0f8EdFbDdD3c0256A80AD8C0F2560B1807873C9c`](https://etherscan.io/address/0x0f8EdFbDdD3c0256A80AD8C0F2560B1807873C9c)) - the Cannon MIPS VM implementation. Executes a single MIPS CPU instruction on-chain as part of the `step` call to determine the validity of claims at the bottom level of the dispute game. There are also two off-chain programs provided to support users interacting with the fault proof system: - `op-challenger` - implements the honest actor algorithm for the `FaultDisputeGame` to automatically challenge invalid output root proposals and defend valid ones. - `op-dispute-mon` - monitors the fault proof system, exposing a variety of metrics that enable monitoring and alerting of the fault proof system, such as when games are forecast or have resolved with a status that is inconsistent with the local `op-node` used by `op-dispute-mon`. The following changes are being introduced with the upgrade: 1. Upgrade the `OptimismPortal` contract ([`0xe2F826324b2faf99E513D16D266c3F80aE87832B`](https://etherscan.io/address/0xe2F826324b2faf99E513D16D266c3F80aE87832B)) that uses the `DisputeGameFactory` as the source of output proposals. ([spec](https://specs.optimism.io/experimental/fault-proof/stage-one/bridge-integration.html)) - The `proveWithdrawalTransaction` method is modified, retaining the same signature function but with the second argument now providing an index within the `DisputeGameFactory`’s list of created games. - Enforces an air-gap requiring a period of time (`DISPUTE_GAME_FINALITY_DELAY_SECONDS`) to have elapsed since the game resolved before the game can be used in a call to `finalizeWithdrawalTransaction`. - The Guardian role can blacklist dispute games or change the `RESPECTED_GAME_TYPE` to invalidate dispute games in the event of failures in the fault proof system. - Users are now able to reprove their withdrawals at any time. Previously, a user could only reprove their withdrawal if the output root was removed from the `L2OutputOracle` by the guardian, but with this upgrade users will be able to reprove their withdrawal at any time. This allows users to change the dispute game their withdrawal is proven against if needed without waiting for the game to actually resolve as invalid. The 7 day withdrawal finalization delay resets when a user reproves their withdrawal to ensure there is still a full 7 day air-gap between proving and finalizing the withdrawal. 1. The `L2OutputOracle` contract is no longer used 2. The `SystemConfig` contract ([`0xF56D96B2535B932656d3c04Ebf51baBff241D886`](https://etherscan.io/address/0xF56D96B2535B932656d3c04Ebf51baBff241D886)) is updated to: - reference the `DisputeGameFactory` address instead of the `L2OutputOracle` address. - enforce a maximum block gas limit of 200,000,000 to prevent the gas limit being raised to the point where block execution is too resource intensive to be processed in cannon as part of the fault dispute system. - remove the `setResourceConfig` setter to prevent the [System Config Owner](https://docs.optimism.io/chain/security/privileged-roles#system-config-owner), from misconfiguring the resource config and preventing force inclusions from L1 (e.g. by setting the maximum deposit gas too low). The resource config can now only be changed by upgrading the `SystemConfig` contract which is controlled by the [L1 Proxy Admin](https://docs.optimism.io/chain/security/privileged-roles#l1-proxy-admin) (a 2-of-2 multisig with the Optimism Foundation and Security Council). These contracts are tagged in the optimism repo at commit [`547ea72d9849e13ce169fd31df0f9197651b3f86`](https://github.com/ethereum-optimism/optimism/commit/547ea72d9849e13ce169fd31df0f9197651b3f86) (tagged as release candidate [`op-contracts/v1.4.0-rc.4`](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv1.4.0-rc.4) [).](https://www.notion.so/4c0c7a1222d54129bf405e408d5eecdd?pvs=21) **Security Considerations** 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 - in particular the ability for the Guardian role to pause withdrawals and disable the Fault Proof System. The Sherlock community completed a [successful bug hunt](https://audits.sherlock.xyz/contests/205), focused on issues which would allow these fundamental safety mechanisms to be subverted. See the [final report](https://audits.sherlock.xyz/contests/205/report) for further details. The reported issues have been addressed. As none of the reported issues circumvented the fundamental safety mechanisms we decided not to pursue a fix review. **Impact Summary** - As part of the upgrade, all pending withdrawals will be invalidated. Users with pending withdrawals will need to re-prove their withdrawals against an output proposal submitted in the form of a `FaultDisputeGame` which will restart the withdrawal delay period. **This means that withdrawals initiated less than one week before the upgrade is executed will only be finalized one week after the upgrade is complete.** For example, a withdrawal initiated 6 days before the upgrade would take a total of 13 days to finalize. - Users reading output roots from the `L2OutputOracle` contract will need to update to read from the `DisputeGameFactory`. - OP Labs does not anticipate any down time due to this upgrade, and node operators are not affected. - While the normal case for dispute games allows them to resolve within the 7 day withdrawal delay period, the maximum possible time for a dispute game to resolve is 16 days which may lengthen the withdrawal delay for withdrawals proven against that dispute game. Extending a game to this point incurs a significant cost and users may reprove their withdrawal against a different output root at any time. The [Game Clock section of the specs](https://specs.optimism.io/experimental/fault-proof/stage-one/fault-dispute-game.html#game-clock) provides further details. - Tooling that performs withdrawals will need to be updated to use the new `DisputeGameFactory` as the source of output roots when proving withdrawals. New versions of the Optimism SDK and viem have already been released with this support. ### **Action Plan** If this proposal passes a Token House vote, the L1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle #23a. Prior to upgrading, the anchor state in the `AnchorStateRegistry` will be validated manually. If the value is invalid due to a game having resolved incorrectly prior to full deployment, a replacement version of the `AnchorStateRegistry` will be deployed using the starting anchor in this proposal, before upgrading contracts. The upgrade will be completed atomically such that all affected L1 contracts will be upgraded within a single transaction. This upgrade has already been activated on internal devnets and the op-sepolia testnet. As this is a L1 contracts-only upgrade, no action is required by node operators. To prepare infra and the community for withdrawal flow changes, we will be rolling out mainnet messaging starting this week. This will expand on the [preparation for breaking changes](https://docs.optimism.io/builders/notices/fp-changes) implemented with contributors for OP Sepolia, which we coordinated with ~30 infra teams and several rounds of public posts. Mainnet communication will include: - _Comms_: At least two rounds of public messaging on OP social channels notifying users of the changes to withdrawal flow, and of the impact on withdrawals during the upgrade window. - Contributors: Coordinate with bridge infra contributors, including maintainers of popular frontends to the standard bridge, to post banners notifying users of the changes. - _Support_: Prep developer support team for inbound support tickets about transactions that need to be reproven due to not finishing the first proof in time before the changes. - _Bridges:_ Notify bridges and other infra contributors whose operations might be impacted due to the withdrawal flow changes. If a critical security issue is discovered before upgrading, OP Labs will collaborate with the community to extensively communicate that the upgrade will no longer occur. ### **Conclusion** The deployment of a permissionless Fault Dispute System to OP Mainnet is a major step forward on the path to decentralization. This proposal is a responsible approach to the roll out, preserving the safety checks and functionality of the Guardian role while still benefiting from permissionless output proposals and laying a foundation for reaching stage 2 decentralization. ---
**Author:** ![zachobront](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/zachobront/32/7861_2.png) [@zachobront](https://gov.optimism.io/u/zachobront)\ **Post date:** [May 17, 2024, 4:26pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/2 "2024-05-17T16:26:08Z")
_ **On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal:** _ For Optimism withdrawals to function, the L2 state root must be posted to L1. You can think of the L2 state root as a single “summary” value that can be used to prove any fact about L2’s state. This value is used when withdrawing funds to prove those funds were actually withdrawn on L2. (Optimism actually uses a few different values to make proving simpler, but we can skip that for this discussion.) Before this upgrade, this L2 root value was posted to the L2OutputOracle contract. It could only be posted by a trusted, permissioned account. As long as this permissioned account acted honestly, the chain would function as intended. This upgrade aims to move towards technical decentralization by allowing anyone to post the L2 root. **How does this work?** L2 roots are proven through “games”. In the current game, anyone can propose a root (and put up a financial bond along with it). Any other user can challenge them (also putting up a bond), and the two users then go back and forth proving facts about how the root was calculated and increasing their bonds until either (a) one of them gives up or (b) they disagree about a fact so basic that it can be proven on chain. If the user who proposed the root wins this game, the root is considered valid. Otherwise, it is considered invalid. The loser also forfeits their bonds to the winner. Only a valid game that has had enough time to work itself out can have withdrawals proven against it, which stops dishonest users from being able to post an incorrect root. **Safeguards** The game itself may still have security issues. As the proposal says: “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.” For this period where the security of the game may still be at risk, Optimism has poured significant resources into building safeguards around the game, as follows: 1. An off chain monitoring system has been set up to monitor all proposed roots and ensure they align with the correct state. 2. After a root is finalized through a game, an additional delay has been added before withdrawals can occur. During this period, the GUARDIAN role can reject the root. This will allow the monitoring to stop invalid withdrawals. 3. A contract called DelayedWETH has been set up to hold the bonds and only allow payouts after a delay, so that bonds can be redirected towards the rightful recipient in the event that a game is abused. **Other Implications** As a part of the OptimismPortal (the contract that handles withdrawals) being upgraded, all previously proved withdrawals will no longer work. This means that any previously proven withdrawal that has not yet been finalized will need to be reproved, including an additional wait before being able to finalize. * * * If you have any questions about the technical details of this upgrade, feel free to post here and I (or someone else in the DAB) will get back to you. ---
**Author:** ![system](https://europe1.discourse-cdn.com/bc41dd/original/2X/3/399c2cdab1be9e0c1ae7481c939f977574c28f5e.svg) [@system](https://gov.optimism.io/u/system)\ **Post date:** [May 17, 2024, 4:35pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/3 "2024-05-17T16:35:58Z")
_As part of the [Path to Open Metagovernance](https://gov.optimism.io/t/the-path-to-open-metagovernance/7728), we’re experimenting with polls to collect more community input._ # Was this non-technical summary useful? _Please provide any additional feedback in the comments below_ _Poll ([view on site](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/3))_ _Poll ([view on site](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/3))_ _Poll ([view on site](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/3))_ ---
**Author:** ![Harper](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/harper/32/420_2.png) [@Harper](https://gov.optimism.io/u/Harper)\ **Post date:** [May 17, 2024, 10:29pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/4 "2024-05-17T22:29:34Z")
Thanks @zachobront and DAB for the summary. Very helpful! ---
**Author:** ![ajsutton](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/ajsutton/32/9024_2.png) [@ajsutton](https://gov.optimism.io/u/ajsutton)\ **Post date:** [May 20, 2024, 10:18pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/5 "2024-05-20T22:18:42Z")
Please note that I’ve edited the original post to add information on two additional changes to the `SystemConfig` contract about enforcing a maximum block gas limit and removing the `setResourceConfig`. These were unintentionally missed in my original summary of the changes but seemed worth noting for transparency. ---
**Author:** ![OPUser](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/opuser/32/179_2.png) [@OPUser](https://gov.optimism.io/u/OPUser)\ **Post date:** [May 20, 2024, 10:37pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/6 "2024-05-20T22:37:36Z")
Thank you for the non-technical summary. I am an [Optimism delegate](https://gov.optimism.io/t/delegate-commitments-old/235/26) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![PGov](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/pgov/32/10448_2.png) [@PGov](https://gov.optimism.io/u/PGov)\ **Post date:** [May 20, 2024, 10:43pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/7 "2024-05-20T22:43:35Z")
I’m an Optimism [delegate](https://gov.optimism.io/t/pgov-delegate-communication-thread/6059) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![lefterisjp](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/lefterisjp/32/9240_2.png) [@lefterisjp](https://gov.optimism.io/u/lefterisjp)\ **Post date:** [May 20, 2024, 10:51pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/8 "2024-05-20T22:51:10Z")
Thanks for the detailed post on fault proofs. Was waiting and looking forward for this hitting on Optimism as an upgrade so this is an easy thing to approve. I am an [Optimism delegate](https://gov.optimism.io/t/delegate-commitments-old/235/9) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![katie](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/katie/32/5184_2.png) [@katie](https://gov.optimism.io/u/katie)\ **Post date:** [May 21, 2024, 12:59am UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/9 "2024-05-21T00:59:05Z")
**I am an [Optimism delegate](https://gov.optimism.io/t/delegate-commitments/235/18) with sufficient voting power and I believe this proposal is ready to move to a vote.** ---
**Author:** ![Gonna.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gonna.eth/32/3379_2.png) [@Gonna.eth](https://gov.optimism.io/u/Gonna.eth)\ **Post date:** [May 21, 2024, 1:30pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/10 "2024-05-21T13:30:07Z")
> [@ajsutton](#): > > This upgrade has already been activated on internal devnets and the op-sepolia testnet. How long has been active? Is there any performance report? > [@ajsutton](#): > > The validity of the current value of the `AnchorStateRegistry` will be manually verified as part of the upgrade process. How does the manual verification happen? ---
**Author:** ![MattGov.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/mattgov.eth/32/11275_2.png) [@MattGov.eth](https://gov.optimism.io/u/MattGov.eth)\ **Post date:** [May 21, 2024, 1:50pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/11 "2024-05-21T13:50:12Z")
**I am an [Optimism delegate](https://vote.optimism.io/delegates/0x1f4BA000D042cA0045eF094691615f3912DebEa8) with sufficient voting power and I believe this proposal is ready to move to a vote.** changed old delegate commitment to new agora page to show OP delegate info ---
**Author:** ![brichis](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/brichis/32/10892_2.png) [@brichis](https://gov.optimism.io/u/brichis)\ **Post date:** [May 21, 2024, 5:23pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/12 "2024-05-21T17:23:39Z")
GM! First, thanks to the DAB for the non-technical summary. After getting all my questions about this upgrade answered, I approve this proposal: I am an [Optimism delegate](https://vote.optimism.io/delegates/brichis.eth) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![Gonna.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gonna.eth/32/3379_2.png) [@Gonna.eth](https://gov.optimism.io/u/Gonna.eth)\ **Post date:** [May 21, 2024, 5:50pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/13 "2024-05-21T17:50:47Z")
The community call answered the questions I had. I am an [Optimism delegate](https://gov.optimism.io/t/delegate-commitments/235/2) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![Luckyhooman.eth](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/luckyhooman.eth/32/1684_2.png) [@Luckyhooman.eth](https://gov.optimism.io/u/Luckyhooman.eth)\ **Post date:** [May 21, 2024, 7:43pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/14 "2024-05-21T19:43:00Z")
I am an [Optimism delegate](https://vote.optimism.io/delegates/butterbum.eth) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![chaselb](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/chaselb/32/3530_2.png) [@chaselb](https://gov.optimism.io/u/chaselb)\ **Post date:** [May 21, 2024, 11:51pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/15 "2024-05-21T23:51:07Z")
On behalf of Blockchain@USC: We are an [Optimism delegate](https://vote.optimism.io/delegates/0x995013b47ef3a2b07b9e60da6d1fff8fa9c53cf4) with sufficient voting power and we believe this proposal is ready to move to a vote. ---
**Author:** ![Joxes](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/joxes/32/5814_2.png) [@Joxes](https://gov.optimism.io/u/Joxes)\ **Post date:** [May 22, 2024, 3:26am UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/16 "2024-05-22T03:26:39Z")
Hey @ajsutton! At SEED Latam, we are thrilled to see this proposal make its way to the forum. Moving OP Mainnet into Stage 1 is a significant step forward, and we are excited that we are likely ready for it. Some aspects were addressed in the last Governance Call, but we believe there are still several points that need to be clarified for the community’s understanding of this new upgrade: 1. How large are the bonds expected to be needed to sustain and win a dispute? A summary of the factors involved would be nice. 2. How many steps/transactions are required to settle a dispute (worst-case scenario)? 3. With Fault Proofs, are escape hatches practically possible? In the event of sequencer and proposer failure, we would expect to initiate an forced withdrawal from L1 and then propose a new state root. Are there any dependencies to consider? 4. Since the roles of proposer and challenger will be open to everyone, is there a guide available outlining the best practices for running them? On a side note, we appreciate the publication of non-technical summaries (cc: @zachobront) below each technical proposal. We hope to help providing context to all interested parties by making these questions outlined above. Thank you. ---
**Author:** ![Leo.Zhang](https://avatars.discourse-cdn.com/v4/letter/l/c6cbf5/32.png) [@Leo.Zhang](https://gov.optimism.io/u/Leo.Zhang)\ **Post date:** [May 22, 2024, 3:54am UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/17 "2024-05-22T03:54:53Z")
> [@ajsutton](#): > > If this proposal passes a Token House vote, the L1 contracts will be upgraded following the completion of the Citizens’ House Veto Period following Voting Cycle #23a @ajsutton So when will be the proposal implemented on mainnet? Is there a specific timeline? Thank you! ---
**Author:** ![Michael](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/michael/32/2489_2.png) [@Michael](https://gov.optimism.io/u/Michael)\ **Post date:** [May 22, 2024, 1:30pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/18 "2024-05-22T13:30:47Z")
Huge step, and I appreciate the focus on the safety failsafes that come with the upgrade. I am an [Optimism delegate](https://vote.optimism.io/delegates/opmichael.eth) with sufficient voting power and believe this proposal is ready to move towards a vote. ---
**Author:** ![mastermojo](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/mastermojo/32/1178_2.png) [@mastermojo](https://gov.optimism.io/u/mastermojo)\ **Post date:** [May 23, 2024, 12:39pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/19 "2024-05-23T12:39:16Z")
I am one of the Synthetix Ambassadors, and I am an Optimism delegate [[Delegate Commitments - #65 by mastermojo](https://gov.optimism.io/t/delegate-commitments/235/65)] with sufficient voting power, and I believe this proposal is ready to move to a vote. ---
**Author:** ![ajsutton](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/ajsutton/32/9024_2.png) [@ajsutton](https://gov.optimism.io/u/ajsutton)\ **Post date:** [May 23, 2024, 11:01pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/20 "2024-05-23T23:01:17Z")
> [@Gonna.eth](#): > > How long has been active? Is there any performance report? We’ve had the fault dispute game running on op-sepolia since [March 19](https://blog.oplabs.co/open-source-and-feature-complete-fault-proofs-bring-permissionless-validation-to-the-op-sepolia-testnet/) and all dispute games have resolved correctly. op-sepolia was updated to use fault proofs prior to the Sherlock audit contest so we have updated it to [deploy the fixes](https://blog.oplabs.co/sherlock-audit-roundup/) as a result of that contest. You can see the interactions with the system starting from the [DisputeGameFactory](https://sepolia.etherscan.io/address/0x05F9613aDB30026FFd634f38e5C4dFd30a197Fa1) contract on Etherscan. For a simpler view, you [can use the subcommands](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#list-games) on `op-challenger` to list games and list claims. > [@Gonna.eth](#): > > How does the manual verification happen? See this answer from @maurelian: [https://gov.optimism.io/t/upgrade-proposal-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/19](https://gov.optimism.io/t/upgrade-proposal-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/19) [Next page](https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161.md?page=2)