Note: These are my personal reflections and do not necessarily represent any shared views of any other individuals within Shielded Labs, nor Shielded Labs as a whole.
The Zcash community just wrapped up sentiment polling across seven constituencies on a set of proposed protocol features. The coinholder vote has understandably received the most attention, in no small part due to its sharp divergence of opinion from other groups.
No single constituency is meant to have a formal veto. Each constituency provides sentiment input that feeds into rough consensus. In practice, Zcash governance can feel like a plutocracy, a technocracy, and a do-ocracy stacked on top of each other in a trenchcoat.
In this post, I want to focus on a poll that received less attention, but is unusually informative for a recurring debate in our ecosystem: objections framed around “trade-offs,” “attack surface,” and “maintenance burden.” To resolve these debates, look no further than the people who live with the code: the Zcash Engineering Caucus.
What is the Zcash Engineering Caucus?
The Engineering Caucus aims to represent the Zcash core engineers: people across the Zcash ecosystem who spend their time specifying, debating, building, testing, reviewing, auditing, modeling, verifying, and deploying the Zcash protocol, its implementations, and other mission-critical infrastructure.
These are the people best positioned to tell the difference between:
- Trade-offs that are explicit, modeled, and testable
vs trade-offs that are asserted but not tied to specific failure modes - Maintenance burden that is bounded by clear interfaces + deprecation paths
vs unbounded “forever support” across clients and tooling - Attack surface defined as threat-model-first invariants, assumptions, and audits
vs “attack surface” as a rhetorical veto without specifics
Finally, and perhaps most importantly: the engineers are not homogeneous in their opinions. The results show it both in their verdicts, as well as in the percentages themselves.
The Engineering Caucus ≠Feature Maximalism
If your prior is “engineers will always vote yes on more protocol features,” the Engineering Caucus results are a helpful corrective.
Two examples are worth highlighting:
- Reducing complexity / attack surface got strong support.
The engineers voted 31 support / 4 oppose / 3 abstain on disallowing v4 transactions (disabling Sprout spending), explicitly framed as reducing protocol complexity and attack surface. - One proposal was net-opposed by engineers
On adding protocol support for STARK proof verification via Transparent Zcash Extensions (TZEs), the engineering vote was 14 support / 19 oppose / 5 abstain. This is a clear signal of skepticism rather than blanket optimism.
That combination (yes to deprecation/simplification, no to certain expansions) is exactly what understanding the trade-offs looks like in practice.
On “Complexity”
Zcash is already quite complex, but that complexity is hard earned.
Teams can (and should) research, experiment, and prototype freely. But the road to mainnet typically begins with a ZIP: a formal technical proposal that gets scrutinized, revised, and argued over in public. Those documents then get distilled into a protocol specification that spans hundreds of pages.
That throttling is intentional. Mainnet should change infrequently, and the bar should be high.
Considerations for Discourse
If someone’s central claim is: “We shouldn’t add protocol features because complexity and attack surface will get us killed," then the most relevant constituency to consult is the one that routinely does threat modeling, code review, and security reasoning on protocol changes.
Here’s the type of technical discourse that I’d love to see more of:
- If there is an attack surface, what is the threat model?
- What are the security invariants the proposal must maintain?
- What are the new trust assumptions, if any?
- What does the review plan look like (ZIP review, spec review, implementation review, test vectors, audits)?
- What is the rollback/deprecation story if we later decide we were wrong?
On our end, I’d love to see engineers make their reasoning legible in public: explicit premises, explicit threat models, and clear support/oppose reasoning, with room for concurrences and dissents. We’re already really, really good in that regard, but now is the time to fill in gaps, widen the audience, and encourage new participants to follow best practices with regards to “working in public.”
Also, if you want to pressure-test proposals live, Zcash Engineering Office Hours are a great venue to ask detailed questions about trade-offs and security assumptions.
Finally, the perennial reminder: Zcash is open source, and built in public. Anyone can read the ZIPs, review code, contribute test cases, or help sharpen threat models. This produces what we’re all after in the end: concrete, reviewable engineering work.