The numbers are slightly different because I’m working off the zcashd release dates for each network upgrade, which represent the time when the upgrade work was finished in the node software. (Even if it hadn’t activated yet.)
But I take your point that about the shorter upgrade intervals, and using the “Zcash age”.
@daira @str4d @teor thanks so much for your feedback 
!!!
Amongst making the other adjustments I’ve done my best to clarify this by being more concrete about when the Zenate should trigger community polling for the Network Upgrades, Major ZIP changes, and Advisory Polling.
ZIP: TBD
Title: Establishing a Zenate for Community-Driven Governance and Managing ZCAP
Owners: TBD
Original-Authors: Matthew Green (@GGuy)
Credits: Josh Swihart (@JoshS)
Status: Draft
Category: Process
Created: 2023-09-12
License: MIT
Terms capitalized such as “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document are to be understood as described in RFC 2119. [#RFC2119]_
The term “network upgrade” in this document refers to the explanation in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License Agreement ([#trademark]_ or successor agreement).
“Zenate” denotes the elected governing body by the Zcash community through the ZCAP process proposed in this ZIP.
“ZCAP” is the Zcash Community Advisory Panel, as outlined at [#zf-community]_.
This ZIP proposes the creation of the Zenate, a crucial body aimed at amplifying the voice and influence of the Zcash community. The Zenate’s central objective is to redefine and democratize the mechanisms of community consensus. To realize this, it will commence its role by assuming stewardship of ZCAP, enhancing its voting procedures to ensure broader transparency and a true representation of community sentiment. In addition to governance, the Zenate is poised to cultivate collaboration among development fund recipients through regular meetings, facilitating a transparent flow of information and shared innovations. By consistently engaging with the community through structured polling, the Zenate aims to shape a future for Zcash that resonates with its users’ aspirations, thereby serving as a dynamic bridge between community desires and the ongoing evolution of Zcash.
The inception of the Zenate marks a profound shift, empowering the Zcash community with amplified authority over the direction of their blockchain. At its core, the Zenate aims to recalibrate and democratize the way community consensus is gauged. This mission commences with the Zenate assuming control of ZCAP and refining its voting processes, ensuring transparency, inclusiveness, and a genuine reflection of the community’s voice.
Beyond its governance role, the Zenate seeks to promote collaboration, particularly among recipients of the development fund. Through orchestrating monthly meetings, it seeks to streamline communication, encourage shared innovations, and expedite common goals. These interactions not only enhance collective output but also keep the community informed about ongoing progress, milestones achieved, and challenges encountered.
Moreover, the Zenate will continually tap into the community’s sentiments, leveraging regular polling to ensure the Zcash journey is genuinely community-driven. This ongoing dialogue, facilitated by the Zenate, aims to crystallize a collective vision for Zcash’s future - one sculpted by the very users it serves. Through these initiatives, the Zenate positions itself as a vital conduit between the community’s aspirations and the blockchain’s evolution, striving to manifest a future that aligns with the shared dreams and ideals of the Zcash community.
A Zenate SHOULD consist of 5-7 active members, chosen via the ZCAP process. Members are expected to commit approximately one day weekly to Zenate tasks. Membership tenure is annual with opportunities for reelection.
To avoid conflicts of interest, members of the Bootstrap board, ZF board members with decision-making authority under the Zcash trademark agreement, and ZIP editors cannot be Zenate members. Their dual role could create a conflict of interest where they may have undue influence on both the proposal and the decision-making processes. Ensuring they are not part of the Zenate helps in maintaining the integrity of the voting process, ensuring that the Zenate remains free from undue influence, and upholding a fair representation of the community.
Zenate members SHALL receive compensation consistent with the allotted 35 hours per month, at a rate of $100US per hour. Changes to this compensation MUST be proposed via a ZIP amendment.
The Zenate makes decisions by majority vote. In cases of tied votes, a community-wide ZCAP poll determines the outcome. The Zenate MUST duly consider concerns brought forward by any body.
Zenate members have an essential responsibility to represent the interests of the Zcash community without any bias. Given their influential position, it is imperative that their decisions are free from personal or financial influences that might compromise the integrity of their roles.
Declaration Requirement:
Annual Review:
Abstaining from Decisions:
Public Access:
Review by Fellow Zenate Members:
Upon its formation, the Zenate will take over ZCAP management. The Zcash Foundation will oversee the first Zenate election through ZCAP. Subsequent elections and ZCAP management falls under the Zenate’s jurisdiction.
ZCAP MUST be used for polling to clearly determine community consensus on specific ZIP state transitions. The polling process for these transitions is as follows:
Reserved to Draft:
Draft to Proposed:
Draft or Proposed to Withdrawn:
Draft/Proposed to Rejected:
Rejected to Draft:
Proposed to Active (For Process/Informational ZIPs):
Proposed to Implemented (For Consensus/Standards ZIPs):
Implemented to Final:
Any Status to Obsolete:
In all ZCAP polls, if no clear majority is achieved, the ZIP remains in its existing state. Detailed procedures for ZIP polling will be delineated by the Zenate, ensuring all operations align with the spirit and intent of ZCAP.
ZCAP polling MAY be invoked for decisions related to the Zcash trademark agreement and its role in Network Upgrades when ZIP consensus alone isn’t sufficient to establish community consensus. Specifically, the Zcash community may wish to use ZCAP polling to ensure that the upgraded chain can bear the Zcash trademark, maintaining the network’s continuity and the trust associated with the name.
The polling process for such decisions SHOULD be as follows:
Trademark Agreement Decisions (When Required):
Network Upgrade Decisions (When Required):
Detailed mechanisms for both trademark agreement and network upgrade decision polling, when necessary, will be provided by the Zenate.
The Zenate can use ZCAP for more than just ZIP state transitions and trademark decisions; it can also gather advice and feedback on critical Zcash-related matters. Such matters may encompass but are not limited to:
Proposed Changes to the Development Fund:
Assessment of Zenate Performance:
Soliciting Suggestions:
Prioritization of Initiatives:
The process for advisory polling is as follows:
It’s vital to note that the Zenate remains the advisory body and, while these polls provide critical insights, the final decisions rest with the Zenate after duly considering all aspects, including the ZCAP’s advice.
ZIP Editors have the capability to refine active ZIPs to align better with the original intent of the ZIP. This capability does not extend to significant modifications that alter the core purpose or philosophy of the ZIP. Changes of this nature need to be supported by a community-wide consensus through a ZCAP poll.
However, minor adjustments such as updating incorrect links, fixing typographical errors or language, or adding additional information that does not change the ZIP’s original objective can be approved by ZIP Editors without resorting to a ZCAP poll.
Major changes that fundamentally alter the ZIP’s objective or strategy, or propose new features or definitions not included in the original ZIP, need to be proposed as a new ZIP or an amendment. Such amendments require approval via a ZCAP poll. These measures ensure a balance between the ZIP’s constant improvement and its adherence to the original intention.
Transitioning an active ZIP to the superseded status when a replacement ZIP becomes active can be done by ZIP Editors without a ZCAP Poll.
This clear delineation between minor modifications and significant changes ensures that pivotal decisions around the Zcash protocol are always based on broad community consensus through ZCAP polls. This mechanism gives ZIP Editors the ability to adapt to improvements while preserving the integrity of the ZIP’s original intent.
The Zenate aims for a diverse ZCAP, including developers, leaders, ecosystem partners, and users. Efforts to include both English and non-English participants are encouraged. The Zenate SHALL actively strive to achieve the diverse ZCAP representation.
The Zenate serves as an advisory body to the Zcash community, supporting the community through education, hosting AMAs, and other initiatives. The Zenate SHALL aim to ensure transparency and accountability among development fund recipients by conducting monthly meetings and encouraging open discussions. The Zenate’s decisions MUST resonate with the Zcash community consensus, with ZCAP polling being the primary determinant of the consensus. Each decision’s alignment with the community consensus, through ZCAP polls, needs documentation. Convincing on-going efforts to improve community polling mechanisms shall be made by the Zenate.
The Zenate upholds community consensus as the foundation of ZIP governance. It mediates community consensus on ZIPs, as measured through polling overseen by the Zenate. Community consensus remains the cornerstone of ZIP governance supported by the Zenate.
Working hand-in-hand with the Zenate, ZIP Editors play a crucial role in the maintenance and governance of ZIPs. They have the authority to move ZIPs across most status transitions, including the ability to activate or finalize ZIPs and propose ZIPs for ZCAP polling. They are also responsible for managing ZIP Amendments, ensuring only necessary changes are made preserving the original intent of the ZIP.
Amendments to ZIPs can be proposed by anyone in the Zcash Community and are reviewed, approved, and edited by the ZIP Editors. Minor edits and corrections can be approved by the ZIP Editors, but major changes require a new ZIP or a ZCAP Poll.
In all cases, changes must align with the original intent of the ZIP. This approach ensures that the ZIP remains true to its original goals and objectives while allowing for necessary updates and improvements.
The Zenate supervises the allocation of block rewards stipulated in ZIP1014 for the development fund. Any modifications to ZIP1014 or successors, once agreed upon by the ECC and ZF, will be incorporated into consensus rules. Actions, decisions, or modifications pertaining to ZIPs need grounding on clear objectives or comprehensive business plans. By approving this ZIP, ECC and ZF recognize the Zenate and ZCAP as representatives of community consensus, consistent with the trademark agreement, solidifying their decision-making roles related to the agreement.
The Zenate SHALL strive for transparency and accountability by regularly divulging its intended goals and operations. Meeting minutes should be reviewed and, after necessary redactions and corrections, publicized.
The Zenate MAY employ part-time staff for administrative tasks like transcription of meeting minutes. Such staff shall receive compensation at market rates.
Initially, the Zcash Foundation (ZF) will provide compensation to Zenate members and staff using funds from its operational budget. An annual review of the compensation rates and overall compensation structure should occur. Any adjustments must be proposed by the Zenate, approved by majority vote, and ratified by ZF.
The Zenate SHALL function in harmony with existing panels, committees, and procedures within Zcash, bringing an enhanced layer of representation and advisory support.
… [#RFC2119] RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>_
… [#zip-0200] ZIP 200: Network Upgrade Mechanism <zip-0200.rst>_
… [#trademark] Zcash Trademark Donation and License Agreement <https://electriccoin.co/wp-content/uploads/2019/11/Final-Consolidated-Version-ECC-Zcash-Trademark-Transfer-Documents-1.pdf>_
… [#zf-community] ZF Community Advisory Panel <https://www.zfnd.org/governance/community-advisory-panel/>_
[Speaking as a ZIP Editor]
Motivation isn’t the same as proselytization; it’s possible to say what the aims of the ZIP are without making strong assumptions that it will be successful. “… aims to cultivate …” and “The Zenate is intended to empower the Zcash community with amplified authority over the direction of their blockchain.” would be fine and sufficient.
This seems to assume a stronger definition of “conflict of interest” than is normally understood. In general, a declared conflict of interest doesn’t by itself mean that there is any impropriety to participating in that area. That would depend on what the relevant interest is, and whether they can maintain impartiality anyway.
For example, in discussions of the dev fund (or previously, the Founders’ Reward) I’ve routinely declared an interest because I am a dev fund recipient and was a Founders’ Reward recipient. But I’ve also participated frequently in discussions about them, written and been credited on ZIPs about them, and helped to implement them.
For certain conflicts of interest this wording could also be too weak. I would suggest:
- If a specific decision or discussion arises where a Zenate member has a conflict of interest that either they or other Zenate members believe could affect or reasonably be seen to affect their impartiality, they MUST abstain from participating in that particular decision or discussion.
(I also deleted “declared”. They should declare conflicts of interest, but this particular provision isn’t dependent on the conflict having been declared.)
ZCAP Polling for ZIPs
First, the process for ZIP status transitions belongs in the Specification of Status Workflow section of ZIP 0. The right way to specify this in your ZIP would be to give the changes to be made to that section. It’s unnecessary and undesirable to mention things that haven’t changed, since it just introduces specification in two places that could get out of sync later. The ZIP Editors will add the relevant changes for ZIP 0 into the PR. For example, the way to state the current proposal would be something like:
This ZIP proposes that certain transitions of ZIP status will require ZCAP polling to determine community consensus. The Specification of Status Workflow section of ZIP 0 [#zip-0000-workflow]_ will change as follows:
Draft/Proposed to Rejected:
If no progress is made on a ZIP for a year, a ZCAP poll SHALL be conducted. The poll MUST present two choices: move to ‘Rejected’ or remain in the current state.Proposed to Active (For Process/Informational ZIPs):
A ZCAP poll is REQUIRED. The poll MUST present two choices: move to ‘Active’ or remain as ‘Proposed’.Proposed to Implemented (For Consensus/Standards ZIPs):
A ZCAP poll is REQUIRED. The poll MUST present two choices: move to ‘Implemented’ or remain as ‘Proposed’.In any ZCAP poll specified above, users can select one option or withhold their vote by not making a selection. Detailed procedures for ZIP polling will be delineated by the Zenate, ensuring all operations align with the spirit and intent of ZCAP. If there is a clear outcome, the ZIP Editors SHOULD follow that outcome.
OK, with that editorial technicality out of the way, I will comment on the substance of these changes.
Draft or Proposed to Withdrawn:
- […] The Zenate SHOULD inform the community of the withdrawal and its reasons.
This is requiring something of the Zenate that may require information they don’t have. It is intentional that ZIP 0 currently places no requirements on Draft ↔ Withdrawn status transitions; currently, a sufficient reason for the Owner to withdraw a ZIP would be “I felt like it.” or “I don’t have capacity to handle this.” Anyone else is free to suggest to the ZIP Editors that they can take over a ZIP per the Transferring ZIP Ownership section of ZIP 0, so I don’t think that this really needs a more heavyweight process. The Zenate and/or the ZIP Editors are free to comment if they want to; it doesn’t need a specification (and if it did, I would suggest a separate update to ZIP 0 that need not be dependent on the Zenate ZIP).
Draft/Proposed to Rejected
ZIP 0 already has the following wording in the ZIP Status Field section:
Rejected: If no progress on a Draft or Proposed ZIP has been made for one year, the ZIP Editors SHOULD move it to Rejected status. It can revert back to Draft/Proposed if the Owner resumes work or resolves issues preventing consensus. The Rejected status MUST be approved by consensus among the current ZIP Editors.
I just don’t see why this needs a ZCAP poll. ZCAP voting on it won’t create progress where there has been none in a year. The only way a ZIP in this state is going to make progress is if someone decides to pick it up — which doesn’t need a poll. You cannot vote people into doing specification work. That’s not to say that a poll would have no effect in terms of demonstrating interest, but just talking to the Owners and telling them there is interest would likely achieve the same effect (if it is going to be achieved) with less overhead.
Proposed to Active (For Process/Informational ZIPs)
Proposed to Implemented (For Consensus/Standards ZIPs)
First a nitpick: {Process, Informational, Consensus, Standards} does not exhaust the ZIP categories defined in ZIP 0. It’s also slightly ambiguous, for example, ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants has category “Consensus Process”. (This is actually a subcategory of Process, which is why ZIP 1014 is Active rather than Implemented.) Anyway, it’s unnecessary to make this split because the proposal is to require a ZCAP vote for both. That is, it could just be:
- Proposed to Active or Implemented:
A ZCAP poll is REQUIRED. The poll MUST present two choices: move to the requested status or remain as ‘Proposed’.
Now, for my substantive comment, ZIP 0 as modified by zcash/zips#716 has the following wording (markup shows the proposed changes in zcash/zips#716):
A Standards ZIP SHOULD only change status from Proposed to Implemented once the Owners provide an associated reference
implementationimplementation. For Consensus ZIPs, an implementation MUST have been merged into at least one consensus node codebase (currently zcashd and/or zebra), typically in the period after the network upgrade’s specification freeze but before the implementation audit. If the Owners miss this deadline, the Editors or Owners MAY choose to update the Deployment section of the ZIP to target another upgrade, at their discretion.A Process or Informational ZIP SHOULD change status from
DraftProposed to Active when it achieves rough consensus on the forum or PR. Such a proposal is said to have rough consensus if it has been substantially complete and open to discussion on the forum or GitHub PR for at least one month, has been in Proposed status for at least one week, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections can be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning MUST be given in such circumstances.
(The time periods might be changed based on a comment by @aiyadt.)
The intention of the Implemented status is just “has this ZIP been implemented?” That’s all. (It must have been Proposed to count as Implemented, because if it was in Draft then we can’t know that what is implemented is the right thing.)
The ZIP Editors are best placed to decide whether a given specification has been implemented. It doesn’t need a ZCAP vote because it’s an objective technical property of the zcashd and zebra codebases (and maybe other codebases in the case of a Wallet ZIP, for example), not an opinion. In any case, Proposed → Implemented is too late for a ZCAP vote, because zcashd, zebra, and wallet implementors are entirely free to implement any ZIP and make it active on the network, and are likely to do the latter at any time after it reaches Proposed status. There might be a case for a more heavyweight process for Consensus ZIPs, but the current draft wording for the Zenate ZIP doesn’t restrict itself to Consensus ZIPs.
If there’s a place for a ZCAP vote, it should be from non-Released → Released. Here is what ZIP 0 as modified by zcash/zips#716 says about that:
A ZIP’s status is Released if it is Proposed, Active, Implemented, or Final (i.e. not Draft, Rejected, Obsolete, or Withdrawn).
A ZIP SHOULD NOT be changed from a non-Released status to a Released status if there is significant community opposition to its content. (However, Draft ZIPs explicitly MAY describe proposals to which there is, or could be expected, significant community opposition.)
Judging whether there is “significant community opposition” seems more like the kind of thing that, in principle, could be decided by a ZCAP poll.
On the other hand, is there really any need to bother ZCAP with ZIP releases that are uncontroversial? Sometimes it is obvious that a ZIP is pretty boring. Some ZIPs fix security flaws and the zcashd and zebra engineers are going to use their technical judgement to decide whether to implement them regardless of what ZCAP says.
In any case, if the intent is enforce a ZCAP gate that new or effectively new specifications go through, then there is a loophole that you could drive a truck through: just change an existing ZIP rather than release a new one. In practice the ZIP Editors should catch abuses of that, but if you’re relying on the ZIP Editors to do so, why require ZCAP votes in some subset of cases that is neither necessary nor sufficient?
Sorry if I’ve sounded a bit negative. Since I’m speaking as a ZIP Editor here, please note that this is intended as editorial / technical / process feedback, not a judgement on the merits of the overall proposal. Also, note that I only got to the “ZCAP Polling for ZIPs” section and have not reviewed subsequent sections.
See also this discussion on zcash/zips#716.
ZF created ZCAP as a means of assessing community sentiment, and uses it as an advisory input when appointing board members, and when discharging its duties and responsibilities under the Trademark Agreement.
The ZF Board has discussed this proposal, and has unanimously agreed that ZF will continue to operate and manage ZCAP.
Can you clarify then who makes the determination of the community direction for ZIPs and the protocol as a whole? That seems to be a fundamental question.