[RFC] Implementation of Governance Cycles in ZKsync

Background

This proposal stems from a community conversation about whether ZKsync should implement governance cycles. Several members of the ZKsync community expressed support for cycles, citing the benefits of having a structured approach to proposal submission and decision-making. Governance cycles can bring predictability, improved coordination, and higher engagement by allowing proposals to be assessed in batches rather than individually.

However, there were also concerns raised about the complexity cycles might introduce for non-core participants, and the potential for slowing down decision-making in fast-moving areas of the ecosystem. Some argued that governance should remain flexible and not rely too heavily on off-chain norms, while others highlighted that cycles could be designed with flexibility in mind, allowing urgent or out-of-cycle proposals when necessary.

Taking these points into consideration, this proposal suggests introducing Governance Cycles in ZKsync to provide a structured, transparent, and predictable framework for governance. The cycles will help focus community attention, improve proposal evaluation, and offer a routine process for participation, while also maintaining the flexibility to handle urgent matters.

Summary

This proposal suggests implementing a structured Governance Cycle for ZKsync, dividing governance activities into clear, recurring phases. The governance cycle will allow for the systematic review and decision-making on proposals, fostering a transparent and predictable governance process.

Objective

The objective of introducing Governance Cycles is to provide an organized framework that streamlines proposal submission, review, voting, and implementation processes. The cycle ensures that ZKsync’s governance operates efficiently while encouraging active community participation.

Cycle Structure

Each governance cycle will be divided into four phases:

  1. Submission Phase (TBD):
  • Proposals are submitted by community members, stakeholders, or working groups.
  • Proposals must be complete, including a rationale, implementation details, and requested funding (if applicable).
  1. Review and Discussion Phase (TBD):
  • The ZKsync community reviews submitted proposals on the forum and other discussion platforms.
  • Community members can provide feedback and suggest modifications.
  1. Voting Phase (TBD):
  • Approved proposals from the review phase are submitted for voting.
  • ZKsync token holders or delegates participate in voting.
  • Guardians retain the ability to cancel proposals during the Voting Phase using the Onchain Veto, in case of significant concerns.
  • Once a proposal passes with a simple majority (without counting abstentions), it enters a 24-hour Timelock Period, where the final review can take place before it is executed.
  1. Implementation Phase (TBD):
  • Successfully voted proposals are implemented or scheduled for execution.

  • Review and feedback from the previous cycle’s execution may be discussed in preparation for the next cycle.

  • Before final execution, Protocol Governor proposals go through a 30-day Risk Review Period, where the Security Council conducts technical reviews. If any issues are found, the proposal may be rejected, or Guardians can approve it if the Security Council doesn’t act.

  • Proposals that pass the Risk Review enter a final 24-hour Timelock Period, after which they are queued for permissionless execution on ZKsync Era.

  • Emergency proposals can bypass the regular governance cycle if an urgent situation arises that requires immediate action.

Benefits of Governance Cycles

  1. Predictability and Structure:
  • Governance cycles ensure that decisions are made within a fixed and transparent schedule. This regularity helps the community plan around governance timelines and ensures that important discussions don’t get lost in constant proposal submissions.
  1. Community Engagement:
  • By having a clear and recurring cycle, the community is more likely to participate. Knowing when they can submit, review, or vote creates a sense of ownership and involvement.
  1. Efficient Resource Allocation:
  • Governance cycles allow ZKsync to allocate time and resources efficiently. Teams can focus on implementing decisions within specific time frames rather than constantly switching between discussions and implementations.
  1. Focus on High-Quality Proposals:
  • By batching proposals in a structured format, the community has more time to review and focus on the most impactful proposals rather than dealing with a constant influx of new ideas.
  1. Reflection and Adjustment:
  • The structured cycles provide the opportunity to review the effectiveness of previously implemented proposals, leading to ongoing improvements in governance processes.

Trade-offs of Governance Cycles

  1. Slower Decision-Making:
  • A structured cycle means that urgent proposals may have to wait until the next cycle. This delay can be frustrating for time-sensitive proposals, especially in a rapidly changing ecosystem.
  1. Bottlenecks at Submission Deadlines:
  • With defined submission periods, there may be a rush to submit proposals right before the deadline. This could overwhelm the review process and lead to less thoughtful discussions.
  1. Fixed Timelines Might Be Restrictive:
  • Some proposals may need longer review periods or immediate action, which may not align well with the predetermined cycle structure. Flexibility is reduced compared to continuous governance.
  1. Increased Pressure During Review and Voting:
  • Concentrating all proposal reviews and votes in specific phases might place more pressure on participants to stay engaged during those windows, potentially leading to fatigue or rushed decisions.

Security Measures and Adjustments

  • Emergency Proposals: In the case of critical situations or protocol vulnerabilities, a special category for emergency proposals can bypass the cycle to ensure immediate action.
  • Cycle Adjustments: Based on feedback, the community can vote to adjust the length of the cycle, the phases, or introduce a mid-cycle review phase if necessary.

Conclusion

Governance cycles are a structured and transparent approach to ZKsync’s decision-making process. They promote active community participation, resource efficiency, and thoughtful review of proposals, though they come with trade-offs in terms of flexibility and potential delays for urgent matters. This proposal recommends the adoption of the Governance Cycle model for a trial period of three governance cycles (nine months) to assess its effectiveness and refine it as needed.

Open to Question

We invite the ZKsync community to review this proposal and share their feedback. Our aim is to build a governance framework that is not only structured and predictable but also flexible enough to adapt to the needs of the ZKsync ecosystem as it grows.

In particular, we’d like the community’s input on the following key areas:

  1. Duration for Each Phase

    What should be the optimal duration for each phase (Submission, Review & Discussion, Voting, and Implementation) to balance thoughtful decision-making with the need for agility in governance?

  2. Seasons
    Should we consider bundling governance cycles into seasons (e.g., quarterly or biannually) to align decision-making with broader ZKsync development goals? This could provide more focus and allow for thorough review at the end of each season, helping us track progress and adapt the governance process

4 Likes

Thanks for bringing this up and summarizing the benefits and trade-offs. From my experience, governance activity is often cyclical and therefore difficult to predict, so there might be cycles with no proposals. I’m also not sure if this would increase community activity.

Therefore, at the current stage, I would argue for no cycles. However, with more proposals coming up, this could be an idea to reiterate on.

Thanks for putting this together.

I’m not against Cycles but what I don’t understand here is what they’ll be enforced on. How do you apply them and to what specifically?

What recurring process there is right now in ZKsync’s governance that Cycles would optimize and improve?

Adding Cycles for all Proposal Submissions (ZIPs, TPPs, or GAPs) is somewhat constraining, as I currently understand this proposal.

1 Like