zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 1014: Funding Cap -> Monthly Funding Cap. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-01-12 00:23:28 +00:00
parent 803aea13f3
commit 136835232a
2 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
zip-1014.html
View File

@ -107,14 +107,14 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<p>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.</p>
</section>
</section>
<section id="funding-cap-and-volatility-reserve">
<h4>Funding Cap and Volatility Reserve</h4>
<p>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 <a href="#transparency-and-accountability">Transparency and Accountability</a>.</p>
<p>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.</p>
<section id="monthly-funding-cap-and-volatility-reserve">
<h4>Monthly Funding Cap and Volatility Reserve</h4>
<p>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 <a href="#transparency-and-accountability">Transparency and Accountability</a>.</p>
<p>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.</p>
<p>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).</p>
<p>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.)</p>
<p>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.)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
</section>
</section>
@ -151,7 +151,7 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<p>Decentralized community governance is used in this proposal via the Community Panel in the following places:</p>
<ol type="1">
<li>As input into the Major Grant Review Committee which governs the <a href="#zf-mg-slice-zcash-foundation-for-major-grants">ZF-MG slice (Zcash Foundation, for major grants)</a>.</li>
<li>For changing the <a href="#funding-cap-and-volatility-reserve">Funding Cap and Volatility Reserve</a>.</li>
<li>For changing the <a href="#monthly-funding-cap-and-volatility-reserve">Monthly Funding Cap and Volatility Reserve</a>.</li>
</ol>
<p>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.</p>
</section>

22
zip-1014.rst
View File

@ -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