# \[FINAL\] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization **URL:** \ **Category:** Protocol Upgrade\ **Created:** [May 16, 2024, 5:00pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157 "2024-05-16T17:00:45Z")\ **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:** [May 16, 2024, 5:00pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/1 "2024-05-16T17:00:45Z")
Hi Maurelian here, I’m a protocol security 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. # Executive Summary The protocol upgrade is intended to increase the security and decentralization of the Superchain by meeting the following requirements: 1. Increasing the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners. This meets the 75% threshold requirement for a Stage 1 rollup outlined in [L2Beat’s Stages framework](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52). 2. Reassigning the role of Guardian from the Foundation to a new Guardian Safe with the Security Council Safe as its sole owner. This moves the Superchain closer to satisfying the 1 week [exit window](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) requirement for Stage 1. 3. Reassigning the owner of the L2ProxyAdmin contract from the Foundation to the Security Council (currently in Phase 0, which is a joint 2/2 multisig between the Security Councils Safe and the Foundation Safe). This ensures the Security Council Safe has a blocking vote for L2 predeploy upgrades and is a requirement for Stage 1. If this vote passes, we recommend the upgrade be deployed shortly after the end of the veto period. # Specifications The full specifications for the Liveness Extension and Deputy Guardian system are available [from the specs repo](https://specs.optimism.io/experimental/security-council-safe.html). ## **Technical Details** This upgrade does not affect the node or execution client software. The following outlines the full set of changes to the existing system: 1. The `SecurityCouncilSafe` is modified to: 2. A new `GuardianSafe` is deployed, which has a threshold of 1, and the Security Council Safe as its only owner. 3. The `SuperchainConfig` contract is upgraded with the `GuardianSafe` in the `Guardian` role (the code is unchanged). 4. The `L2ProxyAdminOwner` is set to the _[aliased](https://docs.optimism.io/chain/differences#address-aliasing)_ address of the `L1ProxyAdminOwner`, which is the Phase 0 Security Council. These contracts are tagged in the optimism repo at commit [`9047beb`](https://github.com/ethereum-optimism/optimism/commit/9047beb54c66a5c572784efec8984f259302ec92) (tagged as release candidate [`op-contracts/v1.5.0-rc.1`](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv1.5.0-rc.1)). # Security Considerations ## Code Security Consistent with the [OP Labs Audit Framework](https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864), OP Labs had the code audited by a [Cantina contest](https://cantina.xyz/competitions/d47f8096-8858-437d-a9f5-2fe85ac9b95e) which ended on May 10th. A Lead Security Researcher from Spearbit was also engaged to audit the system in parallel. This audit uncovered no High severity issues, however a number of improvements were identified which we elected to make in order to reduce the potential for issues resulting from human error. A draft of the report can be viewed [here](https://github.com/ethereum-optimism/optimism/blob/maur/cantina/docs/security-reviews/2024_05_SafeLivenessExtensions-Cantina.pdf). It will be finalized after the completion of judging and escalation, however OP Labs has reviewed the findings with assistance from the Cantina/Spearbit team and are confident that no High severity issues were identified. Those changes (all in the `LivenessModule`) are: 1. A constructor check was removed, which enforced that the Safe’s threshold was greater than 75% of the owner count at the time of the module’s deployment. This check reduces the likelihood of the module being enabled on a misconfigured Safe, but also made the deployment and upgrade process more difficult. The check will instead be done at upgrade time, thus ensuring no loss of safety ([PR here](https://github.com/ethereum-optimism/optimism/pull/10516)). 2. Error message handling was modified to be more consistent with other portions of the codebase ([PR here](https://github.com/ethereum-optimism/optimism/pull/10538)). 3. The module will be deactivated in the event that ownership of the Security Council Safe is transferred to the `FALLBACK_OWNER` (the Foundation Safe). This mitigates the risk of unexpected behavior when the Safe is operating below the expected minimum number of owners ([PR here](https://github.com/ethereum-optimism/optimism/pull/10529)). ## Operational Security We will also establish monitoring systems for detecting events associated with the code. These systems will detect and alert on the following events: 1. In the `LivenessModule` 2. On the Security Council Safe: 3. On the `DeputyGuardianModule`: ## Proxy Admin Owner Security According to the [Stages framework](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe), one of the requirements for Stage 1 is that “Users’ withdrawals cannot be censored by the permissioned operators”. This means that any vector to halt or censor users’ withdrawals OR steal users’ funds must be controlled by the Security Council. An attack vector exists whereby the `L2ProxyAdminOwner` can potentially steal users’ funds by upgrading L2 predeploy contracts. The specific attack is: - Upgrade the `L2toL1MessagePasser` contract, - Insert false entries to the `[sentMessages()` mapping]([https://github.com/ethereum-optimism/optimism/blob/maur/guardian-module/packages/contracts-bedrock/src/L2/L2ToL1MessagePasser.sol#L24](https://github.com/ethereum-optimism/optimism/blob/maur/guardian-module/packages/contracts-bedrock/src/L2/L2ToL1MessagePasser.sol#L24)), - One falsified withdrawal per asset is required to access the full balance of each ERC20 (in the Bridge) or ETH (in the Portal) - Withdraw ERC20s from the Bridge and ETH from the Portal To ensure “no permissioned operators” can censor users’ withdrawals or steal users’ funds (and therefore satisfy Stage 1 requirements), the `L2ProxyAdminOwner` is being transferred from the Foundation Safe to the L2 [alias](https://docs.optimism.io/chain/differences#address-aliasing) of the Phase 0 Security Council. The Security Council Safe will now have a blocking vote on all L2 predeploy upgrades. ## Impact Summary OP Labs does not anticipate any downtime due to this upgrade. Node operators are not affected. Existing contracts retain their current interfaces in order to remain backward compatible with any existing integrations. These changes primarily affect the system of ownership and authorization, and serve to increase the decentralization of the Superchain. # 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. The upgrade will be completed atomically such that all affected L1 contracts will be upgraded within a single transaction. No action is required by node operators, as this is change affects contracts only. 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 This upgrade moves the Superchain forward in terms of decentralization, while preserving existing incident response capabilities and providing safety against potential liveness failures. ---
**Author:** ![Alisha](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/alisha/32/11237_2.png) [@Alisha](https://gov.optimism.io/u/Alisha)\ **Post date:** [May 16, 2024, 6:32pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/2 "2024-05-16T18:32:26Z")
As Security Council Lead, I am excited and proud to see this proposal to progress the Security Council from Phase 0 to Phase 1. This is a huge step in further decentralizing the Superchain 👏 . > [@maurelian](#): > > Increasing the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners. This is a significant change from the current signing threshold, which is 4/13. Signing data from the last two proposal upgrades signed by the Security Council is as follows: - 13/13 SC members submitted signatures for Proposal Upgrade 4; and - 12/13 SC members submitted signatures for Proposal Upgrade 6. Based on these numbers, I do not anticipate any issues with the Security Council meeting the increased signing threshold (75%). During Phase 0, the Security Council was operating on the basis that it should be meeting a 75% signing threshold, in anticipation of moving to Phase 1. I am confident in the ability of the individuals and entities who make up the OP Security Council to meet the new requirements and additional scope set out in this proposal. If anyone is interested in keeping up to date on the Security Council, monthly updates are posted on [opsc.vercel.app](https://opsc.vercel.app/). ---
**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:54pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/3 "2024-05-20T22:54:07Z")
Hey @maurelian thanks for the detailed post. Nice especially to see the SC bump to 10/14 . 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-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/4 "2024-05-21T00:59:40Z")
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:** ![Tane](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/tane/32/6950_2.png) [@Tane](https://gov.optimism.io/u/Tane)\ **Post date:** [May 21, 2024, 2:56am UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/5 "2024-05-21T02:56:17Z")
Thanks @maurelian for putting together the detailed proposal for the Superchain to aim to achieve the Stage 1 requirements. It’s great to see the continuous efforts to improve on the security, integrity and decentralization of the rollup. **We are [an Optimism delegate](https://vote.optimism.io/delegates/tanegov.eth) with sufficient voting power and 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:41pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/6 "2024-05-21T13:41:03Z")
I had to combine this document with the [Fault Proofs post](https://gov.optimism.io/t/upgrade-proposal-fault-proofs/8161/9) to understand the whole process and I feel there are a few gray areas. 1. **Manual Verification Process** : None of them specifically address the manual verification process for the AnchorStateRegistry mentioned in the Fault Proofs post. Clarifying who will conduct this verification and how it will be carried out would provide a more complete picture. 2. **Specific Actions of the Guardian** : While both documents discuss the role of the Guardian and its authority within the system, I can’t find examples of specific actions that the Guardian might take in various scenarios like dispute resolution, protocol upgrades or invalid output roots 3. **Timeline and Coordination** : Both documents outline the proposed actions and upgrades, but are they going to be implemented as soon as the Token House approves? Sorry if this question has already been addressed. With all the S6 governance documents, I haven’t had the chance to give these documents the proper time. Thank you for your patience. ---
**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:51pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/7 "2024-05-21T13:51:05Z")
**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** ---
**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 21, 2024, 2:10pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/8 "2024-05-21T14:10:39Z")
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:** ![GFXlabs](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/gfxlabs/32/171_2.png) [@GFXlabs](https://gov.optimism.io/u/GFXlabs)\ **Post date:** [May 21, 2024, 2:21pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/9 "2024-05-21T14:21:23Z")
We are an Optimism [delegate](https://vote.optimism.io/delegates/0xa6e8772af29b29b9202a073f8e36f447689beef6) with sufficient voting power and we believe this proposal is ready to move to a vote. ---
**Author:** ![Jepsen](https://dub1.discourse-cdn.com/bc41dd/user_avatar/gov.optimism.io/jepsen/32/11352_2.png) [@Jepsen](https://gov.optimism.io/u/Jepsen)\ **Post date:** [May 21, 2024, 3:36pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/10 "2024-05-21T15:36:23Z")
**On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal:** The Optimism team has proposed **three important changes** to enhance the security and decentralization of the network. This is a summary of these changes aimed to be digestible by non-technical members of the Optimism Collective. All of these changes are aimed at achieving a technical description of Stage 1 Decentralization, which is a critical step towards decentralizing the OP stack. These changes have the goal of increasing the security of the OP stack, improving decentralization, and enabling strong incident response. These changes have been audited by third party auditors in a [Cantina contest](https://cantina.xyz/competitions/d47f8096-8858-437d-a9f5-2fe85ac9b95e) which ended on May 10th. A Lead Security Researcher from Spearbit was also engaged to audit the system in parallel. The audits uncovered no High severity issues. **1. Increase in Security Council Threshold:** - Current State: Decisions require 4 out of 13 members to approve. - Proposed Change: Increase this to 10 out of 13 members. - Reason: This higher threshold ensures that more members must agree before any decision is made, significantly improving the network’s security by reducing the risk of a small group making unilateral decisions. _Thresholds_: Threshold signatures are ways to ensure that some group of authorized organizations or individuals have to agree before authorizing an action. For example Imagine you and your friends have a magical treasure chest. To open it, you need a special key. But, instead of one person having the key, the key is split into pieces. Each friend holds a piece of the key. To open the chest, you need a certain number of friends (say 3 out of 5) to put their pieces together. This way, no single person can open the chest alone; it requires teamwork. This makes sure the treasure is safe and only opened when enough friends agree. In general when the threshold is higher, this requires more parties to agree on unlocking the chest. The Security council makes decisions in a similar way to ensure one entity doesn’t have the ability to make unilateral decisions. The chest in this scenario is a smart contract that authorizes actions. Right now the threshold is low (only 4 out of 13 members need to put their key piece together) this upgrade increases the security by requiring that 10 out of 13 key pieces are needed to authorize upgrade changes. The increase in the security council threshold requires that members of the security council need to agree before decisions are made, which improves the network security by reducing the risk that a small group makes unilateral decisions. Notably this meets the 75% threshold requirement for a Stage 1 rollup outlined in[L2Beat’s Stages framework](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52) which is a respected framework for evaluating the stages of decentralization of rollups. **2. Guardian Role Transfer:** - Current State: The Foundation currently holds the Guardian role. - Proposed Change: Transfer this role to a new entity called the Guardian Safe, which will be controlled by the Security Council. - The foundation will be appointed the Deputy Guardian Role, which has the ability to act as a guardian through the Guardian Safe. The _Guardian Role_ is able to pause withdrawals from the OP stack in an unprecedented event in which there is a critical vulnerability in the fault proof system. Withdrawals are the act of withdrawing assets from an OP chain to Ethereum mainnet. The fault proofs are meant to make this process permissionless. But in the scenario where an attacker could withdraw more than they have (withdrawing other users’ funds from the OP Chain), the _Guardian Role_ can stop the attacker. This is considered a short term safeguard, but critical to ensure the safety of the Optimism ecosystem in the case of a catastrophic event. In practice the _Guardian Role_ is a smart contract that can only be called by an authorized wallet. This proposal sets the Security Councils threshold (as described above) as the authorized Guardian. This change also delegates the Guardian capabilities to the foundation by assigning them the _Deputy Guardian Role_, allowing the foundation the same abilities as the _Guardian Role_ (to pause withdrawals). In practice this upgrade only changes the configuration of the _Guardian_ such that the Optimism network can move closer to the stage 1 decentralization described by [L2 Beat](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe). - Current State: The ownership of the L2ProxyAdmin contract is the Optimism Foundation multisig. - Proposed Change: Reassign this ownership to a 2/2 threshold between the Security Council and the Optimism Foundation. - Reason: By transferring the ownership to the Security Council, the control over key administrative functions becomes more decentralized, preventing any single entity from having too much control over the system’s critical upgrades and changes. This change ensures that the Security Council Safe has a blocking vote for L2 pre-deploy upgrades and is a requirement for Stage 1. This means that when a networking upgrade is being voted on, the security council can vote against a network upgrade and prevent the vote from passing. This is important because not all upgrades are safe and if there is a network upgrade that is proposed that has security vulnerabilities, the security council should be able to stop the proposal from passing. ---
**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:34pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/11 "2024-05-21T17:34:50Z")
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:48pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/12 "2024-05-21T17:48:51Z")
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:42pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/13 "2024-05-21T19:42:43Z")
I am concerned about the increase to 10/13 for SC multisig. Its better in terms of security to make upgrades but introduces new risks in terms of loss of keys or liveliness within a certain time frame to 4/13. It would also now require 4 SC members to collude and stop upgrades/hold us ransom. I would prefer it to be closer to 8/13 60% or 9/13 70%. It feels safer to me. As for the other four upgrades, I feel are all understandable to implement. ---
**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 22, 2024, 12:08am UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/14 "2024-05-22T00:08:31Z")
If you received answers to these questions somewhere else, you mind linking it here for reference? I’m also curious about these questions you asked. Separate clarifying question: when all of these changes implemented, what powers will the foundation continue to have in the network? Just as the deputy guardian? Does the Foundation need to approve/execute any other upgrades (say, contracts on L1?). ---
**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 22, 2024, 2:31am UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/15 "2024-05-22T02:31:53Z")
Check the recording link posted here, next to the end of the call they address these questions: > [@Optimism Community Call Recaps & Recordings Thread](https://gov.optimism.io/t/optimism-community-call-recaps-recordings-thread/6937/37): > > Token House: May 14th, 2024 Recording: [May 14, 2024 S6 AMA and Token House Call.mp4 - Google Drive](https://drive.google.com/file/d/1mAWfVMQkG0O_aWdPRtk5ojHuMXhsAgNg/view?usp=sharing)[Cycle 22 Final Grants Roundup](https://gov.optimism.io/t/cycle-22-final-grants-roundup/8086) Total of 530 mission request applications and 130 finalists. The season is now closed and new applications for season 6 will open on July 18th. [Season 6 AMA](https://gov.optimism.io/t/season-6-guide-to-season-6/8113) We are currently in Season 6 Reflection Period: Reading Period. The reflection period will last till June 26th, read [Season 6: Reflection Period Guide](https://gov.optimism.io/t/season-6-reflection-period-guide/8130) for all dates and details. Season 6 will start on June… ---
**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, 2:38am UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/16 "2024-05-22T02:38:23Z")
As far as liveness/losing keys goes, I think there is a module built in if one of the addresses doesn’t prove liveness within 14 weeks. ---
**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, 4:06am UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/17 "2024-05-22T04:06:11Z")
I am an Optimism delegate with [sufficient voting power](https://vote.optimism.io/delegates/joxes.eth) and I believe this proposal is ready to move to a vote. ---
**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:29pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/18 "2024-05-22T13:29:31Z")
Thank you for the good explanation on the call. 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:** ![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:** [May 22, 2024, 4:38pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/19 "2024-05-22T16:38:31Z")
> [@Gonna.eth](#): > > 1. **Manual Verification Process** : None of them specifically address the manual verification process for the AnchorStateRegistry mentioned in the Fault Proofs post. Clarifying who will conduct this verification and how it will be carried out would provide a more complete picture. The verification should be carried out by the Security Council (SC). The OP Labs will provide a L2 block number anchor that the SC will verify that its output is configured in the `AnchorStateRegistry`. The SC will need access to an `op-node` to verify this. The procedure can be summarized as: 1. OP Labs provides a recent block number used to initialize the `AnchorStateRegistry` 2. Given an `op-node`, the SC will run the following script to verify the `AnchorStateRegistry`: ```bash set BLOCK_NUMBER # Anchored L2 block provied by OP Labs set ASR # AnchorStateRegistry address set OPNODE_URL ROOT=$(cast rpc optimism_outputAtBlock $(cast --to-hex $BLOCK_NUMBER) --rpc-url $OPNODE_URL | jq .outputRoot) cast call $ASR 'anchors(uint32) returns(bytes32,uint256)' 0 ``` The output of `cast call` must correspond to the `ROOT` and provided `BLOCK_NUMBER`. ```bash #!/bin/bash set -euo pipefail L1URL="${1:?Must specify L1 RPC URL}" OPNODEURL="${2:?Must specify op-node RPC URL}" ASR="${3:-0x18DAc71c228D1C32c99489B7323d441E1175e443}" RESULT=$(cast call --rpc-url "${L1URL}" "${ASR}" 'anchors(uint32) returns(bytes32,uint256)' 0) # First result is the output root ACTUAL_ROOT=$(echo "$RESULT" | head -n 1) # Second result is the block number but cast outputs it in decimal and scientific notation (e.g. 120059865 [1.2e8]) # So trim to just the decimal number BLOCK_NUM=$(echo "$RESULT" | tail -n 1 | cut -d ' ' -f 1) echo "Block Number: ${BLOCK_NUM}" echo "Actual: ${ACTUAL_ROOT}" BLOCK_HEX=$(cast --to-hex "${BLOCK_NUM}") EXPECTED_ROOT=$(cast rpc optimism_outputAtBlock "${BLOCK_HEX}" --rpc-url "${OPNODEURL}" | jq -r .outputRoot) echo "Expected: ${EXPECTED_ROOT}" if [["${EXPECTED_ROOT}" == "${ACTUAL_ROOT}"]] then echo "Anchor state is valid" else echo "Anchor state is invalid" fi ``` > [@Gonna.eth](#): > > 1. **Specific Actions of the Guardian** : While both documents discuss the role of the Guardian and its authority within the system, I can’t find examples of specific actions that the Guardian might take in various scenarios like dispute resolution, protocol upgrades or invalid output roots The Guardian is able to take 4 actions, which are enumerated in the DeputyGuardian module’s [specification](https://specs.optimism.io/experimental/security-council-safe.html#deputy-guardian-module): 1. Pause withdrawals 2. Unpause withdrawals 3. Blacklist a dispute game 4. Set the respected game type > [@Gonna.eth](#): > > 1. **Timeline and Coordination** : Both documents outline the proposed actions and upgrades, but are they going to be implemented as soon as the Token House approves? The intention is to finalize both upgrades as soon as possible after the Token House approves, and the Citizen’s House veto period has passed on Wednesday June 5th. However its worth noting that the two changes are independent of each other, and if for whatever reason either proposal does not go forward, they are not mutually dependent and can be activated independently. ---
**Author:** ![system](https://europe1.discourse-cdn.com/bc41dd/original/2X/3/399c2cdab1be9e0c1ae7481c939f977574c28f5e.svg) [@system](https://gov.optimism.io/u/system)\ **Post date:** [May 23, 2024, 12:04pm UTC](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/20 "2024-05-23T12:04:10Z")
_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-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/20))_ _Poll ([view on site](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/20))_ _Poll ([view on site](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157/20))_ [Next page](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157.md?page=2)