Establishing a Zenate for ZIP Governance and Managing ZCAP

[GGuy]

Requesting comments for my proposal for Establishing a Zenate for ZIP Governance and Managing ZCAP. May this act as a starting point for conversations between @zooko and @Dodger during future discussions on Zcash governance.

TLDR: This ZIP proposes the creation of a Zenate (Zcash Senate) which SHOULD act as an elected governing body by the community to build, improve, and vote on Zcash Improvement Proposals (ZIPs). Upon its formation, the Zenate SHALL assume the management of ZCAP from the Zcash Foundation.

---

ZIP: TBD
Title: Establishing a Zenate for ZIP 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

Terminology

Terms capitalized such as “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document shall be understood as described in RFC 2119. [#RFC2119]_

The term “network upgrade” in this document is to be read as explained in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License

Agreement ([#trademark]_ or successor agreement).

“Zenate” refers to the governing body that is proposed to establish in this ZIP.

“ZCAP” refers to the Zcash Community Advisory Panel, as clarified at [#zf-community]_.

Abstract

This ZIP proposes the creation of a Zenate (Zcash Senate) which SHOULD act as an elected governing body by the community to build, improve, and vote on Zcash Improvement Proposals (ZIPs). Upon its formation, the Zenate SHALL assume the management of ZCAP from the Zcash Foundation. This ZIP delineates the constituents, governance and responsibilities of the Zenate, as well as details of its interaction with ZCAP and the broader Zcash community.

Motivation

In order to enhance the community-driven evolution in the system, a Zenate can facilitate to ensure that every part of the community is heard and their feedback directly influences the direction that Zcash takes. This approach could be more transparent and offer a platform for collaboration, and prove to be more responsive to the vision that the community holds for Zcash.

Specification

Zenate Composition

A Zenate SHOULD be comprised of 5-7 active members, elected by the Zcash community. Each member SHOULD dedicate approximately one day per week to Zenate operations. The tenure of membership in the Zenate SHALL be on a yearly basis, with the possibility of reelection. Staff of the Zcash Foundation (ZF) and Electric Coin Company (ECC) are ineligible for Zenate membership to prevent potential conflicts of interest due to their joint control of the Zcash trademark.

Zenate Governance

A majority vote SHALL govern the decisions taken by the Zenate. In the event of a voting tie, a community-wide poll via ZCAP will decide the course of action. The Zenate SHALL NOT exercise veto power, however, any body MAY bring concerns to the Zenate which must be duly considered.

ZCAP Management

Upon its formation, the Zenate SHALL assume management of ZCAP. The initial election for Zenate SHALL be conducted through ZCAP as managed by the Zcash Foundation. Thereafter, the Zenate SHALL be responsible for handling ZCAP and its own reelections.

ZCAP Polling

The Zenate SHOULD avoid burdening ZCAP with frequent polling. Ideally, polling should occur approximately once every three months. Additionally, ZCAP SHOULD not be polled on matters that already have clear community consensus or those related to administrative or minor alterations to ZIPs.

Community Consensus

The decisions of the Zenate MUST align with the consensus of the Zcash community. The Zenate SHALL document how each decision aligns with community consensus, as established through polling of ZCAP. Furthermore, the Zenate SHOULD solicit feedback through a variety of community engagement methods, such as X, forums, calls, AMAs, etc.

Development Fund Recipients’ Involvement

The Zenate SHALL conduct monthly meetings involving all development fund recipients. These meetings SHALL serve as a platform for discussing the future of Zcash and maintaining transparency and coordination among stakeholders.

ZIPs and Governance

The Zenate SHALL have the authority to develop, vote on, and implement improvements to ZIPs. As such, the Zenate will be instrumental in shaping the future vision and rules of Zcash.

Development Fund Management

The Zenate oversees the allocation of block rewards specified under ZIP1014 for the purpose of managing the development fund. Action items, decisions, or alterations to ZIPs SHALL be backed with clear objectives and/or well-defined business plans, particularly in relation to the distribution of development funds.

Transparency and Accountability

The Zenate SHALL uphold high standards of transparency and accountability by regularly disclosing its objectives and action plans. Members of the committee SHALL review meeting minutes, and, when necessary, redact sensitive information before posting them publicly.

ZCAP Staff

The Zenate MAY employ part-time staff to assist with administrative tasks, such as transcription of meeting minutes. Such staff SHALL be compensated at competitive market rates.

Integrating with Existing Structures

The Zenate SHALL work in collaboration with existing panels, committees, and procedures within Zcash. The Zenate SHALL rely on ZCAP for providing advisory inputs.

References

… [#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/>_

[gottabeJay]

Thank you both for taking initiative and for presenting an actionable proposal to improve Zcash governance

What does the Zcash community mean?

I think there needs to be a clear definition whom it includes and how they get included.

[GGuy]

@gottabeJay Thanks so much for your feedback! I have attempted to make this a little clearer.

Changes include:

• This ZIP proposes the creation and election of a Zenate (Zcash Senate) by the Zcash community through the ZCAP process. The Zenate SHOULD act as a governing body to build, improve, and vote on Zcash Improvement Proposals (ZIPs). Upon its formation, the Zenate SHALL assume the management of ZCAP from the Zcash Foundation. This ZIP delineates the constituents, governance and responsibilities of the Zenate, as well as details concerning its interaction with ZCAP and the broader Zcash community.
• The Zenate SHALL work towards ensuring that ZCAP diversity represents various sectors of the community, including developers, leaders, ecosystem partners and users. It SHOULD also strive to include English and non-English speaking voices. The Zenate SHALL take actionable steps to foster this diversity within ZCAP.

---

ZIP: TBD
Title: Establishing a Zenate for ZIP 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

Terminology

Terms capitalized such as “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document shall be understood as described in RFC 2119. [#RFC2119]_

The term “network upgrade” in this document is to be read as explained in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License Agreement ([#trademark]_ or successor agreement).

“Zenate” refers to the elected governing body by the Zcash community through the ZCAP process that is proposed to establish in this ZIP.

“ZCAP” refers to the Zcash Community Advisory Panel, as clarified at [#zf-community]_.

Abstract

This ZIP proposes the creation and election of a Zenate (Zcash Senate) by the Zcash community through the ZCAP process. The Zenate SHOULD act as a governing body to build, improve, and vote on Zcash Improvement Proposals (ZIPs). Upon its formation, the Zenate SHALL assume the management of ZCAP from the Zcash Foundation. This ZIP delineates the constituents, governance and responsibilities of the Zenate, as well as details concerning its interaction with ZCAP and the broader Zcash community.

Motivation

In order to enhance the community-driven evolution in the system, a Zenate can facilitate to ensure that every part of the community is heard and their feedback directly influences the direction that Zcash takes. This approach could be more transparent and offer a platform for collaboration, and prove to be more responsive to the vision that the community holds for Zcash.

Specification

Zenate Composition

A Zenate SHOULD be comprised of 5-7 active members, elected by the Zcash community through the ZCAP process. Each member SHOULD dedicate approximately one day per week to Zenate operations. The tenure of Zenate membership SHALL be on a yearly basis, with the possibility of reelection. Staff of the Zcash Foundation (ZF) and Electric Coin Company (ECC) are ineligible for Zenate membership to prevent potential conflicts of interest due to their joint control of the Zcash trademark.

Zenate Governance

A majority vote SHALL govern the decisions taken by the Zenate. In the event of a voting tie, a community-wide poll via ZCAP will decide the course of action. The Zenate SHALL NOT have a veto power, however, any body MAY bring concerns to the Zenate which MUST be duly considered.

ZCAP Management

Upon its formation, the Zenate SHALL assume management of ZCAP. The initial election for the Zenate SHALL be conducted through ZCAP as managed by the Zcash Foundation. Thereafter, the Zenate SHALL be responsible for both managing ZCAP and organizing its own reelections.

ZCAP Polling

The Zenate SHOULD avoid burdening ZCAP with frequent polling. Ideally, polling should occur approximately once every three months. Additionally, ZCAP SHOULD not be polled on matters that already have clear community consensus or those related to administrative or minor alterations to ZIPs.

ZCAP Diversity

The Zenate SHALL work towards ensuring that ZCAP diversity represents various sectors of the community, including developers, leaders, ecosystem partners and users. It SHOULD also strive to include English and non-English speaking voices. The Zenate SHALL take actionable steps to foster this diversity within ZCAP.

Community Consensus

The decisions of the Zenate MUST align with the consensus of the Zcash community. The primary instrument to determine this consensus SHALL be through polling of ZCAP. The Zenate SHALL document how each decision aligns with community consensus, as established through ZCAP polling. Furthermore, the Zenate SHOULD solicit further feedback through a variety of community engagement methods, such as X, forums, calls, AMAs, etc.

Development Fund Recipients’ Involvement

The Zenate SHALL conduct monthly meetings involving all development fund recipients. These meetings SHALL serve as a platform for discussing Zcash’s future and maintaining transparency and coordination among stakeholders.

ZIPs and Governance

The Zenate SHALL have the authority to develop, vote on, and implement improvements to ZIPs. As such, the Zenate will be instrumental in shaping the future vision and rules of Zcash.

Development Fund Management

The Zenate oversees the allocation of block rewards specified under ZIP1014 for the purpose of managing the development fund. Action items, decisions, or alterations to ZIPs SHALL be backed with clear objectives and/or well-defined business plans, particularly in relation to the distribution of development funds.

Transparency and Accountability

The Zenate SHALL uphold high standards of transparency and accountability by regularly disclosing its objectives and action plans. Members of the committee SHALL review meeting minutes, and, when necessary, redact sensitive information before posting them publicly.

ZCAP Staff

The Zenate MAY employ part-time staff to assist with administrative tasks, such as transcription of meeting minutes. Such staff SHALL be compensated at competitive market rates.

Integrating with Existing Structures

The Zenate SHALL work in collaboration with existing panels, committees, and procedures within Zcash. The Zenate SHALL rely on ZCAP for providing advisory inputs.

References

… [#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/>_

[conradoplg]

I like the idea but I find a bit weird that the Zenate controls the ZCAP which is used to elect the Zenate. But I don’t see an easy way out of that. Also there are a lot of vague points, see below.

@GGuy

The Zenate SHOULD avoid burdening ZCAP with frequent polling. Ideally, polling should occur approximately once every three months. Additionally, ZCAP SHOULD not be polled on matters that already have clear community consensus or those related to administrative or minor alterations to ZIPs.

One criticism of the trademark agreement is the vagueness of “clear community consensus” and the same appears here. I don’t see how this rule could be possibly enforced.

@GGuy

The Zenate SHALL have the authority to develop, vote on, and implement improvements to ZIPs. As such, the Zenate will be instrumental in shaping the future vision and rules of Zcash.

This is a bit vague, does it mean that the Zenate has the final say on whether a proposed ZIP will be accepted or not?

@GGuy

The Zenate oversees the allocation of block rewards specified under ZIP1014 for the purpose of managing the development fund. Action items, decisions, or alterations to ZIPs SHALL be backed with clear objectives and/or well-defined business plans, particularly in relation to the distribution of development funds.

What exactly does this mean? If a Zenate is formed before the dev fund ends, does this mean the Zenate will manage the dev fund? How, if the dev fund is deposited in addresses that are encoded in the nodes? What happens when the dev fund ends? Does this mean the Zenate will decide whether it will be renewed or not?

@GGuy

The Zenate MAY employ part-time staff to assist with administrative tasks, such as transcription of meeting minutes. Such staff SHALL be compensated at competitive market rates.

It seems to imply that the Zenate itself will not be compensated in any form. If so, this should be made explicit.

[noamchom]

@GGuy

through the ZCAP

What is meant by this dependency?
To my understanding, for the sake of Zenate independence it would make a lot more sense for it to be created and exist totally outside of the power of the Zcash Foundation (which currently manages ZCAP processes, et).

[GGuy]

@noamchom

To my understanding, for the sake of Zenate independence it would make a lot more sense for it to be created and exist totally outside of the power of the Zcash Foundation (which currently manages ZCAP processes, et).

Open to any concrete suggestions on how we elect Zenate members without using ZCAP . You’d have to let me know who has the authority to set the eligibility criteria for members, who will manage the process, approve the wording, interpret the results, etc.

[GGuy]

@conradoplg thank you so much for your suggestions!!! I truely appreciate the time you took to read it and provide your feedback!!! Please let me know if these changes don’t address your concerns or if you have any other suggestions. This would be a pretty serious ZIP to ratify so every suggestion helps .

I’ve made a few adjustments the major ones are as follows:

• All Zenate members SHALL be compensated for 35 hours monthly at a rate of $100US per hour. Any changes to the compensation, including adjustments for inflation, would require a ZIP change.
• ZCAP MUST be utilized to determine clear community consensus via polling. For the specific purpose of ratifying or amending a ZIP, polling shall present three choices: approve, reject, and withhold vote. Achieving consensus is determined when a majority of participants opt for either ‘approve’ or ‘reject’, excluding ‘withhold vote’ counts. Once a consensus is ascertained through ZCAP polling, the Zenate does not need another poll for minor alterations, as long as they remain consistent with the original intent of the ZIP and poll. For polling questions that encompass more than these three options, they will serve to gauge community sentiments regarding ZCAP’s performance, provide feedback for Zenate’s future direction, and guide Zenate members in prioritizing their contributions.
• The Zenate supervises the allocation of block rewards as outlined in ZIP1014 for the development fund. Actions, decisions, or modifications to ZIPs, particularly concerning the distribution of the development fund, MUST be grounded on clear objectives or detailed business plans. Any modifications to ZIP1014 or its successors, once agreed upon by ECC and ZF, must be incorporated into consensus rules. Crucially, by ratifying this ZIP, both ECC and ZF recognize and accept the Zenate and ZCAP as clear indicators of community consensus in line with the stipulations of the Trademark agreement. This acknowledgment reinforces the Zenate and ZCAP’s roles in decision-making processes related to the Trademark agreement.
• Compensation to Zenate members and staff is executed directly from the block reward to the recipients’ specified addresses. These payments are made 16 weeks in arrears. Such an arrangement is structured to permit payment adjustments to align with the ZIP 200 Network Upgrade Mechanism, ensuring that any modifications take effect before Zcash’s 16-week End-of-Service halt.
  For determining the appropriate amount in USD for the compensation, the ZECUSD exchange rate is computed as the average ZECUSD price of the day exactly 16 weeks prior to the previous End-of-Service halt date. This method ensures transparency in the payment process and avoids potential fluctuations that might arise if compensation were based on real-time or near-term exchange rates.
  This approach not only fortifies the network’s stability and robustness but also brings predictability and transparency to Zenate and staff compensations. It also instills confidence among the members about the fairness and methodological soundness of the payment system.

---

ZIP: TBD
Title: Establishing a Zenate for ZIP 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

Terminology

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]_.

Abstract

This ZIP advocates for the inception and election of a Zenate (Zcash Senate) via the ZCAP process. The Zenate’s primary function is to act as a governing authority for the formulation, enhancement, and voting on Zcash Improvement Proposals (ZIPs). Upon establishment, the Zenate SHALL manage ZCAP, transitioning from the Zcash Foundation. This document clarifies the composition, governance, and duties of the Zenate and its interaction with ZCAP and the larger Zcash community.

Motivation

In order to enhance the community-driven evolution in the system, a Zenate can facilitate to ensure that every part of the community is heard and their feedback directly influences the direction that Zcash takes. This approach could be more transparent and offer a platform for collaboration, and prove to be more responsive to the vision that the community holds for Zcash.

Specification

Zenate Composition

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 reelection opportunities. Zcash Foundation (ZF) and Electric Coin Company (ECC) staff are ineligible for Zenate membership to prevent potential conflicts of interest due to their joint control of the Zcash trademark. All Zenate members SHALL be compensated for 35 hours monthly at a rate of $100US per hour. Any changes to the compensation, including adjustments for inflation, would require a ZIP change.

Zenate Governance

Decisions within the Zenate are by majority vote by the elected members. In case of tied votes, a ZCAP community-wide poll will dictate the outcome. The Zenate SHALL NOT have a veto power, however, any body MAY bring concerns to the Zenate which MUST be duly considered.

ZCAP Management

Upon its inception, the Zenate assumes ZCAP management. The first Zenate election is through ZCAP under the Zcash Foundation’s purview. Subsequently, the Zenate is in charge of ZCAP management and organizing its own reelections.

ZCAP Polling

ZCAP MUST be utilized to determine clear community consensus via polling. For the specific purpose of ratifying or amending a ZIP, polling shall present three choices: approve, reject, and withhold vote. Achieving consensus is determined when a majority of participants opt for either ‘approve’ or ‘reject’, excluding ‘withhold vote’ counts. Once a consensus is ascertained through ZCAP polling, the Zenate does not need another poll for minor alterations, as long as they remain consistent with the original intent of the ZIP and poll. For polling questions that encompass more than these three options, they will serve to gauge community sentiments regarding ZCAP’s performance, provide feedback for Zenate’s future direction, and guide Zenate members in prioritizing their contributions.

ZCAP Diversity

The Zenate aims for ZCAP diversity, encompassing developers, leaders, ecosystem partners, and users. Efforts to include both English and non-English participants are vital. The Zenate SHALL take actionable steps to achieve this diverse ZCAP representation.

Community Consensus

The Zenate’s decisions MUST resonate with the Zcash community’s consensus. ZCAP polling remains the primary consensus determinant. Each decision’s alignment with the community consensus, through ZCAP polls, needs documentation. The Zenate SHOULD also gather feedback via various community engagement avenues, such as X, forums, calls, AMAs, etc. Moreover, the Zenate is also expected to evolve and improve community polling mechanisms over time. Any introduction or change to a polling mechanism would require ratification into this ZIP and clear community consensus.

Development Fund Recipients’ Involvement

Monthly meetings involving all development fund beneficiaries SHALL be conducted by the Zenate. These sessions are platforms for discussing Zcash’s future while ensuring transparency and stakeholder coordination.

ZIPs and Governance

The Zenate possesses the exclusive authority to craft, vote on, and implement ZIP improvements. They are responsible for both ZIP submissions acceptance and new ZIPs creation. As a result, the Zenate has the final say on a proposed ZIP’s fate, underscoring their role in shaping Zcash’s vision and rules.

Development Fund Management

The Zenate supervises the allocation of block rewards as outlined in ZIP1014 for the development fund. Actions, decisions, or modifications to ZIPs, particularly concerning the distribution of the development fund, MUST be grounded on clear objectives or detailed business plans. Any modifications to ZIP1014 or its successors, once agreed upon by ECC and ZF, must be incorporated into consensus rules. Crucially, by ratifying this ZIP, both ECC and ZF recognize and accept the Zenate and ZCAP as clear indicators of community consensus in line with the stipulations of the Trademark agreement. This acknowledgment reinforces the Zenate and ZCAP’s roles in decision-making processes related to the Trademark agreement.

Transparency and Accountability

The Zenate SHALL champion transparency and accountability by regularly disclosing objectives and plans. Committee members SHOULD review meeting minutes, making necessary redactions and corrections before publicizing them.

ZCAP Staff

The Zenate MAY hire part-time assistants for tasks like meeting minutes transcription. Such staff receive compensation at market rates.

Compensation Payments

Compensation to Zenate members and staff is executed directly from the block reward to the recipients’ specified addresses. These payments are made 16 weeks in arrears. Such an arrangement is structured to permit payment adjustments to align with the ZIP 200 Network Upgrade Mechanism, ensuring that any modifications take effect before Zcash’s 16-week End-of-Service halt.

For determining the appropriate amount in USD for the compensation, the ZECUSD exchange rate is computed as the average ZECUSD price of the day exactly 16 weeks prior to the previous End-of-Service halt date. This method ensures transparency in the payment process and avoids potential fluctuations that might arise if compensation were based on real-time or near-term exchange rates.

This approach not only fortifies the network’s stability and robustness but also brings predictability and transparency to Zenate and staff compensations. It also instills confidence among the members about the fairness and methodological soundness of the payment system.

Integrating with Existing Structures

The Zenate SHALL work in collaboration with existing panels, committees, and procedures within Zcash.

References

… [#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/>_

[Jgx7]

i’m against any more organizations funded by block rewards. we need more development focused on the blockchain and privacy based digital money,
not more people getting in between the foundation and the ECC and devopment.

decentralize development. we only need two organizations and we have them. if they arnt doing their job, then vote more better governance so they can be removed.

monero has a pretty cool crowdsourcing option. why don’t you create something in the same way as moneeo does it?

[GGuy]

@Jgx7

monero has a pretty cool crowdsourcing option. why don’t you create something in the same way as moneeo does it?

Sounds good. Any links?

[Jgx7]

https://ccs.getmonero.org/

this is more of a decentralized approach not dependent on zec holders or block rewards. it’s community funded. Now if the entire project was funded by the community. we could get rid of block rewards.

another option is to get rid of all the gatekeepers, and let zec holders distribute their share of blockrewards to the development directly. this could be done as part of a crowdsource platform as well.

[teor]

I’m a staff member of the Zcash Foundation and a ZIP Editor, but I am posting these suggestions in my capacity as a community member:

@GGuy

Zcash Foundation (ZF) and Electric Coin Company (ECC) staff are ineligible for Zenate membership to prevent potential conflicts of interest due to their joint control of the Zcash trademark.

What about board members of these organisations? What about other organisations or individuals funded by the dev fund?

I would also suggest adding broader conflict of interest clause. For example, here is the clause that was just added to ZIP 0:

ZIP Editors MUST declare any potential or perceived conflict of interest they have relating to their responsibilities as ZIP Editors.

https://github.com/zcash/zips/blob/a6227964b50e6084314e9bcf11c6c9183ac27261/zip-0000.rst#zip-editors

@GGuy

The Zenate SHALL NOT have a veto power,

What does “veto power” mean here, and what is that power related to?

@GGuy

For the specific purpose of ratifying or amending a ZIP, polling shall present three choices: approve, reject, and withhold vote.

By “ratifying” do you mean “changing the ZIP status to Proposed”?

What about rejecting a ZIP? Or activating a process ZIP (like this one)?

Please see ZIP 0 for the full list of ZIP statuses, and the specific words used for these status changes:
https://github.com/zcash/zips/blob/a6227964b50e6084314e9bcf11c6c9183ac27261/zip-0000.rst#zip-status-field

@GGuy

The Zenate possesses the exclusive authority to craft, vote on, and implement ZIP improvements. They are responsible for both ZIP submissions acceptance and new ZIPs creation. As a result, the Zenate has the final say on a proposed ZIP’s fate, underscoring their role in shaping Zcash’s vision and rules.

This change will require substantial changes to ZIP 0, because some of these responsibilities are currently assigned to the ZIP Editors. What happens to the ZIP Editor role if this ZIP is activated?

@GGuy

Compensation to Zenate members and staff is executed directly from the block reward to the recipients’ specified addresses. These payments are made 16 weeks in arrears. Such an arrangement is structured to permit payment adjustments to align with the ZIP 200 Network Upgrade Mechanism, ensuring that any modifications take effect before Zcash’s 16-week End-of-Service halt.

I think there’s some confusion here between Zcash network upgrades, and the support guaranteed by ECC for their zcashd distribution. That might make this section tricky to implement.

Network upgrades happen roughly every 18 months, except for Canopy, which happened 4 months after Heartwood. The trademark agreement requires ECC & ZF to approve the Zcash node software for each network upgrade. The last network upgrade was NU5, where ECC & ZF approved both zcashd v5.0.0 and Zebra v1.0.0-beta.10.

A network upgrade is required to change block reward recipient addresses.

ECC’s guarantees support for each zcashd version they distribute for a limited period of time. Typically this period is 16 weeks, but it can be shorter. Other zcashd forks can guarantee a different support period, or remove the halting code entirely. Some operators already do this, because we see older versions on the network all the time.

ZF also guarantees support for each Zebra release for a similar period, and has similar halting code. And forks and operators can change this.

But ECC & ZF release at different times, and use different release cycles. (ECC is typically 6 weeks, ZF is typically 2-4 weeks.)

Each network upgrade needs to be scheduled after:

• the ZIP changes are drafted (1-4 weeks)
• the ZIP changes are approved (2 weeks? this ZIP doesn’t say how long a vote lasts)
• the reference implementations are implemented and tested (4-12 weeks)
• ECC and ZF approve the releases under the trademark agreement (1-2 weeks?)
• all zcashd and Zebra versions without the network upgrade have reached end of support (16 weeks)

The shortest period we have ever had for a network upgrade is 6 months (Canopy). But the typical network upgrade period is 18 - 24 months.

[daira]

[Speaking in my role as a ZIP Editor]

Staff of the Zcash Foundation (ZF) and Electric Coin Company (ECC) are ineligible for Zenate membership to prevent potential conflicts of interest due to their joint control of the Zcash trademark.

The Zenate SHALL have the authority to develop, vote on, and implement improvements to ZIPs.

I’d like to point out that as a practical matter, it is ECC and ZF staff who have the knowledge of the Zcash protocol and processes necessary to act as effective ZIP Editors.

The ZIP Editors as of https://github.com/zcash/zips/pull/707 will be me and @str4d from ECC, and @teor and @conradoplg from ZF. Other people from outside ECC and ZF are very welcome to join us, as I said in this post: Changing the ZIP Editors . However, I really don’t think that transferring the editing task to a body that ECC and ZF staff are excluded from is going to work, or would be in the best interests of the Zcash community or the future security of the protocol.

[GGuy]

Thanks so much @daira and @teor your feedback !!!

I agree @daira. The line about Zenate participants not being ECC or ZF members was a knee jerk reaction to @zooko’s comments during the Community Town Hall #3 (https://twitter.com/i/spaces/1vAxRADqQNPJl?s=20) at 22:20 (1). I will remove this line.

@teor

ZIP Editors MUST declare any potential or perceived conflict of interest they have relating to their responsibilities as ZIP Editors.

Awesome! I’ll add this.

@teor

What does “veto power” mean here, and what is that power related to?

I’ll remove this. This was a watered down reference to veto power mentioned in the trademark agreement. Too vague.

@teor

By “ratifying” do you mean “changing the ZIP status to Proposed”?

True. I’ll adjust to include details about how to measure consensus on changing the status of ZIP.

@teor

This change will require substantial changes to ZIP 0, because some of these responsibilities are currently assigned to the ZIP Editors. What happens to the ZIP Editor role if this ZIP is activated?

My goal was not to replace ZIP editors but it does appear to be worded in such a way. I might have to think about how to soften that interpretation. The goal is that the Zenate work as a body that actively advocate for the community and hold power over the process for measuring of community consensus for use in other ZIPs.

As ZIP-0000 states:

one or more people who write the ZIP using the style and format described below, shepherd the discussions in the appropriate forums, and attempt to build community consensus around the idea

My hope would be that the Zenate and this ZIP be used to more clearly define the process used to measure community consensus. So ZIP-0000 would be adjusted to define community consensus as the “community consensus as measured by the Zenate”. I’ve obviously missed the mark because my wording doesn’t clearly reflect that clearly. Any suggestions on softening this ZIP towards those goals?

Keep in mind the role of a Zenator would be very different to a ZIP editor in practice. These members would conduct regular community outreach efforts and review the performance of ECC and ZF on an ongoing basis in a similar way to how other government bodies advocate for their communities and measure the performance of the things that they fund and adjust the funding as necessary.

@teor

A network upgrade is required to change block reward recipient addresses.

My understanding is that the End-of-Service halt as defined in ZIP-0200, which I believe Zebra also participate in, would allow all nodes to have consensus on block reward address changes. Can we make up some other name like “minor network upgrade”. I’m not saying it’d be easy but I imagine having a process which allows all stackholders to be comfortable making adjustments to the block reward recipients a couple of times a year would be good for Zcash. While it might be easier to pass the funds through a central entity (e.g. ZF) both have pros and cons we need to balance but I’m open to either option if adjusting block reward recipients is a major risk to Zcash nodes.

Am I dreaming that this would be a realistic way to do things? Should I switch this back to more traditional funding methods like ZF managing the Zenate’s funds?

Appendix

Zooko

This isn’t a perfect quote of what @zooko said but hopefully close enough.

I have a problem which is that I am both the CEO of the Electric Coin Company and I’m also a member of the board for the Bootstrap Organisation that has rights to sign off on Zcash forks under the trademark agreement. So this gives bootstrap as an organization this unique power that the bootstrap and ZF has to approve or veto uses of the name Zcash as a name on blockchain forks. That’s a governance power that nobody else can replicate because it’s legally controlled by this trademark.

With my trademark power hat on the bootstrap organization which I represent has some control over the purse strings and with my ECC hat on I want build things which I need the funding necessary to do so which is not ideal.

I do not consider the current ZIP Editors like @daira and @teor to be high risk in this regard. I will remove this stipulation. Although it does seem that @zooko and/or @dodger (and possible other board members) sitting on the Zenate, with a major influence over trademark decisions, would create a significant power imbalance. Not sure how to address this concern. Any thoughts @daira/@teor?

[teor]

@GGuy

Any suggestions on softening this ZIP towards those goals?

Keep in mind the role of a Zenator would be very different to a ZIP editor in practice. These members would conduct regular community outreach efforts and review the performance of ECC and ZF on an ongoing basis in a similar way to how other government bodies advocate for their communities and measure the performance of the things that they fund and adjust the funding as necessary.

If their intended role is to adjust funding, then I’d encourage you to say that. (And avoid things that conflict or overlap with existing groups within the community, unless you explicitly say you’re going to replace them.)

You might also want to consider how the Zenate will interact with ZCG, since it is the largest recipient of the current dev fund. And any other large dev fund recipients that are added in future.

[GGuy]

@teor

If their intended role is to adjust funding, then I’d encourage you to say that. (And avoid things that conflict or overlap with existing groups within the community, unless you explicitly say you’re going to replace them.)

But also to become the definition of “community consensus” that hopefully ECC and ZF will “agree on”, as best they can, for future trademark decisions. For example I’d hope that the Zenate, and it’s process, be used to measure community consensus for uses or the Zcash Trademark including defining which fork can be called “Zcash”.

Love your suggestion here I’ll make sure that’s better defined.

[teor]

@GGuy

@teor

A network upgrade is required to change block reward recipient addresses.

My understanding is that the End-of-Service halt as defined in ZIP-0200, which I believe Zebra also participate in, would allow all nodes to have consensus on block reward address changes. … I’m not saying it’d be easy but I imagine having a process which allows all stackholders to be comfortable making adjustments to the block reward recipients a couple of times a year would be good for Zcash. While it might be easier to pass the funds through a central entity (e.g. ZF) both have pros and cons we need to balance but I’m open to either option if adjusting block reward recipients is a major risk to Zcash nodes.

Am I dreaming that this would be a realistic way to do things? Should I switch this back to more traditional funding methods like ZF managing the Zenate’s funds?

In the 8 years it has existed, Zcash has only had one year where it had 2 network upgrades. (And 4 years where it had no network upgrades.) So there isn’t much evidence that doing 2-3 upgrades per year is technically or administratively possible.

Can we make up some other name like “minor network upgrade”.

I’m not sure that changing the name would help, because a consensus-breaking upgrade is technically complex, and legally the same thing under the trademark agreement.

However, there have been 3 successful implementations of custody of grant funds: ZCG grants via ZF, ZF minor grants, and ECC grants. If there are concerns about the eligibility, privacy, or independence of those grants, I understand there are multiple organisations or subsidiaries that have been set up to address those issues.

@GGuy

Although it does seem that @zooko and/or @dodger (and possible other board members) sitting on the Zenate, with a major influence over trademark decisions, would create a significant power imbalance. Not sure how to address this concern.

It seems like you might have answered your own question here? If your concern is the boards, or people who have decision-making power under the trademark agreement, then I’d encourage you to say that.

[GGuy]

@teor

decision-making power

. Thank you!

@teor

So there isn’t much evidence that doing 2-3 upgrades per year is technically or administratively possible.

Valid!

[daira]

@GGuy

@teor

A network upgrade is required to change block reward recipient addresses.

My understanding is that the End-of-Service halt as defined in ZIP-0200, which I believe Zebra also participate in, would allow all nodes to have consensus on block reward address changes.

No that’s not correct. As ZIP 214 says about the “direct grant option” which is what would need to be used here:

For each network upgrade after Canopy requiring modifications to the set of direct grantees, a separate ZIP SHOULD be published specifying those modifications.

In other words, it was anticipated that changes to these addresses or amounts only be made at network upgrades. It is definitely a consensus change that would cause a bilateral hard fork.

[daira]

@GGuy

I do not consider the current ZIP Editors like @daira and @teor to be high risk in this regard.

(For information: @conradoplg and @str4d are also current ZIP Editors, since zcash/zips#707 was merged 7 hours ago. And @aiyadt will be soon.)

This isn’t the right criterion. Governance processes should be designed to resist capture regardless of the specific people involved. The point I was making earlier was more of a practical issue: if ECC and ZF staff were excluded then we would be missing people who have the necessary experience needed for ZIP editing.

Speaking as a ZIP Editor, it seems to me that the relationship between the proposed Zenate and the ZIP Editors would have to be clarified in order for the proposal to progress, because at the moment it seems to muddy the responsibilities between them.

Note that all ZIP editors are supposed to have editorial independence from any organisations they have contractual relationships with, including ECC and ZF (and Nighthawk Apps, when Aditya joins). That’s why we changed the wording in ZIP 0 from saying that the current editors are “representing” ECC or ZF, to saying we are “associated with” those organisations, and said that “Any technical or process review that ZIP Editors perform is expected to be independent of their contractual or other relationships.”

I’d also like to point out that the ZIP Editorship has just undergone an expansion from two to four five people and has been opened up to other applicants, and we haven’t been able to observe the effects of that change yet.

Speaking personally, I don’t want my role to become any more political than it currently is, if I can help it.

[str4d]

@teor

In the 8 years it has existed, Zcash has only had one year where it had 2 network upgrades. (And 4 years where it had no network upgrades.) So there isn’t much evidence that doing 2-3 upgrades per year is technically or administratively possible.

I don’t quite agree with these numbers, though I agree with the general premise.

Here are the various changes that the network has undergone, in terms of both the calendar year and Zcash’s birthday (October 28, 2016). Sprout is effectively “Network Upgrade -1”, as you can’t upgrade a network that doesn’t exist, and it required comparable engineering effort.

Activation	Height	Date	Zcash age (years)	Upgrade interval (years)
Sprout	0	28 October 2016	0	—
Overwinter	347,500	26 June 2018	1	1.67
Sapling	419,200	29 October 2018	2	0.33
Blossom	653,600	11 December 2019	3	1.125
Heartwood	903,000	16 July 2020	3	0.58
Canopy	1,046,400	18 November 2020	4	0.33
NU5	1,687,104	31 May 2022	5	1.54
(Now)	—	15 September 2023	6	1.29

By calendar years, there have been two years where Zcash had 2 network upgrades (2018 and 2020), and three years where Zcash had no network upgrades (assuming no NU in the rest of this year).

By network age, Zcash has had an upgrade every year so far. There was one year where Zcash had 2 network upgrades, and this year will be the first with no network upgrades. It could also be argued that Sapling was part of year 1, in which case there have been two years where Zcash had 2 network upgrades, and two years where Zcash had no network upgrades.

In the past, an upgrade every 6 months was the aspiration. On paper we’ve reached that for three of the upgrades, but when you take into account that Overwinter, Blossom, and Heartwood were relatively small upgrades (and we were working on their adjacent upgrades at the same time), I think the data indicates that we’ve been closer to a yearly cadence. And the longer intervals between some upgrades make sense when you consider what was being worked on:

• Sapling development started in 2017, and took over a year of work.
• The Android SDK (and lightwalletd) was started in late 2018 (shortly after Sapling activation), and took just over a year to reach its first release.
• NU5 development started in earnest in 2020 (shortly after Heartwood activation, following on from R&D that started in 2019), and took about 1.5 - 2 years of work.
• Sandblasting mitigations have taken a bit over a year of work.
• ZSA development was funded at the beginning of 2022, so that is currently at 1.75 years of work.

So while I agree that 3 network upgrades in a single year is not supported by the evidence, 1 upgrade has been “doable” in the past (though that is conditional on resourcing, and is a harder pace to maintain over time as protocol complexity grows), and 2 upgrades in a year is I suspect the limit, both from an engineering perspective (there is only so small you can make an upgrade, and the costs around actually deploying one don’t scale down) and in terms of what network users are willing to tolerate (I remember the complaints about the short gap between Overwinter and Sapling).