Heads up: Simplifying On-Chain Governance on Tezos

[VincentPoulain]

Hi @Val,

Thanks for the candid feedback. Indeed, the underlying questions are worth addressing.

Our goal with TechRel and other teams is to make participation accessible and provide support to bakers: validator setup and maintenance, advance communication ahead of governance cycles, and animating dedicated Discord channels where they can ask questions and test features on testnets. We try to make these channels as accessible as possible, and we’re always open to improving that experience.

The fact that you’re running into friction here is very important to us. We do understand where you are coming from. Could you highlight any specific areas for improvement so that we can try to address them and improve the experience for everyone?

Our intent is to help build a process where community participation is meaningful as it helps shape the network together.

[Val]

If you want to actually “open the gates” and fix the friction, here are the specific areas that need to change:

• Public Presence of Core Devs: It was promised that core developers would talk more in public channels. So far, that hasn’t happened. We need to see them engaging with the community where the work is actually being discussed, not tucked away.

• Stop Technical Gatekeeping: Telling the community you aren’t “obligated” to help with other proposals is a defensive stance that undermines Tezos governance. You should be assisting community proposals—even the ones you disagree with—by providing a stable testing pipeline and technical guidance. Using technical difficulty as a barrier just deters builders and kills decentralization.

• Prioritize Arguments over Politics: You are supposed to be the sentinels of Tezos. Win the governance through the strength of your technical arguments, not through political maneuvering.

• Vision over Positions: The ecosystem is currently exposed to “politicians” who gift-wrap everything they say to protect their own standing. We need people who are honest and pursue the true Tezos vision, rather than those concerned with their own influence or job security.

• Radical Honesty: Stop the polished PR. The community responds to directness. If something is broken or a proposal is bad, say it plainly without the marketing spin.

These are my 2 cents. If we want participation to be “meaningful,” the environment needs to be meritocratic and transparent, not managed and curated.

[Primate411]

I will echo a lot of what @Val said and add my own thoughts…

First of all I’d like to thank @zaynah and @VincentPoulain for engaging with us and trying to figure out this wild and uncharted territory.

What would make pre-submission phases more visible and useful?

1. Public design documents before code.

The enshrined liquid staking thread running in parallel to this one is a perfect case study. The CLST implementation has been under active development in proto_alpha since at least February 6. Delegate registration, token entrypoints, FA2.1 compliance, RPCs, tests. Multiple engineers, multiple merge batches to master (March 3 and March 9). The “heads up” post went live March 6, a month after development started.

That’s not early engagement. That’s a notification after the fact. If the design had been shared as a document or RFC before the first line of code was written, bakers and ecosystem developers could have weighed in on the economic assumptions being encoded into the implementation. By the time the community sees it, the design decisions are already baked into merged code. Feedback at that point is cosmetic.

Publish the design. Get feedback. Then build. Not the other way around.

2. Structured feedback windows with deadlines and responses.

Heads-up posts are a good start, but they’re one-directional. There’s no structured mechanism for NL to acknowledge specific feedback, explain what was incorporated, and explain what wasn’t and why. A post goes up, people comment, and then the proposal appears on-chain. The community has no way to know if their feedback changed anything.

Propose something concrete: a public feedback summary published before injection that lists community concerns raised, which ones were addressed, and which ones weren’t (with reasoning). That creates accountability on both sides.

3. Economic modeling as a deliverable, not an afterthought.

Features that affect staking dynamics, baker economics, or issuance should come with published simulation data. Not “work in progress” placeholders. If the code is written, the assumptions are made. Publish those assumptions as models the community can evaluate. Right now the CLST proposal has undefined parameters for Baker Fee Maximum, Baker Allocation Maximum, Global Allocation Maximum, and the stake distribution algorithm. These aren’t implementation details. They’re the entire economic design. The community can’t evaluate what it can’t see.

4. Don’t compress governance timelines until the communication pipeline actually works.

You acknowledged in this post that “those earlier discussions and testing opportunities are not visible enough today.” That’s the answer to your own proposal. If the current pre-submission process isn’t reaching bakers effectively at 70 days, compressing to 28 days makes the problem worse, not better. Fix the communication infrastructure first. Prove it works over two or three governance cycles. Then revisit the timeline.

The stabilization testnets and heads-up posts are real improvements and I want to acknowledge that. But as the CLST thread demonstrates, the gap between “we published a heads-up post” and “the community had meaningful input on the design” is still wide. Closing that gap is the prerequisite, not the timeline compression.

On the timeline question specifically

I want to reiterate what I said earlier in this thread: this governance change should not ship in Protocol U. It deserves its own dedicated discussion cycle, ideally spanning multiple governance periods, with baker input from the start. Changing the governance mechanism through governance is one of the most consequential things this chain can do. The process for changing the process should be held to a higher standard than any individual feature proposal.

[VincentPoulain]

Thanks for your feedback, @Val and @Primate411,
I’m not in a position to respond immediately to all the points, as some require internal discussion first.
There are, however, two points on which I would already like (and am able) to react:

“Public Presence of Core Devs”:
The point is easy to understand. It is natural to want the engineers who develop the proposals to be highly present on social media, and so on. But this expectation is also somewhat utopian. Beyond the additional workload this represents - on top of designing features, writing code, managing the other responsibilities inherent to the role, and so forth - we must also accept that if some are comfortable with that, not everyone wants to expose themselves publicly on social media. One can be an excellent engineer, thoughtful and attentive, and still not feel comfortable with, or just willing to have that kind of public interaction. We should neither be surprised nor concerned that only some people choose to do it. This is one of the reasons why TechRel exists.

“Radical Honesty”:
Even though I understand the intention, I also see a degree of utopian thinking in this approach. Why? Because this disregards the need for coherence, and even for teamwork. What is “bad” for one may be “good” for another, and both may have their reasons.
Imagine a group of engineers working on the same topic, for example a protocol proposal. You can safely assume there are debates about how to implement this or that, about the pros and cons of certain features, and so on. Yet in the end, only one proposal, built collectively, is delivered. If everyone started sharing everything they think without any filter on social media, it would quickly become a completely incomprehensible mess: everything and its opposite being published simultaneously, without allowing readers to make sense of converging and diverging views - not to mention nuance.
So yes, we try to speak with one voice, if only to remain understandable. This is nothing more than the alignment necessary for a team to respond as a team to a question addressed to that team.
I can fully accept that my style may come across as “PR”. That’s fine: it is a reality. And here I am explaining, without filters, the reason why. I do, however, take as a point of improvement the need to make this clearer.

This post reflects only my own views. I wanted it to be as transparent as possible.
And regarding your other points, we will of course get back to you.

Thanks again.

[Primate411]

@VincentPoulain, I appreciate the transparency here. This is the kind of honest exchange we need more of.

But I want to push back on the “utopian” framing, because I think it mischaracterizes what’s being asked.

On public presence of core devs:

Nobody is asking engineers to become social media personalities. What we’re asking for is that design decisions are documented publicly before they become code. That’s not a social media ask. That’s a process ask. An RFC on Agora or a design doc on GitLab costs one engineer a few hours and saves the entire community weeks of reverse-engineering intent from commit messages. zaynah’s engagement in these threads proves it’s possible and valuable. We’re not asking for more of that from everyone. We’re asking for it to happen earlier in the lifecycle.

On radical honesty and speaking with one voice:

I understand the need for team coherence. That’s not the issue. The issue is that “one voice” currently means the community hears a polished summary after decisions are made. We’re not asking to see every internal debate in real time. We’re asking for the output of those debates to reach us before the code does.

Right now the sequence is: internal debate, design decisions, implementation, merge to master, heads-up post, community feedback. By the time we’re in the loop, we’re commenting on finished work. The feedback window is real, but the influence window closed weeks earlier.

Flip the sequence: internal debate, design document, community feedback, implementation. That’s not utopian. That’s how RFCs work in every mature open source project. Tezos used to do this. TZIPs exist for exactly this reason.

On developer visibility more broadly:

Tezos has remarkably few core engineers visible in public channels compared to other chains of similar scope. Ethereum, Solana, Cosmos, even smaller projects manage to have developers who engage directly with their communities. This isn’t because those engineers have more free time. It’s because those ecosystems treat community engagement as part of the job, not as an extracurricular risk.

If the environment around Tezos development is one where engineers feel that public engagement isn’t wise, that’s worth examining honestly. Not every engineer needs to be on Twitter. But if the culture actively discourages it, that’s not a personality issue, it’s an organizational signal.

On the pace question:

Tezos has shipped more protocol upgrades than any comparable chain. Over 20, zero hard forks. That’s genuinely impressive engineering. But after 8 years, the honest assessment is that the rate of shipping features has not translated into the adoption or ecosystem growth those features were meant to enable. We’ve rebuilt staking mechanics multiple times. We’ve shipped rollups, DALs, adaptive issuance, and now enshrined liquid staking. Technically brilliant work, cycle after cycle.

And almost nobody outside our community knows or cares.

At some point we have to ask whether shipping 10% slower and spending that margin on connecting with the community, involving bakers in design, and building the relationships that turn technical features into ecosystem momentum might produce better outcomes than another quarter of heads-down feature delivery.

We’ve been running this experiment for 8 years. Some parts of it are working magnificently. Some parts are clearly not. The separation between “engineers who build” and “everyone else who finds out later” is one of the parts that isn’t working. It’s not utopian to say that. It’s experience beating us in the face.

The community members doing governance work, reviewing GitLab, testing protocol changes, and writing detailed feedback in these threads are doing it on their own time, unfunded. Not because it’s in a deliverable, but because they care about the chain. Calling the ask for a published design document before code is merged “utopian” is a hard pill to swallow when the people making that ask are already doing more than what’s being requested, for free.

What we’re concretely asking for:

1. Design documents published before implementation begins
2. A public feedback summary before injection showing what community input was incorporated and what wasn’t
3. Economic modeling published alongside features that affect staking dynamics

None of these require engineers to be public figures. They require a process change, not a personality change. And they’re the prerequisites for any conversation about compressing governance timelines.

[NomadicLabs]

Hi everyone,
We have carefully reviewed the comments and concerns that were raised above, and we would like to thank all contributors for this discussion.

Based on your feedback, we have decided not to include the proposed governance change in the upcoming protocol upgrade proposal “U”. Our intention was to propose a simplification aimed at improving the UX of on-chain governance, but the inputs received show that the proposed changes do not meet this goal.

The broader points raised around design documentation, community feedback loops, and economic modeling have been noted. They will inform our ongoing reflections on governance improvements.

We remain committed to improving the governance experience for bakers and the wider ecosystem, and we want to get it right rather than get it fast. The discussion remains open and we’d love to keep hearing your thoughts. Please continue sharing.

Thanks again to everyone.

[skullzarmy]

Thanks NL. Looking forward to continuing the conversation. I feel like some great points were raised here and I am hopeful we all prioritize alignment going forward.