From 136835232ac41b2a52120680d2d7c5b9b466e0f2 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 12 Jan 2020 00:23:28 +0000 Subject: [PATCH] ZIP 1014: Funding Cap -> Monthly Funding Cap. Signed-off-by: Daira Hopwood --- zip-1014.html | 14 +++++++------- zip-1014.rst | 22 +++++++++++----------- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/zip-1014.html b/zip-1014.html index 3e3ecfb0..cac66485 100644 --- a/zip-1014.html +++ b/zip-1014.html @@ -107,14 +107,14 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli

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

-
-

Funding Cap and Volatility Reserve

-

Each Dev Fund slice has a Funding Cap, initially USD 700,000 for each slice. At the end of each calendar month, the fair market value of the Dev Fund ZEC received during that month will be computed, and the excess over the Funding Cap SHALL be deposited into a dedicated Volatility Reserve account by the funds' recipient. ECC and ZF SHALL describe the methodology used to calculate fair market value in relevant reports described under Transparency and Accountability.

-

Each slice has its own separate Volatility Reserve account, owned and managed by the recipient (ECC or ZF), but limited in how it may be used (i.e., analogously to some types of retirement or trust accounts). Funds may be withdrawn from the Volatility Reserve account only by that same party, in months where the aforementioned monthly ZEC value falls short of the Funding Cap, and only to the extent needed to cover that shortfall.

+
+

Monthly Funding Cap and Volatility Reserve

+

Each Dev Fund slice has a Monthly Funding Cap, initially USD 700,000 for each slice. At the end of each calendar month, the fair market value of the Dev Fund ZEC received during that month will be computed, and the excess over the Monthly Funding Cap SHALL be deposited into a dedicated Volatility Reserve account by the funds' recipient. ECC and ZF SHALL describe the methodology used to calculate fair market value in relevant reports described under Transparency and Accountability.

+

Each slice has its own separate Volatility Reserve account, owned and managed by the recipient (ECC or ZF), but limited in how it may be used (i.e., analogously to some types of retirement or trust accounts). Funds may be withdrawn from the Volatility Reserve account only by that same party, in months where the aforementioned monthly ZEC value falls short of the Monthly Funding Cap, and only to the extent needed to cover that shortfall.

The Volatility Reserve may be kept as ZEC, or sold and held as fiat currency or investments (whose profits will remain in the Volatility Reserve).

-

The Funding Cap SHALL NOT be changed other than by unanimous agreement of ZF, ECC, and the majority vote of the Community Panel. (In case of excessive accumulation of reserves, the community MAY condition an increase of the Funding Cap on the redirection of some of the reserves to a different entity, miners or an airdrop.)

+

The Monthly Funding Cap SHALL NOT be changed other than by unanimous agreement of ZF, ECC, and the majority vote of the Community Panel. (In case of excessive accumulation of reserves, the community MAY condition an increase of the Monthly Funding Cap on the redirection of some of the reserves to a different entity, miners or an airdrop.)

Dev Fund ZEC that has been received, not placed in the Volatility Reserve, and has not yet been used or disbursed, SHALL be kept by the corresponding party (as ZEC, or sold and invested) for later use under the terms of the corresponding slice.

-

Note that grantees of Major Grants are not directly subject to the Funding Cap, and do not have to manage a Volatility Reserve account; this is addressed upstream by the Zcash Foundation, which awards these grants. The hope is that the Foundation-managed ZF-MG Volatility Reserve will ultimately form a large long-term "endowment" pool that cushions the volatility for the various grantees, so grantees can focus on their work instead of hedging short-term price risks.

+

Note that grantees of Major Grants are not directly subject to the Monthly Funding Cap, and do not have to manage a Volatility Reserve account; this is addressed upstream by the Zcash Foundation, which awards these grants. The hope is that the Foundation-managed ZF-MG Volatility Reserve will ultimately form a large long-term "endowment" pool that cushions the volatility for the various grantees, so grantees can focus on their work instead of hedging short-term price risks.

Irrevocable obligations to the above MUST be made by the recipients (e.g., using their Operating Agreements or by receiving the slice as Restricted Funds).

@@ -151,7 +151,7 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polli

Decentralized community governance is used in this proposal via the Community Panel in the following places:

  1. As input into the Major Grant Review Committee which governs the ZF-MG slice (Zcash Foundation, for major grants).
    2. -
  2. For changing the Funding Cap and Volatility Reserve.
    3. +
  3. For changing the Monthly Funding Cap and Volatility Reserve.

It is highly desirable to develop robust means of decentralized community voting and governance --- either by expanding the Community Panel or a successor mechanism --- and to integrate them into both of these processes, by the end of 2021. ECC and ZF SHOULD place high priority on such development and its deployment, in their activities and grant selection.

diff --git a/zip-1014.rst b/zip-1014.rst index d51d8174..1a3e7221 100644 --- a/zip-1014.rst +++ b/zip-1014.rst @@ -252,13 +252,13 @@ of the Zcash consensus rules they maintain. This decision will then be, effectively, ratified by the miners as the network upgrade activates. -Funding Cap and Volatility Reserve -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Monthly Funding Cap and Volatility Reserve +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Each Dev Fund slice has a Funding Cap, initially USD 700,000 for each +Each Dev Fund slice has a Monthly Funding Cap, initially USD 700,000 for each slice. At the end of each calendar month, the fair market value of the Dev Fund ZEC received during that month will be computed, and the excess over -the Funding Cap SHALL be deposited into a dedicated Volatility Reserve +the Monthly Funding Cap SHALL be deposited into a dedicated Volatility Reserve account by the funds' recipient. ECC and ZF SHALL describe the methodology used to calculate fair market value in relevant reports described under `Transparency and Accountability`_. @@ -268,15 +268,15 @@ managed by the recipient (ECC or ZF), but limited in how it may be used (i.e., analogously to some types of retirement or trust accounts). Funds may be withdrawn from the Volatility Reserve account only by that same party, in months where the aforementioned monthly ZEC value falls short of -the Funding Cap, and only to the extent needed to cover that shortfall. +the Monthly Funding Cap, and only to the extent needed to cover that shortfall. The Volatility Reserve may be kept as ZEC, or sold and held as fiat currency or investments (whose profits will remain in the Volatility Reserve). -The Funding Cap SHALL NOT be changed other than by unanimous agreement of -ZF, ECC, and the majority vote of the Community Panel. (In case of excessive +The Monthly Funding Cap SHALL NOT be changed other than by unanimous agreement +of ZF, ECC, and the majority vote of the Community Panel. (In case of excessive accumulation of reserves, the community MAY condition an increase of the -Funding Cap on the redirection of some of the reserves to a different +Monthly Funding Cap on the redirection of some of the reserves to a different entity, miners or an airdrop.) Dev Fund ZEC that has been received, not placed in the Volatility Reserve, @@ -284,8 +284,8 @@ and has not yet been used or disbursed, SHALL be kept by the corresponding party (as ZEC, or sold and invested) for later use under the terms of the corresponding slice. -Note that grantees of Major Grants are not directly subject to the Funding -Cap, and do not have to manage a Volatility Reserve account; this is +Note that grantees of Major Grants are not directly subject to the Monthly +Funding Cap, and do not have to manage a Volatility Reserve account; this is addressed upstream by the Zcash Foundation, which awards these grants. The hope is that the Foundation-managed ZF-MG Volatility Reserve will ultimately form a large long-term "endowment" pool that cushions the volatility for the @@ -365,7 +365,7 @@ Panel in the following places: 1. As input into the Major Grant Review Committee which governs the `ZF-MG slice (Zcash Foundation, for major grants)`_. -2. For changing the `Funding Cap and Volatility Reserve`_. +2. For changing the `Monthly Funding Cap and Volatility Reserve`_. It is highly desirable to develop robust means of decentralized community voting and governance --- either by expanding the Community Panel