# Upgrade Proposal #13: OPCM and Incident Response improvements **URL:** \ **Category:** Protocol Upgrade\ **Created:** [March 7, 2025, 9:49pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739 "2025-03-07T21:49:13Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![maurelian](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/maurelian/32/9353_2.png) [@maurelian](https://gov.optimism.io/u/maurelian)\ **Post date:** [March 7, 2025, 9:49pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/1 "2025-03-07T21:49:13Z")
# **Executive Summary** Hi I’m Maurelian, a Security Engineer at OP Labs. This proposal was written in collaboration with Lewej (@0xEscanor) and @Kelvin from the OP Labs Team. This proposal is intended to be voted on in cycle 34. Neither OP Labs nor I represent or speak on behalf of the Optimism Foundation. **This proposal:** - outlines the implementation of a new system for upgrading L1 contracts across the Superchain (OP Contracts Manager), - 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 (Fault Proofs Incident Response Improvements), and - introduces a new [Safe Module](https://docs.safe.global/advanced/smart-account-modules) called the `DeputyPauseModule` to be installed into the Optimism Foundation Safe to simplify the process of quickly responding to security incidents via the Superchain-wide pause mechanism (Superchain Pause Improvements). ## Impacted Stakeholders & Expected Outcomes - **Optimism Foundation** : Simplified process for triggering Superchain-wide pause quickly in case of an emergency. - **Security Council:** introduces a method to perform “batched” upgrades to multiple chains at once # **Motivation** The goal of this upgrade is to implement the above changes to 1) make contract upgrades more scalable, less prone to error, and easier to test the fully upgrade system with OP Contracts Manager, 2) simplify the process of responding to fault proofs related incidents, and 3) improve the process of triggering the Superchain-wide “pause” functionality without changing any existing security properties. # **Specifications** The major features in this upgrade were previewed in mini-posts to encourage earlier community discussion. Links to each discussion are attached in the relevant section. ## Blockspace Charter - Current Blockspace Charter proposed to be upgraded under this proposal - [OPerating-manual/Standard Rollup Charter.md at e1b305a96a0b60515cc1111a26e73e1973d9c34e · ethereum-optimism/OPerating-manual · GitHub](https://github.com/ethereum-optimism/OPerating-manual/blob/e1b305a96a0b60515cc1111a26e73e1973d9c34e/Standard%20Rollup%20Charter.md) - PR specifying the upgraded Blockspace Charter - [Update standard rollup charter for Upgrade 13 by mslipper · Pull Request #46 · ethereum-optimism/OPerating-manual · GitHub](https://github.com/ethereum-optimism/OPerating-manual/pull/46) ## **Technical Details** ### **OP Contracts Manager and Maintenance Changes** This proposal was previewed [here](https://gov.optimism.io/t/proposal-preview-op-contracts-manager-upgrades-and-release-process-improvements/9662). - The specific protocol changes included in this proposal are: ### **Fault Proofs Incident Response Improvements** This proposal was previewed [here](https://gov.optimism.io/t/proposal-preview-fault-proofs-incident-response-improvements/9659). **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** - Specification: [Common anchor state for all dispute game types](https://github.com/ethereum-optimism/specs/pull/494/files) - Specification: [AnchorStateRegistry incident response changes](https://github.com/ethereum-optimism/specs/pull/517) - Specification: [OptimismPortal incident response changes](https://github.com/ethereum-optimism/specs/pull/519) - Specification: [FaultDisputeGame incident response changes](https://github.com/ethereum-optimism/specs/pull/524) - Specification: [DelayedWETH incident response changes](https://github.com/ethereum-optimism/specs/pull/453) **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](https://forum.l2beat.com/t/stages-update-a-high-level-guiding-principle-for-stage-1/338) 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. ### **DeputyPauseModule (Superchain Pause Improvements)** This proposal was previewed [here](https://gov.optimism.io/t/proposal-preview-deputypausemodule-superchain-pause-improvements/9658). **DeputyPauseModule** - The `DeputyPauseModule` is a new [Safe Module](https://docs.safe.global/advanced/smart-account-modules) that we are proposing to install into the Optimism Foundation Safe. The `DeputyPauseModule` allows the Optimism Foundation to assign a “Pause Deputy” private key that can be used to create signatures that authorize the use of the Superchain-wide pause. - The `DeputyPauseModule` allows the Pause Deputy private key to cause the Optimism Foundation Safe to execute a call to the `DeputyGuardianModule` account ONLY for the purpose of executing the `pause` function. The Pause Deputy has no other capabilities. **Supporting Documentation** - Specification: [DeputyPauseModule](https://github.com/ethereum-optimism/specs/blob/87e13cba8f34a68858a334fc2587041b712facfa/specs/protocol/deputy-pause-module.md) **Audit Reports and Findings** **Radiant Labs** - [Report](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_12-DPM-EVom.pdf) - Low/informational findings only, all addressed **MiloTruck (independent)** - [Report](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_12-DPM-MiloTruck.pdf) - Low/informational findings only, all addressed ## Impact Summaries ### **OP Contracts Manager** The adoption of this proposal will improve the safety and reliability of upgrades. This should in-turn enable smaller and more frequent upgrade to occur, thus increasing the speed of iteration and improvement. ### **Fault Proofs Incident Response Improvements** **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). ### **DeputyPauseModule (Superchain Pause Improvements)** - Adopting this proposal will significantly improve the Optimism Foundation’s ability to quickly respond to incidents while simultaneously eliminating a major source of overhead during the upgrade process (re-signing many pre-signed pause transactions). - The Optimism Foundation Safe is expected to rotate the Pause Deputy private key on a regular basis (approximately every 3 months). - Usage of a private key in place of the existing “pre-signed” pause transactions does not change the existing security model. In either case, the Optimism Foundation retains access to secret material that can quickly trigger the Superchain-wide pause in case of an emergency. Corresponding to this change, [PR#46](https://github.com/ethereum-optimism/OPerating-manual/pull/46/) adds a new Governing Policy for the Deputy Pause Module to the Standard Rollup Charter. ## Precommitment Impact Review This Upgrade Proposal does not impact any of the precommitments in the Standard Rollup Charter. - Collective Fee Take: no modification or onchain implementation introduced. - Governor/Servicer Role Separation: no change to role structures or authorization patterns. - Ossified GasLimits: no changes to ossified gasLimits - Direct Fee Margin Controls: no change to the relevant configuration structure and authorization. Some helper methods for get/set logic are added to the SystemConfig, but do not fulfill the overall intent of this precommittment. # **Action Plan** If this proposal is accepted, the upgrade is expected to take place on April 7, 2025. In that case, mulitisig ceremonies will be coordinate such that the following transactions will be executed. - Upgrade transaction commitments 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 next week. 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. ### Emergency Cancellation The optimistic mainnet releases will be activated on the above mentioned date. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation. # **Conclusion** This proposal outlines more robust incident response processes and technical improvements to contracts and their management. This network upgrade provides simplified processes, allows smaller and more frequent upgrades to occur, and enables more flexible and less disruptive ways to respond to potential incidents in the OP Stack fault proof system. We hope to gain your support for the implementation of these changes. ---
**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:** [March 10, 2025, 2:47pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/2 "2025-03-10T14:47:13Z")
> [@maurelian](#): > > ### Emergency Cancellation > > The optimistic mainnet releases will be activated on the above mentioned date. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation. It’s clear that OP Labs and the Security Council will collaborate on emergency cancellation if needed, but it would be good to **explicitly define who makes the final decision** (Optimism Foundation, Security Council, or both?). > [@maurelian](#): > > DeputyPauseModule While the proposal clarifies most of the technical side, some governance-related question on this (probably not for you maurelian): 1. **Process** : - Will there be public confirmation/logging of key rotations? - Is there a designated team within the Foundation responsible for managing this process? 1. **External delegation** : - If OP Labs or another entity gets access to the Pause Deputy key, how will responsibilities be defined? - Will the Security Council have visibility over these decisions? > [@maurelian](#): > > 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. How much time users have to react before the upgrade? These are all minor questions and I’m fully supportive of this proposal. ---
**Author:** ![SEEDGov](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/seedgov/32/5202_2.png) [@SEEDGov](https://gov.optimism.io/u/SEEDGov)\ **Post date:** [March 10, 2025, 8:59pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/3 "2025-03-10T20:59:36Z")
The SEEDGov delegation, as we have communicated [here](https://gov.optimism.io/t/seed-latam-delegate-communication-thread/2950/46), being an [Optimism delegation](https://vote.optimism.io/delegates/0x94db037207f6fb697dbd33524aadffd108819dc8) with sufficient voting power, we 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:** [March 11, 2025, 2:02am UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/4 "2025-03-11T02:02:17Z")
I am an Optimism Top 100 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:** ![Marcus01](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/marcus01/32/6862_2.png) [@Marcus01](https://gov.optimism.io/u/Marcus01)\ **Post date:** [March 11, 2025, 6:32am UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/5 "2025-03-11T06:32:42Z")
I am an [optimism delegate](https://vote.optimism.io/delegates/0xC841D6DdF66467Af551b35218c0c2e22f9C14b48) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**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:** [March 11, 2025, 4:54pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/7 "2025-03-11T16:54:00Z")
> [@maurelian](#): > > **Radiant Labs** > > - [Report](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_12-DPM-EVom.pdf) > - Low/informational findings only, all addressed GM @maurelian ! This link seems broken: ![Screenshot 2025-03-11 at 10.53.31 a.m.](https://europe1.discourse-cdn.com/bc41dd/original/2X/7/7cd624509cd992e3d9312b577ad690efe78073f0.png) ---
**Author:** ![World\_Foundation](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/world_foundation/32/11501_2.png) [@World\_Foundation](https://gov.optimism.io/u/World_Foundation)\ **Post date:** [March 11, 2025, 5:27pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/8 "2025-03-11T17:27:40Z")
The World Foundation delegation, in its capacity as an [Optimism delegate](https://vote.optimism.io/delegates/0x0f7cf21aca85f8ba65f0b066fa99b251252dcc38) with sufficient voting power, believes this proposal is ready to move to a vote. ---
**Author:** ![nanobro](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/nanobro/32/5872_2.png) [@nanobro](https://gov.optimism.io/u/nanobro)\ **Post date:** [March 11, 2025, 5:32pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/9 "2025-03-11T17:32:57Z")
I am an [Optimism delegate](https://vote.optimism.io/delegates/nanobro.eth) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![kelvin](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/kelvin/32/3162_2.png) [@kelvin](https://gov.optimism.io/u/kelvin)\ **Post date:** [March 11, 2025, 11:57pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/10 "2025-03-11T23:57:31Z")
> [@brichis](#): > > This link seems broken Corrected link is here: [optimism/docs/security-reviews/2024\_12-DPM-RadiantLabs.pdf at develop · ethereum-optimism/optimism · GitHub](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_12-DPM-RadiantLabs.pdf) Sorry about that! ---
**Author:** ![jengajojo](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/jengajojo/32/8397_2.png) [@jengajojo](https://gov.optimism.io/u/jengajojo)\ **Post date:** [March 12, 2025, 2:50pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/11 "2025-03-12T14:50:07Z")
I am an [Optimism delegate](https://vote.optimism.io/delegates/0xc2490d220419acdced68428ac413c8483d08d1ab) with sufficient voting power and I believe this proposal is ready to move to a vote. ---
**Author:** ![MoneyManDoug](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/moneymandoug/32/395_2.png) [@MoneyManDoug](https://gov.optimism.io/u/MoneyManDoug)\ **Post date:** [March 12, 2025, 5:56pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/12 "2025-03-12T17:56:43Z")
I am an [Optimism delegate](https://vote.optimism.io/delegates/Sugma.eth) with sufficient voting power and believe this proposal is ready to move to a vote. ---
**Author:** ![ben-chain](https://avatars.discourse-cdn.com/v4/letter/b/b5a626/32.png) [@ben-chain](https://gov.optimism.io/u/ben-chain)\ **Post date:** [March 12, 2025, 6:19pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/13 "2025-03-12T18:19:12Z")
> **Emergency Cancellation** > The optimistic mainnet releases will be activated on the above mentioned date. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation. > > > It’s clear that OP Labs and the Security Council will collaborate on emergency cancellation if needed, but it would be good to **explicitly define who makes the final decision** (Optimism Foundation, Security Council, or both?). The Optimism Foundation and Security Council together are the final decision-makers, as they are both blocking signers on the 2/2 L1ProxyAdminOwner. > **Process** : > Will there be public confirmation/logging of key rotations? Because key rotations are an onchain action, they are naturally logged. > Is there a designated team within the Foundation responsible for managing this process? > If OP Labs or another entity gets access to the Pause Deputy key, how will responsibilities be defined? > Will the Security Council have visibility over these decisions? The Optimism Foundation’s leadership team is responsible for managing this process, with specific incidence response playbooks delegated to the OP Labs security team. The Security Council will be informed of these decisions, though the current playbooks prioritize taking immediate action to favor safety over liveness, so this information/decision will not come in real time. ---
**Author:** ![wildmolasses](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/wildmolasses/32/11299_2.png) [@wildmolasses](https://gov.optimism.io/u/wildmolasses)\ **Post date:** [March 14, 2025, 6:52pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/14 "2025-03-14T18:52:26Z")
The DAB assessed this proposal and happily recommends its approval. ---
**Author:** ![SEEDGov](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/seedgov/32/5202_2.png) [@SEEDGov](https://gov.optimism.io/u/SEEDGov)\ **Post date:** [March 17, 2025, 1:35pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/15 "2025-03-17T13:35:50Z")
> [@maurelian](#): > > **Audit Reports and Findings** > > **Offbeat Labs** > > Offbeat Labs completed an audit of this code and found 1 Low Severity issue which has been addressed. Could someone from OP Labs confirm if [this](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2025_01-IRI-OffbeatLabs.pdf) is the correct report mentioned as made by Offbeat Labs? Thanks ---
**Author:** ![GoBOB](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gobob/32/11449_2.png) [@GoBOB](https://gov.optimism.io/u/GoBOB)\ **Post date:** [March 17, 2025, 3:16pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/16 "2025-03-17T15:16:40Z")
Hi, BOB team here, we are one of the top 100 delegators. In response to this proposal we are happy with the OPCM + Fault proof response improvement, however can you shed some light on the “DeputyPauseModule”? Specifically, - Definition of the “pause” mean in the Superchain context? Does it halt all rollups or just pausing withdrawals? - What criteria trigger a pause (e.g., % of funds lost)? - How is it unpaused, and how does the Security Council work with chains to restore state? Thank you ---
**Author:** ![maurelian](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/maurelian/32/9353_2.png) [@maurelian](https://gov.optimism.io/u/maurelian)\ **Post date:** [March 17, 2025, 4:30pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/17 "2025-03-17T16:30:15Z")
> [@SEEDGov](#): > > Could someone from OP Labs confirm if [this](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2025_01-IRI-OffbeatLabs.pdf) is the correct report mentioned as made by Offbeat Labs? Thanks Yes, that is correct. ---
**Author:** ![maurelian](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/maurelian/32/9353_2.png) [@maurelian](https://gov.optimism.io/u/maurelian)\ **Post date:** [March 17, 2025, 4:36pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/18 "2025-03-17T16:36:46Z")
> [@GoBOB](#): > > - Definition of the “pause” mean in the Superchain context? Does it halt all rollups or just pausing withdrawals? It currently pauses withdrawals for all chains in the superchain, although there exist plans to make this more granular so that subsets of chains can be paused. > [@GoBOB](#): > > - What criteria trigger a pause (e.g., % of funds lost)? The pause will be preemptively, when a bug is identified which puts user funds at risk necessitating an upgrade. > [@GoBOB](#): > > - How is it unpaused, and how does the Security Council work with chains to restore state? It is unpaused by the security council can call the `unpause()` function on the `SuperchainConfig` contract. I’m not sure about the meaning of “restore state”, but my understanding is that the Security Council would work with affected chains to ensure that it is safe to reactivate withdrawals prior to unpausing. ---
**Author:** ![GoBOB](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gobob/32/11449_2.png) [@GoBOB](https://gov.optimism.io/u/GoBOB)\ **Post date:** [March 18, 2025, 9:04am UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/19 "2025-03-18T09:04:27Z")
Appreciate the feedback Maurelian, We have some followup questions: - Do you have more granular guidelines or criteria of when they will pause all withdrawals? So for example, is a $1k or a $1mm hack? Or is the pause only triggered when they identify a bug in the OP stack code? To me, it’s not entirely clear what class of bugs in terms of likelihood of exploitation, impact and scope would warrant a pause. - On restoring state: this would come into play if the security council pauses withdrawals due to an issue at with an oracle provider. Let’s say an oracle provider and a DeFi protocol loose tons of user funds due to a hack or misconfiguration. The chain in question wants to hard fork and roll back their state to before the hack. How would the security council act? Thank you ---
**Author:** ![Sinkas](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/sinkas/32/6082_2.png) [@Sinkas](https://gov.optimism.io/u/Sinkas)\ **Post date:** [March 19, 2025, 3:57pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/20 "2025-03-19T15:57:41Z")
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas. It’s based on their combined research, fact-checking, and ideation. We voted FOR the proposal. The new emergency procedure outlined in the proposal aligns with our Stage 1 requirements, so we don’t see a reason to be against it. Our research team reviewed the OP Contracts Manager to make sure the contracts were set up as intended and found no issues. ---
**Author:** ![LobbyFi](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/lobbyfi/32/11688_2.png) [@LobbyFi](https://gov.optimism.io/u/LobbyFi)\ **Post date:** [March 20, 2025, 7:44pm UTC](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739/21 "2025-03-20T19:44:52Z")
LobbyFi voted FOR since there was one lobbyist who bid for FOR option. His bid exceeded the threshold, which is at 10% of the instant buy which has been chosen for this proposal.