Proposing Celo L2's Security Council

Governance Governance Proposals
1

Proposing Celo L2’s Security Council

cLabs is proposing the establishment of a Security Council to further decentralize the Celo L2 Network at the time of launch. This council will play a crucial role in safeguarding the network by managing key upgrades and security fixes.

Responsibilities of the Security Council

The Security Council is expected to fulfill the will of Celo’s Onchain Governance related to the following operations:

  • Upgrading L1 protocol contracts for Celo’s L2 implementation.
  • Modifying designations for certain important roles in the system, such as sequencers (i.e., batchers), proposers, challengers, and membership on the Security Council multisig.
  • Executing urgent security fixes via a hotfix of the Celo Contracts.

In rare instances, it can choose to take action without the regular Governance Process to address an urgent matter so long as it does so in the Celo network’s best interest (e.g. fixing a security vulnerability).

By establishing this Security Council, Celo moves closer to its Celo L2 decentralization goals: ensuring no single party is able to upgrade the system, modify rollup state, or censor transactions.

Please note that the regular Governance Process of upgrading Celo Core Contracts and allocating funds of the Celo Community Fund remains unchanged.

Decentralization Impact

Councils play a key role within Celo Governance, as they empower representatives to manage Celo resources and make decisions on behalf of tokenholders. With the introduction of the Security Council, we ensure:

  • No single entity can upgrade L1 protocol contracts
  • No single entity can modify L2 state
  • No single entity can censor L2 users from transacting onchain

Proposed Multisig

Following the model defined by the Optimism Foundation, cLabs is proposing a The Security Council that will operate through a multisig system structured as follows:

A 2/2 Safe multisig with these members:

  1. cLabs Mutisig
  2. Celo Community Security Council

The 2/2 structure ensures that a quorum-blocking group of non-cLabs controlled members exists at all times (i.e. cLabs cannot unilaterally push through changes to the L2 without the Celo Community Security Council’s approval).

The cLabs Multisig will be managed internally with a 75% threshold initially as a 6 out of 8 multisig. The Celo Community Security Council is proposed to start as a 6/8 multisig consisting of the following inaugural members:

  1. L2Beat
  2. Hyperlane
  3. Valora
  4. Mento
  5. Nitya Subramanian
  6. Kris Kaczor
  7. Tim Moreton
  8. Aaron Boyd

This proposed list will be posted for ratification via onchain governance ahead of the L2 hardfork. We plan to follow up with specific term durations and a process for renewals in the future.

Collectively, this 2/2 multisig satisfies Vitalik’s security requirements for an L2 as outlined in the following post. Namely, the multisig has over 8 participants (13 in total across both multisigs), with a 75% threshold, and has a quorum blocking number of members that are outside of cLabs.

Members are still provisioning their hardware wallets and will share addresses in the coming days. As is the case with the OP Security Council, addresses will not be linked to individuals/entities but will be posted to this thread as a complete list when it is ready so it can be compared to the onchain multisig. We encourage all proposed members to post to this thread to confirm that their address is in the list once it is posted.

Security Standards

Signers of the multisig will follow the Optimism multisig security policy, ensuring robust security practices inspired by the OP Stack Multisig, with the one difference that entities can choose to use nested multisigs so long as all signers conform to the same security policy.

Signers required the to hold keys in safety deposit boxes and other secure locations outside of regular business and residential addresses.

15 Likes
2

Thank you @martinvol and the whole cLabs team for putting this together, this is an exciting and necessary step towards further decentralization of Celo L2.

I’m curious will there be a term limit specified for this inaugural cohort similar to the Optimism Security Council? And do you think there will be a process for new members to join in the future?

I think a regular cadence of confirming members will be helpful to ensure everyone is still active and willing and able to participate and prevent any potential issues with indefinite membership.

One suggestion is if we move towards a Seasonal model of governance similar to OP, Security council can have terms that align to it (for example 6, 12, or 18 months). Since this will launch in the middle of transitional Season 0 (Jan-June 2025), a term of 9 months for inaugural cohort might make sense which will take us to end of Season 1 and then a follow up proposal could ratify next cohort members (same or additional). Curious to hear other thoughts on this!

10 Likes
3

In favor of having the initial start for at least 9 months.

3 Likes
4

Excited to see this proposal come forward and in favor of the initial multisig signers. Will support this!

3 Likes
5

Thanks @martinvol and team for the proposal, at my end this proposal is fulfilling all the requirements:

  • Post a proposal in the Celo Forum and leave it for discussion at least for seven (7) days.
  • Present Proposal in a Governance Call and address the feedback received: Proposal was presented during Celo Governance Call #64 | March 20th, 2025

With the above said, from my end the proposal is ready to move into the voting phase when proposer wants to move forward or consider is appropriate.

:bangbang: Remember Current Celo Governance Overview & Procedures

To proceed to the submission and voting phase at least two Celo Governance Guardians must post explicitly that the proposal fulfills the requirements to be able to move into the Voting Stage in the proposal thread on the Celo Forum.

Remember next steps

  • Submission of PR to Celo Governance Repository
    Proposers needs to fork the Celo Governance Repository and add a PR including the proposal .md file and json file.
  • Approval of PR by Celo governance Guardians and merge into main branch of Celo Governance Repository.
    Celo Guardians are responsible for conducting a comprehensive review of every Pull Request (PR) to ensure that there is complete alignment and consistency between the final proposal posted in the forum post and the specific files that are being requested to be merged.
    This review process is strictly technical in nature, focusing solely on verifying the authenticity and good faith of the proposers. It does not involve any personal opinions or biases regarding the merits or content of the proposal itself. To maintain the integrity of the Celo Governance repository, it is mandatory to obtain approval from a minimum of two Governance Guardians for each PR before it can be merged into the main branch.
  • OnChain Submission of Proposal
    After PR is merged into main Governance Repo the proposers needs to fork locally the Celo Governance Repository and submit the proposal onchain using the guidelines described in the Celo Docs.

CC: Governance Working Group (@annaalexa @Wade @0xGoldo)

6

Thanks to @martinvol and the team for submitting this proposal. From my perspective, it meets all necessary criteria:

  • The proposal was posted on the Celo Forum and remained open for discussion for at least seven (7) days.
  • It was introduced during Celo Governance Call #64 on March 20th, 2025, with all relevant feedback addressed.

Given this, the proposal is ready from my end to proceed to voting whenever the proposer feels ready or considers it suitable.

7

The Celo Community Security Council members have all generated their keys :raised_hands:

Here are the addresses for the each of the signers in no particular order:

0x148dfac5df51ab1d7b02a3b53f1e2da1f0a6b5ca
0xD1C635987B6Aa287361d08C6461491Fa9df087f2
0x2be5e223e368e8c0f404a1f3eb4eb09f99c8fad8
0x6fdb3ea186981aa32dd8e7b782d95733ca3c13a1
0x5f70938aa8d2fd91ee3959998e5ddaacfb6ffb85
0xd0cE4D055d04bDA69b20815A3F796019bB68c6Db
0xb963047c5d875b7fe777339b1e6b61ac4df1f3e2
0xc3E966E79eF1aA4751221F55fB8A36589C24C0cA

Edit: Changed one address at the request of the signer.

4 Likes
8

I can confirm that our signer key is on this list

4 Likes
9

The threshold of cLabs multisig got updated to make it bigger, while still complying with 75% threshold. Check the original post.

3 Likes
10

Valora’s signer is on the list.

1 Like
11

I confirm that my address is on the list.

1 Like
12

I confirm that L2BEAT’s address is on the list.

13

I confirm that Aaron Boyd’s address is on the list

14

First, we want to thank cLabs and all contributors involved in this proposal. The creation of a Security Council for Celo L2 is a critical step in advancing the protocol’s decentralization roadmap and ensuring the security of the rollup architecture at launch. The proposed structure shows clear intent to establish a credible and secure governance layer. The 2-of-2 multisig setup, with a quorum-blocking mechanism that includes a diverse set of reputable stakeholders, strikes a pragmatic balance between decentralization and operational security in these early stages.

That said, there are a few areas that would benefit from additional clarity to have the full picture.

First, it would be helpful to understand what emergency response procedures are in place. While the proposal gives the Council the authority to act in rare and urgent situations, it is unclear whether there is a documented escalation process or decision-making protocol for such events. In a real-time security incident, who determines if a vulnerability meets the criteria for a hotfix? What communication, if any, can the community expect after such actions are taken? Establishing a transparent and repeatable framework for emergency scenarios would go a long way toward maintaining community trust.

On a related note, it would be valuable to know whether the Council is intentionally geographically distributed. In time-sensitive situations—such as potential exploits or required upgrades—signer availability and responsiveness are key. Is there sufficient time zone coverage across the Council to ensure 24/7 readiness? And if not, is there a backup or failover protocol in place in case certain signers are unavailable? These operational details could make a meaningful difference in practice.

Another important area that could benefit from clarification is the matter of funding and resourcing. Are there plans to provide operational support to Security Council members, such as compensation for participation, hardware wallets, or security audits? If so, will this come from the Celo Community Fund or through a separate allocation? While Council membership is a service to the network, we should be realistic about the operational costs associated with maintaining high security and availability standards—and transparent about how those costs are being addressed.

Looking ahead, it would also be great to see some commitment to regular communication between the Council and the broader community. Will the Security Council host periodic office hours, AMAs, or postmortems? Even a light-touch cadence—for example, one public session per term or after major upgrades—would help maintain alignment and accountability. As this group will be responsible for executing governance directives and potentially making time-sensitive decisions, opening a channel for occasional dialogue would help build trust and familiarity.

Regarding the structural recommendations, it is essential to establish clear guidelines for the terms and processes that will govern the Council’s operations. While the proposal notes that term durations will be finalized at a later date, we must commit to a well-defined timeline for setting term lengths, rotation mechanisms, and renewal or replacement procedures—whether community-driven or governed. If we are serious about achieving progressive decentralization, these elements should not remain ambiguous.

It is also important to clarify how the Council will execute on-chain governance decisions. For instance, we need to determine whether a standardized process exists for issuing instructions once a proposal passes. Additionally, we should define what happens in cases where the intent behind execution is unclear or disputed. Providing more transparency around these procedures will help align expectations between governance participants and the Security Council.

As for security policy enforcement, we support allowing signers the flexibility to use nested multisigs. However, this flexibility must be accompanied by a shared, clearly auditable security standard. This means ensuring consistent policy enforcement across all configurations, moving beyond soft guarantees to uphold a uniform, reliable security framework. The reference to Optimism’s policy is a great starting point, and I’d encourage the team to make explicit how that standard will be adapted and enforced across different signer setups.

This proposal is a well-structured start that moves Celo in the right direction. We support the establishment of the Security Council and commend the team for anchoring it in best practices from across the ecosystem. I believe the Council will be a foundational layer for ensuring the security and responsiveness of Celo L2—and with the clarifications above, it can also be a model of transparent and accountable protocol stewardship.

Having said that, SEED Gov is supportive—contingent on the above being clarified or addressed shortly after launch. The Council will be a cornerstone of L2 governance and security, and getting it right from day one sets the tone for what the community can expect.

1 Like