When We Disagree: Making Rough Consensus Work

Governance
1

A Zcash governance trilogy, part 2 of 3.

Rough Consensus Proposal vs Objections boxing gloves
Rough Consensus Proposal vs Objections boxing gloves1670×942 396 KB

TL;DR: Polls measure preferences. Running code measures operational acceptance. Neither gives anyone the final say, and no constituency has an automatic veto. Building rough consensus means answering substantive objections, not asking every group for permission. NU7 showed how difficult that can be. The Development Fund dispute will test whether we can apply the same principles when money is at stake.

Rough consensus is easy when everybody agrees.

The interesting situation is what happens when they don’t.

In Part 1, An Ode to Rough Consensus, I promised to examine two distinctions in this follow-up. The first:

Polling measures expressed preference. Running code measures operational acceptance. Neither, on its own, gives anybody the final say.

The second is the difference between keeping Zcash Community Grants (ZCG) alive and keeping its funding alive.

NU7 supplies our first case study. The argument over the Development Fund is another. They are really about the same question: what do we do when the signals conflict, the objections are real, and nobody has the authority to compel everybody else?

The ballot result is not the argument

In February 2026, 70.4% of participating ZCAP members supported Zcash Shielded Assets (ZSAs). In the parallel coinholder sentiment poll, 98.6% of participating coin-weighted ZEC opposed them. The Zcash Foundation published the disagreement rather than pretending the constituencies agreed. It described the divergence not as a failure of the process but as the process doing its job, by surfacing real disagreement. It also acknowledged that this raised a legitimate question: how should different constituencies be weighed when they conflict significantly?

The headline percentages look decisive. Their meaning is far less straightforward.

Seventy per cent was not seventy per cent of Zcash users. Ninety-eight per cent was not ninety-eight per cent of people holding ZEC. There were 203 ballots on the ZSA coinholder question, and nobody can say how many independent human voters they represent. What the coinholder percentage measures is the weight of the participating ZEC.

One critic dismissed the 69 ZCAP members who supported ZSAs: “Weddings under 100 people are considered small.”

Fair enough. The February ZCAP poll had 99 participants: on ZSAs, 69 for, 29 against and one abstention. That is a small electorate, and its representativeness deserves scrutiny.

But the comparison mixes people and coins. A coinholder ballot is not an independently verified headcount, and the weighted result cannot establish broader human participation.

You cannot attack ZCAP for having too few people and then defend coinholder voting by counting coins as though they were people.

A small electorate is a legitimate concern. An electorate whose human size we cannot determine raises a different concern. Neither disappears because we prefer the result.

And the ballot did not tell us why the coinholder weight voted no. The Foundation said as much at the time: before any decision, it needed to understand why coinholders opposed ZSAs so strongly.

Was the ZSA design too complex? Not ready for NU7? A distraction from more urgent engineering? Or did voters oppose shielded assets as a feature in principle for their own reasons?

Those are different objections. Some might be answered by better engineering or a different timetable. Others might reflect a durable disagreement about what Zcash should become.

It matters, too, that the February question asked about sentiment toward ZSAs as a protocol feature, not simply whether a particular implementation should ship on a particular date. So the result cannot be shrunk into a verdict on timing alone, however convenient that would be for ZSA supporters. Nor can it be enlarged into an instruction to stop all ZSA research or funding, however convenient that would be for ZSA opponents.

The coinholder opposition was treated as an important signal, as it should have been.

But an influential no is not automatically a constitutional veto.

Nor was it the only signal: ZCAP and coinholders were not the only groups polled. The Engineering Caucus, ZecHub, Zcash Brasil, Zcash Español and Zcash Türkiye ran the same questions through their own panels, and the organisers described their results on ZSAs as “more mixed signals”. Some of those panels were small: Zcash Türkiye had seven participants and Zcash Español thirteen. Even so, the overall picture was not one constituency blocking another. It was one group clearly in favour, one overwhelmingly against and the rest divided.

The poll organisers concluded that ZSAs had not reached clear community support for NU7. Under rough consensus, a change without broad support does not proceed and the status quo is kept. In this case, that meant ZSAs were not included in NU7.

When does an objection block consensus?

ZIP 0 makes ZIP owners responsible for building consensus and documenting dissent. It does not allocate a fixed percentage to each electorate or give ZCAP, coinholders, developers, miners or foundations a separate veto over every protocol proposal.

The IETF’s explanation of rough consensus, RFC 7282, is useful here. An objection must be considered on its merits. Its substance must be answered. But the person raising it does not have to agree with the answer for the group to proceed.

ZIP 0 even uses the phrase unaddressed substantiated objection in its rules for Process and Informational ZIPs. That is not a mechanical voting threshold for every network upgrade. It does capture the relevant discipline: establish what is being objected to, and explain what has been done about it.

Consider three possible replies to a proposed upgrade.

One: This change lets an attacker create money. If true, that is a devastating technical objection, even if the person raising it owns no ZEC and has never voted in ZCAP.

Two: I think this feature should wait until the wallet migration is complete. That is a concrete objection about sequence, risk and cost. It can be investigated, and perhaps answered with a revised schedule.

Three: No. Coinholders voted against it. That tells us something important about support. It does not tell us what needs fixing.

“No” is a position, not an argument. The argument comes when somebody explains why.

The same critic went further: “The vote is done. Nobody needs to convince anyone of anything. That’s how it works.” That may describe the verdict of a binding vote within its assigned remit. It does not describe an advisory poll being used as evidence of rough consensus.

This cuts both ways. Developers cannot brush off an overwhelming coinholder signal as irrelevant simply because the poll is advisory. Coinholders cannot claim the right to prohibit a change without making the case against it. ZCAP cannot demand its own assent as a condition of progress. Neither can miners.

Building rough consensus means answering objections, not asking every constituency for permission.

Here is what that work looks like, using ZSAs:

  1. Record the position. Participating coin-weighted ZEC opposed them overwhelmingly, while most participating ZCAP members supported them.
  2. Find the reasons. Ask what people objected to, rather than inferring motives from a tally.
  3. Test the substance. Which objections could better engineering, a narrower scope or a later date answer, and which could not?
  4. Publish the assessment. Say which objections were met, which remain and how the other signals were weighed.
  5. Respect the result. If broad support has not emerged, the change waits.

That is not a veto for whoever objected loudest. It is what happens when the case for change has not yet been made.

That does not mean every proposal must eventually go through. There may be serious objections that remain unanswered, technical risks nobody can responsibly accept, or simply too little broad support. In that case, rough consensus has not emerged. The change does not proceed.

The year also gave us a case where the technical facts were not a matter of taste. A critical soundness flaw in Orchard was discovered on 29th May. An emergency soft fork followed on 2nd June, NU6.2 restored Orchard with a corrected circuit on 3rd June, and on 28th July the Ironwood upgrade (NU6.3) sealed the old pool behind a turnstile. This was not an occasion for each constituency to vote on whether the mathematics was inconvenient. The engineers had to demonstrate a remedy, operators had to deploy it, and users needed a trustworthy chain. When the integrity of the money supply is at stake, an emergency fix may have to ship before anyone could even write a sentiment poll.

The danger is that temporary concentration becomes habitual. The emergency passes. Then back to plurality.

Nor should we be naive about de facto vetoes. If everyone starts treating a negative poll from each constituency as an obligatory stop sign, we will have created a set of vetoes without ever writing them into a ZIP. Renaming those vetoes “rough consensus” would not make them any less real. A constituency can hold enormous practical blocking power without holding a formal veto, and calling a poll “advisory” does not by itself prove the difference.

The distinction is whether the objection has to be addressed, or the objector has to be satisfied. One is a process of reasoned disagreement. The other is a permission system.

An unresolved objection may be enough to prevent rough consensus, and in the moment that can look exactly like a veto. But it does not give its author a standing right to block every future version of the proposal.

The judgement concerns the particular change, the evidence and the objections still outstanding. Nor is an addressed objection necessarily a weak one. Decision-makers must explain why the evidence supports proceeding despite it, or why it remains serious enough to prevent consensus.

Put simply, there are two tests.

First: is there a substantiated objection that has not been answered? A serious objection may be decisive when four conditions hold:

  1. It is substantiated. It comes with evidence or a concrete line of reasoning, not just “no”.
  2. It is about this change, or the process being used to decide it, not about the proposer or an earlier version of the proposal.
  3. It is material. If true, it would mean real harm: to security or soundness, to the money supply, to privacy, to users’ funds, or to commitments people relied on.
  4. It has not been answered. Nobody has fixed the problem, and nobody has shown convincingly why proceeding is acceptable anyway.

If all four hold, a single objection can be decisive, whether or not its author holds coins or a vote. Not because its author has a veto, but because the evidence shows that proceeding would be unacceptable. That is the “attacker can create money” case above.

RFC 7282 makes the same point: what matters is whether an objection has been addressed, not how many people raised it.

Second: is support broad enough to proceed? Preferences without reasons (“No. Coinholders voted against it.”) do not block on their own. They count as evidence about how broad support is. A narrow no in one group should not stop a change by itself, unless somebody can name a reason that passes the first test. Overwhelming opposition from a major constituency is powerful evidence that support is not broad. It does not settle the question mechanically: somebody still has to weigh the reasons and the other evidence, and explain the judgement. For ZSAs in NU7, that judgement was that the change should wait.

Neither test gives any group a standing veto. The next version of a proposal, or a later poll, is judged afresh.

Sometimes the question is the problem

NU7 gave us another lesson in September.

During the consultation on the Network Sustainability Mechanism (NSM), people objected to poll questions whose meaning depended on how an earlier question was answered. The questions were revised. That was not obstruction. It was an objection being addressed.

Then the revised polls produced a genuine disagreement over when ZEC removed from circulation by the NSM should begin returning to block rewards.

The September coinholder poll attracted roughly 2.4 million ZEC, from about 3.6 million eligible ZEC at the snapshot. Participating coin-weighted ZEC strongly preferred February 2031. Community panels were more favourable to starting sooner. The results and the divergence are public.

On 15th September, the five coordinating organisations said they were aligned on February 2031 because they regarded it as the most conservative interpretation. They also left open the possibility of reconsidering the date if circumstances changed.

One can disagree with that judgement. But it was an articulated judgement, not a calculation that said coinholder votes must always win. The choice aligned with coinholder sentiment.

In both prominent disagreements, the eventual outcome aligned with the coinholder signal. That is not evidence that coinholders were ignored. It is evidence that their preferences mattered. It is not evidence that they acquired sovereignty.

The same problem is live in the November consultation. I have asked for a positive no-change option, distinct from abstaining. That is an objection to the question, not to any proposal.

Sometimes building consensus means asking a better question. Sometimes the better question reveals that the disagreement is real.

What running code actually proves

At 02:34 UTC on 6th November 2026, NU7 activated on mainnet at block 3,543,405, the height specified by ZIP 259. Blocks began targeting 25 seconds rather than 75. The NSM was activated, and version 4 transactions became invalid.

That was a remarkable engineering achievement. It also tells us something important about governance.

Developers wrote and reviewed implementations. The people operating full nodes chose compatible consensus software. Mining pools produced blocks the updated network accepted. Exchanges, custodians, wallets and users continued dealing with the resulting chain.

That is operational acceptance. It is not a second opinion poll.

A mining pool generally chooses the block template and validating software used by its operation. The individual miner supplying hashpower can often choose a pool, but does not thereby cast a separate ballot on each consensus rule. A full node checks validity under the rules it runs. Enough hashpower cannot turn a block that violates those rules into a valid one.

Nakamoto consensus helps nodes agree on which valid history to follow. It does not tell us which validity rules ought to exist.

That is why “the miners approved NU7” is a misleading description. NU7 activated at a specified block height. Pools and nodes adopted compatible rules and the chain continued. There was no activation threshold requiring 80% or 95% of miners to signal yes.

This matters without making developers kings. A working implementation demonstrates feasibility, not legitimacy by itself. An elegant ZIP is not enough if nobody will implement it. A poll majority is not enough if independent participants refuse to operate the rules it recommends.

Equally, a developer may build and run an experimental network without first collecting the blessings of ZCAP, wealthy coinholders or any other group. Permissionless innovation should not end at the edge of governance.

A poll is evidence. Running code is evidence. Neither is a crown.

Who gets to say consensus has emerged?

This is the awkward part. Rough consensus has no magic scoring formula.

Somebody must assess the evidence, identify which objections are substantive, explain how they were answered, distinguish technical feasibility from political support, and decide whether there is broad enough agreement to move forward.

Under ZIP 0, ZIP owners and ZIP Editors have defined roles in that process. The people building and operating the upgrade then exercise their own independent judgement.

Those people have influence. They are accountable for how they use it. And if they judge wrongly, the remedies are ones Zcash already has: anyone can challenge their published reasoning, advance a competing proposal or implementation, or decline to run the software. No group decides alone, including the people doing the judging.

If they merely count endorsements from influential backers, they have not done their job. If they pretend an objection vanished because its author lacks coins, they have not done their job. If they call every dissenting constituency an absolute veto, they have not done their job either.

The process is not perfect. A small group can acquire too much influence over what counts as “rough”. That risk is an argument for public reasons, competing centres of power and credible opposition, not for replacing judgement with whichever voting weight is largest.

And now we must apply the same standard to money.

Keeping ZCG is not the same as funding ZCG

The current Development Fund rules are set by ZIP 1016. Eight per cent of the block subsidy supports Zcash Community Grants; twelve per cent goes to the Coinholder-Controlled Fund. The two streams have different decision mechanisms and both are scheduled to end at the third halving, expected in November 2028.

This is a deliberate division of power. Coinholders have binding authority over their assigned grants fund. ZCG can fund future work through an identifiable committee, subject to scrutiny, elections and the grant rules. Neither electorate controls the other stream.

Several proposals now seek to change that arrangement before 2028. The Future Dev and Legal Defense Fund proposal, authored by Sean Bowe, Zooko Wilcox and Jason McGee, would redirect ZCG’s incoming 8% into a new lockbox and leave the 12% coinholder stream untouched. It would also require 50,000 ZEC from ZCG’s existing treasury to be transferred to the NSM, and leave the lockbox’s spending rules to a later ZIP. That is not just a change to the flow of funds. It moves resources before settling who will be accountable for using them.

A lockbox is not a grants programme. Not deciding yet is sometimes a decision.

Daira-Emma Hopwood’s Zcash Adoption Pool ZIP takes almost the opposite approach, keeping the 8% under a renamed committee.

Whatever one thinks of each, some principles apply to all of them.

Preserving a committee while ending its incoming funding is not preserving the funding arrangement. It changes the balance between independent prospective grants and the coinholder-directed stream. My own ZecHub Communities proposal illustrates the purpose of prospective grants: small, staged commitments to emerging communities that have not yet had the opportunity to demonstrate success.

Moving one stream while leaving the other intact is not neutral. If the reason is a higher ZEC price, it applies to both streams. If accumulation is the danger, scrutinise both streams. If particular grants have been poor, name them and examine the record. If a committee has conflicts, reform the committee.

Prominent endorsements are evidence of support. They are not a replacement for the work of rough consensus.

My own view of the current proposals is in a separate post: The ZCG Lockbox: one tap off, the bigger one left running.

Accountability cuts both ways

Maxime Desalle has raised an objection to ZCG elections that deserves an answer. His published analysis identifies 72 members of a 201-person ZCAP dataset associated with ZCG-funded projects. One committee member was elected with 58 votes.

That establishes meaningful overlap between the electorate and the people whose work the committee may fund. It does not establish that 72 people voted together, controlled an election or acted improperly. Grant recipients are also often the people doing the work Zcash needs. But conflicts of interest and a narrow electorate cannot be waved away.

Nor can the question be evaded by replacing named voters with anonymous ones: a shielded ballot proves control of voting weight, not the absence of conflicts.

The distinction is practical. When a grant linked to Paul Brigner’s organisation was considered in August, the ZCG meeting minutes recorded his recusal. We can scrutinise that decision and ask whether the remaining review was adequate. We cannot ask the same questions of unnamed coinholder voters without additional safeguards.

In November 2025, Naval challenged opponents of token-holder voting to say who should be in charge, who appoints them and why they should be trusted. I answered in December with a modest proposal: three ZCG seats elected by ZCAP and two by coinholders. It has since become a draft hybrid-election ZIP, alongside proposed organisational-independence and conflict rules; neither has been reviewed publicly yet.

It is a specific answer, not a defence of the status quo. Coinholders would elect committee members directly, but no single electorate would be the whole of ZCG, and those members would remain identifiable and accountable for grant decisions.

As I have disclosed, I am a ZCAP member and intend to stand for a ZCG seat in December, so these questions apply to me personally, and are not theoretical. The hybrid elections would not take effect in time for that election.

The Hand of God is a worse form of accountability than the Ten Legs of the ZCG committee. At least we know whose legs those are.

In The Hand of God I noted that the Q3 round approved only two of fourteen applications below USD 25,000. That proves nothing about anyone’s motives, but it shows why a binding ballot is no substitute for explaining decisions, protecting small projects and checking conflicts.

Better governance is possible without pretending that the only choices are rule by five committee members or rule by whoever controls the most ZEC.

What if nobody wins?

The November Development Fund consultation is explicitly advisory. The deadline for proposals is 11:59pm UTC on 8th November. The proposed poll questions are published on 9th November for discussion until 15th November, and polls for coinholders and community panels run from 16th to 30th November.

The organisers will then assess whether there is rough consensus to move forward with a proposal; if it emerges, the engineering teams and miners will work together on an NU7.1 upgrade.

The organisers will have to explain how they weigh conflicting signals, which substantive objections have been answered, and why sufficient agreement has or has not emerged. A published tally is only the beginning of that explanation. Will they publish that reasoning, particularly if the polls disagree?

That if matters.

As I said above, I have asked for no change to be an explicit polling option, distinct from abstain or none of the above. A person ought to be able to express a preference for keeping the existing rules without being forced to pick a competing change.

But the status quo does not need to win a new election to survive.

If no proposed change achieves rough consensus, ZIP 1016 continues. ZCG keeps receiving its 8%; the Coinholder-Controlled Fund keeps receiving its 12%; both incoming streams end at the scheduled third halving in 2028. Existing treasuries may continue to be spent under their applicable rules after new issuance ends. Keeping the existing rules is not a victory for ZCG. It is simply what happens when no proposed change achieves rough consensus.

And the expiry cuts the other way. Extending those streams beyond 2028 would require fresh rough consensus too.

Before 2028, changing the funding requires rough consensus. After 2028, continuing the issuance requires rough consensus.

That is not a special exemption for ZCG. It is the same rule we applied when ZSAs did not enter NU7. A proposed change without sufficiently broad agreement does not become the new rule simply because a consultation was held.

Suppose the November polls split the way the ZSA polls did, but in reverse: coinholders strongly in favour of changing the Development Fund, ZCAP and the other panels strongly against. The two tests still apply.

If a material objection remains unanswered and proceeding would be irresponsible, the change waits. If the evidence shows that sufficiently broad support is lacking, the change waits.

Anyone who treated overwhelming coinholder opposition as evidence that broad support was missing must take overwhelming opposition from community panels equally seriously.

Neither result creates an automatic veto. The reasoning has to be consistent whichever side is in the minority, even when the conclusions differ.

And if a team released node software with the change anyway, the change would only take effect if miners, node operators, exchanges and wallets chose to run that software. If enough of them refused, it would fail, or split the chain.

Rough consensus is not a machine for producing a winner. Sometimes the legitimate result is no change.

Do the work

This is where the principle becomes uncomfortable.

A large coinholder vote can be hard to disregard. So can the endorsement of respected engineers. So can a public objection from people whose livelihoods depend on a funding stream. All deserve examination. None deserves unthinking obedience.

Polls tell us something. Running code tells us something else. Neither makes a constituency sovereign. A loud no is not a reasoned objection; an important supporter is not a substitute for answering one.

Building rough consensus means answering objections, not asking every group for permission.

ZSAs did not enter NU7 because sufficiently broad agreement for that change had not emerged. The existing rules stayed in place. The Development Fund dispute now asks whether we can apply the same standard to proposals backed by some of the most influential people in Zcash.

The test is not whether our preferred side wins.

Rough consensus is easy to praise when the result suits us. Its real test comes when it doesn’t.

There is one difficulty this article has only touched. Shielded voting can establish control of voting weight without revealing who controls it. That privacy is essential, but it complicates the scrutiny of conflicts, coercion and concentrated power.

So, next: Part 3, Governance in a Shielded World.

Sources
1 Like
The ZCG Lockbox: One Tap Off, the Bigger One Left Running
An Ode to Rough Consensus
The ZCG Lockbox: One Tap Off, the Bigger One Left Running
2

(post deleted by author)