Heads up: Simplifying On-Chain Governance on Tezos

Research and Development
1

We would like to share an approach to simplifying Tezos’ on-chain governance mechanism, which we are considering for the upcoming protocol U proposal.

It incorporates feedback from bakers and other ecosystem contributors, as well as lessons learned from recent governance experiments in the broader Tezos ecosystem, including Etherlink.

The goal is to make Tezos governance faster, more nimble, and simpler to manage for bakers – without compromising on the safety guarantees and decentralized decision-making that Tezos is known for.

Given the importance of the governance mechanism, we encourage bakers and the wider community to carefully study the ideas, changes, and rationales and share your feedback with us.

What we are looking to address

Some recurring themes appear in the feedback we receive from bakers and in our own experiences with developing and communicating about protocol upgrade proposals.

Too many voting rounds: Bakers currently vote up to 3 times per governance cycle, creating voting fatigue, inconsistent participation, and a heavy communication burden.

Slow iteration: The current 70-day governance cycle introduces significant latency from upgrade development to activation (or rejection). The slow iteration makes protocol evolution less responsive and holds back development.

The changes at a glance

The changes we aim to include in the protocol U proposal would have the following impact on the governance mechanism:

  • Shorter total duration. A full governance cycle is reduced from 70 days to 28 days.
  • Shorter voting periods: Voting periods are reduced from 14 days to 7 days (the Adoption period remains 14 days).
  • Simplified structure. Instead of 5 periods with 3 votes, a governance cycle has 3 periods with 2 votes.
  • Persistent votes: Votes in favour of a proposal cast in the first voting round automatically carry into the second round unless explicitly changed.
  • Opt-out for bakers: Bakers can opt out of being counted for the quorum.

Current governance model

Period Duration Purpose Details
Proposal 14 days Selection of a candidate proposal. Bakers can upvote multiple proposals. The most upvoted proposal proceeds to the next phase if supported by at least 5% of total voting power.
Exploration 14 days First ratification vote. Yea/Nay/Pass vote. Proceeding to the next phase requires 80% “Yea” supermajority with quorum reached.
Cooldown 14 days Testing and discussion. No on-chain activity.
Promotion 14 days Second ratification vote. Yea/Nay/Pass vote. Adoption requires an 80% “Yea” supermajority with quorum reached.
Adoption 14 days Gives the ecosystem time to adapt code and infrastructure before the new protocol activates. No on-chain activity. The new protocol activates automatically at the end.

Potential new governance model

Period Duration Purpose Details
Selection 7 days Selection of a candidate proposal. Bakers can upvote multiple proposals. The most upvoted proposal proceeds to Promotion if supported by at least 20% of total voting power.
Promotion 7 days Ratification vote. Yea/Nay/Pass vote. Adoption requires an 80% “Yea” supermajority with quorum reached. An upvote cast during Selection automatically carries over as a “Yea” for the proposal in Promotion unless explicitly changed.
Adoption 14 days Gives the ecosystem time to adapt code and infrastructure before the new protocol activates. No on-chain activity. The new protocol activates automatically at the end.

Faster iteration, less overhead, same legitimacy

The changes are meant to reduce operational overhead and communication friction for both bakers and protocol developers, while maintaining strong legitimacy for adopted proposals. They also enable faster and more flexible implementation of new features.

Shorter duration: The existing 70-day governance cycle slows iteration. A 28-day cadence enables more responsive and flexible protocol evolution while keeping sufficient safeguards and implementation buffers.

Shorter voting periods: Switching from 14-day to 7-day voting periods reduces the governance cycle length by a total of 14 days, while still providing ample time for bakers to cast their vote. Quorum requirements in the Promotion period continue to ensure that proposals are adopted only with a broad mandate.

Simplified structure: The Cooldown and Exploration periods are removed. Cooldown is a remnant of a previous automatic test chain period, which ultimately wasn’t practical. It doesn’t allow for adjustments to a proposal, and effectively adds 14 days of inactivity to the governance cycle. In practice, feedback loops and discussions for a proposal now happen before it is submitted, which also allows for adjustments. With Cooldown removed, the Exploration period would simply replicate the Promotion period without meaningful activity in between. Instead, a higher threshold during the Selection period (20% instead of 5%) ensures that only proposals with strong support proceed to the Promotion vote, where the 80% supermajority and quorum rules continue to apply.

Persistent votes: Voting fatigue is a common point of feedback from bakers. With persistent votes, an upvote cast during Selection automatically carries over as a “Yea” vote for the proposal in the Promotion period unless explicitly changed. It enables bakers to participate in governance with a single voting action per governance cycle.

Quorum opt-out for bakers: Today, quorum requirements mean that even bakers who do not wish to participate in governance need to repeatedly submit “Pass” votes for a proposal to proceed through governance. This change allows bakers to explicitly opt out of quorum to reduce operational overhead. A baker can opt in again at any time, and the quorum dynamically adjusts to reflect the active governance set.

Key considerations

Quorum after transition: Introducing these changes may require recalibrating the dynamic quorum, either through a one-time reset or a smoothing rule, so that the new system does not inherit irregularities from past participation patterns.

Sufficient information in advance: The simplified governance process without the Exploration and Cooldown periods puts more responsibility on protocol developers to provide information and offer feedback loops before a proposal is submitted. The more familiar bakers are with a proposal, the stronger its chances of advancing through the governance process.

Tooling adaptation: Tooling providers must make opt-out status and persistent votes clearly visible to avoid confusion and ensure that bakers remain fully aware of their governance status. Clear visibility of opt-out status improves information about who can be expected to be part of a vote/quorum and strengthens transparency of the new governance process.

Fewer voting rounds: Going from 3 to 2 voting rounds may, on the surface, seem like a reduction of safeguards. However, the stricter requirements in the Selection period ensure that proposals don’t proceed through the governance process without a strong mandate. The Promotion vote still requires an 80% supermajority with quorum met for a proposal to be adopted.

Shorter voting periods: Early announcements and clear communication timelines are required to ensure bakers have sufficient time to react. In turn, the total active governance window is concentrated into a focused two-week window that encourages active and vivid community discussion instead of attention being spread over two months. Proposals emerging without prior announcement risk not gaining the support needed to pass on-chain if bakers don’t feel properly informed.

Quorum limited to active participants: Bakers have different levels of engagement with governance. The opt-out mechanism respects that diversity while ensuring quorum reflects those who actively choose to participate, keeping quorum a meaningful signal of genuine mandate.

We want your feedback

This proposal is shared early to gather community input. We are particularly interested in feedback on:

  • Voting period durations
  • The Selection period quorum threshold
  • Whether to keep the quorum EMA untouched or reinitialize it at protocol activation
  • Operational impact on baker workflows

We welcome all thoughts, concerns, and suggestions, including on the broader approach. Please share them below.

8 Likes
2

I’m going to be direct: this proposal weakens governance under the banner of convenience, and I think it deserves serious pushback.

Persistent votes are rubber stamps.

Let’s call this what it is. If a baker upvotes a proposal in Selection and that vote automatically carries as a “Yea” in Promotion, you’ve created a system where a single click approves a protocol change from start to finish. The second vote isn’t a vote anymore. It’s an opt-out window. Most bakers are running infrastructure businesses. They vote, move on, deal with their operations. You’re banking on them coming back 7 days later to reconsider? Inertia becomes approval.

7-day voting windows are not “ample time.”

Bakers are not full-time governance participants. Many of us run businesses, manage infrastructure across time zones, and don’t sit on Agora refreshing the page. 14 days was already tight for reading a proposal, testing on a testnet, discussing with peers, and casting an informed vote. 7 days means you either vote on instinct or you miss the window. Protocol changes to a Layer 1 blockchain should not be on a sprint cycle.

Removing Cooldown removes the discovery window.

You frame Cooldown as “a remnant of a previous automatic test chain period” that “doesn’t allow for adjustments.” That framing ignores what Cooldown actually does in practice: it’s 14 days where the community can find problems after the first vote passes. Bugs surface, edge cases get discussed, bakers who weren’t paying attention catch up. Removing it means there’s zero buffer between “this looks good” and “this is happening.” Feedback happens before submission now, sure. It also happens after. That’s defense in depth.

Removing Exploration collapses two distinct decisions into one.

Exploration asks “should this proposal move forward for serious consideration?” Promotion asks “should this activate on mainnet?” Those are different questions with different weight. Collapsing them into a single Promotion vote with a higher Selection threshold doesn’t replace the deliberative function of Exploration. A 20% threshold in Selection filters for popularity, not for thorough review. A proposal can be popular and broken.

Quorum opt-out inverts the meaning of quorum.

The entire point of quorum is to ensure proposals have broad mandate. Letting bakers remove themselves from the denominator doesn’t reduce their “operational overhead.” It reduces the legitimacy bar for every future proposal. If enough bakers opt out, a small minority of active participants can push through protocol changes on a chain that secures real economic value. “Quorum dynamically adjusts to reflect the active governance set” is a polite way of saying “we lower the bar until whoever shows up is enough.”

28 days from proposal to activation is reckless for an L1.

This isn’t a smart contract deployment or a frontend feature flag. Protocol changes affect consensus, staking, issuance, and every piece of infrastructure built on top of Tezos. Tooling providers, wallet developers, indexers, exchanges, and bakers all need time to prepare. 28 days total with only 14 of those being non-Adoption time is not responsible engineering. The Adoption period staying at 14 days doesn’t help if the proposal was inadequately reviewed in the 14 days before it.

Voting fatigue is a communication problem, not a structural one.

If bakers are fatigued by voting three times in 70 days, the answer is better tooling and clearer communication, not fewer votes. Build systems that make governance participation easier: automated notifications, clearer proposal summaries, one-click voting from baker dashboards. Make participation easier instead of reducing the number of decisions bakers get to make. Low engagement doesn’t call for less democracy.

Who does this actually benefit?

Faster cycles with fewer checkpoints and sticky votes benefit the people writing proposals. They get faster iteration, less friction, and auto-carried votes from the Selection round. Bakers get fewer opportunities to say no, less time to evaluate, and a system that counts their silence as approval. I’d like to hear from other bakers whether “faster” is actually what they’re asking for, or whether “clearer and easier to participate in” is closer to the real need.

I support making governance more accessible. I don’t support making it faster at the cost of making it thinner. Tezos governance is one of the few genuine differentiators this chain has. Gutting it to save 42 days is not the trade I’d make.

3 Likes
3

I think we can use this new governance model as the Fast-Track version and the old one as the regular lengthy one for critical upgrades. Adaptive Governance.

Most changes are technical and they will benefit from faster iterations, while critical economic changes should require more time and testing.

In general, I support the idea of faster iterations. Etherlink governance is a good example.

5 Likes
4

I like the fast-track suggestion.

  • Fast-Track (Nomadic Labs’ proposal):
    For non-breaking protocol changes — like new opcodes, gas optimizations, or non-consensus upgrades — that don’t require community coordination.

  • Standard (current model):
    For breaking changes — consensus rules, staking mechanics, tokenomics, or anything that affects how the network operates or requires ecosystem prep.

2 Likes
5

I appreciate the compromise idea and I get the intent. Everyone wants faster iteration. I do too.

My concern is that a fast-track lane sounds clean in theory and gets messy the second it touches real protocol work.

Who classifies a proposal as fast-track eligible?

What review process does that classifier follow?

Who can challenge that classification, and when?

What happens if impact is underestimated and we only discover it after activation?

That is where governance gets weakened.

A lot of protocol changes that look “technical” still have economic and operational impact. Gas changes affect app behavior and user costs. New opcodes change contract patterns and audit surface. Infra level changes hit bakers, indexers, wallets, and exchanges in different ways. The blast radius is often obvious only after broader review.

Fast-track also creates social pressure. Once the lane exists, every proposal sponsor has an incentive to argue their proposal belongs there. Over time the exception becomes routine. That drift is predictable.

If we want to do this responsibly, we need hard guardrails up front:

  1. Explicit exclusion list for fast-track

  2. Clear objective eligibility criteria

  3. Public pre-submission review window

  4. Challenge mechanism for misclassified proposals

  5. Automatic fallback to standard governance on dispute

  6. Periodic review with rollback if participation or legitimacy drops

Without that, we are optimizing for shipping speed over governance quality.

I am in favor of improving governance UX and reducing friction for bakers. I am not in favor of reducing decision quality or shrinking legitimacy to get there. Tezos governance is a core differentiator. We should be extremely careful with anything that makes it easier to move fast and easier to think less.

5 Likes
6

Primate got a point here:

”Who classifies a proposal as fast-track eligible?”

Since everything is code, we could define before hand what variables and parameters are technical and which ones are NOT.

Food for thought.

2 Likes
7

This new voting system could possibly even work just fine with baker behavior adjustments, more automatic initial nay votes to force more review time, whatever the case may be.

Sometimes bakers would auto nay just in case and sometimes votes would fail to produce quorum and a revote would be necessary anyway. All-in-all, I’m curious to explore and discuss this further. A more dynamic voting mechanic is something we do need.

But in time for U? Come on! Please, please involve bakers earlier in this kind of thought processes.

2 Likes
8

New opcodes and gas changes are absolutely breaking. This is the misunderstanding that can only occur when there are no external developers that don’t have the luxury of more direct coordination. Shortening the block times constantly is a breaking change. A valid argument might be that applications that rely on it are malformed, but they will break. The change is breaking.

Persistent votes makes sense to me. Most of the other changes just feel like they’re designed to give an easy out for large apathetic bakers. Don’t weaken the quorum when I already prefer full consensus over quorums. Shutting out minority positions, such as those of developers who have little stake, is not great.

1 Like
9

I really agree with this statement.

A Fast-track voting is in a interesting idea. I think Etherlink’s Fast track voting a great example of what NOT to do.

If Tezos governance is what holds the Tezos X road together, any sort of change to be deeply discussed with the community, and bakers. We need to be 200% confident that the changes are best for our Tezos ecosystem.

I feel like speeding up the governance process which has historically worked for over 20 upgrades, needs to be discussed (potentially over multiple protocols) and not thrown in at the of end protocol upgrade as “nice to have”.

2 Likes
10

The governance cycle as it is now was already too fast for developers of tools to keep up! I understand that we want to get down the roadmap fast, but Tezos is a huge and complex and delicate system. I do not approve of speeding things up in general. What should change though IMO is the separation of technical and economical upgrade proposals!

1 Like
11

The Cart is Before the Horse: Transparency Must Precede Compressed Timelines

While the goal of reducing voter fatigue and enabling faster iteration is understandable, this proposal attempts to solve a structural communication problem by simply giving the community less time to notice it.

I am strongly opposed to compressing the governance cycle from 70 days to 28 days. We have not demonstrated the ability to effectively communicate, document, and openly debate protocol upgrades within the current, more forgiving timeframe, and recent actions suggest transparency is moving in the wrong direction.

If we are currently struggling to properly disseminate information over a two-month period, drastically reducing that window will turn participation into a guessing game and governance by blind trust.

1. The Myth of “Pre-Submission” Discussion and Closed-Door Decisions The proposal claims that removing the Cooldown and Exploration periods is acceptable because “feedback loops and discussions for a proposal now happen before it is submitted.”

Where exactly are these discussions supposed to happen now? With the recent closure of the public Slack channels, the very venues for open, accessible, and asynchronous community debate are being dismantled. We are seeing a concerning trend of vital governance discussions moving behind closed doors. Shifting the entire burden of discovery to an unstructured, informal “pre-proposal” phase while simultaneously shutting down public squares means independent bakers will be left completely in the dark until the 7-day voting sprint begins. That is not decentralization; that is an oligarchy of whoever happens to be in the private chat.

2. Historical Communication Deficits Even with 14-day voting windows and dedicated discovery periods, bakers and ecosystem participants routinely scramble to understand the full scope of proposed changes. Documentation is often highly technical, siloed, or released too late for meaningful, widespread community digestion. If 70 days is currently proving insufficient for a majority of bakers to feel confident and informed, a 28-day sprint effectively guarantees that only core insiders will know what they are voting on.

3. Tooling and Transparency as Prerequisites, Not Afterthoughts. The proposal acknowledges that “tooling providers must make opt-out status and persistent votes clearly visible.” This touches on the real root of voter fatigue: a lack of streamlined, accessible governance tooling and proactive communication.

Before we even consider cutting the governance cycle by 60%, the ecosystem needs:

  • Public, Open Venues: A reversal of the trend toward closed-door development and the re-establishment of centralized, easily accessible public forums for real-time technical debate.
  • Standardized Executive Summaries: Clear, non-developer-friendly breakdowns of every protocol change before it hits the chain.
  • Proactive Communication Frameworks: Automated alerts and dedicated dashboards that push information to bakers, rather than requiring them to hunt it down.

Agility is a worthy goal for Tezos, but speed must be earned through superior infrastructure, radical transparency, and crystal-clear communication. It cannot be manufactured by cutting corners on review time, closing public communication channels, and treating voter inertia as approval. Until the communication pipeline is robust enough that bakers feel over-informed rather than overwhelmed, shortening the cycle is a reckless risk to the network’s decentralized legitimacy.

12

Particularly don’t like the automatic carryover of vote to next round. Also, does this further shorten the time for testing? Side question: when will Shadownet start cutting over to the next protocol prior to mainnet’s, as was done with ghostnet?

13

Finally, we’re formalizing the “Click Once to Comply” model so we can stop pretending governance is a marathon and just admit it’s a rubber-stamping ceremony.

Shrinking the cycle to 28 days is a masterstroke—it ensures the “community” has just enough time to blink before those persistent votes finish their centralized chores.:victory_hand:

14

Some big bakers are under Arthur’s influence, haha :sweat_smile:
they depend on TF money

15

Here’s a follow-up I want to share for context, because I think the history matters when we talk about changing governance timelines.

Since Athens, there have been at least 6 user-activated protocol overrides or emergency upgrades on Tezos mainnet:

  1. Babylon > Babylon2 (2019) — bigmap bug in Michelson — Source
  2. Edo > Edo2 (2021) — critical bug in Tickets — Source
  3. Hangzhou > Hangzhou2 (2021) — critical issue in Michelson views — Source
  4. Mumbai > Mumbai2 (2023) — liveness vulnerability that could halt block production — Source
  5. ParisB > ParisB2 (2024) — three bugs including reward computation and unstake logic — Source
  6. ParisC (2024) — critical Smart Rollups bug found after activation, broke Etherlink withdrawals — Source

Every one of these bugs was found during or shortly after the existing governance timeline. Several were caught during Cooldown or Exploration, the exact periods this proposal removes. ParisC was found days after activation and required an emergency user-activated upgrade. Nomadic Labs themselves acknowledged after ParisC that “this is not an isolated event.”

I bring this up not to assign blame. Bugs happen. Complex protocol work is hard. But the history tells us something important: the existing timeline, with all its periods, has repeatedly served as the window where critical issues surface. Shortening that window doesn’t make the code better. It makes the safety net smaller.

Under the proposed 28-day cycle with no Cooldown and no Exploration, several of these bugs would have shipped to mainnet with less community review time. The 7-day voting windows leave almost no buffer for independent testing and verification by bakers and tooling teams who don’t have access to the codebase months in advance.

We’ve also seen during recent governance cycles that the UAPO mechanism itself raises questions about equity and access for third-party proposal authors. Streamlining governance increases dependence on a single team’s ability to catch issues before submission, because the community will have less time to catch them after. The track record shows that pre-submission review alone has not been sufficient.

If we want faster governance, I think we need to invest in the infrastructure that makes faster governance safe: better pre-submission testing frameworks accessible to all proposal authors, independent audit capacity, clear UAPO policies, and tooling that helps bakers evaluate proposals quickly. Speed without that foundation just means we find bugs in production instead of in governance.

I’m supportive of improving governance. I just want to make sure we’re learning from the history we already have.

4 Likes
16

said better than I could have. This is EXACTLY how I feel. Thanks for bringing receipts @Primate411

17

To really reduce the voting process by shortening the testing period, a team of testers is needed who can be held accountable for their work; at the moment, everything is done on a voluntary basis and everyone relies on each other.

By reducing the time, it increases the likelihood that a bug won’t be discovered by chance; for many, Tezos projects aren’t their main job.

1 Like
18

I was optimistic about this change at first, but reading this critique I fully agree with @Primate411 we should not make this tradeoff.

1 Like
19

Thanks, everyone, for taking the time to provide such detailed feedback. We really appreciate it — even when the comments are critical (which can sometimes be uncomfortable for us) — because governance changes only make sense if the people who actually participate in governance feel comfortable with them.

A few quick clarifications, and also a bit of context from our side.

First, on persistent votes. They are not meant to remove the second vote or turn Promotion into a rubber stamp. Persistent votes are rewritable at any time during the voting period. The idea is simply to avoid forcing bakers to repeat the same vote multiple times if their position hasn’t changed. If a baker wants to reconsider, change their vote, or withdraw it, they can still do so exactly as today.

Second, on review time and bug discovery. Our intention with this proposal is not to reduce the time available for discussion or testing. Quite the opposite, actually. What we are trying to privilege is discussion and testing before the proposal reaches on-chain governance, rather than relying on the governance periods themselves as the main place where issues are discovered.

Over the last cycles, we have already started shifting the process in that direction.

Since the P governance cycle (actually the second O cycle), we have been publishing feature dissemination / heads-up posts on Agora more than a month before injection, precisely to invite early feedback and discussion from bakers, developers, and the broader ecosystem.

Then, starting from Q, we added a public stabilization phase of about one month, with a dedicated testnet. The goal there is to allow both the core teams and the broader community to test the proposal before it enters governance.

The idea behind the governance simplification proposal is partly based on those learnings: if discussion and testing happen earlier, the governance periods themselves can focus more on coordination and decision-making rather than discovery.

That said, reading through the comments here, one thing seems clear: those earlier discussions and testing opportunities are not visible enough today. Several of you mentioned transparency and communication gaps, and that’s important feedback for us.

As protocol engineers, we can publish feature dissemination posts early and run public stabilization testnets, but that clearly isn’t enough if the community still feels that proposals appear too late or that discussions happen out of sight.

So a genuine question back to you all: what would make those early phases more visible and useful?

Is it clearer summaries? Better notifications? A more structured place for discussion? Something else entirely?

If we want governance to move faster while remaining robust, the communication and testing pipeline around it has to work well for everyone.

We’re listening, and the goal of this post was also to check whether what we believed we had progressively put in place since the latter governance cycles (starting around the second O cycle) is actually working from the community’s perspective.

3 Likes
20

Let’s be real: your ‘early testnets’ are a mess. You’re asking the community to spend their limited free time iterating on half-baked ideas while your teams are fully funded to do the same. We can only afford to test the final product. If you actually want to ‘even the playing field,’ try this: hire five random people for two hours a day to navigate your proposal process. The catch? They aren’t allowed to use your direct internal channels. If they can’t figure out what’s going on or test the features effectively, then your ‘transparency’ is just an illusion. Stop expecting community to be your unpaid QA department.

Then there’s the ‘flexibility’—or lack thereof. You claim to want feedback, yet you refuse to adapt to community ideas citing ‘constrained resources.’ Look at Protocol Q: the majority rejected it, but instead of amending, you re-injected it three times to exhaust the opposition into submission. It wasn’t a collaboration; it was a war of attrition.

You expect the community to ‘govern’—which really just means ‘rubber-stamp’—whatever you put forward under the false promise of a publicly governed project. Don’t act surprised when people don’t spend their lives testing your drafts outside of governance. Why would we volunteer our time to ‘figure out’ a system that only listens when we say yes?"

2 Likes