Specifications and Zcash Improvement Proposals for the Zcash cryptocurrency.
Participation in the Zcash project is subject to a Code of Conduct.
+The ZIP process is documented in ZIP 0.
This is the list of ZIPs that were under consideration for the NU3 upgrade (around ~April 2020).
@@ -80,6 +81,19 @@ZIP: 0 Title: ZIP Process Owners: Daira Hopwood <daira@electriccoin.co> - Josh Cincinnati <josh@zfnd.org> + George Tankersley <george@zfnd.org> +Original-Authors: Daira Hopwood <daira@electriccoin.co> + Josh Cincinnati <josh@zfnd.org> Credits: Luke Dashjr Status: Active Category: Process @@ -268,7 +270,7 @@ Updates:
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
-"Jubjub" refers to the elliptic curve defined in 8 section 5.4.8.3.
+"Jubjub" refers to the elliptic curve defined in 12.
The following algorithm standardized in 10 is used:
+The following algorithm standardized in 16 is used:
Let 𝓖 be as defined in 8 section 5.4.6.1 and let 𝓗 be as defined in 9.
+Let 𝓖 be as defined in 11 and let 𝓗 be as defined in 9.
CDKfvk((akpar, nkpar, ovkpar, dkpar, cpar), i) → (aki, nki, ovki, dki, ci)
Let EncodeASK(ask) be the 32-byte encoding of ask in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in 8 section 5.6.8.
+Let EncodeASK(ask) be the 32-byte encoding of ask in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in 15.
Let DecodeASK(ASK) be the result of clearing the 4 most significant bits of the first byte of ASK, and decoding the 32-byte result according to the inverse of EncodeASK.
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding FVK (as specified in 8 section 5.6.7) is given by:
+A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding FVK (as specified in 14) is given by:
@@ -255,7 +255,7 @@ License: MITBLAKE2b-256("ZcashSaplingFVFP", FVK)
A "Sprout address fingerprint" of a Sprout payment address with raw encoding ADDR (as specified in 8 section 5.6.3, including the lead bytes) is given by:
+A "Sprout address fingerprint" of a Sprout payment address with raw encoding ADDR (as specified in 13, including the lead bytes) is given by:
@@ -378,7 +378,7 @@ License: MITBLAKE2b-256("Zcash_Sprout_AFP", ADDR)
| 10 | +Zcash Protocol Specification, Section 5.4.1.6 DiversifyHash Hash Function | +
|---|
| 11 | +Zcash Protocol Specification, Section 5.4.6.1 Spend Authorization Signature | +
|---|
| 12 | +Zcash Protocol Specification, Section 5.4.8.3 Jubjub | +
|---|
| 13 | +Zcash Protocol Specification, Section 5.6.3 Sprout Shielded Payment Addresses | +
|---|
| 14 | +Zcash Protocol Specification, Section 5.6.7 Sapling Full Viewing Keys | +
|---|
| 15 | +Zcash Protocol Specification, Section 5.6.8 Sprout Spending Keys |
|---|
| 10 | +16 | NIST Special Publication 800-38G -- Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption |
|---|---|---|
| 3 | -Zcash Protocol Specification, Section 4.6 | +Zcash Protocol Specification, Section 4.6 Sending Notes |
ZIP: 401 +Title: Addressing mempool denial-of-service +Owners: Daira Hopwood <daira@electriccoin.co> +Status: Final +Category: Network +Created: 2019-09-09 +License: MIT+
The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+This proposal specifies a change to the behaviour of zcashd nodes intended to mitigate denial-of-service from transaction flooding.
Adoption of this proposal would increase robustness of Zcash nodes against denial-of-service attack, in particular attacks that attempt to exhaust node memory.
+Bitcoin Core added size limitation for the mempool in version 0.12 3, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.
+The memory usage of a node’s mempool should be bounded.
+The eviction policy should as far as possible not be “gameable” by an adversary, i.e. an adversary should not be able to cause legitimate transactions (that do not themselves present any denial-of-service problem) to be preferentially evicted relative to its own transactions.
+Any configuration options should have reasonable defaults, i.e. without changing relevant configuration, a node should be adequately protected from denial-of-service via mempool memory exhaustion.
+The current architecture of Zcash imposes fundamental limits on scaling of transaction throughput. This proposal does not increase the aggregate transaction capacity of the network. (The Blossom upgrade does increase transaction capacity, by a factor of two 2.)
+Denial-of-service issues in the messaging layer of the peer-to-peer protocol are out of scope for this proposal.
+This proposal is focused primarily on memory exhaustion attacks. It does not attempt to use fees to make denial-of-service economically prohibitive, since that is unlikely to be feasible while maintaining low fees for legitimate users. It does not preclude changes in fee policy.
+This specification describes the intended behaviour of zcashd nodes. Other node implementations MAY implement the same or similar behaviour, but this is not a requirement of the network protocol. Thus, RFC 2119 conformance keywords below are to be interpreted only as placing requirements on the zcashd implementation (and potentially other implementations that have adopted this specification in full).
The mempool of a node holds a set of transactions. Each transaction has a cost, which is an integer defined as:
+++max(serialized transaction size in bytes, 4000)
+
Each transaction also has an eviction weight, which is cost + low_fee_penalty, where low_fee_penalty is 16000 if the transaction pays a fee less than 10000 zatoshi, otherwise 0.
+Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where the time indicates when the given txid was evicted. This SHOULD be empty on node startup. The size of RecentlyEvicted SHOULD never exceed eviction_memory_entries entries, which is the constant 40000.
There MUST be a configuration option mempooltxcostlimit, which SHOULD default to 80000000.
There MUST be a configuration option mempoolevictionmemoryminutes, which SHOULD default to 60.
On receiving a transaction:
+mempooltxcostlimit, then the node MUST repeatedly call EvictTransaction (with the new transaction included as a candidate to evict) until the total cost does not exceed mempooltxcostlimit.EvictTransaction MUST do the following:
+eviction_memory_entries entries.Nodes SHOULD remove transactions from RecentlyEvicted that were evicted more than mempoolevictionmemoryminutes minutes ago. This MAY be done periodically, and/or just before RecentlyEvicted is accessed when receiving a transaction.
The accounting for transaction size should include some overhead per transaction, to reflect the cost to the network of processing them (proof and signature verification; networking overheads; size of in-memory data structures). The implication of not including overhead is that a denial-of-service attacker would be likely to use minimum-size transactions so that more of them would fit in a block, increasing the unaccounted-for overhead. A possible counterargument would be that the complexity of accounting for this overhead is unwarranted given that the format of a transaction already imposes a minimum size. However, the proposed cost function is almost as simple as using transaction size directly.
+The threshold 4000 for the cost function is chosen so that the size in bytes of a typical fully shielded Sapling transaction (with, say, 2 shielded outputs and up to 5 shielded inputs) will fall below the threshold. This has the effect of ensuring that such transactions are not evicted preferentially to typical transparent transactions because of their size.
+The proposed eviction policy differs significantly from that of Bitcoin Core 3, which is primarily fee-based. This reflects differing philosophies about the motivation for fees and the level of fee that legitimate users can reasonably be expected to pay. The proposed eviction weight function does involve a penalty for transactions with a fee lower than the standard (0.0001 ZEC) value, but since there is no further benefit to increasing the fee above the standard value, it creates no pressure toward escalating fees. For transactions up to 4000 bytes, this penalty makes a transaction that pays less than the standard fee value five times as likely to be chosen for eviction (because 4000 + 16000 = 20000 = 4000 * 5).
+The fee penalty is not included in the cost that determines whether the mempool is considered full. This ensures that a DoS attacker does not have an incentive to pay less than the standard fee in order to cause the mempool to be considered full sooner.
+The default value of 80000000 for mempooltxcostlimit represents no more than 40 blocks’ worth of transactions in the worst case, which is the default expiration height after the Blossom network upgrade 2. It would serve no purpose to make it larger.
The mempooltxcostlimit is a per-node configurable parameter in order to provide flexibility for node operators to change it either in response to attempted denial-of-service attacks, or if needed to handle spikes in transaction demand. It may also be useful for nodes running in memory-constrained environments to reduce this parameter.
The limit of eviction_memory_entries = 40000 entries in RecentlyEvicted bounds the memory needed for this data structure. Since a txid is 32 bytes and a timestamp 8 bytes, 40000 entries can be stored in ~1.6 MB, which is small compared to other node memory usage (in particular, small compared to the maximum memory usage of the mempool itself under the default mempooltxcostlimit). eviction_memory_entries entries should be sufficient to mitigate any performance loss caused by re-accepting transactions that were previously evicted. In particular, since a transaction has a minimum cost of 4000, and the default mempooltxcostlimit is 80000000, at most 20000 transactions can be in the mempool of a node using the default parameters. While the number of transactions “in flight” or across the mempools of all nodes in the network could exceed this number, we believe that is unlikely to be a problem in practice.
Note that the RecentlyEvicted queue is intended as a performance optimization under certain conditions, rather than as a DoS-mitigation measure in itself.
+The default expiry of 40 blocks after Blossom activation represents an expected time of 50 minutes. Therefore (even if some blocks are slow), most legitimate transactions are expected to expire within 60 minutes. Note however that an attacker’s transactions cannot be relied on to expire.
+This specification is proposed to be implemented in zcashd v2.1.0. It is independent of the Blossom network upgrade.
| 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +Shorter Block Target Spacing | +
|---|
| 3 | +Bitcoin Core PR 6722: Limit mempool by throwing away the cheapest txn and setting min relay fee to it | +
|---|
ZIP: 1001 +Title: Keep the Block Distribution as Initially Defined — 90% to Miners +Owner: mistfpga (zcash forums) <steve@mistfpga.net> +Status: Draft +Category: Consensus +Created: 2019-08-01 +License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/> +Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-keep-the-block-distribution-as-initaly-defined-90-to-miners/33843>+
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. 2
+For clarity this ZIP defines these terms:
+| 1 | +If there is contradiction between Spirit and any other part of the proposal that needs to be addressed, in the event it is not addressed Spirit is assumed to overrule all. | +
|---|
The spirit of this ZIP is to is to ensure that the Founders’ Reward ends. It is not the intention of this ZIP to stop protocol-based donations.
+It is a simple short ZIP.
+Hopefully it will be compatible with a number of other ZIPs and can be worked into them.
+FoundersReward(height) MUST equal 0 if Halving(height) >= 1. (For clarity once the halving happens the Founders’ Reward stops, as per the rules outlined in 4 and 5.)This ZIP requires no changes to current consensus implementations.
+| 2 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 3 | +Zcash blog: Funding, Incentives, and Governance. February 1, 2016 | +
|---|
| 4 | +Zcash Protocol Specification, Version 2019.0.8 exactly. Section 7.7: Calculation of Block Subsidy and Founders Reward | +
|---|
| 5 | +Zcash Protocol Specification, Version 2019.0.8 exactly. Section 7.8: Payment of Founders’ Reward | +
|---|
ZIP: 1002 +Title: Opt-in Donation Feature +Owner: mistfpga (zcash forums) <steve@mistfpga.net> +Status: Draft +Category: Standards Track +Created: 2019-07-17 +License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/> +Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846>+
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 3
+This ZIP defines these terms:
+| 1 | +If there is contradiction between Spirit and any other part of the proposal that needs to be addressed, in the event it is not addressed Spirit is assumed to overrule all. | +
|---|
Governance on how decisions are made. This ZIP is not meant to be used as a form of governance. It is a protocol-level opt-in for supporting the Zcash network development (like the Founders’ Reward, just with opt-out).
+Signalling. Whilst a lot of the ZIP relies on the ability to signal intent in one way or another, it does not put forward such a mechanism and is designed to work with various form of signalling, or potentially without signalling at all.
+The spirit of this ZIP is:
+Technology changes, and it changes fast. What works now, may be easily breakable in 10 years, 20 years and certainly 50 years.
+To help ensure ZEC can keep up with these changes, now and in 50 or 500 years' time, there needs to be a continual funding for research into new technology and financial stability in order to attract new talent.
+The only source of indefinite wealth transfer is transaction fees or donations. This ZIP is specifically about voluntary donations (including via mining fees).
+| 2 | +The Zcash Foundation has stated (later clarified in 4) that the Foundation would only support proposals that: a) don’t rely on the Foundation being a single gatekeeper of funds; b) don’t change the upper bound of ZEC supply; and c) have some kind of opt-in mechanism for choosing to disburse funds (from miners and/or users). | +
|---|
this proposal is being published as a ZIP for the purpose of discussion and for the Zcash Foundation's sentiment collection process, despite significant issues with lack of clarity in the above specification.
+Stuff that is already implemented in some form or another:
+| 3 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 4 | +Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. | +
|---|
ZIP: 1003 +Title: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate +Owner: aristarchus (zcash forums) +Status: Draft +Category: Consensus / Process +Created: 2019-06-19 +License: MIT +Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862>+
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. 1
+For clarity in this ZIP I define these terms:
+This proposal would allocate a 20% Dev Fund Percentage to be split evenly between the Electric Coin Company (ECC) and the Zcash Foundation during the 2nd Halvening period. This proposal aims to be simple to implement, without a single point of failure, and comes with mandates for transparency, accountability and a mandate to build a development fund voting mechanism to be used during the 3rd Halvening period. This proposal is designed to strike a balance between ensuring that high quality development work can continue uninterrupted, with the need to further decentralize Zcash development funding as soon as possible.
+Strengths of this proposal:
+Here are the general properties of the mandated voting mechanism. I don’t want to specify the technical implementation details, since I believe this is a job suited for the engineers building this system.
+These requirements would apply to both ECC and the Zcash Foundation. The mandate is to adhere to these accountability requirements originally put forward by the Foundation:
+Motivated by the Zcash Foundation’s proposal that the ECC become a non-profit 3, I am going to list general requirements for the ECC to abide by if they choose to receive funds and work on behalf of ZEC holders.
+I am not mandating non-profit status for the ECC. Maybe that is the best legal structure, maybe something else is better.
+Finally, in the event that the voting system isn’t implemented by the start of the 3rd Halvening period, the 20% of funds intended to go to the ‘voting development fund’ should instead not be minted.
+| 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. | +
|---|
| 3 | +Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. | +
|---|
ZIP: 1004 +Title: Miner-Directed Dev Fund +Owner: Andrew Miller (@amiller on zcash forums) +Status: Draft +Category: Consensus +Created: 2019-06-19 +License: public domain +Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864>+
The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+For clarity, this ZIP defines these terms:
+This proposal reserves a portion (20%) of the newly minted coins in each block for the development fund. A fixed set of developer entities would be eligible to receive these funds. The fund would be miner-directed in the sense that the miner of each block can determine how to allocate these funds to eligible developers.
+Like most development fund proposals, this is motivated by the potential value to the Zcash community of using newly minted coins to hire developers to continue improving Zcash. 2
+Unlike most other development fund proposals, this proposal is distinct in providing a fine-grained “opt-in” 3 feature, since miners have the choice to provide a small amount of development funding or none at all.
+During the 2nd Halvening Period, a fixed portion (DF% = 20%) of the newly minted coins in each block are reserved for a Miner-Directed Dev Fund (MDDF). A hardcoded set of developer entities (e.g., Electric Coin Company, Zcash Foundation, Parity, or others), represented in the code by their t-address or z-address public keys, are eligible to receive funding from the MDDF. The fund is “miner-directed” in the sense that the miner in each block chooses how to allocate the MDDF coins among the developer entities, simply by creating outputs in the coinbase transaction. The DF% is a maximum — miners can also “opt out” by minting a lower number of coins for the MDDF, or none at all.
+This proposal is explicitly limited in scope to the 2nd Halvening Period. After the end of this period, the entire block reward in each block is awarded to the miner. The upper bound on the rate of newly minted coins MUST remain the same as before this proposal (i.e., at most 25 ZEC minted per 10 minutes during the 2nd Halvening Period).
+Implementations MAY define a default opt-in allocation (e.g., DF%/2 to the Electric Coin Company and DF%/2 to the Zcash Foundation).
+Implementations SHOULD support changing the allocation (overriding any such default) through a configuration option.
+The following examples illustrate how miners can build the outputs of the coinbase transactions to allocate the MDDF to eligible developers. Assume Dev1, Dev2 are the hardcoded addresses of eligible developers, and Miner is the address of the mining pool mining this block. Assume that the total newly minted coins are 3.125 ZEC per block during the 2nd Halvening Period (this takes into account the change to a 75-second block target spacing after the Blossom Network Upgrade 5), and that DF% = 20%, MR% = 80%.
Example 1: Split equally between two developers
+The transaction outputs of the coinbase transaction are as follows:
+MinerDev1Dev2.Example 2: Opt-out of the development fund
+The transaction outputs of the coinbase transaction are as follows:
+Miner.Raised objections and issues so far:
+| 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +Notes on reaching agreement about a potential Zcash development fund. Andrew Miller, June 3, 2019. | +
|---|
| 3 | +Comment on a post “The future of Zcash in the year 2020” in the Zcash Community Forum. Josh Cincinnati, June 3, 2019. | +
|---|
| 4 | +Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019. | +
|---|
| 5 | +ZIP 208: Shorter Block Target Spacing | +
|---|
ZIP: 1005 +Title: Zcash Community Funding System +Owner: Dimitris Apostolou <dimitris.apostolou@icloud.com> +Status: Draft +Category: Consensus +Created: 2019-06-23 +License: MIT +Discussions-To: <https://forum.zcashcommunity.com/t/zip-proposal-zcfs-zcash-community-funding-system/33898>+
This proposal introduces a new funding mechanism called the Zcash Community Funding System (ZCFS).
+The motivations for ZCFS are:
+This specification is a modification of the Monero Community Crowdfunding System (CCS) and is defined as follows:
+The ZCFS is intentionally left as informal as possible. This allows for flexibility of the system, and keeps things from being red-taped into oblivion. However, there are some things you should understand, things that will be expected of you, as either a proposer or a donor, and a recommended way of structuring a proposal for maximum likelihood that your project will be funded.
+ZIP: 1006 +Title: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity +Owners: James Todaro <james@blocktown.capital> + Joseph Todaro <joseph@blocktown.capital> +Credits: Mario Laul <mario@placeholder.vc> + Chris Burniske <chris@placeholder.vc> +Status: Draft +Category: Consensus / Process +Created: 2019-08-31 +License: MIT +Discussions-To: <https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782>+
The key words “MUST”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document are to be interpreted as described in RFC 2119. 1
+The additional terms below are to be interpreted as follows:
+This proposal puts forward the financing mechanism and fundamental rules of governance for the creation of a Zcash Development Fund.
+The governance rules of the Third Entity MUST include the following:
+Prior to any transfer of funds from the Zcash Development Fund, the ECC, ZF, and Third Entity MUST specify, approve, and make public the final rules on applying for and receiving funding from the Zcash Development Fund, including the details of the decision-making process for approving or rejecting funding requests. These rules MUST apply equally to all Applicants, including the ECC, ZF, and Third Entity, and MUST include the following:
+Any decision to alter the governance of the Zcash Development Fund as described in this proposal and in final detail by the ECC, ZF, and Third Entity MUST involve the Zcash community at large, similar to the process outlined in the ZF’s August 6, 2019 statement 2. All transfers from the Zcash Development Fund MUST be in full accordance with the requirements described in this proposal.
+The Zcash network is scheduled to undergo its first halving in October 2020, per current protocol specifications. At the time of the first halving, the codebase dictates that the Founder’s Reward, which consists of 20% of the ZEC from every block reward, will be terminated. Without codebase modification, for example in the upcoming NU4 Network Upgrade, 100% of block rewards would be claimed by miners after the first halving.
+The two organizations presently leading development and maintenance of the Zcash network receive funds from the Founder’s Reward. These organizations, the ECC and ZF, have recently requested a source of funding after the first halving in order to continue operations for the foreseeable future. The source of funds could theoretically be from either a modification to the codebase dictating a Zcash Development Fund from block rewards or, alternatively, from external sources. The ECC has indicated though that it would “wind down or pivot” rather than accept funding from any sources that would give “special interests” control over the ECC 3.
+Based on the ECC’s demands, the block reward appears to be the most agreeable source of resources for a Zcash Development Fund.
+This proposal, originally published in the Zcash Community Forum on August 14, 2019 4 and formalized further in a blog post on August 23, 2019 5, outlines the funding mechanism and governance of such a Zcash Development Fund. Herein, we propose a feature of NU4 whereby 10% of the ZEC from every new block reward between the first halving and second halving would be directly deposited in a Zcash Development Fund.
+For the period between the launch of the Zcash network in 2016 and the first halving, there has been a centralized 20% fee known as the Founder’s Reward taken from the block reward. Other active ZIP drafts advocate a Zcash Development Fund of 20% allocation from the block reward after the first halving. We believe that a cumulative eight years of centralized fees from the block reward at the identical rate of 20% would ultimately result in a narrow community that accepts the likelihood of a perpetual 20% fee on the Zcash network.
+With a Zcash Development Fund that is only 10% of the block reward, a precedent will be set that a large centralized fund is not indefinite and will decrease faster than simply the rate of block reward halvings. Although this proposal specifically addresses the period between the first and second halving, this proposed feature may set a precedent whereby the percent fee from block rewards allocated to a Zcash Development Fund continually decreases every halving, e.g. 20% (FR) from 2016-2020, 10% from 2020-2024, 5% from 2024-2028, 2.5% from 2028-2032 (effectively quartering the ZEC allocated to a development fund every four years). We believe that this social contract could restore the community’s faith in the decentralization of Zcash as the network incentives align more closely with that of Bitcoin’s over time. Alternatively, it is not unreasonable for the Zcash governance system to elect a 0% allocation for the Zcash Development Fund upon the second halving. For a more detailed exploration regarding the selection of 10%, please review the blog post ‘Proposal for 10% Dev Fund in Zcash 2020 Network Upgrade’ 6.
+Of note, we are not suggesting or implying that the funding from the Founder’s Reward and a Zcash Development Fund would be managed in a similar way or have similar directives. The Zcash Development Fund feature that we propose for NU4 does not allocate any funds to former angel investors, VCs or vested employees. Furthermore, the Zcash Development Fund would be subject to more explicit and transparent rules of governance, as outlined in the Specification section of this proposal.
+The rationale behind this proposal is as follows:
+Recognized objections to this proposal include:
+Aspects of this proposal, particularly the Terminology and Specification sections, were adapted and expanded definitions and concepts put forth in Placeholder’s dev fund proposal from August 22, 2019 8.
+| 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. | +
|---|
| 3 | +ECC Initial Assessment of Community Proposals. Electric Coin Company blog, August 26, 2019. | +
|---|
| 4 | +Proposal for the Zcash 2020 Network Upgrade (topic on the Zcash community forum). | +
|---|
| 5 | +Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 23, 2019. | +
|---|
| 6 | +Proposal for 10% Dev Fund in Zcash 2020 Network Upgrade. Blocktown Capital, August 14, 2019. | +
|---|
| 7 | +Executive Summary: Blocktown Proposal for Zcash 2020 Network Upgrade. Blocktown Capital, August 15, 2019. | +
|---|
| 8 | +Dev Fund Proposal: 20% to a 2-of-3 multisig with community-involved governance (topic on the Zcash community forum). | +
|---|
| 9 | +The Zcash Network Upgrade Pipeline. Electric Coin Company blog, December 3, 2018. | +
|---|
ZIP: 1007 +Title: Enforce Development Fund Commitments with a Legal Charter +Owners: @lex-node (zcash forums) + @mistfpga (zcash forums) <steve@mistfpga.net> +Status: Draft +Category: Process +Created: 2019-08-24 +License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/> +Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709>+
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+For clarity this ZIP defines these terms:
+A supplemental proposal to ensure feature selection and work is community-driven.
+Hopefully it will be compatible with a number of other ZIPs and can be worked into them.
+This proposal is supplemental to any Development Funding Proposal that places or purports to place conditions on how the Electric Coin Company (ECC) and the Zcash Foundation (ZF) use development funds, or take other related off-chain actions such as requirements and Covenants.
+For example, the proposal 2 provides that “[f]unds accruing to the Zcash Development Fund MUST be used only for ... technical work directly connected to the various software implementations of the Zcash protocol.” However, once development funding is approved and implemented via a Network Upgrade, there will be no enforcement mechanism to ensure that the ZF and ECC abide by this requirement.
+This proposal aims to provide such an enforcement mechanism. If this proposal is adopted, then the ECC and/or ZF, as applicable MUST enter into a legal agreement that would entitle ZEC holders to enforce ECC’s/ZF’s performance of any Covenants. For the purposes of this proposal we will refer to the legal agreement as the “DevFund Charter” or “Charter” for short, but it MAY also be styled in other ways – e.g. as a Constitution, Bylaws, Fund Governance Agreement, etc.
+The DevFund Charter SHOULD be used to the benefit of all ZEC users, but the DevFund Charter MAY provide that an enforcement action requires the support of the holders of a plurality, majority or supermajority of ZEC. ZEC held by the ZF, ECC and their officers, directors, employees and/or affiliates SHOULD be excluded from the denominator in calculating the requisite plurality, majority or supermajority of ZEC.
+a "plurality" in a vote means the option that received more votes than any other single option, but it is unclear how this applies to "a plurality of ZEC". Taking into account experience from stake-weighted voting in other cryptocurrencies, the threshold of a simple majority (50%), or more, of all *issued* ZEC voting for any enforcement action would seem to be an extremely high bar.
+A quorum of yet-to-be-decided number of representatives from a number of groups specified by the DevFund Charter MAY provide that an enforcement action requires the support of the assigned representatives of each. One such mechanism SHOULD be ZEC balance, however this would require a 66% majority or a 85% supermajority. (These numbers are not binding and are up for discussion)
+It is assumed that the Electric Coin Company, Zcash Foundation, or party with a direct conflict of interest SHOULD identify their vote/signal - which MAY be rejected from the vote.
+Legal enforcement MAY occur in a court of law, non-binding mediation or binding arbitration. The DevFund Charter MAY also provide rights to other Zcash community constituencies, such as specified miners or the “Third Entity” contemplated by 2.
+Because ZEC holders do not have specific legal rights against the ECC or ZF, but MAY wish to condition renewed on-chain development funding on the ECC’s or ZF’s agreement to use the development funds in certain ways, ZEC holders should have the legal right to enforce ECC’s/ZF’s compliance with those agreements.
+| 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity | +
|---|
ZIP: 1008 +Title: Fund ECC for Two More Years +Owners: @kek (zcash forums) + @mistfpga (zcash forums) <steve@mistfpga.net> +Status: Draft +Category: Consensus +Created: 2019-09-02 +License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/> +Discussions-To: <https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778>+
The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. 2
+For clarity this ZIP defines these terms:
+| 1 | +If there is contradiction between Spirit and any other part of the proposal that needs to be addressed, in the event it is not addressed Spirit is assumed to overrule all. | +
|---|
Everything except moving the development fund end date.
+The spirit of this proposal is to keep to the current structure of the Electric Coin Company (ECC) receiving funding from the block distribution for two years' worth of blocks after the first halving in October 2020.
+To give more time to work out the full ramifications of any potential pivot / slow down, yet keep "all in on ZEC" for two more years with as little disruption as possible.
+Nothing about distribution recipients changes.
+The current distribution of the Founders’ Reward is dependent on arrangements between the participants that will, if not explicitly renewed, expire at the first halving. There are currently direct and indirect recipients other than the ECC and Zcash Foundation. It is unclear whether funding of the ECC and Foundation is intended to continue at the current absolute ZEC rate, or at the same rate relative to the block subsidy which halves in October 2020. Further specification would be needed in order to fulfil and clarify the spirit of the proposal.
+The 1.1m USD cap cannot be specified as a consensus rule since there is no on-chain oracle for the USD price.
+Provisions that referred to specific block heights have been revised since they were inconsistent with the change in block target spacing 4 that will occur with the Blossom Network Upgrade 3; and even if recalculated, fixed block heights would potentially be inconsistent with future changes in target block spacing.
+| 2 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 3 | +ZIP 206: Deployment of the Blossom Network Upgrade | +
|---|
| 4 | +ZIP 208: Shorter Block Target Spacing | +
|---|
ZIP: 1009 +Title: Five-Entity Strategic Council +Owner: Avichal Garg <avichalgarg@electriccapital.com> +Status: Draft +Category: Process +Created: 2019-08-28 +License: MIT +Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801>+
Key terms
+This proposal reserves 20% of newly minted coins in each block for a Developer Fund. A five-person Strategic Council would be elected by the community every two years. The Strategic Council would determine the high level strategy, goals, and metrics to evaluate progress for the ecosystem on a six-month cadence. The Strategic Council would be responsible for allocating funding to Executors for the subsequent six months and summarizing the performance of Executors in the prior six months. Executors would submit proposals to the Strategic Council on a six-month cadence, including project plans, funding plans, and how they will measure success on a scale from 1-10. At the end of six months, Executors will grade themselves and the Strategic Council will summarize what was accomplished with a target of 7/10 in every quarter on a roll-up basis (a simple average of all of the outstanding projects for that six months).
+This is an attempt to put on my startup CEO hat and address the strategic and execution challenges I believe have held back Zcash from realizing its full potential.
+Principles & Observations Based on My Experiences (a.k.a. Biases?)
+Because layer 1 protocols are network-effect driven, without a quickly growing network-effect in miners, developers, users, and liquidity, a layer 1 protocol will ultimately collapse.
+The primary driver of success in a network-effect business is how quickly you grow the network effects.
+To grow a network effect, you must have both the correct strategy and excellent execution. If your strategy is not correct, no matter how well you execute, you will fail. If your execution is not excellent, you will not be able to assess whether lack of progress is due to poor execution or poor strategy.
+Thus, to build the network effects Zcash needs to succeed, we must answer five questions:
+1. Who determines the strategy?
+2. How do they decide on the strategy?
+3. How are they held accountable to having the correct strategy?
+4. Who executes?
+5. How are Executors held accountable to excellent execution?
+1. Who determines strategy?
+2. How do they decide?
+How are they held accountable for having the correct strategy?
+4. Who executes?
+5. How are they held accountable to excellent execution?
+Raised objections, issues, and open questions:
+these should be made into inline references.
+ZIP: 1010 +Title: Compromise Dev Fund Proposal With Diverse Funding Streams +Owner: Josh Cincinnati <josh@zfnd.org> +Credits: Matt Luongo + Eran Tromer + Andrew Miller + mistfpga + lex-node + and many others +Status: Draft +Category: Consensus +Created: 2019-08-31 +License: MIT +Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812/>+
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. 1
+The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 2
+I try to put the best pieces of various proposals together. A 20% of the block reward for a 4-year development fund that disburses to a trust controlled by both the Electric Coin Company (ECC) and Zcash Foundation (ZF), but with stringent controls on how funds may be allocated. It sidesteps code complexity in implementation by off-loading disbursements to a legal trust; funds the ECC/ZF; ECC stays a for-profit with restrictions; funds external parties through ZF Grants; all while carving out a limited-scoped opportunity for extending governance to more groups than the ECC/ZF.
+Zcash won't thrive without a dev fund. I wish this wasn't true (I really do), and for the longest time I was against the idea. But I've come to fear the alternative without one; I fear the privacy technology pioneered by Zcash may never reach its true potential — not just for our community, but for others interested in novel approaches to private money.
+The Foundation, ECC, and broader community has offered many suggestions and guidelines for a potential dev fund, below is my attempt at synthesizing them into a compromise that's greater than the sum of its parts:
+for security reasons, it may be useful to refine the "single address" to a list of rolling addresses as described in section 7.8 of the current protocol specification. Other references to a "single address" in this document have not been changed.
+Please note: a previous version of this proposal included a portion of the funds being tied to shielded adoption, based on ideas brought forward by Eran Tromer in 4. After many discussions I came to worry about the gameability of the metric and decided to drop it entirely.
+Upon the NU4 network activation, 20% of the mining reward (post-Blossom / post-halvening = 0.625 ZEC per block) MUST go to a single shielded address with a viewing key widely distributed and known to the community and controlled by a trust established by the ECC and Zcash Foundation. If the trust and associated address aren't established by the NU4 activation deadline, then there MUST NOT be any change to the mining reward. Every quarter-year (105,000 blocks at the post-Blossom rate), until 4 years after NU4 activation (1,680,000 blocks at the post-Blossom rate), the trust SHOULD disburse funds the following way, requiring a public report with every disbursement:
+When this proposal was written it was expected that NU4 activation would correspond exactly to the first (October 2019) halvening. Since that may not be the case, I have resolved a potential ambiguity in the original wording by specifying that the trust disburses funds for 4 years, rather than that it disburses funds until the second (October 2020) halvening.
+0.625 ZEC * 105000 = 65625 ZEC accrued in the trust every quarter. If both the ECC and Zcash Foundation met the accountability requirements set by the trust, then disbursements would look like this:
+This example assumes no change to target block spacing.
+Here I'm borrowing from the Foundation's guidance 3 but adding some stipulations to cement the Foundation's independence, prevent the Foundation from hoarding its endowment, and handle the ECC as a for-profit. Before disbursing funds each quarter, the trust MUST validate that both the ECC and Zcash Foundation:
+For the Zcash Foundation, the trust MUST further require:
+Additionally, for the ECC, the trust MUST validate the following before each disbursement:
+The ECC MUST share necessary information with the trust to ascertain no violations of the above, but the information itself (i.e. cap table and detailed financials) SHOULD remain private between the ECC and the trustees unless there is a violation that is not cured.
+The violating party has 30 days to attempt to cure the violation (if it's possible). If they cannot, future funds MUST be redirected to ZF Grants via a restricted donation to the Zcash Foundation. (That is, not usable by either the Zcash Foundation or ECC, more on that below.)
+A portion of the dev fund goes to the Foundation but with the express (and restricted) purpose of being distributed via ZF Grants (a restriction that MUST be legally enforced by the trust). The Foundation would continue to administer ZF Grants and distribute funds, but it SHOULD NOT decide where those funds go and would not allowed to be recipients of these funds; instead, the trust MUST demand that the ZF Grants process include broader input in the manner described below. In the discussions around the various "third party" proposals, some have suggested a 3-of-5 approach where the ECC and Zcash Foundation are in the minority; I think that structure would work well for these funds. It's not the full dev fund so we are limiting the downside risk of selecting the "wrong" third parties, which also means we can give those third parties more voice (by making them outnumber the ECC/Zcash Foundation). The Foundation MAY also chose to fund ZF Grants beyond the restricted donations from the trust, but doing so would be at their discretion.
+Thanks to the discussion on Matt Luongo's proposal there's a good blueprint for how this group would work. I'm borrowing some comments I made on Matt's proposal thread 8 and modifying them to apply to a ZF Grants-specific Grant Review Committee, rather than the Foundation's board.
+The ZF Grant Review Committee would be compromised of five members, voted on in the following manner:
+The group would meet biweekly to make funding decisions, the results of which will be made public on ZF Grants. Taking a note from Eran Tromer's recent proposal, the group would have a goal of making at least two "Large Grants" every year. A "Large Grant" would have an expected scope of six months and 1/4th to 1/3rd of the total ZF Grants yearly budget, with the goal of getting more dedicated external teams involved.
+There are scores of great ideas on the forums, and I took the (subjective, mind you) best parts of each into a proposal that hopefully meets the standards of the ECC, the Zcash Foundation, and the broader community.
+With all due respect to the proposers behind some variant of a "2-of-3 multisig" decision-making process for all disbursement decisions: I think this is a bad idea. To quote a previous forum post of mine:
+++...2-of-3 multisig [is] better if we find the right third party. That in and of itself requires an additional process/mutual agreement between the three parties (which is much more difficult than a bilateral agreement), and as I’ve mentioned before in presentations in the past, 2-of-2 with known entities dedicated to Zcash is better than jumping straight to 2-of-3 with a third party hastily decided or staying with 1-of-1 entity trademarks and software development processes.
+As for why 2-of-2 is still strictly better than 1-of-1: in the case of cryptocurrency governance, I believe that inaction in the case of disagreement is a better outcome than one party unilaterally exercising power.
+
More to the point, I worry that the "third party" in question is being idolized into some Platonic ideal, and in reality either the ECC or the Zcash Foundation would spend a great deal of their time currying favor in either the process or selection of the party in question in the limited time between now and that party's selection. Given that the Zcash Foundation is charged with representing community interests, I'm not sure why another community-focused representative would really make sense from the ECC's perspective — they'd be constantly outvoted if interests clashed, so from a balance of power perspective I'm not sure why the ECC would find that tenable. And I'm not sure the community would want the "third party" to be another profit-generating enterprise, like a VC or another startup, which would tip power another way.
+The crux of this proposal still centers around the idea that the Zcash Foundation and ECC share responsibility for protocol development, which is now bolstered by the 2-of-2 agreement on the trademark. It assumes and expects that both continue developing consensus-compatible node software that interacts with the Zcash network. But it mandates accountability for disbursement of funds to the ECC/Zcash Foundation, and expands outside stakeholder input on funds that wouldn't be earmarked for the ECC/Zcash Foundation (similar to Placeholder's earlier version of their proposal and Matt Luongo's current proposal), while it doesn’t preclude the possibility of migrating to broader "2-of-3" later on future governance decisions.
+The main reason: reducing complexity creep in consensus code. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 with the simplest possible code-change and spend more time ironing out the details of the trust "off-chain." Since both the ECC and the Zcash Foundation are based in the US, using a trust with well-specified criteria for disbursements is a reasonable path. This also fits in nicely with lex-node's proposal 9 for legal covenants on funding.
+The biggest issue is custody of the funds under the trust's control, but I suspect this can be managed with a partnership with a custody partner. There's also the issue that non-public information would need to be verified and validated by the trust, but I view this as a net positive for the community ("transparency for organizations, privacy for individuals").
+TBD, but it should be relatively simple to code in both zebra and zcashd.
+| 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|
| 2 | +ZIP 200: Network Upgrade Mechanism | +
|---|
| 3 | +Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. | +
|---|
| 4 | +Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019. | +
|---|
| 5 | +“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018. | +
|---|
| 6 | +ZF Grants — Funding for Zcash ecosystem projects | +
|---|
| 7 | +The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. | +
|---|
| 8 | +Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019. | +
|---|
| 9 | +ZIP 1007: Enforce Development Fund Commitments with a Legal Charter | +
|---|
ZIP: 1011 +Title: Decentralize the Dev Fee +Owner: Matt Luongo <matt@thesis.co> +Status: Draft +Category: Process +Created: 2019-09-27 +License: MIT +Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252>+
This proposal describes a structure for Zcash governance, including funding and managing new Zcash development, decentralizing those development efforts, and resolving governance hangups between the Zcash Foundation and the Electric Coin Company.
+These goals are accomplished via a 20% dev fee, enacted in NU4 and continuing for one halving period. This fee will fund a diverse group of development teams to ensure Zcash maintains best-in-class research and engineering talent while growing a robust ecosystem, funding the Zcash Foundation with 25% of the dev fee, and a newly established principal developer role with 35% of the dev fee.
+My name is Matt Luongo. I'm an entrepreneur who's been full-time in the crypto space since 2014, co-founding Fold, a Bitcoin payments company, and more recently Keep, a private computation startup built on Ethereum. At Keep, we've done some work around Zcash, and our parent company, Thesis, is considering investing more heavily in Zcash development for our latest project.
+I'm deeply interested in privacy tech. For me, privacy is about consent –consent to share my habits, beliefs, and preferences– and I see privacy as the inevitable next frontier in our pursuit of an economy that respects individual choice.
+My perspective is as the founder of a for-profit company focused on building self-sovereign technology who wants to develop on Zcash. We work in this space ideologically, but our work isn't free; attracting and growing talent requires funding.
+If you're interested in more on my background, I've introduced myself more properly on the forum.
+Since Zcon1, I've been looking to fund work to build an Ethereum / Zcash bridge. I've spoken to the ECC, the Zcash Foundation, and a number of early Zcash community members on how best to move forward with this project, and in the process I've learned a lot about how the community works and dev governance has been structured thus far.
+Inevitably, I've become interested in the community's proposals for a new dev fee, and thought about how the right structure might support work like ours.
+I believe the Zcash community has an opportunity to deploy a new incentive structure that will attract companies like ours to build and improve Zcash, leading to a more resilient network, stronger technology, and wider usage.
+We're all here to build a robust, private, decentralized currency. But in the dev fee proposals I've seen so far, the idea of a Zcash narrative that distinguishes it from the competition is absent.
+Of the slew of ZIPs addressing Zcash's future, there's only been one strong narrative case — the idea that Zcash exists purely as a hedge against Bitcoin's long-term privacy failure. Put simply, Zcash is "Bitcoin, but private".
+Zcash should aim higher. Bitcoin is the only coin that has successfully made a store of value argument, which I like to call "worse is better". Don't upgrade the network –the argument goes– stability is more important than solving today's problems. Bitcoin is chasing the Lindy effect, where worse is better, and the network becomes stronger every day it survives. That's great for Bitcoin. For the rest of us, though, better is better. Zcash should be better.
+Zcash is known for having the best tech in the space, built by one of the best teams in the space. We should lean in to that reputation, nurturing the best research and engineering talent to take Zcash to the next level, and leveraging a Zcash dev fee as a differentiator to build the world's best private medium of exchange.
+To understand Zcash governance, it's worth reviewing "default" cryptocurrency governance. Most proof-of-work chains today have three major governing roles:
+On a chain like Bitcoin, any of these roles can veto a network upgrade.
+These roles together form a balance of power that makes contentious forks difficult — any change that a large swath of users disapproves of could split the chain.
+In Zcash, the addition of the Electric Coin Company (ECC) and the Zcash Foundation skew this balance.
+Both organizations are comprised of Zcash founders, developers, researchers, and privacy proponents who have driven this ecosystem forward and represent its values. Nevertheless, their mode of operation today skews a healthy balance of power in Zcash governance.
+The mechanisms of that skew are the Zcash trademark, held jointly by the Foundation and the ECC, and primary client software development, now split between the ECC and the Foundation.
+In a disagreement between miners, users, and developers, the Foundation and ECC have the option of enforcing the Zcash trademark, effectively allowing them to choose a winning fork against the will of users, miners, and other developers.
+In addition, the Foundation's sole maintenance of the zebrad client allows them to "soft veto" a network upgrade.
Unfortunately, the Foundation and the ECC aren't organized as arms-length entities today.
+This situation poses a number of problems for new and existing Zcash users, as well as both entities.
+The Zcash ecosystem, as it exists today, leaves little incentive for outside developers to participate.
+Zcash development has a high learning curve.
+Most outside developers need to see a clear path to longer-term funding before they can commit to the cost of that curve.
+Even those developers who already have the expertise to work on this system are frustrated by the lack of longer-term funding. For evidence, look at Parity's exit from Zcash after zebrad development, or Summa's struggles to work on Zcash.
Sustainably attracting talent to Zcash is critical to maintain innovation and build resilience.
+The first requirement is a balanced governance structure. Developers should be rewarded, without rewarding governance capture. What's best for the chain and ZEC holders should always come before commercial interests.
+The second, and secondary, requirement is funding Zcash development. While the chain shouldn't be run by a commercial entity, it will need to be supported by them.
+The third requirement is the support of a more resilient ecosystem by:
+Finally, avoid introducing unnecessary additional entities into the governance process.
+General on-chain governance is outside the scope of this proposal. On-chain governance is an exciting idea -- what if we had an impartial arbiter funding development? My experience with on-chain governance to date, however, leads me to believe it's still a risky direction. Zcash should focus on what it's good at –privacy– and leave proving on-chain governance models to other projects.
+While this proposal attempts to outline a long-term structure for Zcash funding and governance, specifying the structure beyond the next 4 years is out of scope. Much will have changed in 4 years. Perhaps this structure will be sufficient; perhaps we'll be battling the Third Crypto War, and need to go back to the drawing table.
+The below proposal is an effort to cleanly resolve the problems with Zcash's current governance, while
+A few proposals have suggested the introduction of a mysterious "third entity" to resolve disagreements between the Foundation and the ECC.
+I prefer a different approach, refocusing the role of the Foundation and making room for the ECC to work with a robust developer ecosystem.
+In this proposal, the Foundation shall support community development through running the forum and events, gathering community sentiment, managing short-term development grants, research and development, and conducting the diligence behind the assignment and disbursement of a development fee. This development fee shall be funded by 20% of the block reward, with as much as half of the fee burned in case of extraordinary growth in the price of ZEC.
+The Foundation shall receive 25% of the dev fee. If the volume-weighted average price of ZEC over the month means the foundation would receive greater than $500k that month, the Foundation shall set aside enough ZEC such that their max monthly budget is
++++ \(\mathsf{MaxBenefit}(\mathsf{RewardDollarAmount}) = \mathsf{Min}(500000, 500000 * \sqrt{\frac{\mathsf{RewardDollarAmount}}{500000}})\) +
+
The excess ZEC should be purpose-restricted to the Foundation grants program, ensuring the funds are earmarked to grow outside community talent and involvement.
+Capping the monthly expenses of the Foundation will limit growth, while encouraging fiscal discipline.
+The remaining 75% of the dev fee shall be distributed between development teams working to maintain clients.
+Prior to each network upgrade, the Foundation shall recommend a list of addresses and a total number of ZEC per block each address is meant to receive from the dev fee. The recommendation will be "ratified" by the miners as the network upgrade activates.
+Dev fee recipients are distinguished from grant recipients in the scope and timelines of their work, as well as the specificity of direction. The intent is to allow teams to focus on a core competency, while encouraging research and adjacent work.
+Dev fee recipients are chosen semi-annually by the Foundation based on their ability to move Zcash forward. Recipients will typically be development teams, though "full stack" teams that can communicate well with the community, expand Zcash usage, and widely share their work should be advantaged.
+Recipients shall submit quarterly plans to the community for their efforts, as well as monthly progress updates.
+All work funded by the dev fee will be open source, under licenses compatible with the existing Zcash clients.
+Though the Foundation shall periodically judge the efficacy of dev fee recipients, deciding on and driving roadmaps for Zcash is the role of dev fee recipients, in partnership with the community. This role is neatly balanced by users running full nodes and miners, either of which can veto a network upgrade.
+While dev fee recipients are not required to work exclusively on Zcash, considering the nature of their work, recipients must guarantee they aren't obliged to the interests of competing projects.
+The role of the principal developer is as a "first among equals" amongst the dev fee recipients.
+The principal developer shall make a number of guarantees.
+In exchange, the principal developer is granted an indefinite minimum dev fee allocation of 20%, with a maximum allocation of 35% of the total fee, as recommended annually by the Foundation.
+The principal developer will have a wide remit to pursue longer-term research relevant to Zcash, though it will submit the same plans required of other recipients. The principal developer will only be recommended for removal by the Foundation in extraordinary circumstances, including reneging on the above guarantees or extreme negligence.
+To manage the dev fee and fulfill its community and diligence duties, the Foundation shall maintain a board of 5 independent members. Rather than the structure in the current bylaws, the board will consist of
+The Foundation requires a professional board. Board member selection should heavily favor candidates with existing formal public or private sector board experience.
+Board seats should rotate periodically, while maintaining long enough terms and overlap for consistent governance.
+Each board member should bring a unique network and set of skills to bear to increase the impact of the Foundation.
+No board members shall have an ongoing commercial interest in any recipients of the dev fee.
+Considering their expertise, the Foundation shall deliver a transition plan, including a board election schedule and report on the feasibility of a future coin vote process to determine a board seat.
+I propose that the ECC be considered as the initial principal developer, receiving an indefinite dev fee allocation in exchange for their exclusive focus on Zcash research and development, and assigning all patents and marks relevant to Zcash to the Foundation.
+I believe this arrangement is best for the Zcash ecosystem, and with proper management of funds, should satisfy the ongoing needs of the ECC.
+The Foundation shall organize a bi-weekly call for all dev fee recipients and other third party developers. The call will be live-streamed for community participation, though the speaking participants will be invite only. At a minimum, a single representative from each dev fee recipient should attend.
+The Foundation shall also maintain a simple chat solution for development of the protocol. While the chat logs should be publicly viewable, it need not be open to public participation.
+I believe this proposal can form the basis for a new way forward for Zcash — a robust, decentralized ecosystem with fair governance. I also hope it can bring together the stakeholders in this discussion, and allow us to get back to why we're all here — to protect the world's financial privacy.
+I look forward to feedback on GitHub and the Zcash forum.
+In the interest of transparency, I'd like to make a few professional disclosures.
+I'm the largest shareholder of Thesis, the parent company and studio behind Fold and Keep. Thesis is a for-profit company that might benefit from this proposal as a dev fee recipient. While today I maintain exclusive control of Thesis, the company has taken outside investment in the past.
+As far as my financial interest in Zcash, I've held a small amount of ZEC since shortly after launch. I'm in the process of building my personal ZEC position, as well as a position at Thesis.
+Thanks to my friends and colleagues Carolyn, Laura, Josh, James, Corbin, and Antonio for early review of the text this proposal.
+Thanks to my fellow dev fund ZIP authors, Avichal Garg at Electric Capital, Antoinette Marie, Josh Cincinnati, ED at the Zcash Foundation, Jacob Phillips at Autonomous Partners, Andrew Miller, Chris Burniske, Eran Tromer, and the fellows at Blocktown, each of whose ideas influenced this proposal. And of course, thanks to Sonya Mann and the Foundation for coordinating discussions around these different proposals.
+Outside ongoing discussions in the forum and with other ZIP authors, I've spoken with a number of prominent community members while developing this proposal, though none were provided early access to the text of the proposal. I appreciated the thoughtful discussions with Josh Cincinnati, Zooko Wilcox, Josh Swihart, Ian Miers, and others.
+ZIP: 1013 +Title: Keep It Simple, Zcashers: 10% to ECC, 10% to ZF +Owners: Gordon Mohr (@gojomo on relevant forums) +Status: Draft +Category: Consensus / Process +Created: 2019-11-14 +License: Public Domain +Discussions-To: <https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashers-kisz-10-to-ecc-10-to-zfnd/35425>+
The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. 1
+The terms below are to be interpreted as follows:
+This ZIP proposes:
+After the 1st Zcash Halvening, when the "Founders’ Reward" system- bootstrapping protocol-based development funding expires, continue to direct 20% of new ZEC issuance to development-related activities for ongoing research, development, innovation, and maintenance of Zcash.
+Assign half of such funds to the ECC, and half to the ZF. Continue this allocation until the 2nd Halvening.
+There have been many proposals for potential allocations of Zcash block rewards (ZEC inflation) after the 1st Halvening. Many cluster around similar broad parameters:
+However, no existing ZIPs explicitly propose the most simple variation on this theme - one that maintains maximal continuity with prior practice. This 'Keep It Simple, Zcashers' ZIP aims to fill that gap.
+This proposal intends to be easy to describe, understand, and implement.
+This proposal does not seek to propose any particular course of action past the 2nd Halvening.
+To implement this ZIP, the Zcash protocol and compatible software MUST:
+This proposal specifically refrains from adding any new conditions or procedural formalities, technical or legal, on the delivery of development funds.
+There is only the expectation that these recipients SHOULD continue the stated missions, practices of transparency, and responsiveness to community input that they have demonstrated thus far.
+This proposal primarily differs from similar proposals in two ways: (1) it places no new comditions/processes on the disbursement of ZEC development funds; (2) it specifies a fixed, 50-50 division-of-funds between the ECC and ZF.
+These differences are motivated by a desire for simplicity and continuity. This allocation can be implemented technically without novel institutions, processes, or legal agreements.
+Rather than relying on lists-of-conditions with underspecified enforcement or dispute-resolution mechanisms, the adequate performance of fund recipients is expected due to:
+From original "Founders’ Reward"-era development-funds, roughly 15% has been directed to the ZF. (Or, about 3 points of the full 20 points of bootstrap- funds.) However, from its later start, the ZF has recently grown its technical, grantmaking, and organizational capabilities, and wide sentiment in the Zcash community, ECC, and ZF desires the ZF grow to a role of equivalent or greater importance as the ECC for long-term Zcash evolution. Thus this proposal specifies a 50:50 split of future development funds, rather than continuing any prior proportions.
+| 1 | +Key words for use in RFCs to Indicate Requirement Levels | +
|---|