diff --git a/README.rst b/README.rst index 6a9101c9..5c6e5eeb 100644 --- a/README.rst +++ b/README.rst @@ -72,7 +72,7 @@ Released ZIPs 211 Disabling Addition of New Value to the Sprout Chain Value Pool Final 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final 213 Shielded Coinbase Final - 214 Consensus rules for a Zcash Development Fund Final + 214 Consensus rules for a Zcash Development Fund Revision 0: Final, Revision 1: Draft 215 Explicitly Defining and Modifying Ed25519 Validation Rules Final 216 Require Canonical Jubjub Point Encodings Final 221 FlyClient - Consensus-Layer Changes Final @@ -93,6 +93,8 @@ Released ZIPs 321 Payment Request URIs Proposed 401 Addressing Mempool Denial-of-Service Active 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active + 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 2001 Lockbox Funding Streams Proposed Draft ZIPs @@ -150,7 +152,6 @@ written. 402 New Wallet Database Format Reserved 403 Verification Behaviour of zcashd Reserved 416 Support for Unified Addresses in zcashd Reserved - 2001 Lockbox Funding Streams Draft guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft @@ -232,7 +233,7 @@ Index of ZIPs 211 Disabling Addition of New Value to the Sprout Chain Value Pool Final 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final 213 Shielded Coinbase Final - 214 Consensus rules for a Zcash Development Fund Final + 214 Consensus rules for a Zcash Development Fund Revision 0: Final, Revision 1: Draft 215 Explicitly Defining and Modifying Ed25519 Validation Rules Final 216 Require Canonical Jubjub Point Encodings Final 217 Aggregate Signatures Reserved @@ -302,7 +303,8 @@ Index of ZIPs 1012 Dev Fund to ECC + ZF + Major Grants Obsolete 1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active - 2001 Lockbox Funding Streams Draft + 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 2001 Lockbox Funding Streams Proposed guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft diff --git a/rendered/draft-noamchom67-manufacturing-consent.html b/rendered/draft-noamchom67-manufacturing-consent.html index e5bdf1b9..8a4bf295 100644 --- a/rendered/draft-noamchom67-manufacturing-consent.html +++ b/rendered/draft-noamchom67-manufacturing-consent.html @@ -10,7 +10,7 @@ Title: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub Owner: Noam Chom <noamchom1967@gmail.com> Credits: The ZIP-1014 Authors -Status: Active +Status: Withdrawn Category: Consensus Process Created: 2024-06-25 License: MIT diff --git a/rendered/draft-zf-community-dev-fund-2-proposal.html b/rendered/draft-zf-community-dev-fund-2-proposal.html index 4fdd60ea..13c5b253 100644 --- a/rendered/draft-zf-community-dev-fund-2-proposal.html +++ b/rendered/draft-zf-community-dev-fund-2-proposal.html @@ -10,7 +10,7 @@ Title: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve Owners: Jack Gavigan <jack@zfnd.org> Credits: The ZIP 1014 Authors -Status: Draft +Status: Withdrawn Category: Consensus Process Created: 2024-07-01 License: MIT diff --git a/rendered/index.html b/rendered/index.html index 8ee5e0a9..4c20da6c 100644 --- a/rendered/index.html +++ b/rendered/index.html @@ -47,7 +47,7 @@ 211 Disabling Addition of New Value to the Sprout Chain Value Pool Final 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final 213 Shielded Coinbase Final - 214 Consensus rules for a Zcash Development Fund Final + 214 Consensus rules for a Zcash Development Fund Revision 0: Final, Revision 1: Draft 215 Explicitly Defining and Modifying Ed25519 Validation Rules Final 216 Require Canonical Jubjub Point Encodings Final 221 FlyClient - Consensus-Layer Changes Final @@ -68,6 +68,8 @@ 321 Payment Request URIs Proposed 401 Addressing Mempool Denial-of-Service Active 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active + 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 2001 Lockbox Funding Streams Proposed

Draft ZIPs

These are works-in-progress that have been assigned ZIP numbers. These will eventually become either Proposed (and thus Released), or one of Withdrawn, Rejected, or Obsolete.

@@ -115,7 +117,6 @@ 402 New Wallet Database Format Reserved 403 Verification Behaviour of zcashd Reserved 416 Support for Unified Addresses in zcashd Reserved - 2001 Lockbox Funding Streams Draft guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft
@@ -178,7 +179,7 @@ 211 Disabling Addition of New Value to the Sprout Chain Value Pool Final 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Final 213 Shielded Coinbase Final - 214 Consensus rules for a Zcash Development Fund Final + 214 Consensus rules for a Zcash Development Fund Revision 0: Final, Revision 1: Draft 215 Explicitly Defining and Modifying Ed25519 Validation Rules Final 216 Require Canonical Jubjub Point Encodings Final 217 Aggregate Signatures Reserved @@ -248,7 +249,8 @@ 1012 Dev Fund to ECC + ZF + Major Grants Obsolete 1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active - 2001 Lockbox Funding Streams Draft + 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 2001 Lockbox Funding Streams Proposed guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft diff --git a/rendered/zip-0214.html b/rendered/zip-0214.html index 1e49cae6..be8647c7 100644 --- a/rendered/zip-0214.html +++ b/rendered/zip-0214.html @@ -9,44 +9,135 @@ 
ZIP: 214
 Title: Consensus rules for a Zcash Development Fund
 Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
-Status: Final
+        Kris Nuttycombe <kris@nutty.land>
+Status: Revision 0: Final, Revision 1: Draft
 Category: Consensus
 Created: 2020-02-28
 License: MIT
 Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>

Terminology

The key words "MUST", "SHALL", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

-

The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (6 or successor agreement).

+

The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (6 or successor agreement) while that agreement is in effect. On termination of that agreement, the term "Zcash" will refer to the continuations of the same Mainnet and Testnet block chains as determined by social consensus.

The term "network upgrade" in this document is to be interpreted as described in ZIP 200 8 and the Zcash Trademark Donation and License Agreement (6 or successor agreement).

The term "block subsidy" in this document is to be interpreted as described in section 3.10 of the Zcash Protocol Specification 3.

The term "halving" in this document are to be interpreted as described in sections 7.8 of the Zcash Protocol Specification 5.

-

The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 12.

-

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 4.

+

The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 13.

+

The terms "Zcash Community Grants (or "ZCG") and "Financial Privacy Foundation" (or "FPF") in this document are to be interpreted as described in ZIP 1015 14.

+

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 4.

"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.

+

"NU6" is the code-name for the seventh Zcash network upgrade, also known as Network Upgrade 6.

Abstract

-

This ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.

+

Revision 0 of this ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.

+

Revision 1 of this ZIP describes consensus rule changes related to funding of Zcash development via block rewards, to be enacted at Network Upgrade 6 and lasting for 1 year.

Applicability

This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other block chains using Zcash technology.

Motivation

-

Motivation for the Zcash Development Fund itself is considered in ZIP 1014 12, which gives a high-level description of the intended structure of the fund.

-

An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.

+

Motivation for the Zcash Development Fund itself is considered in ZIPs 1014 13 and 1015 14, which give high-level descriptions of the intended structure of the funds.

+

An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIPs 1014 and 1015, which have already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIPs 1014 and 1015.

Requirements

-

The primary requirement of this ZIP is to make changes to consensus rules necessary and sufficient to implement the intent of ZIP 1014.

+

The primary requirement of this ZIP is to make changes to consensus rules necessary and sufficient to implement the intent of ZIPs 1014 and 1015.

The Zcash Development Fund distributes funding in ZEC obtained from block subsidies on Mainnet. This ZIP should also specify corresponding rules, addresses, and activation height for Testnet, in order to allow testing and auditing of the design and implementation within sufficient lead time before activation on Mainnet.

Non-requirements

-

This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what is implementable by Zcash consensus rules.

+

This ZIP is not required to enforce provisions of ZIP 1014 or ZIP 1015 that fall outside what is implementable by Zcash consensus rules.

Specification

-

The Blossom network upgrade changed the height of the first halving to block height 1046400 10, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.

-

Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400.

-

ZIP 207 9 SHALL be activated in Canopy.

-

The following funding streams are defined for Mainnet:

-
+

Revisions

+
    +
  • Revision 0: The initial version of this specification, as agreed upon by the Zcash community in ZIP 1014 13.
    • +
+
    +
  • Revision 1: Funding streams defined to start at Zcash's second halving, and last for one year, as agreed upon in ZIP 1015 14.
    • +
+
+

Activation

+

The Blossom network upgrade changed the height of the first halving to block height 1046400 10, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.

+

Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400.

+

Revision 0 of ZIP 207 9 SHALL be activated in Canopy.

+

Since ZIP 1015 specifies that the specified funding streams start at the second halving, the activation height of NU6 on Mainnet therefore SHALL be 2726400.

+

Revision 1 of ZIP 207 9 SHALL be activated in NU6.

+

As specified in 9, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.

+
+

Funding Streams

+

As of Revision 0, the following funding streams are defined for Mainnet:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_ZIP214_BP710010464002726400
FS_ZIP214_ZF510010464002726400
FS_ZIP214_MG810010464002726400
+
+

As of Revision 0, the following funding streams are defined for Testnet:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_ZIP214_BP710010285002796000
FS_ZIP214_ZF510010285002796000
FS_ZIP214_MG810010285002796000
+
+

As of Revision 1, the following additional streams are defined for Mainnet:

@@ -59,32 +150,22 @@ Discussions-To: <9, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.

-

The following funding streams are defined for Testnet:

-
+

As of Revision 1, the following additional streams are defined for Testnet:

@@ -97,50 +178,47 @@ Discussions-To: <

Dev Fund Recipient Addresses

+

Notes for Revision 0:

+
    +
  • The block heights of halvings are different between Testnet and Mainnet, as a result of different activation heights for the Blossom network upgrade (which changed the block target spacing). The end height of these funding streams corresponds to the second halving on each network.
    • +
  • On Testnet, the activation height of Canopy will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1116000) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1116000 (inclusive) to 2796000 (exclusive).
    • +
+

Notes for Revision 1:

+
    +
  • The new funding streams begin at the second halving for Mainnet, but the second halving on Testnet occurred prior to the introduction of the new funding streams. For both new funding streams on each network, the associated duration corresponds to approximately one year's worth of blocks.
    • +
+ +
+

Dev Fund Recipient Addresses for Revision 0

For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC on behalf of BP; and ZF) SHALL generate sequences of recipient addresses to be used for each stream in each funding period:

  • ECC SHALL generate the addresses for the FS_ZIP214_BP funding stream, which on Mainnet corresponds to the BP slice;
  • ZF SHALL generate the addresses for the FS_ZIP214_ZF and FS_ZIP214_MG funding streams, which on Mainnet correspond to the ZF slice and MG slice respectively.

Within each stream, the addresses MAY be independent, or MAY be repeated between funding periods. Each party SHOULD take account of operational security issues associated with potential compromise of the associated spending keys.

-

Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 12.

+

Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 13.

No requirements are imposed on the use of funds sent to Testnet funding streams.

Direct-grant option

-

ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 12

-

The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total value of funding streams assigned to direct grantees MUST be subtracted from the value of the funding stream for the remaining MG slice (or, if all Major Grants are direct, replace the funding stream for the MG slice).

-

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

+

ZIP 1014 specified a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 13 However, this option was never taken up.

-

Mainnet Recipient Addresses

+
+

Mainnet Recipient Addresses for Revision 0

FS_ZIP214_BP.AddressList[0..47] = [
   "t3LmX1cxWPPPqL4TZHx42HU3U5ghbFjRiif",
   "t3Toxk1vJQ6UjWQ42tUJz2rV2feUWkpbTDs",
@@ -197,7 +275,12 @@ FS_ZIP214_ZF.AddressList[0..47] = ["t3dvVE3SQEi7kqNzwrfNePxZ1d4hUyztBA1"] * 48
 FS_ZIP214_MG.AddressList[0..47] = ["t3XyYW8yBFRuMnfvm5KLGFbEVz25kckZXym"] * 48

(i.e. FS_ZIP214_ZF.AddressList and FS_ZIP214_MG.AddressList for Mainnet each consist of 48 repetitions of the same address).

-

Testnet Recipient Addresses

+
+

Mainnet Recipient Addresses for Revision 1

+

<TBD>

+
+
+

Testnet Recipient Addresses for Revision 0

FS_ZIP214_BP.AddressList[0..50] = [
   "t26ovBdKAJLtrvBsE2QGF4nqBkEuptuPFZz",
   "t26ovBdKAJLtrvBsE2QGF4nqBkEuptuPFZz",
@@ -257,14 +340,21 @@ FS_ZIP214_ZF.AddressList[0..50] = ["t27eWDgjFYJGVXmzrXeVjnb5J3uXDM9xH9v"] * 51
 FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51

(i.e. FS_ZIP214_ZF.AddressList and FS_ZIP214_MG.AddressList for Testnet each consist of 51 repetitions of the same address).

+
+

Testnet Recipient Addresses for Revision 1

+
+

FS_FPF_ZCG.AddressList[0..12] = ["t2HifwjUj9uyxr9bknR8LFuQbc98c3vkXtu"] * 13

+
+
-

Rationale

-

The rationale for ZF generating the addresses for the FS_ZIP214_MG funding stream is that ZF is the financial recipient of the MG slice as specified in ZIP 1014. 12

+
+

Rationale for Revision 0

+

The rationale for ZF generating the addresses for the FS_ZIP214_MG funding stream is that ZF is the financial recipient of the MG slice as specified in ZIP 1014. 13

Generation of recipient addresses for Testnet is specified to be done by the same parties as on Mainnet, in order to allow practicing each party's security procedures.

It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.

Deployment

-

This proposal is intended to be deployed with Canopy. 11

+

Revision 0 of this proposal was deployed with Canopy. 11 Revision 1 of this proposal is intended to be deployed with NU6. 12

References

@@ -279,7 +369,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51 - +
2Zcash Protocol Specification, Version 2021.2.16 or laterZcash Protocol Specification, Version 2023.4.0 or later
@@ -287,7 +377,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51 3 - Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward + Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward @@ -295,7 +385,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51 4 - Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet + Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 3.12: Mainnet and Testnet @@ -303,7 +393,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51 5 - Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward + Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward @@ -355,14 +445,30 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51 - +
+ + + +
12ZIP 253: Deployment of the NU6 Network Upgrade
+ + + +
13 ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
+ + + + + + + +
14ZIP 1015: Block Reward Allocation for Non-Direct Development Funding
diff --git a/rendered/zip-1015.html b/rendered/zip-1015.html new file mode 100644 index 00000000..2381a2b4 --- /dev/null +++ b/rendered/zip-1015.html @@ -0,0 +1,222 @@ + + + + ZIP 1015: Block Reward Allocation for Non-Direct Development Funding + + + +
+ 
ZIP: 1015
+Title: Block Reward Allocation for Non-Direct Development Funding
+Owners: Jason McGee <aquietinvestor@gmail.com>
+        @Peacemonger (Zcash Forum)
+        Kris Nuttycombe <kris@nutty.land>
+Credits: @GGuy (Zcash Forum)
+         Daira-Emma Hopwood
+         Jack Grigg
+         Skylar Saveland
+Status: Proposed
+Category: Consensus
+Created: 2024-08-26
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/881>
+

Terminology

+

The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

+

"Zcash Community Advisory Panel", also called "ZCAP", refers to the panel of community members assembled by the Zcash Foundation and described at 5.

+

"Zcash Community Grants", also called "ZCG", refers to the committee selected by the Zcash Community Advisory Panel or a successor process (e.g. as established by FPF) to decide on the funding of grants intended to fund the Zcash ecosystem.

+

"Financial Privacy Foundation", also called "FPF", refers to the Cayman Islands-incorporated non-profit foundation company limited by guarantee of that name.

+
+

Abstract

+

This ZIP proposes the allocation of a percentage of the Zcash block subsidy, post-November 2024 halving, split between Zcash Community Grants (ZCG) and an in-protocol "lockbox." The "lockbox" is a separate pool of issued funds tracked by the protocol, as described in ZIP 2001: Lockbox Funding Streams 4. No disbursement mechanism is currently defined for this "lockbox"; the Zcash community will need to decide upon and specify a suitable decentralized mechanism for permitting withdrawals from this lockbox in a future ZIP in order to make these funds available for funding grants to ecosystem participants.

+

The proposed lockbox addresses significant issues observed with ZIP 1014 3, such as regulatory risks, inefficiencies due to funding of organizations instead of projects, and centralization. While the exact disbursement mechanism for the lockbox funds is yet to be determined and will be addressed in a future ZIP, the goal is to employ a decentralized mechanism that ensures community involvement and efficient, project-specific funding. This approach is intended to potentially improve regulatory compliance, reduce inefficiencies, and enhance the decentralization of Zcash's funding structure.

+
+

Motivation

+

Starting at Zcash's second halving in November 2024, under pre-existing consensus rules 100% of the block subsidies would be allocated to miners, and no further funds would be automatically allocated to any other entities. Consequently, unless the community takes action to approve new block-reward-based funding, existing teams dedicated to development or outreach or furthering charitable, educational, or scientific purposes would likely need to seek other sources of funding; failure to obtain such funding would likely impair their ability to continue serving the Zcash ecosystem. Setting aside a portion of the block subsidy to fund development will help ensure that both existing teams and new contributors can obtain funding in the future.

+

It is important to balance the incentives for securing the consensus protocol through mining with funding crucial charitable, educational, and scientific activities like research, development, and outreach. Additionally, there is a need to continue to promote decentralization and the growth of independent development teams.

+

For these reasons, the Zcash Community wishes to establish a new Zcash Development Fund after the second halving in November 2024, with the intent to put in place a more decentralized mechanism for allocation of development funds. The alternatives presented here are intended to address the following:

+
    +
  1. Regulatory Risks: The current model involves direct funding of US-based organizations, which can potentially attract regulatory scrutiny from entities such as the SEC, posing legal risks to the Zcash ecosystem.
    2. +
  2. Funding Inefficiencies: The current model directly funds organizations rather than specific projects, leading to a potential mismatch between those organizations' development priorities and the priorities of the community. Furthermore, if organizations are guaranteed funds regardless of performance, there is little incentive to achieve key performance indicators (KPIs) or align with community sentiment. A future system that allocates resources directly to projects rather than organizations may help reduce inefficiencies and better align development efforts with community priorities.
    3. +
  3. Centralization Concerns: The current model centralizes decision-making power within a few organizations, contradicting the decentralized ethos of blockchain technology. Traditional organizational structures with boards and executives introduce single points of failure and limit community involvement in funding decisions.
    4. +
  4. Community Involvement: The current system provides minimal formal input from the community regarding what projects should be funded, leading to a misalignment between funded projects and community priorities.
    5. +
  5. Moving Towards a Non-Direct Funding Model: There is strong community support for a non-direct Dev Fund funding model. Allocating funds to a Deferred Dev Fund Lockbox incentivizes the development of a decentralized mechanism for the disbursement of the locked funds.
    6. +
  6. Limited Runway: ZCG does not have the financial runway that ECC/BP and ZF have. As such, allocating ongoing funding to ZCG will help ensure the Zcash ecosystem has an active grants program.
    7. +
  7. Promoting Decentralization: Allocating a portion of the Dev Fund to Zcash Community Grants ensures small teams continue to receive funding to contribute to Zcash. Allowing the Dev Fund to expire, or putting 100% into a lockbox, would disproportionally impact grant recipients. This hybrid approach promotes decentralization and the growth of independent development teams.
    8. +
  8. Mitigating Regulatory Risks: The Financial Privacy Foundation (FPF) is a non-profit organization incorporated and based in the Cayman Islands. By minimizing direct funding of US-based organizations, this proposal helps to reduce potential regulatory scrutiny and legal risks.
    9. +
+

By addressing these issues, this proposal aims to ensure sustainable, efficient, and decentralized funding for essential activities within the Zcash ecosystem.

+
+

Requirements

+
    +
  1. In-Protocol Lockbox: The alternatives presented in this ZIP depend upon the Lockbox Funding Streams proposal 4.
    2. +
  2. Regulatory Considerations: The allocation of funds should minimize regulatory risks by avoiding direct funding of specific organizations. The design should enable and encourage compliance with applicable laws and regulations to support the long-term sustainability of the funding model.
    3. +
+
+

Non-requirements

+

The following considerations are explicitly deferred to future ZIPs and are not covered by this proposal:

+
    +
  1. Disbursement Mechanism: The exact method for disbursing the accumulated funds from the lockbox is not defined in this ZIP. The design, implementation, and governance of the disbursement mechanism will be addressed in a future ZIP. This includes specifics on how funds will be allocated, the voting or decision-making process, and the structure of the decentralized mechanism (such as a DAO).
    2. +
  2. Regulatory Compliance Details: The proposal outlines the potential to reduce regulatory risks by avoiding direct funding of US-based organizations, but it does not detail specific regulatory compliance strategies. Future ZIPs will need to address how the disbursement mechanism complies with applicable laws and regulations.
    3. +
  3. Impact Assessment: The long-term impact of reallocating a portion of the block subsidy to the lockbox on the Zcash ecosystem, including its effect on miners, developers, and the broader community, is not analyzed in this ZIP. Subsequent proposals will need to evaluate the outcomes and make necessary adjustments based on real-world feedback and data.
    4. +
+
+

Specification

+

Development Funding Recipients

+

Lockbox

+

The "lockbox" is a pool of issued funds tracked by the protocol, as described in ZIP 2001: Lockbox Funding Streams 4. No disbursement mechanism is currently defined for this "lockbox"; the Zcash community will need to decide upon and specify a suitable decentralized mechanism for permitting withdrawals from this lockbox in a future ZIP in order to make these funds available for funding grants to ecosystem participants.

+
+

Zcash Community Grants (ZCG)

+

The stream allocated to Zcash Community Grants (ZCG) is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem, to the extent that such teams are available and effective. The 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 the Financial Privacy Foundation (FPF). FPF MUST disburse them for grants and expenses reasonably related to the administration of the ZCG program, but subject to the following additional constraints:

+
    +
  1. These funds MUST only be used to issue grants to external parties that are independent of FPF, and to pay for expenses reasonably related to the administration of the ZCG program. They MUST NOT be used by FPF for its internal operations and direct expenses not related to the administration of grants or the grants program.
    2. +
  2. ZCG 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. +
  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. +
  4. The ZCG committee SHOULD be restricted to funding projects that further the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general) as permitted by FPF and any relevant jurisdictional requirements.
    5. +
  5. ZCG awards are subject to approval by a five-seat ZCG Committee. The ZCG Committee SHALL be selected by the ZF’s Community Advisory Panel or a successor process (e.g. as established by FPF). Elections SHALL be staggered to ensure continuity within the Committee.
    6. +
  6. The ZCG Committee’s funding decisions will be final, requiring no approval from the FPF Board, but are subject to veto if the FPF judges them to violate any relevant laws or other (current or future) obligations.
    7. +
  7. ZCG Committee members SHALL have a one-year term and MAY sit for reelection. The ZCG Committee is subject to the same conflict of interest policy that governs the FPF 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, at most one person with association with the ZF, and at most one person with association with FPF are allowed to sit on the ZCG 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). Similarly, FPF should also endeavor to establish its own means of collecting community sentiment for the purpose of administering ZCG elections.
    8. +
  8. 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 the ZCG program. 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 ZCG Committee. Expenses related to the administration of the ZCG program 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 ZCG Committee.
      • +
    • Paying independent consultants to develop requests for proposals that align with the ZCG program.
      • +
    • Paying independent consultants for expert review of grant applications.
      • +
    • Paying for sales and marketing services to promote the ZCG program.
      • +
    • Paying third party consultants to undertake activities that support the purpose of the ZCG program.
      • +
    • Reimbursement to members of the ZCG Committee for reasonable travel expenses, including transportation, hotel and meals allowance.
      • +
    +
    9. +
  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 FPF. The compensation rate and hours for committee members SHALL be determined by the ZF’s Community Advisory Panel or successor process.
    10. +
  10. The ZCG Committee’s decisions relating to the allocation and disbursement of funds from the Discretionary Budget will be final, requiring no approval from the FPF Board, but are subject to veto if the FPF judges them to violate laws or FPF reporting requirements and other (current or future) obligations.
    11. +
+

FPF 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.

+

FPF SHALL strive to define target metrics and key performance indicators, and the ZCG Committee SHOULD utilize these in its funding decisions.

+
Furthering Decentralization
+

FPF SHALL conduct periodic 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, FPF 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 keep its domicile outside of the United States.

+
+
Transparency and Accountability
+

FPF MUST accept the following obligations in this section on behalf of ZCG:

+
    +
  • Publication of the ZCG Dashboard, providing a snapshot of ZCG’s current financials and any disbursements made to grantees.
    • +
  • Bi-weekly meeting minutes documenting the decisions made by the ZCG committee on grants.
    • +
  • Quarterly reports, detailing future plans, execution on previous plans, and finances (balances, and spending broken down by major categories).
    • +
  • Annual detailed review of the organization performance and future plans.
    • +
  • Annual financial report (IRS Form 990, or substantially similar information).
    • +
+

BP, ECC, ZF, FPF, ZCG 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).

+

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 2), preferably the MIT license.

+
+
Enforcement
+

FPF MUST contractually commit to fulfill these obligations on behalf of ZCG, and the prescribed use of funds, such that substantial violation, not promptly remedied, will result in a modified version of Zcash node software that removes ZCG’s Dev Fund slice and allocates it to the Deferred Dev Fund lockbox.

+
+
+
+

Funding Streams

+
    +
  • 12% of the block subsidy is to be distributed to the lockbox.
    • +
  • 8% of the block subsidy is to be distributed to the Financial Privacy Foundation (FPF), for the express use of the Zcash Community Grants Committee (ZCG) to fund independent teams in the Zcash ecosystem.
    • +
+

As of the activation of this ZIP, the complete set of funding streams for Mainnet will be:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_DEFERRED1210027264003146400
FS_FPF_ZCG810027264003146400
+

The set of funding streams for Testnet will be:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_DEFERRED1210029760003396000
FS_FPF_ZCG810029760003396000
+
+
+

References

+ + + + + + + +
1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
+ + + + + + + +
2The Open Source Definition
+ + + + + + + +
3ZIP 1014: Dev Fund Proposal and Governance
+ + + + + + + +
4ZIP 2001: Lockbox Funding Streams
+ + + + + + + +
5Zcash Community Advisory Panel
+
+
+ + \ No newline at end of file diff --git a/rendered/zip-2001.html b/rendered/zip-2001.html index abd6514e..bc2f3d31 100644 --- a/rendered/zip-2001.html +++ b/rendered/zip-2001.html @@ -12,7 +12,7 @@ Title: Lockbox Funding Streams Owners: Kris Nuttycombe <kris@nutty.land> Credits: Daira-Emma Hopwood <daira-emma@electriccoin.co> Jack Grigg <jack@electriccoin.co> -Status: Draft +Status: Proposed Category: Consensus Created: 2024-07-02 License: MIT diff --git a/zips/draft-noamchom67-manufacturing-consent.rst b/zips/draft-noamchom67-manufacturing-consent.rst index 1116732e..bbbb9e35 100644 --- a/zips/draft-noamchom67-manufacturing-consent.rst +++ b/zips/draft-noamchom67-manufacturing-consent.rst @@ -4,7 +4,7 @@ Title: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub Owner: Noam Chom Credits: The ZIP-1014 Authors - Status: Active + Status: Withdrawn Category: Consensus Process Created: 2024-06-25 License: MIT diff --git a/zips/draft-nuttycom-funding-allocation.rst b/zips/draft-nuttycom-funding-allocation.rst index 15b2bd51..81cd398f 100644 --- a/zips/draft-nuttycom-funding-allocation.rst +++ b/zips/draft-nuttycom-funding-allocation.rst @@ -8,7 +8,7 @@ Credits: Daira-Emma Hopwood Jack Grigg @Peacemonger (Zcash Forum) - Status: Draft + Status: Withdrawn Category: Consensus Created: 2024-07-03 License: MIT diff --git a/zips/draft-zf-community-dev-fund-2-proposal.rst b/zips/draft-zf-community-dev-fund-2-proposal.rst index 30182c7f..603aa981 100644 --- a/zips/draft-zf-community-dev-fund-2-proposal.rst +++ b/zips/draft-zf-community-dev-fund-2-proposal.rst @@ -4,7 +4,7 @@ Title: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve Owners: Jack Gavigan Credits: The ZIP 1014 Authors - Status: Draft + Status: Withdrawn Category: Consensus Process Created: 2024-07-01 License: MIT diff --git a/zips/zip-0214.rst b/zips/zip-0214.rst index 7efbda2d..2f153919 100644 --- a/zips/zip-0214.rst +++ b/zips/zip-0214.rst @@ -3,7 +3,8 @@ ZIP: 214 Title: Consensus rules for a Zcash Development Fund Owners: Daira-Emma Hopwood - Status: Final + Kris Nuttycombe + Status: Revision 0: Final, Revision 1: Draft Category: Consensus Created: 2020-02-28 License: MIT @@ -19,7 +20,9 @@ in all capitals. The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement ([#trademark]_ or successor -agreement). +agreement) while that agreement is in effect. On termination of that agreement, +the term "Zcash" will refer to the continuations of the same Mainnet and Testnet +block chains as determined by social consensus. 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 @@ -36,19 +39,30 @@ The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "MG slice" in this document are to be interpreted as described in ZIP 1014 [#zip-1014]_. +The terms "Zcash Community Grants (or "ZCG") and "Financial Privacy Foundation" +(or "FPF") in this document are to be interpreted as described in ZIP 1015 +[#zip-1015]_. + The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. "Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4. +"NU6" is the code-name for the seventh Zcash network upgrade, also known as +Network Upgrade 6. + Abstract ======== -This ZIP describes consensus rule changes interpreting the proposed structure of -the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last -for 4 years. +`Revision 0`_ of this ZIP describes consensus rule changes interpreting the +proposed structure of the Zcash Development Fund, which is to be enacted in +Network Upgrade 4 and last for 4 years. + +`Revision 1`_ of this ZIP describes consensus rule changes related to funding +of Zcash development via block rewards, to be enacted at Network Upgrade 6 and +lasting for 1 year. Applicability @@ -61,21 +75,22 @@ applicable to other block chains using Zcash technology. Motivation ========== -Motivation for the Zcash Development Fund itself is considered in ZIP 1014 -[#zip-1014]_, which gives a high-level description of the intended structure of -the fund. +Motivation for the Zcash Development Fund itself is considered in ZIPs 1014 +[#zip-1014]_ and 1015 [#zip-1015]_, which give high-level descriptions of the +intended structure of the funds. An important motivation for describing the consensus rules in a separate ZIP is -to avoid making unintended changes to ZIP 1014, which has already been agreed -between ECC, ZF, and the Zcash community. This facilitates critically assessing -whether the consensus rule changes accurately reflect the intent of ZIP 1014. +to avoid making unintended changes to ZIPs 1014 and 1015, which have already +been agreed between ECC, ZF, and the Zcash community. This facilitates +critically assessing whether the consensus rule changes accurately reflect the +intent of ZIPs 1014 and 1015. Requirements ============ The primary requirement of this ZIP is to make changes to consensus rules necessary -and sufficient to implement the intent of ZIP 1014. +and sufficient to implement the intent of ZIPs 1014 and 1015. The Zcash Development Fund distributes funding in ZEC obtained from block subsidies on Mainnet. This ZIP should also specify corresponding rules, addresses, and @@ -86,13 +101,29 @@ and implementation within sufficient lead time before activation on Mainnet. Non-requirements ================ -This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what -is implementable by Zcash consensus rules. +This ZIP is not required to enforce provisions of ZIP 1014 or ZIP 1015 that fall +outside what is implementable by Zcash consensus rules. Specification ============= +Revisions +--------- + +.. _`Revision 0`: + +* Revision 0: The initial version of this specification, as agreed upon + by the Zcash community in ZIP 1014 [#zip-1014]_. + +.. _`Revision 1`: + +* Revision 1: Funding streams defined to start at Zcash's second halving, + and last for one year, as agreed upon in ZIP 1015 [#zip-1015]_. + +Activation +---------- + The Blossom network upgrade changed the height of the first halving to block height 1046400 [#zip-0208]_, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds. @@ -100,9 +131,21 @@ The Blossom network upgrade changed the height of the first halving to block hei Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400. -ZIP 207 [#zip-0207]_ SHALL be activated in Canopy. +`Revision 0`_ of ZIP 207 [#zip-0207]_ SHALL be activated in Canopy. -The following funding streams are defined for Mainnet: +Since ZIP 1015 specifies that the specified funding streams start at the second +halving, the activation height of NU6 on Mainnet therefore SHALL be 2726400. + +`Revision 1`_ of ZIP 207 [#zip-0207]_ SHALL be activated in NU6. + +As specified in [#zip-0207]_, a funding stream is active for a span of blocks +that includes the block at its start height, but excludes the block at its end +height. + +Funding Streams +--------------- + +As of `Revision 0`_, the following funding streams are defined for Mainnet: ================= =========== ============= ============== ============ Stream Numerator Denominator Start height End height @@ -112,11 +155,7 @@ The following funding streams are defined for Mainnet: ``FS_ZIP214_MG`` 8 100 1046400 2726400 ================= =========== ============= ============== ============ -As specified in [#zip-0207]_, a funding stream is active for a span of blocks -that includes the block at its start height, but excludes the block at its end -height. - -The following funding streams are defined for Testnet: +As of `Revision 0`_, the following funding streams are defined for Testnet: ================= =========== ============= ============== ============ Stream Numerator Denominator Start height End height @@ -126,7 +165,25 @@ The following funding streams are defined for Testnet: ``FS_ZIP214_MG`` 8 100 1028500 2796000 ================= =========== ============= ============== ============ -Notes: +As of `Revision 1`_, the following additional streams are defined for Mainnet: + +================= =========== ============= ============== ============ + Stream Numerator Denominator Start height End height +================= =========== ============= ============== ============ +``FS_DEFERRED`` 12 100 2726400 3146400 +``FS_FPF_ZCG`` 8 100 2726400 3146400 +================= =========== ============= ============== ============ + +As of `Revision 1`_, the following additional streams are defined for Testnet: + +================= =========== ============= ============== ============ + Stream Numerator Denominator Start height End height +================= =========== ============= ============== ============ +``FS_DEFERRED`` 12 100 2976000 3396000 +``FS_FPF_ZCG`` 8 100 2976000 3396000 +================= =========== ============= ============== ============ + +Notes for `Revision 0`_: * The block heights of halvings are different between Testnet and Mainnet, as a result of different activation heights for the Blossom network upgrade (which @@ -139,9 +196,15 @@ Notes: initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1116000 (inclusive) to 2796000 (exclusive). +Notes for `Revision 1`_: -Dev Fund Recipient Addresses ----------------------------- +* The new funding streams begin at the second halving for Mainnet, but the second + halving on Testnet occurred prior to the introduction of the new funding streams. + For both new funding streams on each network, the associated duration + corresponds to approximately one year's worth of blocks. + +Dev Fund Recipient Addresses for `Revision 0`_ +---------------------------------------------- For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC on behalf @@ -163,26 +226,16 @@ the corresponding slice specified in ZIP 1014 [#zip-1014]_. No requirements are imposed on the use of funds sent to Testnet funding streams. - Direct-grant option ''''''''''''''''''' -ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC +ZIP 1014 specified a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the **MG slice** may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. [#zip-1014]_ +However, this option was never taken up. -The funding stream mechanism allows for this option by adding a funding stream -corresponding to each direct grantee, with addresses generated by ZF. In this case -the total value of funding streams assigned to direct grantees MUST be subtracted -from the value of the funding stream for the remaining **MG slice** (or, if all -Major Grants are direct, replace the funding stream for the **MG slice**). - -For each network upgrade after Canopy requiring modifications to the set of direct -grantees, a separate ZIP SHOULD be published specifying those modifications. - - -Mainnet Recipient Addresses ---------------------------- +Mainnet Recipient Addresses for `Revision 0`_ +--------------------------------------------- :: @@ -244,9 +297,13 @@ Mainnet Recipient Addresses (i.e. ``FS_ZIP214_ZF.AddressList`` and ``FS_ZIP214_MG.AddressList`` for Mainnet each consist of 48 repetitions of the same address). +Mainnet Recipient Addresses for `Revision 1`_ +--------------------------------------------- -Testnet Recipient Addresses ---------------------------- + + +Testnet Recipient Addresses for `Revision 0`_ +--------------------------------------------- :: @@ -311,9 +368,14 @@ Testnet Recipient Addresses (i.e. ``FS_ZIP214_ZF.AddressList`` and ``FS_ZIP214_MG.AddressList`` for Testnet each consist of 51 repetitions of the same address). +Testnet Recipient Addresses for `Revision 1`_ +--------------------------------------------- -Rationale -========= + FS_FPF_ZCG.AddressList[0..12] = ["t2HifwjUj9uyxr9bknR8LFuQbc98c3vkXtu"] * 13 + + +Rationale for `Revision 0`_ +=========================== The rationale for ZF generating the addresses for the ``FS_ZIP214_MG`` funding stream is that ZF is the financial recipient of the **MG slice** as specified @@ -331,21 +393,24 @@ other than at network upgrades. Deployment ========== -This proposal is intended to be deployed with Canopy. [#zip-0251]_ +`Revision 0`_ of this proposal was deployed with Canopy. [#zip-0251]_ +`Revision 1`_ of this proposal is intended to be deployed with NU6. [#zip-0253]_ References ========== .. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_ -.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ -.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ -.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward `_ +.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later `_ +.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2023.4.0 [NU5]. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward `_ .. [#trademark] `Zcash Trademark Donation and License Agreement `_ .. [#osd] `The Open Source Definition `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0207] `ZIP 207: Funding Streams `_ .. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ .. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade `_ +.. [#zip-0253] `ZIP 253: Deployment of the NU6 Network Upgrade `_ .. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_ +.. [#zip-1015] `ZIP 1015: Block Reward Allocation for Non-Direct Development Funding `_ diff --git a/zips/zip-1015.rst b/zips/zip-1015.rst new file mode 100644 index 00000000..62f41484 --- /dev/null +++ b/zips/zip-1015.rst @@ -0,0 +1,383 @@ +:: + + ZIP: 1015 + Title: Block Reward Allocation for Non-Direct Development Funding + Owners: Jason McGee + @Peacemonger (Zcash Forum) + Kris Nuttycombe + Credits: @GGuy (Zcash Forum) + Daira-Emma Hopwood + Jack Grigg + Skylar Saveland + Status: Proposed + Category: Consensus + Created: 2024-08-26 + License: MIT + Pull-Request: + + +Terminology +=========== + +The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this +document are to be interpreted as described in BCP 14 [#BCP14]_ when, and only +when, they appear in all capitals. + +"Zcash Community Advisory Panel", also called "ZCAP", refers to the panel of +community members assembled by the Zcash Foundation and described at [#zcap]_. + +"Zcash Community Grants", also called "ZCG", refers to the committee selected +by the Zcash Community Advisory Panel or a successor process (e.g. as established +by FPF) to decide on the funding of grants intended to fund the Zcash ecosystem. + +"Financial Privacy Foundation", also called "FPF", refers to the Cayman +Islands-incorporated non-profit foundation company limited by guarantee of +that name. + + +Abstract +======== + +This ZIP proposes the allocation of a percentage of the Zcash block subsidy, +post-November 2024 halving, split between Zcash Community Grants (ZCG) and an +in-protocol "lockbox." The "lockbox" is a separate pool of issued funds tracked +by the protocol, as described in ZIP 2001: Lockbox Funding Streams [#zip-2001]_. +No disbursement mechanism is currently defined for this "lockbox"; the Zcash +community will need to decide upon and specify a suitable decentralized +mechanism for permitting withdrawals from this lockbox in a future ZIP in order +to make these funds available for funding grants to ecosystem participants. + +The proposed lockbox addresses significant issues observed with ZIP 1014 +[#zip-1014]_, such as regulatory risks, inefficiencies due to funding of +organizations instead of projects, and centralization. While the exact +disbursement mechanism for the lockbox funds is yet to be determined and will be +addressed in a future ZIP, the goal is to employ a decentralized mechanism that +ensures community involvement and efficient, project-specific funding. This +approach is intended to potentially improve regulatory compliance, reduce +inefficiencies, and enhance the decentralization of Zcash's funding structure. + + +Motivation +========== + +Starting at Zcash's second halving in November 2024, under pre-existing +consensus rules 100% of the block subsidies would be allocated to miners, and no +further funds would be automatically allocated to any other entities. +Consequently, unless the community takes action to approve new +block-reward-based funding, existing teams dedicated to development or outreach +or furthering charitable, educational, or scientific purposes would likely need +to seek other sources of funding; failure to obtain such funding would likely +impair their ability to continue serving the Zcash ecosystem. Setting aside a +portion of the block subsidy to fund development will help ensure that both +existing teams and new contributors can obtain funding in the future. + +It is important to balance the incentives for securing the consensus protocol +through mining with funding crucial charitable, educational, and scientific +activities like research, development, and outreach. Additionally, there is a +need to continue to promote decentralization and the growth of independent +development teams. + +For these reasons, the Zcash Community wishes to establish a new Zcash +Development Fund after the second halving in November 2024, with the intent to +put in place a more decentralized mechanism for allocation of development +funds. The alternatives presented here are intended to address the following: + +1. **Regulatory Risks**: The current model involves direct funding of US-based + organizations, which can potentially attract regulatory scrutiny from + entities such as the SEC, posing legal risks to the Zcash ecosystem. + +2. **Funding Inefficiencies**: The current model directly funds organizations + rather than specific projects, leading to a potential mismatch between those + organizations' development priorities and the priorities of the community. + Furthermore, if organizations are guaranteed funds regardless of + performance, there is little incentive to achieve key performance indicators + (KPIs) or align with community sentiment. A future system that allocates + resources directly to projects rather than organizations may help reduce + inefficiencies and better align development efforts with community + priorities. + +3. **Centralization Concerns**: The current model centralizes decision-making + power within a few organizations, contradicting the decentralized ethos of + blockchain technology. Traditional organizational structures with boards and + executives introduce single points of failure and limit community + involvement in funding decisions. + +4. **Community Involvement**: The current system provides minimal formal input + from the community regarding what projects should be funded, leading to a + misalignment between funded projects and community priorities. + +5. **Moving Towards a Non-Direct Funding Model**: There is strong community + support for a non-direct Dev Fund funding model. Allocating funds to a + Deferred Dev Fund Lockbox incentivizes the development of a decentralized + mechanism for the disbursement of the locked funds. + +6. **Limited Runway**: ZCG does not have the financial runway that ECC/BP and ZF + have. As such, allocating ongoing funding to ZCG will help ensure the Zcash + ecosystem has an active grants program. + +7. **Promoting Decentralization**: Allocating a portion of the Dev Fund to Zcash + Community Grants ensures small teams continue to receive funding to + contribute to Zcash. Allowing the Dev Fund to expire, or putting 100% into a + lockbox, would disproportionally impact grant recipients. This hybrid + approach promotes decentralization and the growth of independent development + teams. + +8. **Mitigating Regulatory Risks**: The Financial Privacy Foundation (FPF) is a + non-profit organization incorporated and based in the Cayman Islands. By + minimizing direct funding of US-based organizations, this proposal helps to + reduce potential regulatory scrutiny and legal risks. + +By addressing these issues, this proposal aims to ensure sustainable, +efficient, and decentralized funding for essential activities within the Zcash +ecosystem. + + +Requirements +============ + +1. **In-Protocol Lockbox**: The alternatives presented in this ZIP depend upon + the Lockbox Funding Streams proposal [#zip-2001]_. + +2. **Regulatory Considerations**: The allocation of funds should minimize + regulatory risks by avoiding direct funding of specific organizations. The + design should enable and encourage compliance with applicable laws and regulations to + support the long-term sustainability of the funding model. + + +Non-requirements +================ + +The following considerations are explicitly deferred to future ZIPs and are not +covered by this proposal: + +1. **Disbursement Mechanism**: The exact method for disbursing the accumulated + funds from the lockbox is not defined in this ZIP. The design, + implementation, and governance of the disbursement mechanism will be + addressed in a future ZIP. This includes specifics on how funds will be + allocated, the voting or decision-making process, and the structure of the + decentralized mechanism (such as a DAO). + +2. **Regulatory Compliance Details**: The proposal outlines the potential to + reduce regulatory risks by avoiding direct funding of US-based + organizations, but it does not detail specific regulatory compliance + strategies. Future ZIPs will need to address how the disbursement mechanism + complies with applicable laws and regulations. + +3. **Impact Assessment**: The long-term impact of reallocating a portion of the + block subsidy to the lockbox on the Zcash ecosystem, including its effect on + miners, developers, and the broader community, is not analyzed in this ZIP. + Subsequent proposals will need to evaluate the outcomes and make necessary + adjustments based on real-world feedback and data. + + +Specification +============= + +Development Funding Recipients +------------------------------ + +Lockbox +''''''' + +The "lockbox" is a pool of issued funds tracked by the protocol, as described in +ZIP 2001: Lockbox Funding Streams [#zip-2001]_. No disbursement mechanism is +currently defined for this "lockbox"; the Zcash community will need to decide +upon and specify a suitable decentralized mechanism for permitting withdrawals +from this lockbox in a future ZIP in order to make these funds available for +funding grants to ecosystem participants. + +Zcash Community Grants (ZCG) +'''''''''''''''''''''''''''' + +The stream allocated to Zcash Community Grants (ZCG) is intended to fund +independent teams entering the Zcash ecosystem, to perform major ongoing +development (or other work) for the public good of the Zcash ecosystem, to the +extent that such teams are available and effective. The 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 the Financial Privacy Foundation +(FPF). FPF MUST disburse them for grants and expenses reasonably related to the +administration of the ZCG program, but subject to the following additional +constraints: + +1. These funds MUST only be used to issue grants to external parties that are + independent of FPF, and to pay for expenses reasonably related to the + administration of the ZCG program. They MUST NOT be used by FPF for + its internal operations and direct expenses not related to the + administration of grants or the grants program. + +2. ZCG 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. The ZCG committee SHOULD be restricted to funding projects that further the + Zcash cryptocurrency and its ecosystem (which is more specific than + furthering financial privacy in general) as permitted by FPF + and any relevant jurisdictional requirements. + +5. ZCG awards are subject to approval by a five-seat ZCG Committee. The ZCG + Committee SHALL be selected by the ZF’s Community Advisory Panel or a + successor process (e.g. as established by FPF). Elections SHALL be staggered + to ensure continuity within the Committee. + +6. The ZCG Committee’s funding decisions will be final, requiring no approval + from the FPF Board, but are subject to veto if the FPF judges them to + violate any relevant laws or other (current or future) obligations. + +7. ZCG Committee members SHALL have a one-year term and MAY sit for reelection. + The ZCG Committee is subject to the same conflict of interest policy that + governs the FPF 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, at most one person with + association with the ZF, and at most one person with association with FPF + are allowed to sit on the ZCG 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). Similarly, FPF should + also endeavor to establish its own means of collecting community sentiment + for the purpose of administering ZCG elections. + +8. 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 the ZCG program. 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 ZCG Committee. Expenses related to the administration of the + ZCG program 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 ZCG Committee. + * Paying independent consultants to develop requests for proposals that + align with the ZCG program. + * Paying independent consultants for expert review of grant applications. + * Paying for sales and marketing services to promote the ZCG program. + * Paying third party consultants to undertake activities that support the + purpose of the ZCG program. + * Reimbursement to members of the ZCG 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 FPF. The compensation rate and hours for committee + members SHALL be determined by the ZF’s Community Advisory Panel or + successor process. + +10. The ZCG Committee’s decisions relating to the allocation and disbursement + of funds from the Discretionary Budget will be final, requiring no approval + from the FPF Board, but are subject to veto if the FPF judges + them to violate laws or FPF reporting requirements and other + (current or future) obligations. + +FPF 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. + +FPF SHALL strive to define target metrics and key performance indicators, +and the ZCG Committee SHOULD utilize these in its funding decisions. + +Furthering Decentralization +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +FPF SHALL conduct periodic 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, FPF 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 keep its domicile outside of the United States. + +Transparency and Accountability +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +FPF MUST accept the following obligations in this section on behalf of ZCG: + +* Publication of the ZCG Dashboard, providing a snapshot of ZCG’s current + financials and any disbursements made to grantees. +* Bi-weekly meeting minutes documenting the decisions made by the ZCG committee + on grants. +* Quarterly reports, detailing future plans, execution on previous plans, and + finances (balances, and spending broken down by major categories). +* Annual detailed review of the organization performance and future plans. +* Annual financial report (IRS Form 990, or substantially similar information). + +BP, ECC, ZF, FPF, ZCG 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). + +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 +~~~~~~~~~~~ + +FPF MUST contractually commit to fulfill these obligations on behalf of +ZCG, and the prescribed use of funds, such that substantial violation, not +promptly remedied, will result in a modified version of Zcash node software +that removes ZCG’s Dev Fund slice and allocates it to the Deferred Dev Fund +lockbox. + +Funding Streams +--------------- + +* 12% of the block subsidy is to be distributed to the lockbox. +* 8% of the block subsidy is to be distributed to the Financial Privacy + Foundation (FPF), for the express use of the Zcash Community Grants Committee + (ZCG) to fund independent teams in the Zcash ecosystem. + +As of the activation of this ZIP, the complete set of funding streams for +Mainnet will be: + +================= =========== ============= ============== ============ + Stream Numerator Denominator Start height End height +================= =========== ============= ============== ============ +``FS_DEFERRED`` 12 100 2726400 3146400 +``FS_FPF_ZCG`` 8 100 2726400 3146400 +================= =========== ============= ============== ============ + +The set of funding streams for Testnet will be: + +================= =========== ============= ============== ============ + Stream Numerator Denominator Start height End height +================= =========== ============= ============== ============ +``FS_DEFERRED`` 12 100 2976000 3396000 +``FS_FPF_ZCG`` 8 100 2976000 3396000 +================= =========== ============= ============== ============ + + +References +========== + +.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to + Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs + Lowercase in RFC 2119 Key Words" `_ +.. [#osd] `The Open Source Definition `_ +.. [#zip-1014] `ZIP 1014: Dev Fund Proposal and Governance `_ +.. [#zip-2001] `ZIP 2001: Lockbox Funding Streams `_ +.. [#zcap] `Zcash Community Advisory Panel `_ diff --git a/zips/zip-2001.rst b/zips/zip-2001.rst index 2d7e0c2f..93b22728 100644 --- a/zips/zip-2001.rst +++ b/zips/zip-2001.rst @@ -5,7 +5,7 @@ Owners: Kris Nuttycombe Credits: Daira-Emma Hopwood Jack Grigg - Status: Draft + Status: Proposed Category: Consensus Created: 2024-07-02 License: MIT