The Security Council (SC) did not submit a Budget Proposal for Season 6, as it is funded by the OP Foundation. However, key milestones and KPIs for Season 6 included:
Successfully running the first Security Council election for Cohort A (completed).
Meeting quorum for protocol upgrade signing ceremonies as an ongoing KPI (achieved throughout Season 6).
Meeting liveness requirements (achieved throughout Season 6).
The SC successfully achieved all its major milestones and KPIs during the Season.
2. Impact Assessment
The Security Council’s outputs strongly supported Intent #1: Progress towards decentralization.
Protocol Upgrades: The SC played a critical role in supporting upgrades aligned with Stage 1 decentralization requirements. The Security Council continued to impact the technical decentralization of Optimism.
Elections: The successful completion of the first SC election for Cohort A was a significant step forward for the Optimism Collective’s decentralization goals. Completing this election contributed to the governance decentralization of Optimism.
These efforts have advanced the Collective’s ability to operate in a decentralized manner, increasing the resilience of the protocol and the Security Council itself.
3. Challenges Faced
Resourcing Limitations: The SC remains reliant on OP Labs for operational and technical support. While OP Labs is invaluable, this reliance could undermine the SC’s independence in the long term.
Operational Friction: Compensation processing through the OP Foundation faced continued friction during the first half of the Season. This issue was resolved midway through Season 6 but highlighted inefficiencies in operational workflows.
4. Suggested Improvements to Operations
To address these challenges, the following solutions are proposed:
Budget Autonomy: Allowing the SC to manage its own budget would improve operational efficiency, reduce reliance on the OP Foundation, and enhance resilience.
Resourcing and Tools: Additional resources or tools to support technical independence could reduce the reliance on OP Labs and ensure the SC’s long-term sustainability.
5. Adjustments to the Mandate
As the Superchain governance framework evolves, the Security Council’s mandate should adapt to accommodate an extension in its responsibilities. The introduction of Blockspace Charters, temporary multisig structures, and the Superchain Registry may expand the scope of Security Council operations. To align with these changes, we propose addressing the following considerations on the next review of the Security Council’s mandate:
Operational Changes: The Security Council should formalize processes for managing temporary multisig structures and integrating its operations with the Superchain Registry. These changes will ensure smoother coordination and clearer accountability for protocol upgrades involving multiple stakeholders.
Emergency Procedures: Enhancing the Security Council’s emergency response mechanisms is critical to addressing risks such as governance capture or discrepancies in chain configurations. Clear, codified emergency procedures will empower the Security Council to act decisively while maintaining transparency. Any required infrastructure (such as third party apps or interfaces) should be put in place.
Collaboration Tools: The Security Council should set up tools and workflows to facilitate seamless communication with key stakeholders, including the Optimism Foundation, Chain Governors, and other governance participants. This will ensure timely and effective decision-making across the Superchain.
These adjustments aim to equip the Security Council with the necessary structure and flexibility to navigate the growing complexity of the Superchain while ensuring that its operations remain transparent, accountable, and aligned with the Optimism Collective’s guiding principles.
6. Continuation of Operations
The Security Council plays a critical element in the success of the OP Superchain. The scope and responsibilities of the Security Council should continue to evolve in a manner aligned with Blockspace Charters. Alongside evolving the technical scope of the Security Council, the Security Council should be equipped with the resources and budget to take on elements related to the execution of operations, building resilience and progressing continued decentralization of the OP collective.
Hey @alisha.eth - great retro here. When you mention additional resources and tools, can you share more about what resources and tools you think the SC could benefit from in Season 7?
Hi, I’m Matt and I work at OP Labs, and my views are my own.
In regards to the “Resourcing and Tools” proposal, we (OP Labs) are about to kick off a project to improve the superchain-ops repo, where the core goal is to make it much easier to safely create tasks to execute onchain transactions. Once this project is complete, the repo would be easy enough to use such that the Security Council could create and execute a task on it’s own, without any input from us.
A summary of the planned changes is that:
Common actions will have templates. You will be able to define execution of a templated task simply by populating a TOML input file with the required parameters.
The calldata a task executes will be specified as Solidity, like a regular forge script. This is much easier to write and understand than the current input.json format where everything is ABI-encoded. forge-proposal-simulator will be the tool behind this.
Many validation checks will be run by default, so it’s easy to gain confidence that a task is safe to execute.
Please let me know any feedback you have here, including any aspects you’d like more detail on, or others areas of the superchain-ops flow you’d like to see improved.
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two. In this particular case we also reached out for feedback to other L2BEAT team members.
While in general, we highly appreciate both the work that the Security Council did in Season 6 and this retrospective, we have some thoughts and suggestions that might be useful for the upcoming Season.
To begin with, we want to address what we think is an important oversight in the Security Council’s mandate.
The SC played a critical role in supporting upgrades aligned with Stage 1 decentralization requirements. The Security Council continued to impact the technical decentralization of Optimism.
We believe specifying who is responsible for reviewing and validating the contents of proposed upgrades might be a good idea. Right now, the responsibility is not clearly assigned as no single entity in governance is specifically accountable for it, and the responsibility simply lies in the Token House in general, which causes it to be diffused. As far as we know, no one is explicitly responsible for validating the contents of proposed upgrades within the Security Council (according to the Internal Operating Procedures) either.
Council participants are expected to verify that a proposed protocol upgrade or role designation decision has been approved by Optimism Governance. They are not expected to directly evaluate the “merit” of the accompanying proposed code (e.g., for security purposes).
Having security audits for the source code is not solving this issue either as audits, by definition, check if the code works as it is supposed to work; they’re not supposed to be opinionated about whether the code makes changes that are not in the best interest of Optimism Collective.
Moreover, the exact calldata of the upgrade that the Security Council is signing is known only to the Security Council, and, as things stand, is not mentioned in the upgrade proposals on the forum or in the vote on Agora. Therefore, only Security Council members can really fact-check if the calldata they are signing is an outcome of a code compilation mentioned in the proposal. In our opinion, the transaction that the Security Council is signing should be mentioned directly in the proposal so that anyone can verify if it’s correct.
As far as we know, right now, the participants of the Security Council are required to be individuals using an EOA address. As L2BEAT, we wanted to participate in the Security Council as a multisig, but we were told it’s not possible at this stage. We would like to highly encourage enabling participation as a multisig as this allows for much better operational management and security of this role. With multisig, we could set up our procedures for handling this responsibility, while right now, this responsibility lies solely in the hands of an individual selected from our team.
The role of the Security Council in Optimism is not limited to just planned upgrades for the protocol, but also to be a challenger in Optimism’s fault proof system. However, as far as we know, the Security Council fully relies on OP Labs and/or Foundation to serve this role, as individual Security Council participants are not expected to run their own system monitoring tools. The charter says:
It is expected that various members of the Optimism Collective would call attention to a faulty L2 output proposal
So, the Security Council has the final responsibility to intervene in case of a faulty L2 output proposal, but it doesn’t have the tools to fulfill this role as the responsibility for noticing the faulty L2 output proposal is diluted across “various members of the Optimism Collective.” We think this should be addressed and clarified in the future.
One more feedback that we got is a small issue - currently the Github repository mixes the contracts that are being verified with the code being executed while verifying/signing. It poses some additional risks related to the maintenance of this code locally. The improvement we’d like to suggest is to separate the contracts and the code that compiles and signs them ) to separate repositories, and try to avoid frequent changes to the non-contracts repositories.
Finally, as delegates, we would like to raise the process issue of setting the budget for the Security Council. While we agree that SC should have Budget Autonomy, we are a bit concerned that with the position that the Security Council has within the Optimism ecosystem, the Token House might be simply forced to accept any budget that SC proposes as the situation in which SC does not have any approved budget is an existential threat to the whole ecosystem.
Hi @AnthiasLabs the Security Council will focus on putting in place infrastructure for monitoring (to trigger incidents) and notifications (to send email/txt/voice/app alerts) to improve the ability of the Security Council to independently monitor the network for incidents that may require the Security Council to take action.
I recently posted the Season 7 budget for the Security Council. With an approved budget, the Security Council will be in a position to support initiatives and experiments related to tooling required for the Security Council (i.e. tooling for multisig signing and the verification of upgrades). Historically, the Security Council has been reliant on the developer resources available at OP Labs to pursue such development.
Hi @kaereste and @Sinkas. I appreciate your response and am looking forward to being able to cover my replies in more details in upcoming calls.
For each upgrade, the Security Council simulates and verifies the contents of the proposed upgrades. Here is an example of the a signing ceremony used by the SC. Please let me know if your expectation is that someone within OP governance (or whether the SC specifically) should be validating the contents of proposed upgrades over and above this level.
This is a great point. The Security Council is excited to support OP Labs over the coming months in it’s work to revise the process for signing upgrades, so call data is public and can be verified by anyone. This is obviously a preferred path forward in terms of both security and transparency.
Another great point. The inclusion of multisigs adds a meaningful level of complexity to tooling development. Up to now, the Security Council has been reliant on OP Labs to develop such tooling. In the Season 7 Security Council Budget has requested OP for an Infrastructure and Experiments category and specifically included R&D related to multisig tooling within that category.
An area of focus in the Season 7 budget is putting monitoring tools in place so that the Security Council is able to independently carry out its responsibility as a Challenger.
This consideration will certainly impact the work being done on revising the superchain-ops repo. I will tag @mds1 here to confirm visibility to OP Labs, who will be leading this work.
I believe in the ability of the Security Council to be responsive to any concerns related to its operating budget in a given Season, so that the Token House doesn’t feel it is effectively held hostage by the SC. The Security Council is very open to feedback on the Season 7 budget from Delegates in the week ahead of voting. I am looking forward to participating in public calls related to council budgets over the next week.