Proposal Preview: Fault Proofs Incident Response Improvements

Technical Proposals 📃
1

Executive Summary

OP Labs is planning to submit a proposal that introduces technical improvements to several key contracts to enable more flexible and less disruptive ways to respond to any potential incidents in the OP Stack fault proof system.

Please note that this is a Proposal Preview and is not an actual proposal. It is meant to allow the Collective to provide feedback and ask questions before an official proposal is published.

Impacted Stakeholders & Expected Outcomes

  • Guardian and Security Council: Better control over incident response actions.
  • Users: Fewer disruptions during incident responses.

Definitions

  • Guardian — The Ethereum account that is given the ability to carry out certain safety-net actions. The Guardian is expected to use these capabilities when a bug in the system could threaten the safety of the native bridge. For the Superchain, the Guardian is the Security Council Safe. The Security Council Safe has permitted the Optimism Foundation Safe to act as the Guardian through a Safe Module that the Security Council Safe can revoke at any time.
  • Phase 0 Security Council Account — The 2/2 Safe composed of the Security Council Safe and the Optimism Foundation Safe.

Motivation

Why are we submitting this proposal?

The OP Stack fault proof system is still under active development. Although the system is being actively hardened on an ongoing basis, we believe that the Collective should be prepared to respond quickly and effectively to any potential bugs or incidents that could arise. We are submitting this proposal because we believe that the proposed changes significantly simplify the process of responding to incidents and, as a result, make the system safer as a whole.

Why should the Collective adopt this proposal?

This proposal makes a number of major improvements to the ways that we can respond to any potential bugs in the proof system.

Specifically:

  • The Guardian will be able switch between different available proof systems without automatically invalidating all existing proofs and forcing users to go through the costly and delayed process of re-proving their withdrawals. The Guardian will still have the option to invalidate all existing proofs if necessary.
  • The Guardian will be able to carry out safety actions like invalidating bugged fault proof instances without negatively impacting other parts of the system in ways that could require a system upgrade to resolve.
  • Bonds deposited into fault proof instances that are invalidated by the Guardian will be automatically refunded back to their original depositors. This means that the Phase 0 Security Council Account will no longer need to manually intervene in cases where bonds would be distributed incorrectly. However, the Phase 0 Security Council Account still retains this capability to step in manually if necessary.

Overall, this proposal is a lightweight change that mitigates most of the negative effects of existing incident response mechanisms while still retaining all of the response options that the Guardian and Phase 0 Security Council Account currently have.

Conflicts of interest

We do not believe there are any actual or expected conflicts of interest with this proposal. Our goal with this proposal is to reduce the impact of available incident response mechanisms. We believe this proposal is in the general best interest of the Collective.

Technical Details

Summary

DelayedWETH

  • DelayedWETH.hold(...) (callable only by the Phase 0 Security Council Account) now executes an approval and transfer from the target account to the owner account instead of simply executing an approval.
  • We provide a version of DelayedWETH.hold(...) that does not require the owner to specify the target’s balance. These changes significantly reduce the complexity of the runbook for executing a DelayedWETH.hold(...) action.

OptimismPortal

  • OptimsimPortal.setRespectedGameType(...) (callable only by the Guardian) no longer sets the respected game type and the retirement timestamp at the same time. We provide a special reserved input value (type(uint32).max) that can be used to set the retirement timestamp.
  • OptimismPortal.checkWithdrawal(...) now asserts that a FaultDisputeGame was the respected game type at the time of creation rather than asserting that the game is currently the respected game type.
  • Combined, these two changes mean that changing the respected game type no longer automatically invalidates all existing withdrawals while maintaining the option to invalidate withdrawals if necessary.

AnchorStateRegistry

  • AnchorStateRegistry.tryUpdateAnchorState(...) is removed and the AnchorStateRegistry.setAnchorState(...) function is repurposed as the primary way for FaultDisputeGame contracts to attempt to update the anchor state.
  • The AnchorStateRegistry’s internal anchor state is now unified across all game types instead of storing a different state per game type. AnchorStateRegistry.setAnchorState(...) now verifies that the game is fully finalized and only allows the respected game type (as defined in the OptimismPortal) to update the anchor state.
  • Changes to the AnchorStateRegistry in total mean that the anchor state cannot become “poisoned” in a way that the state recognized by the AnchorStateRegistry is not recognized by the OptimismPortal.
  • Additionally, the AnchorStateRegistry is updated so that all OP Stack chains can share a common AnchorStateRegistry implementation.

FaultDisputeGame

  • The FaultDisputeGame is modified to support the concept of “bond refunding” whereby bonds are automatically distributed back to their original depositors if the game is invalidated either by the retirement timestamp or the blacklisting mechanism. This reduces the need to actively step in to redistribute bonds if necessary.

Supporting Documentation

Audit Reports and Findings

Offbeat Labs

Offbeat Labs completed an audit of this code and found 1 Low Severity issue which has been addressed.

Spearbit

Spearbit completed an audit of this code, but the report is not finalized as of the publication of this post. Spearbit found 1 Medium Severity and 2 Low Severity issue.

The Medium Severity issue did not represent any safety risk - a deliberate design decision was found to conflict with the updated L2Beat Stage 1 requirements that were published at the end of January 2025, after the component was designed. We are updating our design process going forward to take these new L2Beat Stage 1 requirements into account. We have since modified the design of the component to satisfy the updated L2Beat requirements.

Impact Summary

  • Adopting this proposal will significantly improve the Collective’s ability to respond to any potential bugs or threats in the fault proof system without causing unnecessary disruption for users or developers.

IMPORTANT: If adopted and deployed, this proposal will cause a one-time invalidation of all pending withdrawal proofs created on L1. Users would be notified ahead of time to complete any pending withdrawals before the upgrade is executed and to avoid creating new withdrawal proofs that would not become executable in time. This aspect of the proposal does not place any ETH or ERC-20 tokens at risk and would simply require the user to submit a second withdrawal proof transaction on L1 in the worst case. This type of invalidation has already occurred in previous upgrades (e.g., when fault proofs were first introduced).

2 Likes