Ensuring Flexibility and Sustainability of the Zcash Development Fund - Draft

Governance
1

Hello Zcash Community,

While the last few years haven’t seen the dramatic adoption we’d all hoped for, I believe ZIP GGuy offers a crucial path forward. This proposal aims to address the concerns raised by the community and charts a course for Zcash’s long-term growth and sustainability. Below, you’ll find a format proposal for ZIP GGuy, a dev fund designed to replace ZIP 1014 after the next halving.

ZIP GGuy takes a dynamic, long-term approach. It introduces a declining fund allocation schedule, a new governance body for greater community involvement, broader grant categories to address diverse needs, and provisions specifically crafted to foster decentralization and sustainability within the Zcash ecosystem.

Let’s look at the key differences between ZIP 1014 and ZIP GGuy:

Summary of differences between ZIP1014 and draft ZIP GGuy.

ZIP 1014 and ZIP GGuy propose structures for the Zcash Development Fund, but they differ in their allocations, governance, and future objectives. Here’s a summary of the key differences:

Fund Allocation and Schedule

  • ZIP 1014: Establishes a Development Fund at the first Zcash halving in 2020, allocating 20% of block subsidies into three slices: 35% for the Bootstrap Project (BP), 25% for the Zcash Foundation (ZF), and 40% for Major Grants (MG). This Dev Fund is to last for 4 years, until the second halving in 2024.
  • ZIP GGuy: Proposes a Development Fund starting at the second halving in 2024, allocating a total of 60% of block subsidies. The allocation is divided into four slices: 24% Unissued Reserve (UR), 26.6% for BP, 19% for ZF, and 30.4% for Zcash Community Grants (ZCG). The fund’s allocation is subject to a declining schedule, reducing over time to ensure sustainability.

Governance and Oversight

  • ZIP 1014: Governance relies on existing entities (ECC, ZF) and legal mechanisms, with an emphasis on decentralized governance through community input (e.g., Community Advisory Panel for ZF). Major Grants are administered by ZF with community input and scrutiny.
  • ZIP GGuy: Introduces a new community-elected governance body to oversee fund adjustments and pivotal decisions, emphasizing a flexible and responsive governance structure. This body will utilize a polling mechanism to capture community consensus, ensuring that any major amendments to the Development Fund or its policies are thoroughly vetted and aligned with the broader Zcash ecosystem’s needs and preferences before implementation.

Long-Term Sustainability and Decentralization

  • ZIP 1014: Does not explicitly address long-term sustainability after the fund’s initial 4-year term or the transition towards more decentralized governance mechanisms beyond existing structures.
  • ZIP GGuy: Emphasizes long-term sustainability through a declining schedule for Development Fund allocation and the establishment of an Unissued Reserve. It also mandates periodic reviews to explore the transition of ZCG into an independent organization, further decentralizing the ecosystem.

Additional Provisions

  • ZIP GGuy includes several new provisions not found in ZIP 1014, such as:
    • A declining schedule for Development Fund allocations to ensure long-term sustainability.
    • The establishment of an Unissued Reserve to provide flexibility for future ecosystem needs.
    • The creation of a new governance body and ZCG Committee with specified roles, responsibilities, and compensation.
    • Explicit mention of transitioning ZCG to an independent organization to promote decentralization.

In summary, while ZIP 1014 focuses on establishing a Development Fund with specific allocations and emphasizes existing governance structures, ZIP GGuy proposes a more dynamic, long-term approach with a declining fund allocation schedule, a new governance body, broader grant categories, and provisions for future decentralization and sustainability of the Zcash ecosystem.

RST Version (suitable for diffing with ZIP 1014)

Ensuring Flexibility and Sustainability of the Zcash Development Fund - Draft

ZIP:
Title: Ensuring Flexibility and Sustainability of the Zcash Development Fund
Owners: Matthew Green (@gguy)
Status: Draft
Category: Consensus Process
Created: 2024-03-04
License: MIT
Discussions-To: …
Pull-Request: …

Terminology

The key words “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “SHOULD”, and “MAY” in this document are to be interpreted as described in RFC 2119. [#RFC2119]_

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

The terms “block subsidy” and “halving” in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. [#protocol]_

“Electric Coin Company”, also called “ECC”, refers to the Zerocoin Electric Coin Company, LLC.

“Bootstrap Project”, also called “BP”, refers to the 501(c)(3) nonprofit corporation of that name.

“Zcash Foundation”, also called “ZF”, refers to the 501(c)(3) nonprofit corporation of that name.

“Section 501(c)(3)” refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). [#section501c3]_

“Community Advisory Panel” refers to the panel of community members assembled by the Zcash Foundation and described at [#zf-community]_.

The terms “Testnet” and “Mainnet” are to be interpreted as described in section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.

Abstract

This proposal describes a structure for the Zcash Development Fund, to be enacted in Network Upgrade 6 with a declining schedule for the Development Fund allocation, ensuring sustainability. This Dev Fund would total 60% of the block subsidies with gradually reduce over time, split into 4 slices:

  • 24% Unissued Reserve (denoted UR slice);
  • 26.6% for the Bootstrap Project (denoted BP slice);
  • 19% for the Zcash Foundation, for general use (denoted ZF slice);
  • 30.4% for additional “Zcash Community Grants” for large-scale long-term projects
    (denoted ZCG slice).

Subsequent blocks will see the Bootstrap Project, Zcash Foundation, and Zcash Community Grants reward decline according to the declining schedule function ( f(x) = (0.7^{(1/420769)})^x ), where (x) is the number of blocks mined since the start of this schedule. The remaining development fund will be allocated to the “Unissued Reserve” slice ensuring the Development Fund allocation always totals 60%.

Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged.

Motivation

Starting at Zcash’s second halving in November 2024, by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, no substantial new funding may be available to existing teams dedicated to furthering charitable, educational, or scientific purposes, such as research, development, and outreach: the Electric Coin Company (ECC), the Zcash Foundation (ZF), and the many entities funded by the ZF grant program.

There is a need to strike a balance between incentivizing the security of the consensus protocol (i.e., mining) versus crucial charitable, educational, and/or scientific aspects, such as research, development, outreach, and the future funding needs of the network.

Furthermore, there is a need to balance the sustenance of ongoing work by the current teams dedicated to Zcash, with encouraging decentralization and growth of independent development teams.

For these reasons, the Zcash Community desires to allocate and contribute a slice of the block subsidies otherwise allocated to miners as a donation to support charitable, educational, and scientific activities within the meaning of Section 501(c)(3).

Requirements

The Dev Fund should encourage decentralization of the work and funding, by supporting new teams dedicated to Zcash. The Zcash Community should implement a continuous governance and fund adjustment mechanism, introducing a flexible governance structure for adapting the Development Fund allocation based on the ecosystem’s evolving needs. There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.

The Dev Fund should maintain the existing teams and capabilities in the Zcash ecosystem, unless and until concrete opportunities arise to create even greater value for the Zcash ecosystem.

There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.

Major funding decisions should be based, to the extent feasible, on inputs from domain experts and pertinent stakeholders.

The Dev Fund mechanism should not modify the monetary emission curve (and in particular, should not irrevocably burn coins).

In case the value of ZEC jumps, the Dev Fund recipients should not wastefully use excessive amounts of funds. Conversely, given market volatility and eventual halvings, it is desirable to create rainy-day reserves.

The Dev Fund mechanism should not reduce users’ financial privacy or security. In particular, it should not cause them to expose their coin holdings, nor cause them to maintain access to secret keys for much longer than they would otherwise. (This rules out some forms of voting, and of disbursing coins to past/future miners.)

The new Dev Fund system should be simple to understand and realistic to implement. In particular, it should not assume the creation of new mechanisms (e.g., election systems) or entities (for governance or development) for its execution; but it should strive to support and use these once they are built.

Comply with legal, regulatory, and taxation constraints in pertinent jurisdictions.

Non-requirements

General on-chain governance is outside the scope of this proposal.

Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or one-person-one-vote) are outside the scope of this proposal, though there is prescribed room for integrating them once available.

New Governance Body

Following the second halving, the Zcash-Ecosystem is committed to establishing a new community-elected governance body. This entity will be tasked with overseeing adjustments to the fund and making pivotal governance decisions. To foster heightened accountability and transparency, the governance body will oversee both the deployment of the Development Fund and any future policy adjustments. Furthermore, to ensure responsible use of funds, the Development Fund will follow a declining schedule for allocations, naturally reducing funding over time and encouraging efficient and judicious use by recipients. For any additional funding requests beyond this schedule, recipients must propose a Dev Fund amendment to the new governing body. Significantly, this governing body will employ a polling mechanism to capture community consensus, ensuring that major amendments to the fund or policies are ratified in alignment with the ecosystem’s evolving needs and priorities. This approach ensures a dynamic and responsive funding model that is deeply rooted in community input and consensus.

Specification

Consensus changes implied by this specification are applicable to the Zcash Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be applied to the Zcash Testnet for testing purposes.

Dev Fund allocation

Starting at the second Zcash halving in 2024, the Dev Fund SHALL be allocated as follows:

  • 24% Unissued Reserve (denoted UR slice);
  • 26.6% for the Bootstrap Project (denoted BP slice);
  • 19% for the Zcash Foundation, for general use (denoted ZF slice);
  • 30.4% for additional “Major Grants” for large-scale long-term projects
    (denoted ZCG slice).

Subsequent blocks will see the Bootstrap Project, Zcash Foundation, and Zcash Community Grants reward decline according to the declining schedule function ( f(x) = (0.7^{(1/420769)})^x ), where (x) is the number of blocks mined since the start of this schedule. The remaining development fund will be allocated to the “Unissued Reserve” slice ensuring the Development Fund allocation always totals 60%.

The slices are described in more detail below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address(es) for each block. This Dev Fund will extend indefinitly (unless extended/modified by a future ZIP).

UR slice (Unissued Reserve)

The Unissued Reserve (UR) slice represents a portion of the Development Fund that is not immediately allocated to any specific entity or project. Instead, it serves as a strategic reserve to provide flexibility and ensure the long-term sustainability of the Zcash ecosystem. The UR slice can be deployed in the future for unforeseen circumstances, additional funding opportunities, or to support the ecosystem in the event of economic downturns or declines in the market price of ZEC.

The management and use of the UR slice will be determined through community governance processes and the oversight of a designated committee or equivalent body. This committee will be responsible for proposing and gathering community concensus regarding the allocation of the UR slice based on the strategic needs of the Zcash ecosystem. The committee’s decisions must align with the overall mission of supporting financial privacy and the Zcash platform, and they must comply with the legal and regulatory requirements applicable to the Zcash Development Fund.

The UR slice will be reserved in a transparent and accountable manner, with regular reporting on its status and any allocations made from it. The goal is to ensure that the UR slice is a reliable and effective tool for the long-term resilience and prosperity of the Zcash ecosystem.

BP slice (Bootstrap Project)

This slice of the Dev Fund will flow as charitable contributions from the Zcash Community to the Bootstrap Project, the newly formed parent organization to the Electric Coin Company. The Bootstrap Project is organized for exempt educational, charitable, and scientific purposes in compliance with Section 501(c)(3), including but not limited to furthering education, information, resources, advocacy, support, community, and research relating to cryptocurrency and privacy, including Zcash. This slice will be used at the discretion of the Bootstrap Project for any purpose within its mandate to support financial privacy and the Zcash platform as permitted under Section 501(c)(3). The BP slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.

ZF slice (Zcash Foundation’s general use)

This slice of the Dev Fund will flow as charitable contributions from the Zcash Community to ZF, to be used at its discretion for any purpose within its mandate to support financial privacy and the Zcash platform, including: development, education, supporting community communication online and via events, gathering community sentiment, and awarding external grants for all of the above, subject to the requirements of Section 501(c)(3). The ZF slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.

Zcash Community Grants (ZCG)

This slice of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) that benefits the public good within the Zcash ecosystem, to the extent that such teams are available and effective. The Zcash Community Grants (ZCG) Committee is given the discretion to allocate funds not only to major grants, but also to a diverse range of projects that advance the usability, security, privacy, and adoption of Zcash, including community programs, dedicated resources, and other projects of varying sizes.

The funds SHALL be received and administered by ZF. ZF MUST disburse them for “Major Grants” and expenses reasonably related to the administration of Major Grants, but subject to the following additional constraints:

  1. These funds MUST primarily be used to issue Major Grants to external parties that are independent of ZF. They can also be used to fund other initiatives such as community support personnel and public goods projects that benefit Zcash, and to pay for expenses reasonably related to the administration of Major Grants. They MUST NOT be used by ZF for its internal operations and direct expenses not related to administration of Major Grants. Additionally, BP, ECC, and ZF are ineligible to receive Major Grants.

  2. Major Grants SHOULD support well-specified work proposed by the grantee, at reasonable market-rate costs. They can be of any duration or ongoing without a duration limit. Grants of indefinite duration SHOULD have semiannual review points for continuation of funding.

  3. Priority SHOULD be given to Major Grants that bolster teams with substantial (current or prospective) continual existence, and set them up for long-term success, subject to the usual grant award considerations (impact, ability, risks, team, cost-effectiveness, etc.). Priority SHOULD be given to Major Grants that support ecosystem growth, for example through mentorship, coaching, technical resources, creating entrepreneurial opportunities, etc. If one proposal substantially duplicates another’s plans, priority SHOULD be given to the originator of the plans.

  4. Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general) as permitted under Section 501(c)(3).

  5. Major Grants awards are subject to approval by a five-seat Major Grant Review Committee. The Major Grant Review Committee SHALL be selected by the ZF’s Community Advisory Panel or successor process. Elections SHALL be staggered to ensure continuity within the Committee.

  6. The Major Grant Review Committee’s funding decisions will be final, requiring no approval from the ZF Board, but are subject to veto if the Foundation judges them to violate U.S. law or the ZF’s reporting requirements and other (current or future) obligations under U.S. IRS 501(c)(3).

  7. Major Grant Review Committee members SHALL have a one-year term and MAY sit for reelection. The Major Grant Review Committee is subject to the same conflict of interest policy that governs the ZF Board of Directors (i.e. they MUST recuse themselves when voting on proposals where they have a financial interest). At most one person with association with the BP/ECC, and at most one person with association with the ZF, are allowed to sit on the Major Grant Review Committee. “Association” here means: having a financial interest, full-time employment, being an officer, being a director, or having an immediate family relationship with any of the above. The ZF SHALL continue to operate the Community Advisory Panel and SHOULD work toward making it more representative and independent (more on that below).

    Major Grant Review Committee members are expected to work approximately 35 hours per month and will be compensated accordingly from the Major Grants budget. The total compensation for the committee, paid from the Major Grants budget, should be equivalent to a full-time position.

  8. From 1st January 2022, a portion of the ZCG Slice shall be allocated to a Discretionary Budget, which may be disbursed for expenses reasonably related to the administration of Major Grants. The amount of funds allocated to the Discretionary Budget SHALL be decided by the ZF’s Community Advisory Panel or successor process. Any disbursement of funds from the Discretionary Budget MUST be approved by the Major Grant Review Committee. Expenses related to the administration of Major Grants include, without limitation the following:

    • Paying third party vendors for services related to domain name registration, or the design, website hosting and administration of websites for the Major Grant Review Committee.
    • Paying independent consultants to develop requests for proposals that align with the Major Grants program.
    • Paying independent consultants for expert review of grant applications.
    • Paying for sales and marketing services to promote the Major Grants program.
    • Paying third party consultants to undertake activities that support the purpose of the Major Grants program.
    • Reimbursement to members of the Major Grant Review Committee for reasonable travel expenses, including transportation, hotel and meals allowance.

  9. A portion of the Discretionary Budget MAY be allocated to provide reasonable compensation to members of the ZCG Committee. Committee member compensation SHALL be limited to the hours needed to successfully perform their positions and MUST align with the scope and responsibilities of their roles. The allocation and distribution of compensation to committee members SHALL be administered by the ZF. The compensation rate and hours for committee members SHALL be determined by the ZF’s Community Advisory Panel or successor process.

  10. The Major Grant Review Committee’s decisions relating to the allocation and disbursement of funds from the Discretionary Budget will be final, requiring no approval from the ZF Board, but are subject to veto if the Foundation judges them to violate U.S. law or the ZF’s reporting requirements and other (current or future) obligations under U.S. IRS 501(c)(3).

ZF SHALL recognize the ZCG slice of the Dev Fund as a Restricted Fund donation under the above constraints (suitably formalized), and keep separate accounting of its balance and usage under its Transparency and Accountability_ obligations defined below.

ZF SHALL strive to define target metrics and key performance indicators, and the Major Grant Review Committee SHOULD utilize these in its funding decisions.

Direct-grant option

It may be deemed better, operationally or legally, if the Major Grant funds are not accepted and disbursed by ZF, but rather directly assigned to the grantees. Thus, the following mechanism MAY be used in perpetuity for some or all grantees, if agreed upon by both ECC and ZF before Network Upgrade 4 (Canopy) activation:

Prior to each network upgrade, based on the ZCG Committee’s recommendation, the Foundation SHALL publish a list of grantees’ addresses and the total number of Dev Fund ZEC per block they should receive. ECC and ZF SHALL implement this list in any implementations of the Zcash consensus rules they maintain. This decision will then be, effectively, ratified by the miners as the network upgrade activates.

Furthering Zcash Decentralization

BP/ECC and ZF SHALL conduct periodic (e.g. semiannual or annual) reviews of the organizational structure, performance, and effectiveness of the ZCG program and committee, taking into consideration the input and recommendations of the ZCG Committee. As part of these periodic reviews, ECC and ZF MUST commit to exploring the possibility of transitioning ZCG into an independent organization if it is economically viable and it aligns with the interests of the Zcash ecosystem and prevailing community sentiment.

In any transition toward independence, priority SHALL be given to maintaining or enhancing the decentralization of the Zcash ecosystem. The newly formed independent organization MUST ensure that decision-making processes remain community-driven, transparent, and responsive to the evolving needs of the Zcash community and ecosystem. In order to promote geographic decentralization, the new organization SHOULD establish its domicile outside of the United States.

Transparency and Accountability

Obligations

BP, ECC, ZF, and Major Grant recipients (during and leading to their award period) SHALL all accept the obligations in this section.

Ongoing public reporting requirements:

  • Quarterly reports, detailing future plans, execution on previous plans, and finances (balances, and spending broken down by major categories).
  • Monthly developer calls, or a brief report, on recent and forthcoming tasks. (Developer calls may be shared.)
  • Annual detailed review of the organization performance and future plans.
  • Annual financial report (IRS Form 990, or substantially similar information).

These reports may be either organization-wide, or restricted to the income, expenses, and work associated with the receipt of Dev Fund. As BP is the parent organization of ECC it is expected they may publish joint reports.

It is expected that ECC, ZF, and Major Grant recipients will be focused primarily (in their attention and resources) on Zcash. Thus, they MUST promptly disclose:

  • Any major activity they perform (even if not supported by the Dev Fund) that is not in the interest of the general Zcash ecosystem.
  • Any conflict of interest with the general success of the Zcash ecosystem.

BP, ECC, ZF, and grant recipients MUST promptly disclose any security or privacy risks that may affect users of Zcash (by responsible disclosure under confidence to the pertinent developers, where applicable).

BP’s reports, ECC’s reports, and ZF’s annual report on its non-grant operations, SHOULD be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.

All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative [#osd]_), preferably the MIT license.

Enforcement

For grant recipients, these conditions SHOULD be included in their contract with ZF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to ZF.

BP, ECC, and ZF MUST contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other party to issue a modified version of Zcash node software that removes the violating party’s Dev Fund slice, and use the Zcash trademark for this modified version. The slice’s funds will be reassigned to ZCG (whose integrity is legally protected by the Restricted Fund treatment).

ZF Board Composition

Members of ZF’s Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC, except as provided for by the grace period described below.

Grace period: members of the ZF board who hold ECC equity (but do not have other current relationships to ECC) may dispose of their equity, or quit the Board, by 1 November 2021. (The grace period is to allow for orderly replacement, and also to allow time for ECC corporate reorganization related to Dev Fund receipt, which may affect how disposition of equity would be executed.)

The Zcash Foundation SHOULD endeavor to use the Community Advisory Panel (or successor mechanism) as advisory input for future board elections.

Acknowledgements

This proposal is a modification of Zooko Wilcox and Andrew Miller’s ZIP 1014 [#zip-1012]_ with feedback from the community.

The authors are grateful to all of the above for their excellent ideas and any insightful discussions.

… _Zcash Community Forum: https://forum.zcashcommunity.com/

References

… [#RFC2119] RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>_
… [#protocol] Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>_
… [#protocol-networks] Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>_
… [#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>_
… [#osd] The Open Source Definition <https://opensource.org/osd>_
… [#zip-0200] ZIP 200: Network Upgrade Mechanism <zip-0200.rst>_
… [#zip-1014] ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>_
… [#zf-community] ZF Community Advisory Panel <https://www.zfnd.org/governance/community-advisory-panel/>_
… [#section501c3] U.S. Code, Title 26, Section 501(c)(3) <https://www.law.cornell.edu/uscode/text/26/501>_

6 Likes
3

(Wearing my ZIP editor hat, and not an ECC or zcashd maintainer hat.)

Process note: ZIP Editors are responsible for assigning ZIP numbers, not ZIP owners. Per the ZIP Workflow section of ZIP 0:

Owners MUST NOT self-assign ZIP numbers

Please remove all references to “ZIP 1015” from this draft ZIP. (The ZIP Editors will assign a ZIP number in due course, per the ZIP Workflow, assuming that the ensuing discussion results in a draft that makes sense as a standalone ZIP and not an amendment to an existing ZIP.)

A declining schedule function as specified here introduces deployment timeline risk, due to zcashd being deprecated.

The current Funding Stream implementation in zcashd has four parameters: numerator, denominator, startHeight, and endHeight. The per-block output for a given Funding Stream is then computed as (informally, refer to the protocol spec for more formal details) (blockSubsidy * numerator) / denominator for every block in the interval [startHeight, endHeight). This is straightforward, well-tested, and easy to update with new parameters (as was intended to enable e.g. adding direct-grant options in a straight-forward way per ZIP 1014).

Changing this to a non-linear function, particularly one involving the pow operator on floating-point numbers, means that the existing implementation cannot be reused, and adds complexity to the consensus rule specification and implementation (particularly around how floating-point operations are evaluated and edge cases handled, which the current draft ZIP does not specify, and which need to be completely unambiguous to ensure consensus compatibility). While these issues can potentially be addressed, it eats into the complexity budget of NU6 (competing with other changes that might be desirable), and may or may not be considered a “major” change to the zcashd consensus rule implementation[1] which could mean zcashd does not have an implementation of the changes for NU6.

As an alternative, the non-linear function could be coarsely emulated as a sequence of step functions. The implementation of Funding Streams in zcashd is entirely compatible with defining several shorter [startHeight, endHeight) ranges with progressively-decreasing numerator/denominator ratios[2], each of which continues to have a well-defined output. At some height where the ratio of “Unissued Reserve” to “Development Fund” becomes very close to 1, the ZIP could then define a single open-ended Funding Stream range covering the remaining “indefinite” period.

[1] ECC have previously said they will make no major consensus rule changes to zcashd and are instead focusing their zcashd work towards its deprecation, in particular for it to be out of the way before ZSAs being deployed in a network upgrade.
[2] In the limit endHeight = startHeight + 1, this would directly encode the output of the non-linear function (after working out the floating-point issues), but it would be somewhat impractical to encode 4,292,240,896 Funding Streams (2^32 - 2726400) in consensus logic.

4 Likes
4

Isn’t this desirable?

There should be no reason for zcashd to exist under NU6 (?)

Or will the deprecation of zcashd span far beyond only the end of the NU5 epoch (?)

It feels wasteful to be engineering (catering?) around zcashd within NU6 implementation, even though zcashd has long been planned for deprecation.

4 Likes
5

(Wearing my zcashd maintainer hat)

For those who have not been following Arborist calls, the current thinking is for NU6 to be a smaller network upgrade that only contains things that are reasonable for us to get into zcashd while focusing on its deprecation, and for ZSAs (which are definitely not reasonable to get into zcashd) to be deployed in NU7. This makes it feasible for NU6 to occur this year.

If ZSAs (or other major changes) were included in NU6 then there would be no network upgrade this year (as we expect it will take the entire year to deprecate zcashd, including implementing and deploying the necessary replacement for zcashd’s wallet and migrating everyone off it), delaying consensus changes like explicit fee fields in transactions (solving a long-standing UX issue), or potentially altering how memos are encoded in transactions (which is required for Authenticated Reply Addresses due to the size of Orchard-related proofs).

8 Likes
6

How many funding streams is too many? Would you hate me if I wanted those steps to happen monthly for each recipient? I’m trying to remove any cognitive biases that would funnel people to request changes at around the same time by making the steps too long. Also are you suggesting it’s still okay to actively calculate the steps using the declining function and produce a “Funding Stream” for each step? I’m happy to amend my proposal to do the following just need some nudges if what I’ve done is on the right track.

import numpy as np

# Declining schedule function
def declining_schedule(x):
    return (0.7**(1/420769))**x

# Number of blocks per month
blocks_per_month = 35064

# Calculate the mean declining function amount for each month for the next 4 years (48 months)
mean_declining_amounts = []
for month in range(1, 49):  # From month 1 to month 48
    # Calculate the start and end block for the month
    start_block = blocks_per_month * (month - 1)
    end_block = blocks_per_month * month
    
    # Calculate the mean declining amount for the month
    month_blocks = np.arange(start_block, end_block)
    month_amounts = declining_schedule(month_blocks)
    mean_amount = np.mean(month_amounts)
    
    mean_declining_amounts.append(mean_amount)

mean_declining_amounts

Result:[0.9852851505046214, 0.9564306198628304, 0.9284211074760405, 0.9012318665944211, 0.8748388751881377, 0.8492188147235933, 0.8243490495612164, 0.8002076069565927, 0.7767731576472756, 0.7540249970081198, 0.7319430267584879, 0.7105077372051731, 0.6897001900053433, 0.6695020014342827, 0.649895326143143, 0.630862841392358, 0.6123877317467897, 0.5944536742190835, 0.5770448238481073, 0.5601457996997331, 0.543741671277592, 0.5278179453317962, 0.5123605530539735, 0.49735583764730246, 0.4827905422605632, 0.46865179827554576, 0.4549271139374671, 0.44160436331835223, 0.4286717756036262, 0.4161179246924552, 0.40393171910264447, 0.39210239217117776, 0.38061949254173727, 0.3694728749308013, 0.3586526911641615, 0.3481493814759388, 0.33795366606241306, 0.32805653688320113, 0.31844924970254274, 0.30912331636365986, 0.3000704972893654, 0.29128279420229564, 0.2827524430583329, 0.2744719071869769, 0.2664338706326035, 0.2586312316907276, 0.25105709663355946, 0.24370477361931125]
1 Like
7

I have no substantive comment yet, and I’m no longer a ZIP Editor, but note that the “Original-Authors” field is being used here in a way that was not intended. I would recommend that it be removed. While Andrew Miller and Zooko Wilcox indeed wrote much of and are the current Owners of ZIP 1014, they were never authors of this draft ZIP. The following acknowledgement is sufficient:

This proposal is a modification of Zooko Wilcox and Andrew Miller’s ZIP 1014 [#zip-1012]_ with feedback from the community.

5 Likes
8

I think it’s important to ensure funds are used for core blockchain development and not blank check unissued funds → 100% should be held for zcash blockchain development for projects such as POS, ZSA, Stabelcoins, Programmability, etc… My preference is to not add any more organizations;
but to remove consensus as a governance tool and move to coin weighted voting
to make existing orgs governance better. ZCG needs a tighter mandate. they went too far outside the scope of zcash development in the past. they need better controls to ensure money is not wasted as well. More accountability and make it easier to remove orgs who do not show money is spent wisely.

No increase in zec issuance above that under existing halving schedule.

4 Likes
9

60% block reward after or around the same time as the halving, with Proof of Stake still off in the distance somewhere… this pretty much gives miners no incentive to continue mining Zcash.

13 Likes
10

Monthly seems reasonable. A quick local calculation (likely containing bugs) using the current draft, your draft Python code, and no ZSF changes, indicates that for the currently-specified slices, after around 300-320 monthly funding streams the output value per block would be smaller than the dust limit of 54 zatoshis (and thus defined as negligible under current network rules). It takes 390-410 months until the output value per block reaches 0 zatoshi; for that tail-end window it would make more sense to just stretch the last just-above-dust-limit Funding Stream to be longer than a month (i.e. flat, not non-linear) until it emits the same amount of ZEC as would be emitted under the non-linear tail. So that’s a bit under 1000 Funding Stream definitions, which is still a large amount, but one that is much more readily encodable in consensus rules with the current implementation logic.

That’s one way of approaching it. You might also want to look at ZIP 234: Block Issuance Smoothing (which your draft ZIP may also need to analyse and account for): it uses a sequential multiplication approach (by a BLOCK_SUBSIDY_FRACTION constant) to approximate an exponential decay function, with a simulation that checks the discrepancy between the decay function and the approximation. You’d still want to define a sequence of Funding Streams for the easiest integration, but they would be easier to check.

In any case, each Funding Stream needs a (numerator, denominator) tuple, rather than a decimal multiplier.

5 Likes
11

don’t know who came up with the idea to raise the dev fund to 60%, but doing that will not only result in another large fud campaign against zcash, but also a decrease in security! what should be tell the miners?

“hey sorry, we are moving to POS in the future, but in the meantime we want to take more than half of the block rewards away from you, but please keep on mining and securing the network for us”

this is important too, if we are going to give more money to the 3 orgs, this should be talked about in advance. even on social media this topic is used against us now! i can understand these arguments myself, it looks pretty sad to see leaders like @Dodger not having enough confidence in Zcash to not change the coins for BTC and ETH in the future. we should keep in mind that the picture we are framing here doesn’t look good for new people looking to join our community, it even gives longtime community members and holders of ZEC a hard time.

9 Likes
12

this is the way to go, let’s hope we get there one day!

3 Likes
13

Hi GGuy! Thanks for putting this together.

Read through the draft with my “community developer hat” (if there’s such thing). I think that the long term and accounting for the unforeseeable future approach is very welcome. This “we don’t know what’s going to happen next” situation is very detrimental to the sustainability of the ecosystem and it’s the main thing that needs to be fixed first. I also noticed a few things that I’ve read from many community members (and internet trolls as well :heart:) throughout the years and I feel they are not present or not sufficiently addressed, and others seem addressed with overly excessive measures.

Disclaimer: I think this is a great step forward. Please don’t take these remarks as something bad or a harsh critic. they are not! I’m conscious that we’ve may have heard or read some these arguments in heated discussions and on hurtful terms so might internally take them with some bitterness. Please don’t.

On Zcash funding and it’s relationship with community’s confidence
I believe the community’s most important claim is about how ZIP-1014 failed to provide accountability and incentives to recipients to perform more efficiently which many community members though it lead to stagnation and wrong assessment of the ecosystem’s needs, risks, weaknesses and strengths, not only making Zcash less effective and strong but also fostering the growth of many potential “Zcash killer” neighboring projects.

Many things we all know happened and the confidence of Zcash’s community on its leadership plummeted along with the coin price. How will this ZIP contribute to avoid these problems of the past and help rebuild confidence on ZEC from both community members, Zodlers and potential partners in the midst of the rise of many competitors no matter how friendly they seem? (Namada, Firo, Aleo, Penumbra, Secret, etc).

Beware of Uncle Ben Parker’s principle: More ZEC pie, more responsibilities

Seems to me that small grant recipients are still under greater scrutiny than the big chunk recipients (BP and ZF). Even thought the proposed text attempts to put everyone under the same duties, they are proportionally not. Historically grant recipients have been under more scrutiny than direct recipients. This dynamic is something worth discussing.

Community grants recipients not meeting their milestones get their funding cut off, end of story. It’s actionable by ZCG and a common practice among all grant committees across crypto and non-crypto projects. That’s seems fair play.

Also, confidence earned has to worth something. Orgs becoming direct recipients, supposes they’ve been in a permanent long relationship with the ecosystem, and there’s community sentiment that they should be given the confidence and the responsibility of becoming a big actor in it. Treating a direct recipient as a small grantee and shutting it doing fair and square does not seem right neither smart for the ecosystem itself (maybe some extreme situations could require so)

Also we need to consider that these organizations might change over time. For better or for worse. A walk of life. What if a direct recipient enters a decay cicle in its performance and consistently misses their proposed goals, how that would affect their share of the Zec pie? Some of this is implied by the following section but since the body of governance has not been defined, it may never be addressed.

Also the governance body should be put in place upon a certain deadline. What happens if it’s never constituted?

Better and safer mechanisms of conflict resolution

Then this section conflicts with the body of governance statement above.

Seems quite nuclear to me. Two orgs can collude into forking the chain and cancelling the third one. These two colluding actors could hijack the whole ecosystem. It seems to me that they have more power than the governance body that it’s supposed to control them.

5 Likes
14

Maybe no development team should get a direct slice. A organizational governance body gets the direct slice; and then it should be the one that contracts with a development team. The governance body then can allocate the funding to the development team (or teams) based on skill sets required, funding, performance much the same as it works with grants. We need to avoid duplication of corporate overhead and make sure as much money gets to skillful and qualified developers as possible. That is the flow of funds goes to the governance body first and then the team gets funding from the governance body. If the development team is not acting in good faith or otherwise performing as expected, the organizational body can simply replace the development team. This approach does not require any modifications to node software; but does require more transparent and well thought out governance. Moreover, this makes the existing orgs more flexible with clear cut roles to ensure development is focused on the blockchain and projects directly related to Zcash development (as opposed to non development and non Zcash blockchain projects). ZCG slice is way to high based on historical performance. We should start with fixing governance before making these fairly major changes.

2 Likes
15

i like that idea, but WHO will be the governance body that allocates these funds?

also, we do not have a safe system in place to vote for those leaders, the only option i can think of would be coin voting.

1 Like
16

There is really no better, or more fair, or more objective way to govern other than allowing the constituents use their coins to vote. Otherwise we end up with what we have now which I believe is much worse than the risk of being captured by large coin holders. In fact, its more likely we are captured by grant recipients who might not have the same interests in the Zcash blockchain development as ZEC holders. With that, I have been persuaded that people who use ZEC might not hold a balance and its a compelling argument up to a point. I’m not convinced that traders who are going in and out of ZEC for trading purposes should be considered. So, the most logical way is for coin weighted voting. Some ideas

  1. Something akin to the Zenate. It’s sole purpose is to act as a fiduciary for ZEC holders and Zcash. It would be a board of highly qualified technical people and those who have a deep understanding of TradeFi and DeFi.

Ideally, this entity could a) be the one that has some authority to cut funding for both the Foundation and Bootstrap if its determined they are spending on non Zcash projects or funding teams that are not completing projects or funding duplicative projects. b) ensure the entities are not using funds to invest into other projects (maybe when Zcash is much further along in its own development) c) act as a treasury to take the burden off the exsting orgs re hedging as they both seem to be using different hedging strategies and d) have some excess funding to ensure critical development projects are fully funded. EG it would be great if we had an entity that had control of the excess assets and could hire more engineers to deprecate old code and speed up ZSAs and/or other projects. It seems that each entity on its own starts to act like a fiefdom which is bad for development. We should be cutting back to almost $0 for marketing, videos, education and reallocating money to core engineering to speed up NU5/NU6. But we dont have the mechanism today.

  1. Also, we could have smaller boards associated that oversee each org. And then these boards/org hire the team. I think that is the way its supposed to work currently. Currently it looks like the boards and development is intertwined and hard to tell how it works…But it seems people dont like reporting to a board which is why they want their own org…

Just a few ideas. But governance and core blockchain development is more important to me rather than figuring out how to take away from miners or reallocate money to ZCG.

17

sliceAllocation
sliceAllocation2314×1409 118 KB

This figure shows the allocation changes for the next 2 years without any modifications.

Addressing Governance, Competition, and Accountability

This ZIP focuses on revitalizing Zcash’s development and regaining community trust by ensuring the dev fund allocation is regularly reviewed and modified based on performance and outcomes. Here’s how it attempts to do that:

1. Performance-Based Incentives

  • Price as Metric: A steady or increasing ZEC price is crucial. A 30% annual increase offsets the declining funding schedule, incentivizing focus on value creation.
  • Accountability: The declining schedule forces recipients to deliver strong results to justify further funding. Transparency, clear roadmaps, and past performance will be essential when requesting future allocations.

2. Fostering Competition and Efficiency

  • Open Opportunities: The unallocated funding pool (UR) encourages new players (like QEDIT or other partners) to propose innovative projects, increasing competition and potentially leading to more efficient use of funds.
  • Adaptability: Organizations must continuously demonstrate their value to the Zcash ecosystem. If an organization underperforms, their funding could be reduced or reallocated to more promising initiatives.

3. Incentivizing Detailed Proposals

  • Accountability for Results: Organizations can no longer rely on guaranteed funding. To secure resources, they must continuously prove their value with detailed business plans and roadmaps that demonstrate both potential impact and the ability to execute.
  • Competition for Resources: The UR creates a competitive environment where organizations must present strong, well-defined proposals to stand out. This means clear goals, achievable milestones, and realistic budgets.
  • Community Input: This ZIP sets the stage for a community-driven governing body to oversee the UR, likely prioritizing proposals with the strongest business cases and clearest paths to success.
  • Transparency as Necessity: Open communication of plans, achievements, and resource allocation builds trust and allows for informed community assessments.
  • Flexibility for Increased Funding: Recipients can apply to increase their funding at any time to offset the declining schedule. This application process will require a strong justification, likely including updated business plans, roadmaps, and performance metrics demonstrating a compelling need for additional resources.

4. Key Points

  • This ZIP doesn’t directly establish a governance body, but it creates a strong incentive for one to emerge to guide the UR’s allocation.
  • To ensure success, clear metrics for success and a transparent process for evaluating proposals are needed.

In Summary: This system aims to break the stagnation hindering Zcash. It promotes a competitive, results-oriented environment, ensuring development funding is used effectively to drive growth, innovation, and the ongoing success of Zcash.

@pacu Thanks for your feedback! Does this post address some of the concerns? I will attempt to adjust the wording around the governing body but any suggestions that make this ZIP clearer are appreciated. Regarding performance and differences between a ZCG style milestone based funding mechanism and a block reward allocation I’d say there are pros and cons to both approaches, but I think it’s clear block reward recipients have been held less accountable in the past and this ZIP tries to address this.

1 Like
18

it’s going in the right direction; but UR should not be considered unless it’s tied to coin weighted voting (for the board who get voted in annually, not project voting). and very strong board governance and well defined over site responsibilities. Protect ZEC holders / ecosystem from wasteful spending and ensure blockchain development. We should be mainly an engineering development focus in my opinion. Blank check funding is a problem. so i would suggest a well thought out governance structure and mission rather than undefined UR. UR allocates money to the other orgs, and holds excess funding (they dont fund teams directly).

i don’t like the declining curve as much as real time governance that has the power to change allocations immediately if warranted under predefined circumstances or quarterly/annually otherwise.

Allocations seem off. But that would be up to the boards and more of a group effort between the orgs depending on their respective projects.

1 Like
19

Regarding your comments, I wholeheartedly agree with the following:

  • Combining funding approaches: A hybrid strategy of a declining funding curve along with real-time governance offers the best of both worlds. The decline incentivizes innovation and accountability, while real-time governance allows necessary flexibility for immediate adjustments.
  • Conditioning Universal Recipient status: The UR concept is powerful, but it absolutely must be tied to robust oversight and governance. A model like the Zcash Small Council (ZSC) and Zcash People’s Parliament (ZPP) could be instrumental in ensuring sound UR management. This oversight would protect ZEC holders and promote focused blockchain development.
  • Dynamic allocations: The initial allocation percentages will undoubtedly require adjustment. This ZIP aims to create a system where effective funding reallocation happens quickly. Success hinges on constantly evaluating performance – underperformers see reduced support, while those excelling could receive increased funding.

Additionally, I fully support the implementation of coin-weighted voting for critical governance decisions. This mechanism would further align funding allocation with the interests of ZEC holders. Previously this hasn’t been included in my proposals due to the lack of mechanism to provide coin weighted voting, but that feature is now in sight I believe it should play a pivotal role in decision making.

1 Like
20

The most critical decision is the election of the governance board. Especially to make it completely independent from grant recipients and acts fiduciary to ZEC and Zcash blockchain. To make sure the idea of privacy is not funded so far removed from the Zcash blockchain. We need to attract highly qualified blockchain experts who really understand DeFi.

21

Not speaking for ECC, only for myself as a ZEC holder and protocol security analyst (but acknowledging the potential conflict of interest in being ECC’s R&D Engineering manager):

An initial 60% dev fund fraction seems way too high. The per-block miner subsidy is currently 2.5 ZEC. Under the current consensus rules with no dev fund extension, it would change to 1.5625 ZEC after the halving expected in November 2024. Under a 20% dev fund extension it would change to 1.25 ZEC, but under @GGuy’s proposal it would change to 0.625 ZEC.

Since honest hash rate is very roughly proportional to miner subsidy all else being equal (coin price, electricity price, etc.), this could potentially result in a precipitous 75% drop in hash rate from honest miners, while adversaries still have access to the same hashing power. I am concerned by the potential consequences for mining security while Zcash is still using Proof-of-Work, and also by lack of sufficient funds available from issuance for staking rewards if Zcash moves to PoS or a PoW/PoS hybrid.

16 Likes