This proposal solves the wrong problem and pushes Tezos governance in the wrong direction. It does not advance on-chain governance where Tezos actually needs advancement. It neglects the real weaknesses that years of amendment cycles have exposed, and instead removes safeguards and compresses a process that has repeatedly helped the ecosystem detect issues, improve proposals, and build real consensus.
The proposal treats later-stage voting, testing windows, and repeated participation as unnecessary friction. In practice, those elements have played a critical role in surfacing issues, forcing reassessment, and strengthening outcomes. This approach ignores how Tezos governance has actually functioned and redirects reform away from the areas where it needs to evolve.
This proposal does not build from a serious understanding of what has actually worked well in Tezos governance, what structural supports our governance process depends on, or what additional mechanisms Tezos still needs to develop. It elevates efficiency above legitimacy, participation, and resilience, and in doing so it weakens the very system it claims to improve.
The stages the proposal treats as redundant are not redundant
The proposal argues that the current governance process includes unnecessary friction.
It states:
“Too many voting rounds: Bakers currently vote up to 3 times per governance cycle, creating voting fatigue, inconsistent participation, and a heavy communication burden.”
The proposal therefore removes Exploration and Cooldown and reduces the process to two voting rounds.
This reasoning misunderstands the function of those stages.
The testing window between votes has repeatedly surfaced issues before activation. That window exists for a reason. It gives developers, bakers, and infrastructure providers time to evaluate the code and verify that the proposal behaves as expected.
The amendment history shows that this stage has repeatedly helped the ecosystem detect problems before activation.
Removing these stages weakens that safeguard.
So-called persistent votes do not encourage active reassessment
The proposal introduces what it calls “persistent votes”:
“Votes in favour of a proposal cast in the first voting round automatically carry into the second round unless explicitly changed.”
This design reduces the need for delegates to actively revisit their decision in later stages.
Tezos governance does not operate as a one-time decision. New information emerges during testing, discussion, and integration. Delegates benefit from revisiting proposals after that information surfaces.
Later stages create a clear moment where delegates must reassess their position. That requirement keeps governance deliberate and responsive.
So-called persistent votes move in the opposite direction. They allow early decisions to carry forward by default and reduce the incentive to re-engage with the proposal.
Governance should reinforce active participation at each stage. It should not rely on inertia.
Quorum opt-out diminishes governance instead of strengthening it
The proposal also introduces a quorum opt-out mechanism:
“This change allows bakers to explicitly opt out of quorum to reduce operational overhead.”
“Quorum limited to active participants… keeping quorum a meaningful signal of genuine mandate.”
This change does not strengthen governance. It shrinks it. It loses sight of why bakers must actively participate in governance at each stage, even when (especially when) that participation takes the form of a Pass vote. That requirement is not overhead. It is part of what keeps governance active, visible, and legitimate.
Today, bakers who choose not to actively support or oppose a proposal still remain part of the governance process through repeated Pass votes. That requirement has value. It keeps bakers constitutionally present, maintains regular engagement, and preserves quorum as a signal that the broader validating set remains attentive to protocol changes.
The opt-out mechanism removes that requirement. It allows bakers to disengage from governance entirely while still participating in block production.
This does not make quorum more meaningful. It changes what quorum measures.
Instead of reflecting whether the full validating set remains engaged, quorum becomes a measure of a smaller, self-selected subset of participants. That reduces the base of legitimacy.
Governance should encourage participation and re-engagement across the full baker set. It should not create cleaner paths for disengagement.
Governance is more than a technical pipeline
The proposal frames governance primarily as a process that introduces delay:
“Slow iteration: The current 70-day governance cycle introduces significant latency from upgrade development to activation.”
This framing treats governance as a pipeline to optimize.
Tezos governance does not function that way.
Between voting stages:
- developers explain the proposal
- bakers evaluate the change
- infrastructure providers test compatibility
- the community debates the upgrade
These interactions form the core of governance. They create understanding, consensus, and legitimacy.
Friction in this process serves a purpose. It forces proposals to withstand scrutiny before activation.
What the historical record actually shows
The amendment history from Athens through Tallinn shows a clear pattern.
Protocol upgrades often evolve during the governance cycle, either because the ecosystem has not yet reached sufficient understanding and alignment, or because testing surfaces issues.
Upgrade cycles in which the first version did not achieve sufficient understanding or alignment
- Ithaca → Ithaca 2
- Oxford → Oxford 2
In these cases, the issue was not a late-stage technical defect. The ecosystem had not reached sufficient clarity or alignment around the proposal. That lack of understanding surfaced through the governance process and led to rejection or revision.
That outcome strengthened the proposals. It forced clearer communication, better justification, and more complete alignment before adoption.
It also had another effect. By forcing a restart of the governance cycle, these cases allowed corrected versions to be resubmitted through the normal process. Without that reset, those same issues could have surfaced later in the cycle and required a patched activation through a UAPO.
The governance process did not slow progress in these cases. It prevented the need for a less formal corrective path.
Upgrade cycles in which the first version was revised within governance
In this case, developers identified an issue during the Proposal Period and released a corrected version, Jakarta 2. Bakers were explicitly told not to support the original proposal and to upvote Jakarta 2 instead. The corrected version then went through governance and activated.
Upgrade cycles in which a patched version replaced the initially advancing version (UAPO)
- Babylon
- Edo
- Hangzhou
- Mumbai
- ParisB
In these cases, developers discovered issues late and used User-Activated Protocol Overrides (UAPO) to deploy patched versions at activation.
Upgrade cycles in which a problem appeared after activation
- ParisB2 (which itself was a UAPO of Paris B) → ParisC (post-activation upgrade)
This case required an emergency corrective path after activation.
What the real problems are, and what we should be addressing
Formal patch ratification when issues appear late
The real governance gap appears when issues surface late in the cycle.
Today, the ecosystem relies on UAPOs or emergency upgrade paths to handle those situations. These mechanisms work operationally, but they sit outside the formal governance process.
Tezos governance needs a canonical way to ratify patched protocol versions when late-stage fixes become necessary.
That would preserve the core principle of on-chain governance: the protocol that runs on-chain should match the protocol that delegates approve.
More expressive governance at the component level
Another limitation lies in how governance handles disagreement.
If delegates disagree with a single parameter or module, they must submit a fully competing proposal. That structure creates fragmentation and turns narrow disagreements into broader conflicts.
Tezos governance should evolve toward more granular decision-making. It should allow the ecosystem to resolve specific disagreements without forcing entirely separate amendment paths.
Strengthening governance rather than compressing it
Tezos governance should evolve in response to what its amendment history reveals.
That history shows:
- proposals change during the cycle
- testing surfaces real issues
- later reassessment improves outcomes
The system needs mechanisms that support those realities.
Removing stages does the opposite.
The direction of reform matters
Tezos governance is one of the protocol’s defining innovations. In my view, it is the most important one, because it is the innovation that governs all the others. It is what makes Tezos adaptable. It is what makes Tezos future-proof. It is what separates Tezos from other blockchains. Another chain may lead in one area at one moment and Tezos may lead in another at a different moment, but that is not the decisive point. On-chain governance is what ensures that Tezos can continually absorb, refine, and adopt what is best over time. That is why it matters more than any single technical advantage.
This proposal compresses governance, removes safeguards, and weakens participation at later stages. It does not address the real challenges that the amendment history has revealed.
Tezos should strengthen governance, not compress it.
The next step is not fewer stages, persistent votes, or quorum opt-outs. The next step is a stronger governance system: one that preserves legitimacy, requires active participation, formalizes patch ratification, and develops more expressive ways to resolve disagreement. Tezos does not need less governance. Tezos needs better governance.
