mirror of https://github.com/zcash/zips.git
Merge remote-tracking branch 'upstream/main' into draft-dev-fund-proposal-20
This commit is contained in:
Kris Nuttycombe
commit
82166a003e
|
|
@ -162,6 +162,9 @@ be deleted.
|
||||||
|
|
||||||
<embed><table>
|
<embed><table>
|
||||||
<tr> <th>Title</th> </tr>
|
<tr> <th>Title</th> </tr>
|
||||||
<tr> <td class="left"><a href="draft-nuttycom-funding-allocation.rst">Allocation of Block Rewards for Decentralized Development Funding</a></td>
|
<tr> <td class="left"><a href="draft-hopwood-coinbase-balance.rst">Blocks should balance exactly</a></td>
|
||||||
|
<tr> <td class="left"><a href="draft-noamchom67-manufacturing-consent.rst">Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub</a></td>
|
||||||
|
<tr> <td class="left"><a href="draft-nuttycom-funding-allocation.rst">Block Reward Allocation for Non-Direct Development Funding</a></td>
|
||||||
<tr> <td class="left"><a href="draft-nuttycom-lockbox-streams.rst">Lockbox Funding Streams</a></td>
|
<tr> <td class="left"><a href="draft-nuttycom-lockbox-streams.rst">Lockbox Funding Streams</a></td>
|
||||||
|
<tr> <td class="left"><a href="draft-zf-community-dev-fund-2-proposal.rst">Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve</a></td>
|
||||||
</table></embed>
|
</table></embed>
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,129 @@
|
||||||
|
<!DOCTYPE html>
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Draft hopwood-coinbase-balance: Blocks should balance exactly</title>
|
||||||
|
<meta charset="utf-8" />
|
||||||
|
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||||
|
<body>
|
||||||
|
<section>
|
||||||
|
<pre>ZIP: XXX
|
||||||
|
Title: Blocks should balance exactly
|
||||||
|
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||||
|
Credits: Jack Grigg
|
||||||
|
Kris Nuttycombe
|
||||||
|
Status: Draft
|
||||||
|
Category: Consensus
|
||||||
|
Created: 2024-07-02
|
||||||
|
License: MIT
|
||||||
|
Discussions-To: <<a href="https://github.com/zcash/zips/issues/864">https://github.com/zcash/zips/issues/864</a>></pre>
|
||||||
|
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>The key word "MUST" in this document is to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, it appears in all capitals.</p>
|
||||||
|
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">5</a></p>
|
||||||
|
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification. <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">4</a></p>
|
||||||
|
<p>The character § is used when referring to sections of the Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||||
|
</section>
|
||||||
|
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>In the current Zcash protocol, the miner of a coinbase transaction is permitted to claim up to and including the total amount of miner subsidy plus fees from other transactions in the block, but is not required to claim the full amount.</p>
|
||||||
|
<p>This proposal would require the full amount of miner subsidy and fees to be collected in coinbase transactions.</p>
|
||||||
|
</section>
|
||||||
|
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>The current semantics of coinbase transactions creates a potential for miners to miscalculate the total amount of miner subsidy plus fees in a block. If they claim a higher amount than the actual miner subsidy plus total fees, the block will be invalid, but if they claim a lower amount, the excess is effectively burnt. As a consequence, the effective ZEC issuance can fall short of the amount calculated from the intended issuance curve.</p>
|
||||||
|
<p>This unnecessarily complicates the question of how much ZEC has been issued: if it is defined as not including the amounts that were left unclaimed by miners, then it is difficult to calculate, and cannot be predicted exactly in advance for any given block height. Alternatively if it is defined to include those amounts, then that introduces potentially confusing discrepancies between different definitions of issuance or total supply.</p>
|
||||||
|
</section>
|
||||||
|
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>The consensus rule change specified in this ZIP must:</p>
|
||||||
|
<ul>
|
||||||
|
<li>allow issuance to be predicted exactly in advance, starting from the point at which it activates;</li>
|
||||||
|
<li>preclude errors by miners in computing the total miner subsidy plus fees for transactions in the mined block;</li>
|
||||||
|
<li>be deployable in the NU6 network upgrade, which is not expected to define a new transaction version.</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>Since this ZIP is intended to activate in a network upgrade that is not expected to support a new transaction version, it cannot resolve the issue that the amounts of fees are implicit in non-coinbase transactions. That issue results in various potential security difficulties and the potential for users' wallets to inadvertently overpay the fee, but solving that would require an explicit "fee" field.</p>
|
||||||
|
<p>(It would technically be possible to encode the fee as a transparent output, but that would be a more disruptive change than is desirable, since other consensus rules would have to change in order to prevent this output from being spent, and since existing consumers of the transaction format could misinterpret such outputs.)</p>
|
||||||
|
<p>This consensus change is not intended to prevent other methods of provably removing ZEC from the circulating supply, such as sending it to an address for which it would be demonstrably infeasible to find the spending key.</p>
|
||||||
|
</section>
|
||||||
|
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>From the activation block of this ZIP onward, coinbase transactions MUST claim all of the available miner subsidy plus fees in their block. More specifically, the following paragraph and consensus rule in § 3.4 "Transactions and Treestates" of the Zcash Protocol Specification <a id="footnote-reference-5" class="footnote_reference" href="#protocol-transactions">3</a>:</p>
|
||||||
|
<blockquote>
|
||||||
|
<p>Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction, and transparent outputs remove value from this pool. As in Bitcoin, the remaining value in the transparent transaction value pool of a non-coinbase transaction is available to miners as a fee. The remaining value in the transparent transaction value pool of a coinbase transaction is destroyed.</p>
|
||||||
|
<p><strong>Consensus rule:</strong> The remaining value in the transparent transaction value pool MUST be nonnegative.</p>
|
||||||
|
</blockquote>
|
||||||
|
<p>is modified to become:</p>
|
||||||
|
<blockquote>
|
||||||
|
<p>Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction, and transparent outputs remove value from this pool. The effect of Sapling Spends and Outputs, and of Orchard Actions on the transaction value pool are specified in § 4.13 and § 4.14 respectively.</p>
|
||||||
|
<p>As in Bitcoin, the remaining value in the transparent transaction value pool of a non-coinbase transaction is available to miners as a fee. That is, the sum of those values for non-coinbase transactions in each block is treated as an implicit input to the transaction value balance of the block's coinbase transaction (in addition to the implicit input created by issuance).</p>
|
||||||
|
<p>The remaining value in the transparent transaction value pool of coinbase transactions in blocks prior to NU-X is destroyed. From activation of NU-X, this remaining value is required to be zero; that is, all of the available balance MUST be consumed by outputs of the coinbase transaction.</p>
|
||||||
|
<p><strong>Consensus rules:</strong></p>
|
||||||
|
<ul>
|
||||||
|
<li>The remaining value in the transparent transaction value pool of a non-coinbase transaction MUST be nonnegative.</li>
|
||||||
|
<li>[Pre-NU-X] The remaining value in the transparent transaction value pool of a coinbase transaction MUST be nonnegative.</li>
|
||||||
|
<li>[NU-X onward] The remaining value in the transparent transaction value pool of a coinbase transaction MUST be zero.</li>
|
||||||
|
</ul>
|
||||||
|
</blockquote>
|
||||||
|
<p>where "NU-X" is to be replaced by the designation of the network upgrade in which this ZIP will be activated.</p>
|
||||||
|
<p>Note that the differences in the first two paragraphs of the above replacement text are clarifications of the protocol, rather than consensus changes. Those could be made independently of this ZIP.</p>
|
||||||
|
<p>This change applies identically to Mainnet and Testnet.</p>
|
||||||
|
</section>
|
||||||
|
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>Subject to community agreement, this ZIP is proposed to be deployed with NU6. <a id="footnote-reference-6" class="footnote_reference" href="#zip-0253">6</a></p>
|
||||||
|
</section>
|
||||||
|
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>TODO</p>
|
||||||
|
</section>
|
||||||
|
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading to the submission of this ZIP.</p>
|
||||||
|
</section>
|
||||||
|
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<table id="bcp14" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>1</th>
|
||||||
|
<td><a href="https://www.rfc-editor.org/info/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"</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="protocol" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>2</th>
|
||||||
|
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2023.4.0 or later</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="protocol-transactions" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>3</th>
|
||||||
|
<td><a href="protocol/protocol.pdf#transactions">Zcash Protocol Specification, Version 2023.4.0. Section 3.4: Transactions and Treestates</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="protocol-networks" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>4</th>
|
||||||
|
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-0200" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>5</th>
|
||||||
|
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-0253" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>6</th>
|
||||||
|
<td><a href="zip-0253">ZIP 253: Deployment of the NU6 Network Upgrade</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
|
@ -0,0 +1,174 @@
|
||||||
|
::
|
||||||
|
|
||||||
|
ZIP: XXX
|
||||||
|
Title: Blocks should balance exactly
|
||||||
|
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
|
||||||
|
Credits: Jack Grigg
|
||||||
|
Kris Nuttycombe
|
||||||
|
Status: Draft
|
||||||
|
Category: Consensus
|
||||||
|
Created: 2024-07-02
|
||||||
|
License: MIT
|
||||||
|
Discussions-To: <https://github.com/zcash/zips/issues/864>
|
||||||
|
|
||||||
|
|
||||||
|
Terminology
|
||||||
|
===========
|
||||||
|
|
||||||
|
The key word "MUST" in this document is to be interpreted as described in BCP 14
|
||||||
|
[#BCP14]_ when, and only when, it appears in all capitals.
|
||||||
|
|
||||||
|
The term "network upgrade" in this document is to be interpreted as described in
|
||||||
|
ZIP 200. [#zip-0200]_
|
||||||
|
|
||||||
|
The terms "Testnet" and "Mainnet" are to be interpreted as described in section
|
||||||
|
3.12 of the Zcash Protocol Specification. [#protocol-networks]_
|
||||||
|
|
||||||
|
The character § is used when referring to sections of the Zcash Protocol Specification
|
||||||
|
[#protocol]_.
|
||||||
|
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
========
|
||||||
|
|
||||||
|
In the current Zcash protocol, the miner of a coinbase transaction is permitted to
|
||||||
|
claim up to and including the total amount of miner subsidy plus fees from other
|
||||||
|
transactions in the block, but is not required to claim the full amount.
|
||||||
|
|
||||||
|
This proposal would require the full amount of miner subsidy and fees to be
|
||||||
|
collected in coinbase transactions.
|
||||||
|
|
||||||
|
|
||||||
|
Motivation
|
||||||
|
==========
|
||||||
|
|
||||||
|
The current semantics of coinbase transactions creates a potential for miners to
|
||||||
|
miscalculate the total amount of miner subsidy plus fees in a block. If they claim
|
||||||
|
a higher amount than the actual miner subsidy plus total fees, the block will be
|
||||||
|
invalid, but if they claim a lower amount, the excess is effectively burnt. As a
|
||||||
|
consequence, the effective ZEC issuance can fall short of the amount calculated
|
||||||
|
from the intended issuance curve.
|
||||||
|
|
||||||
|
This unnecessarily complicates the question of how much ZEC has been issued: if it
|
||||||
|
is defined as not including the amounts that were left unclaimed by miners, then it
|
||||||
|
is difficult to calculate, and cannot be predicted exactly in advance for any given
|
||||||
|
block height. Alternatively if it is defined to include those amounts, then that
|
||||||
|
introduces potentially confusing discrepancies between different definitions of
|
||||||
|
issuance or total supply.
|
||||||
|
|
||||||
|
|
||||||
|
Requirements
|
||||||
|
============
|
||||||
|
|
||||||
|
The consensus rule change specified in this ZIP must:
|
||||||
|
|
||||||
|
* allow issuance to be predicted exactly in advance, starting from the point at
|
||||||
|
which it activates;
|
||||||
|
* preclude errors by miners in computing the total miner subsidy plus fees for
|
||||||
|
transactions in the mined block;
|
||||||
|
* be deployable in the NU6 network upgrade, which is not expected to define a new
|
||||||
|
transaction version.
|
||||||
|
|
||||||
|
|
||||||
|
Non-requirements
|
||||||
|
================
|
||||||
|
|
||||||
|
Since this ZIP is intended to activate in a network upgrade that is not expected
|
||||||
|
to support a new transaction version, it cannot resolve the issue that the amounts
|
||||||
|
of fees are implicit in non-coinbase transactions. That issue results in various
|
||||||
|
potential security difficulties and the potential for users' wallets to inadvertently
|
||||||
|
overpay the fee, but solving that would require an explicit "fee" field.
|
||||||
|
|
||||||
|
(It would technically be possible to encode the fee as a transparent output, but
|
||||||
|
that would be a more disruptive change than is desirable, since other consensus
|
||||||
|
rules would have to change in order to prevent this output from being spent, and
|
||||||
|
since existing consumers of the transaction format could misinterpret such outputs.)
|
||||||
|
|
||||||
|
This consensus change is not intended to prevent other methods of provably removing
|
||||||
|
ZEC from the circulating supply, such as sending it to an address for which it
|
||||||
|
would be demonstrably infeasible to find the spending key.
|
||||||
|
|
||||||
|
|
||||||
|
Specification
|
||||||
|
=============
|
||||||
|
|
||||||
|
From the activation block of this ZIP onward, coinbase transactions MUST claim all
|
||||||
|
of the available miner subsidy plus fees in their block. More specifically, the
|
||||||
|
following paragraph and consensus rule in § 3.4 "Transactions and Treestates" of
|
||||||
|
the Zcash Protocol Specification [#protocol-transactions]_:
|
||||||
|
|
||||||
|
Transparent inputs to a transaction insert value into a transparent transaction
|
||||||
|
value pool associated with the transaction, and transparent outputs remove value
|
||||||
|
from this pool. As in Bitcoin, the remaining value in the transparent transaction
|
||||||
|
value pool of a non-coinbase transaction is available to miners as a fee. The
|
||||||
|
remaining value in the transparent transaction value pool of a coinbase transaction
|
||||||
|
is destroyed.
|
||||||
|
|
||||||
|
**Consensus rule:** The remaining value in the transparent transaction value pool
|
||||||
|
MUST be nonnegative.
|
||||||
|
|
||||||
|
is modified to become:
|
||||||
|
|
||||||
|
Transparent inputs to a transaction insert value into a transparent transaction
|
||||||
|
value pool associated with the transaction, and transparent outputs remove value
|
||||||
|
from this pool. The effect of Sapling Spends and Outputs, and of Orchard Actions
|
||||||
|
on the transaction value pool are specified in § 4.13 and § 4.14 respectively.
|
||||||
|
|
||||||
|
As in Bitcoin, the remaining value in the transparent transaction value pool of
|
||||||
|
a non-coinbase transaction is available to miners as a fee. That is, the sum of
|
||||||
|
those values for non-coinbase transactions in each block is treated as an implicit
|
||||||
|
input to the transaction value balance of the block's coinbase transaction (in
|
||||||
|
addition to the implicit input created by issuance).
|
||||||
|
|
||||||
|
The remaining value in the transparent transaction value pool of coinbase transactions
|
||||||
|
in blocks prior to NU-X is destroyed. From activation of NU-X, this remaining value
|
||||||
|
is required to be zero; that is, all of the available balance MUST be consumed by
|
||||||
|
outputs of the coinbase transaction.
|
||||||
|
|
||||||
|
**Consensus rules:**
|
||||||
|
|
||||||
|
* The remaining value in the transparent transaction value pool of a non-coinbase
|
||||||
|
transaction MUST be nonnegative.
|
||||||
|
* [Pre-NU-X] The remaining value in the transparent transaction value pool of a
|
||||||
|
coinbase transaction MUST be nonnegative.
|
||||||
|
* [NU-X onward] The remaining value in the transparent transaction value pool of
|
||||||
|
a coinbase transaction MUST be zero.
|
||||||
|
|
||||||
|
where "NU-X" is to be replaced by the designation of the network upgrade in which
|
||||||
|
this ZIP will be activated.
|
||||||
|
|
||||||
|
Note that the differences in the first two paragraphs of the above replacement text
|
||||||
|
are clarifications of the protocol, rather than consensus changes. Those could be
|
||||||
|
made independently of this ZIP.
|
||||||
|
|
||||||
|
This change applies identically to Mainnet and Testnet.
|
||||||
|
|
||||||
|
|
||||||
|
Deployment
|
||||||
|
==========
|
||||||
|
|
||||||
|
Subject to community agreement, this ZIP is proposed to be deployed with NU6. [#zip-0253]_
|
||||||
|
|
||||||
|
|
||||||
|
Reference implementation
|
||||||
|
========================
|
||||||
|
|
||||||
|
TODO
|
||||||
|
|
||||||
|
|
||||||
|
Acknowledgements
|
||||||
|
================
|
||||||
|
|
||||||
|
The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading
|
||||||
|
to the submission of this ZIP.
|
||||||
|
|
||||||
|
|
||||||
|
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" <https://www.rfc-editor.org/info/bcp14>`_
|
||||||
|
.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later <protocol/protocol.pdf>`_
|
||||||
|
.. [#protocol-transactions] `Zcash Protocol Specification, Version 2023.4.0. Section 3.4: Transactions and Treestates <protocol/protocol.pdf#transactions>`_
|
||||||
|
.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||||
|
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||||
|
.. [#zip-0253] `ZIP 253: Deployment of the NU6 Network Upgrade <zip-0253.rst>`_
|
||||||
|
|
@ -0,0 +1,300 @@
|
||||||
|
<!DOCTYPE html>
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Draft noamchom67-manufacturing-consent: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub</title>
|
||||||
|
<meta charset="utf-8" />
|
||||||
|
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||||
|
<body>
|
||||||
|
<section>
|
||||||
|
<pre>ZIP: ####
|
||||||
|
Title: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
|
||||||
|
Owner: Noam Chom <noamchom1967@gmail.com>
|
||||||
|
ZIP-1014 Owners: Andrew Miller <socrates1024@gmail.com>
|
||||||
|
Zooko Wilcox <zooko@electriccoin.co>
|
||||||
|
ZIP-1014 Original-Authors: Eran Tromer
|
||||||
|
ZIP-1014 Credits: Matt Luongo
|
||||||
|
@aristarchus
|
||||||
|
@dontbeevil
|
||||||
|
Daira Emma Hopwood
|
||||||
|
George Tankersley
|
||||||
|
Josh Cincinnati
|
||||||
|
Andrew Miller
|
||||||
|
Status: Active
|
||||||
|
Category: Consensus Process
|
||||||
|
Created: 2024-06-25
|
||||||
|
License: MIT
|
||||||
|
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/manufacturing-consent-noamchoms-nu6-block-reward-proposal/47155">https://forum.zcashcommunity.com/t/manufacturing-consent-noamchoms-nu6-block-reward-proposal/47155</a>>
|
||||||
|
Pull-Request: TBD</pre>
|
||||||
|
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
|
||||||
|
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">6</a> and the Zcash Trademark Donation and License Agreement (<a id="footnote-reference-3" class="footnote_reference" href="#trademark">4</a> or successor agreement).</p>
|
||||||
|
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a></p>
|
||||||
|
<p>"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric Coin Company, LLC.</p>
|
||||||
|
<p>"Bootstrap Project", also called "BP", refers to the 501(c)(3) nonprofit corporation of that name.</p>
|
||||||
|
<p>"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit corporation of that name.</p>
|
||||||
|
<p>"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). <a id="footnote-reference-5" class="footnote_reference" href="#section501c3">12</a></p>
|
||||||
|
<p>"Community Advisory Panel" refers to the panel of community members assembled by the Zcash Foundation and described at <a id="footnote-reference-6" class="footnote_reference" href="#zf-community">11</a>.</p>
|
||||||
|
<p>"Zcash Community Grants", also called "ZCG", refers to grants program (formerly known as ZOMG) that funds independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem. <<a href="https://zcashcommunitygrants.org/">https://zcashcommunitygrants.org/</a>></p>
|
||||||
|
<p>"Financial Privacy Fund", also called "FPF" refers to the start-up non-profit organization incorporated and based in the Cayman Islands. <<a href="https://www.financialprivacyfoundation.org/">https://www.financialprivacyfoundation.org/</a>></p>
|
||||||
|
<p>"Qedit" refers to the company founded in 2016 by a world-class team of accomplished tech entrepreneurs, researchers, and developers; QEDIT has emerged as a global leader in the field of Zero-Knowledge Proofs. <<a href="https://qed-it.com/about-us/">https://qed-it.com/about-us/</a>></p>
|
||||||
|
<p>"ZecHub" refers to the team of content creators who have supported Zcash through a series of ZCG approved grants. <<a href="https://forum.zcashcommunity.com/t/zechub-an-education-hub-for-zcash-2024-continued/47947">https://forum.zcashcommunity.com/t/zechub-an-education-hub-for-zcash-2024-continued/47947</a>></p>
|
||||||
|
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-7" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||||
|
<p>The term "ZSA" is to be interpreted as "Zcash Shielded Assets" the protocol feature enhancement (and subsequent application layer, legal, maintenance efforts, et al) on-going by Qedit, et al. <<a href="https://forum.zcashcommunity.com/t/grant-update-zcash-shielded-assets-monthly-updates/41153">https://forum.zcashcommunity.com/t/grant-update-zcash-shielded-assets-monthly-updates/41153</a>></p>
|
||||||
|
<p>✳️ is used to denote elements of the process part of the ZIP that are still to-be-determined.</p>
|
||||||
|
</section>
|
||||||
|
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>This proposal describes a structure for the Zcash Development Fund, to be enacted in Network Upgrade 6 and last for 4 years. This Dev Fund would consist of 15% of the block subsidies, as the following allocations:</p>
|
||||||
|
<ul>
|
||||||
|
<li>5% for the Zcash Foundation (for internal work and grants);</li>
|
||||||
|
<li>4% for the Bootstrap Project (the parent of the Electric Coin Company) for the 1st year only;</li>
|
||||||
|
<li>4% for Zcash Community Grants for continuation of their current activities as-is;</li>
|
||||||
|
<li>2% for Qedit in support of their ZSA activities, and other Zcash protocol support;</li>
|
||||||
|
</ul>
|
||||||
|
<p>Following the first year, when ECC will no longer receive their 4% allocation, those block subsidies will be distributed as 1% to ZCG, 1% to ZecHub, 1% to FPF, and 1% to ZF.</p>
|
||||||
|
<p>Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged. This proposal mandates the ecosystem to design and deploy a "non-direct funding model" as generally recommended in Josh Swihart's proposal. <a id="footnote-reference-8" class="footnote_reference" href="#draft-swihart">13</a></p>
|
||||||
|
<p>Upon creation/ activation of a "non-direct funding model" this ZIP should be reconsidered (potentially terminated) by the Zcash ecosystem, to determine if its ongoing direct block subsidies are preferred for continuation. Discussions/ solications/ sentiment gathering from the Zcash ecosystem should be initiated ~6 months in advance of the presumed activation of a "non-direct funding model", such that the Zcash ecosystem preference can be expediently realized.</p>
|
||||||
|
<p>Block subsidies will be administered through two organizations:</p>
|
||||||
|
<ol type="1">
|
||||||
|
<li>Zcash Foundation (✳️ for ECC, ZCG)</li>
|
||||||
|
<li>Financial Privacy Fund (✳️ for Qedit, ZecHub)</li>
|
||||||
|
</ol>
|
||||||
|
<p>✳️ <strong>ZF and FPF adminstration of block subsidy details, costs, et al are currently under debate</strong> <a id="footnote-reference-9" class="footnote_reference" href="#zf-fpf-admin-details">14</a></p>
|
||||||
|
</section>
|
||||||
|
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>As of Zcash's second halving in November 2024, by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, no new funding may be available to existing teams dedicated to furthering charitable, educational, or scientific purposes, such as research, development, and outreach: the Electric Coin Company (ECC), the Zcash Foundation (ZF), the ZCG, and the many entities funded by the ZF and ZCG grant programs.</p>
|
||||||
|
<p>There is a need to strike a balance between incentivizing the security of the consensus protocol (i.e., mining) versus crucial charitable, educational, and/or scientific aspects, such as research, development and outreach.</p>
|
||||||
|
<p>Furthermore, there is a need to balance the sustenance of ongoing work by the current teams dedicated to Zcash, with encouraging decentralization and growth of independent development teams.</p>
|
||||||
|
<p>For these reasons, the Zcash Community desires to allocate and contribute a portion of the block subsidies otherwise allocated to miners as a donation to support charitable, educational, and scientific activities within the meaning of Section 501(c)(3).</p>
|
||||||
|
<p>This proposal also introduces the benefit of a non-USA based entity (FPF) as the administrator for block subsidies to two organizations that are also non-USA based (Qedit and ZecHub). USA based regulatory risk continues to (negatively) impact the Zcash project, which has been predominantly based in the USA.</p>
|
||||||
|
</section>
|
||||||
|
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>The Dev Fund should encourage decentralization of the work and funding, by supporting new teams dedicated to Zcash.</p>
|
||||||
|
<p>The Dev Fund should maintain the existing teams and capabilities in the Zcash ecosystem, unless and until concrete opportunities arise to create even greater value for the Zcash ecosystem.</p>
|
||||||
|
<p>There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.</p>
|
||||||
|
<p>Major funding decisions should be based, to the extent feasible, on inputs from domain experts and pertinent stakeholders.</p>
|
||||||
|
<p>The Dev Fund mechanism should not modify the monetary emission curve (and in particular, should not irrevocably burn coins).</p>
|
||||||
|
<p>In case the value of ZEC jumps, the Dev Fund recipients should not wastefully use excessive amounts of funds. Conversely, given market volatility and eventual halvings, it is desirable to create rainy-day reserves.</p>
|
||||||
|
<p>The Dev Fund mechanism should not reduce users' financial privacy or security. In particular, it should not cause them to expose their coin holdings, nor cause them to maintain access to secret keys for much longer than they would otherwise. (This rules out some forms of voting, and of disbursing coins to past/future miners.)</p>
|
||||||
|
<p>The Dev Fund system should be simple to understand and realistic to implement. In particular, it should not assume the creation of new mechanisms (e.g., election systems) or entities (for governance or development) for its execution; but it should strive to support and use these once they are built.</p>
|
||||||
|
<p>Dev Fund recipients should comply with legal, regulatory, and taxation constraints in their pertinent jurisdiction(s).</p>
|
||||||
|
</section>
|
||||||
|
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>General on-chain governance is outside the scope of this proposal.</p>
|
||||||
|
<p>Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or one-person-one-vote) are outside the scope of this proposal, however this proposal does mandate the undertaking of the project to build a "non-direct funding model" as generally described in <a id="footnote-reference-10" class="footnote_reference" href="#draft-swihart">13</a>.</p>
|
||||||
|
</section>
|
||||||
|
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>Consensus changes implied by this specification are applicable to the Zcash Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be applied to the Zcash Testnet for testing purposes.</p>
|
||||||
|
<section id="dev-fund-allocation"><h3><span class="section-heading">Dev Fund allocation</span><span class="section-anchor"> <a rel="bookmark" href="#dev-fund-allocation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<p>Starting at the second Zcash halving in 2024, until the third halving in 2028, 15% of the block subsidy of each block SHALL be allocated to a "Dev Fund" that consists of the following allocations:</p>
|
||||||
|
<ul>
|
||||||
|
<li>5% for the Zcash Foundation (for internal work and grants);</li>
|
||||||
|
<li>4% for the Bootstrap Project (the parent of the Electric Coin Company) for the 1st year only;</li>
|
||||||
|
<li>4% for Zcash Community Grants for continuation of their current activities as-is;</li>
|
||||||
|
<li>2% for Qedit in support of their ZSA activities, and other Zcash protocol support;</li>
|
||||||
|
</ul>
|
||||||
|
<p>Following the first year, when ECC will no longer receive their 4% allocation, those block subsidies will be distributed as 1% to ZCG, 1% to ZecHub, 1% to FPF, and 1% to ZF.</p>
|
||||||
|
<p>This proposal mandates the ecosystem to design and deploy a "non-direct funding model" as generally recommended in Josh Swihart's proposal <a id="footnote-reference-11" class="footnote_reference" href="#draft-swihart">13</a>.</p>
|
||||||
|
<p>"Dev Fund" block subsidies will be administered through two organizations:</p>
|
||||||
|
<ol type="1">
|
||||||
|
<li>Zcash Foundation (✳️ for ECC, ZCG)</li>
|
||||||
|
<li>Financial Privacy Fund (✳️ for Qedit, ZecHub)</li>
|
||||||
|
</ol>
|
||||||
|
<p>✳️ <strong>ZF and FPF adminstration of block subsidy details, costs, et al are currently under debate</strong> <a id="footnote-reference-12" class="footnote_reference" href="#zf-fpf-admin-details">14</a></p>
|
||||||
|
<p>The allocations are described in more detail below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address(es) for each block. This Dev Fund will end at the third halving (unless extended/modified by a future ZIP).</p>
|
||||||
|
<section id="bp-allocation-bootstrap-project"><h4><span class="section-heading">BP allocation (Bootstrap Project)</span><span class="section-anchor"> <a rel="bookmark" href="#bp-allocation-bootstrap-project"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>✳️ These funds SHALL be received and administered by ZF.</p>
|
||||||
|
<p>This allocation of the Dev Fund will flow as charitable contributions from the Zcash Community to the Bootstrap Project, the newly formed parent organization to the Electric Coin Company. The Bootstrap Project is organized for exempt educational, charitable, and scientific purposes in compliance with Section 501(c)(3), including but not limited to furthering education, information, resources, advocacy, support, community, and research relating to cryptocurrency and privacy, including Zcash. This allocation will be used at the discretion of the Bootstrap Project for any purpose within its mandate to support financial privacy and the Zcash platform as permitted under Section 501(c)(3). The BP allocation will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.</p>
|
||||||
|
</section>
|
||||||
|
<section id="zf-allocation-zcash-foundation-s-general-use"><h4><span class="section-heading">ZF allocation (Zcash Foundation's general use)</span><span class="section-anchor"> <a rel="bookmark" href="#zf-allocation-zcash-foundation-s-general-use"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>This allocation of the Dev Fund will flow as charitable contributions from the Zcash Community to ZF, to be used at its discretion for any purpose within its mandate to support financial privacy and the Zcash platform, including: development, education, supporting community communication online and via events, gathering community sentiment, and awarding external grants for all of the above, subject to the requirements of Section 501(c)(3). The ZF allocation will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.</p>
|
||||||
|
</section>
|
||||||
|
<section id="zcash-community-grants-zcg"><h4><span class="section-heading">Zcash Community Grants (ZCG)</span><span class="section-anchor"> <a rel="bookmark" href="#zcash-community-grants-zcg"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>This allocation of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major and minor ongoing development (or other work) for the public good of the Zcash ecosystem, to the extent that such teams are available and effective.</p>
|
||||||
|
<p>✳️ These funds SHALL be received and administered by ZF (or FPF, pending TBD outcomes of FPF proposal: <a id="footnote-reference-13" class="footnote_reference" href="#zf-fpf-admin-details">14</a>). ZF MUST disburse them for "Major Grants" and expenses reasonably related to the administration of Major Grants, but subject to the following additional constraints:</p>
|
||||||
|
<ol type="1">
|
||||||
|
<li>These funds MUST only be used to issue Major Grants to external parties that are independent of ZF, and to pay for expenses reasonably related to the administration of Major Grants. They MUST NOT be used by ZF for its internal operations and direct expenses not related to administration of Major Grants. Additionally, BP, ECC, and ZF are ineligible to receive Major Grants.</li>
|
||||||
|
<li>Major Grants SHOULD support well-specified work proposed by the grantee, at reasonable market-rate costs. They can be of any duration or ongoing without a duration limit. Grants of indefinite duration SHOULD have semiannual review points for continuation of funding.</li>
|
||||||
|
<li>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.</li>
|
||||||
|
<li>Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general) as permitted under Section 501(c)(3).</li>
|
||||||
|
<li>Major Grants awards are subject to approval by a five-seat Major Grant Review Committee. The Major Grant Review Committee SHALL be selected by the ZF's Community Advisory Panel or successor process.</li>
|
||||||
|
<li>The Major Grant Review Committee's funding decisions will be final, requiring no approval from the ZF Board, but are subject to veto if the Foundation judges them to violate U.S. law or the ZF's reporting requirements and other (current or future) obligations under U.S. IRS 501(c)(3).</li>
|
||||||
|
<li>Major Grant Review Committee members SHALL have a one-year term and MAY sit for reelection. The Major Grant Review Committee is subject to the same conflict of interest policy that governs the ZF Board of Directors (i.e. they MUST recuse themselves when voting on proposals where they have a financial interest). At most one person with association with the BP/ECC, and at most one person with association with the ZF, are allowed to sit on the Major Grant Review Committee. "Association" here means: having a financial interest, full-time employment, being an officer, being a director, or having an immediate family relationship with any of the above. The ZF SHALL continue to operate the Community Advisory Panel and SHOULD work toward making it more representative and independent (more on that below).</li>
|
||||||
|
<li>From 1st January 2022, a portion of the MG allocation shall be allocated to a Discretionary Budget, which may be disbursed for expenses reasonably related to the administration of Major Grants. The amount of funds allocated to the Discretionary Budget SHALL be decided by the ZF's Community Advisory Panel or successor process. Any disbursement of funds from the Discretionary Budget MUST be approved by the Major Grant Review Committee. Expenses related to the administration of Major Grants include, without limitation the following:
|
||||||
|
<ul>
|
||||||
|
<li>Paying third party vendors for services related to domain name registration, or the design, website hosting and administration of websites for the Major Grant Review Committee.</li>
|
||||||
|
<li>Paying independent consultants to develop requests for proposals that align with the Major Grants program.</li>
|
||||||
|
<li>Paying independent consultants for expert review of grant applications.</li>
|
||||||
|
<li>Paying for sales and marketing services to promote the Major Grants program.</li>
|
||||||
|
<li>Paying third party consultants to undertake activities that support the purpose of the Major Grants program.</li>
|
||||||
|
<li>Reimbursement to members of the Major Grant Review Committee for reasonable travel expenses, including transportation, hotel and meals allowance.</li>
|
||||||
|
</ul>
|
||||||
|
<p>The Major Grant Review Committee's decisions relating to the allocation and disbursement of funds from the Discretionary Budget will be final, requiring no approval from the ZF Board, but are subject to veto if the Foundation judges them to violate U.S. law or the ZF's reporting requirements and other (current or future) obligations under U.S. IRS 501(c)(3).</p>
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
<p>ZF SHALL recognize the MG allocation 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 <a href="#transparency-and-accountability">Transparency and Accountability</a> obligations defined below.</p>
|
||||||
|
<p>ZF SHALL strive to define target metrics and key performance indicators, and the Major Grant Review Committee SHOULD utilize these in its funding decisions.</p>
|
||||||
|
</section>
|
||||||
|
<section id="qedit"><h4><span class="section-heading">Qedit</span><span class="section-anchor"> <a rel="bookmark" href="#qedit"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>✳️ These funds SHALL be received and administered by FPF.</p>
|
||||||
|
<p>This allocation of the Dev Fund will flow as charitable contributions from the Zcash Community to Qedit, for the purposes of supporting their ongoing activities related to Zcash Shielded Assets, and related protocol/ application/ legal/ and other efforts.</p>
|
||||||
|
</section>
|
||||||
|
<section id="zechub"><h4><span class="section-heading">ZecHub</span><span class="section-anchor"> <a rel="bookmark" href="#zechub"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>✳️ These funds SHALL be received and administered by FPF.</p>
|
||||||
|
<p>This allocation of the Dev Fund will flow as charitable contributions from the Zcash Community to ZecHub, for the purposes of continuing their ongoing content contributions, community organizing, et al within the Zcash ecosystem.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section id="transparency-and-accountability"><h3><span class="section-heading">Transparency and Accountability</span><span class="section-anchor"> <a rel="bookmark" href="#transparency-and-accountability"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<section id="obligations"><h4><span class="section-heading">Obligations</span><span class="section-anchor"> <a rel="bookmark" href="#obligations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>BP, ECC, ZF, ZCG, Qedit, FPF and ZecHub are recommended to accept the obligations in this section.</p>
|
||||||
|
<p>Ongoing public reporting requirements:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Quarterly reports, detailing future plans, execution on previous plans, and finances (balances, and spending broken down by major categories).</li>
|
||||||
|
<li>Monthly developer calls, or a brief report, on recent and forthcoming tasks. (Developer calls may be shared.)</li>
|
||||||
|
<li>Annual detailed review of the organization performance and future plans.</li>
|
||||||
|
<li>Annual financial report (IRS Form 990, or substantially similar information).</li>
|
||||||
|
</ul>
|
||||||
|
<p>These reports may be either organization-wide, or restricted to the income, expenses, and work associated with the receipt of Dev Fund. As BP is the parent organization of ECC it is expected they may publish joint reports.</p>
|
||||||
|
<p>It is expected that ECC, ZF, and ZCG will be focused primarily (in their attention and resources) on Zcash. Thus, they MUST promptly disclose:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Any major activity they perform (even if not supported by the Dev Fund) that is not in the interest of the general Zcash ecosystem.</li>
|
||||||
|
<li>Any conflict of interest with the general success of the Zcash ecosystem.</li>
|
||||||
|
</ul>
|
||||||
|
<p>BP, ECC, ZF, and grant recipients MUST promptly disclose any security or privacy risks that may affect users of Zcash (by responsible disclosure under confidence to the pertinent developers, where applicable).</p>
|
||||||
|
<p>BP's reports, ECC's reports, and ZF's annual report on its non-grant operations, SHOULD be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.</p>
|
||||||
|
<p>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 <a id="footnote-reference-14" class="footnote_reference" href="#osd">5</a>), preferably the MIT license.</p>
|
||||||
|
</section>
|
||||||
|
<section id="enforcement"><h4><span class="section-heading">Enforcement</span><span class="section-anchor"> <a rel="bookmark" href="#enforcement"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>For grant recipients, these conditions SHOULD be included in their contract with ZF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to ZF.</p>
|
||||||
|
<p>BP, ECC, and ZF MUST contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other party to issue a modified version of Zcash node software that removes the violating party's Dev Fund allocation, and use the Zcash trademark for this modified version. The allocation's funds will be reassigned to MG (whose integrity is legally protected by the Restricted Fund treatment).</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section id="future-community-governance"><h3><span class="section-heading">Future Community Governance</span><span class="section-anchor"> <a rel="bookmark" href="#future-community-governance"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<p>It is highly desirable to develop robust means of decentralized community voting and governance –either by expanding the Zcash Community Advisory Panel or a successor mechanism– and to integrate them into this process by the end of 2025. BP, ECC, ZCG, and ZF SHOULD place high priority on such development and its deployment, in their activities and grant selection.</p>
|
||||||
|
</section>
|
||||||
|
<section id="zf-board-composition"><h3><span class="section-heading">ZF Board Composition</span><span class="section-anchor"> <a rel="bookmark" href="#zf-board-composition"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<p>Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC, except as provided for by the grace period described below.</p>
|
||||||
|
<p>Grace period: members of the ZF board who hold ECC equity (but do not have other current relationships to ECC) may dispose of their equity, or quit the Board, by 21 November 2024. (The grace period is to allow for orderly replacement, and also to allow time for ECC corporate reorganization related to Dev Fund receipt, which may affect how disposition of equity would be executed.)</p>
|
||||||
|
<p>The Zcash Foundation SHOULD endeavor to use the Community Advisory Panel (or successor mechanism) as advisory input for future board elections.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>This proposal is a modification of ZIP 1014 <a id="footnote-reference-15" class="footnote_reference" href="#zip-1014">10</a> and a modification from the original "Manufacturing Consent" proposal as described in the Zcash Forum, in response to observable Zcash community sentiment.</p>
|
||||||
|
<p>The author is grateful to everyone in the Zcash ecosystem.</p>
|
||||||
|
</section>
|
||||||
|
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<table id="bcp14" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>1</th>
|
||||||
|
<td><a href="https://www.rfc-editor.org/info/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"</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="protocol" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>2</th>
|
||||||
|
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="protocol-networks" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>3</th>
|
||||||
|
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="trademark" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>4</th>
|
||||||
|
<td><a href="https://electriccoin.co/wp-content/uploads/2019/11/Final-Consolidated-Version-ECC-Zcash-Trademark-Transfer-Documents-1.pdf">Zcash Trademark Donation and License Agreement</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="osd" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>5</th>
|
||||||
|
<td><a href="https://opensource.org/osd">The Open Source Definition</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-0200" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>6</th>
|
||||||
|
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1003" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>7</th>
|
||||||
|
<td><a href="zip-1003">ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1010" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>8</th>
|
||||||
|
<td><a href="zip-1010">ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1011" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>9</th>
|
||||||
|
<td><a href="zip-1011">ZIP 1011: Decentralize the Dev Fee</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1014" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>10</th>
|
||||||
|
<td><a href="zip-1014">ZIP 1012: Dev Fund to ECC + ZF + Major Grants</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zf-community" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>11</th>
|
||||||
|
<td><a href="https://www.zfnd.org/governance/community-advisory-panel/">ZF Community Advisory Panel</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="section501c3" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>12</th>
|
||||||
|
<td><a href="https://www.law.cornell.edu/uscode/text/26/501">U.S. Code, Title 26, Section 501(c)(3)</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="draft-swihart" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>13</th>
|
||||||
|
<td><a href="https://forum.zcashcommunity.com/t/zcash-funding-bloc-a-dev-fund-proposal-from-josh-at-ecc/47187">Zcash Funding Bloc : A Dev Fund Proposal from Josh at ECC</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zf-fpf-admin-details" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>14</th>
|
||||||
|
<td><a href="https://forum.zcashcommunity.com/t/proposal-zcg-under-fpf/48113/11">Proposal: ZCG under FPF</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
|
@ -0,0 +1,506 @@
|
||||||
|
::
|
||||||
|
|
||||||
|
ZIP: ####
|
||||||
|
Title: Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
|
||||||
|
Owner: Noam Chom <noamchom1967@gmail.com>
|
||||||
|
ZIP-1014 Owners: Andrew Miller <socrates1024@gmail.com>
|
||||||
|
Zooko Wilcox <zooko@electriccoin.co>
|
||||||
|
ZIP-1014 Original-Authors: Eran Tromer
|
||||||
|
ZIP-1014 Credits: Matt Luongo
|
||||||
|
@aristarchus
|
||||||
|
@dontbeevil
|
||||||
|
Daira Emma Hopwood
|
||||||
|
George Tankersley
|
||||||
|
Josh Cincinnati
|
||||||
|
Andrew Miller
|
||||||
|
Status: Active
|
||||||
|
Category: Consensus Process
|
||||||
|
Created: 2024-06-25
|
||||||
|
License: MIT
|
||||||
|
Discussions-To: <https://forum.zcashcommunity.com/t/manufacturing-consent-noamchoms-nu6-block-reward-proposal/47155>
|
||||||
|
Pull-Request: TBD
|
||||||
|
|
||||||
|
|
||||||
|
Terminology
|
||||||
|
===========
|
||||||
|
|
||||||
|
The key words "MUST", "MUST NOT", "SHALL", "SHALL 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.
|
||||||
|
|
||||||
|
The term "network upgrade" in this document is to be interpreted as
|
||||||
|
described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License
|
||||||
|
Agreement ([#trademark]_ or successor agreement).
|
||||||
|
|
||||||
|
The terms "block subsidy" and "halving" in this document are to be interpreted
|
||||||
|
as described in sections 3.10 and 7.8 of the Zcash Protocol Specification.
|
||||||
|
[#protocol]_
|
||||||
|
|
||||||
|
"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric
|
||||||
|
Coin Company, LLC.
|
||||||
|
|
||||||
|
"Bootstrap Project", also called "BP", refers to the 501(c)(3) nonprofit
|
||||||
|
corporation of that name.
|
||||||
|
|
||||||
|
"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit
|
||||||
|
corporation of that name.
|
||||||
|
|
||||||
|
"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue
|
||||||
|
Code (Title 26 of the U.S. Code). [#section501c3]_
|
||||||
|
|
||||||
|
"Community Advisory Panel" refers to the panel of community members assembled
|
||||||
|
by the Zcash Foundation and described at [#zf-community]_.
|
||||||
|
|
||||||
|
"Zcash Community Grants", also called "ZCG", refers to grants program
|
||||||
|
(formerly known as ZOMG) that funds independent teams entering the Zcash ecosystem,
|
||||||
|
to perform major ongoing development (or other work)
|
||||||
|
for the public good of the Zcash ecosystem.
|
||||||
|
<https://zcashcommunitygrants.org/>
|
||||||
|
|
||||||
|
"Financial Privacy Fund", also called "FPF" refers to the start-up non-profit
|
||||||
|
organization incorporated and based in the Cayman Islands.
|
||||||
|
<https://www.financialprivacyfoundation.org/>
|
||||||
|
|
||||||
|
"Qedit" refers to the company founded in 2016 by a world-class team of
|
||||||
|
accomplished tech entrepreneurs, researchers, and developers;
|
||||||
|
QEDIT has emerged as a global leader in the field of Zero-Knowledge Proofs.
|
||||||
|
<https://qed-it.com/about-us/>
|
||||||
|
|
||||||
|
"ZecHub" refers to the team of content creators who have supported Zcash
|
||||||
|
through a series of ZCG approved grants.
|
||||||
|
<https://forum.zcashcommunity.com/t/zechub-an-education-hub-for-zcash-2024-continued/47947>
|
||||||
|
|
||||||
|
The terms "Testnet" and "Mainnet" are to be interpreted as described in
|
||||||
|
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
|
||||||
|
|
||||||
|
The term "ZSA" is to be interpreted as "Zcash Shielded Assets" the protocol
|
||||||
|
feature enhancement (and subsequent application layer, legal, maintenance
|
||||||
|
efforts, et al) on-going by Qedit, et al.
|
||||||
|
<https://forum.zcashcommunity.com/t/grant-update-zcash-shielded-assets-monthly-updates/41153>
|
||||||
|
|
||||||
|
✳️ is used to denote elements of the process part of the ZIP that are still
|
||||||
|
to-be-determined.
|
||||||
|
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
========
|
||||||
|
|
||||||
|
This proposal describes a structure for the Zcash Development Fund, to be
|
||||||
|
enacted in Network Upgrade 6 and last for 4 years. This Dev Fund would consist
|
||||||
|
of 15% of the block subsidies, as the following allocations:
|
||||||
|
|
||||||
|
* 5% for the Zcash Foundation (for internal work and grants);
|
||||||
|
* 4% for the Bootstrap Project (the parent of the Electric Coin Company) for the 1st year only;
|
||||||
|
* 4% for Zcash Community Grants for continuation of their current activities as-is;
|
||||||
|
* 2% for Qedit in support of their ZSA activities, and other Zcash protocol support;
|
||||||
|
|
||||||
|
Following the first year, when ECC will no longer receive their 4% allocation,
|
||||||
|
those block subsidies will be distributed as 1% to ZCG, 1% to ZecHub, 1% to FPF,
|
||||||
|
and 1% to ZF.
|
||||||
|
|
||||||
|
Governance and accountability are based on existing entities and legal mechanisms,
|
||||||
|
and increasingly decentralized governance is encouraged. This proposal mandates
|
||||||
|
the ecosystem to design and deploy a "non-direct funding model" as generally
|
||||||
|
recommended in Josh Swihart's proposal. [#draft-swihart]_
|
||||||
|
|
||||||
|
Upon creation/ activation of a "non-direct funding model" this ZIP should be
|
||||||
|
reconsidered (potentially terminated) by the Zcash ecosystem, to determine
|
||||||
|
if its ongoing direct block subsidies are preferred for continuation.
|
||||||
|
Discussions/ solications/ sentiment gathering from the Zcash
|
||||||
|
ecosystem should be initiated ~6 months in advance of the presumed
|
||||||
|
activation of a "non-direct funding model", such that the Zcash ecosystem
|
||||||
|
preference can be expediently realized.
|
||||||
|
|
||||||
|
Block subsidies will be administered through two organizations:
|
||||||
|
|
||||||
|
1. Zcash Foundation (✳️ for ECC, ZCG)
|
||||||
|
2. Financial Privacy Fund (✳️ for Qedit, ZecHub)
|
||||||
|
|
||||||
|
✳️ **ZF and FPF adminstration of block subsidy details, costs, et al are currently under debate**
|
||||||
|
[#zf-fpf-admin-details]_
|
||||||
|
|
||||||
|
|
||||||
|
Motivation
|
||||||
|
==========
|
||||||
|
|
||||||
|
As of Zcash's second halving in November 2024, by default 100% of the block
|
||||||
|
subsidies will be allocated to miners, and no further funds will be automatically
|
||||||
|
allocated to any other entities. Consequently, no new funding
|
||||||
|
may be available to existing teams dedicated to furthering charitable,
|
||||||
|
educational, or scientific purposes, such as research, development, and outreach:
|
||||||
|
the Electric Coin Company (ECC), the Zcash Foundation (ZF), the ZCG, and the many
|
||||||
|
entities funded by the ZF and ZCG grant programs.
|
||||||
|
|
||||||
|
There is a need to strike a balance between incentivizing the security of the
|
||||||
|
consensus protocol (i.e., mining) versus crucial charitable, educational, and/or
|
||||||
|
scientific aspects, such as research, development and outreach.
|
||||||
|
|
||||||
|
Furthermore, there is a need to balance the sustenance of ongoing work by the
|
||||||
|
current teams dedicated to Zcash, with encouraging decentralization and growth
|
||||||
|
of independent development teams.
|
||||||
|
|
||||||
|
For these reasons, the Zcash Community desires to allocate and
|
||||||
|
contribute a portion of the block subsidies otherwise allocated to
|
||||||
|
miners as a donation to support charitable, educational, and
|
||||||
|
scientific activities within the meaning of Section 501(c)(3).
|
||||||
|
|
||||||
|
This proposal also introduces the benefit of a non-USA based entity (FPF) as
|
||||||
|
the administrator for block subsidies to two organizations that are also
|
||||||
|
non-USA based (Qedit and ZecHub). USA based regulatory risk continues to
|
||||||
|
(negatively) impact the Zcash project, which has been predominantly based in the USA.
|
||||||
|
|
||||||
|
|
||||||
|
Requirements
|
||||||
|
============
|
||||||
|
|
||||||
|
The Dev Fund should encourage decentralization of the work and funding, by
|
||||||
|
supporting new teams dedicated to Zcash.
|
||||||
|
|
||||||
|
The Dev Fund should maintain the existing teams and capabilities in the Zcash
|
||||||
|
ecosystem, unless and until concrete opportunities arise to create even greater
|
||||||
|
value for the Zcash ecosystem.
|
||||||
|
|
||||||
|
There should not be any single entity which is a single point of failure, i.e.,
|
||||||
|
whose capture or failure will effectively prevent effective use of the funds.
|
||||||
|
|
||||||
|
Major funding decisions should be based, to the extent feasible, on inputs from
|
||||||
|
domain experts and pertinent stakeholders.
|
||||||
|
|
||||||
|
The Dev Fund mechanism should not modify the monetary emission curve (and in
|
||||||
|
particular, should not irrevocably burn coins).
|
||||||
|
|
||||||
|
In case the value of ZEC jumps, the Dev Fund recipients should not wastefully
|
||||||
|
use excessive amounts of funds. Conversely, given market volatility and eventual
|
||||||
|
halvings, it is desirable to create rainy-day reserves.
|
||||||
|
|
||||||
|
The Dev Fund mechanism should not reduce users' financial privacy or security.
|
||||||
|
In particular, it should not cause them to expose their coin holdings, nor
|
||||||
|
cause them to maintain access to secret keys for much longer than they would
|
||||||
|
otherwise. (This rules out some forms of voting, and of disbursing coins to
|
||||||
|
past/future miners.)
|
||||||
|
|
||||||
|
The Dev Fund system should be simple to understand and realistic to
|
||||||
|
implement. In particular, it should not assume the creation of new mechanisms
|
||||||
|
(e.g., election systems) or entities (for governance or development) for its
|
||||||
|
execution; but it should strive to support and use these once they are built.
|
||||||
|
|
||||||
|
Dev Fund recipients should comply with legal, regulatory, and taxation
|
||||||
|
constraints in their pertinent jurisdiction(s).
|
||||||
|
|
||||||
|
|
||||||
|
Non-requirements
|
||||||
|
================
|
||||||
|
|
||||||
|
General on-chain governance is outside the scope of this proposal.
|
||||||
|
|
||||||
|
Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or
|
||||||
|
one-person-one-vote) are outside the scope of this proposal, however this
|
||||||
|
proposal does mandate the undertaking of the project to build a "non-direct
|
||||||
|
funding model" as generally described in [#draft-swihart]_.
|
||||||
|
|
||||||
|
Specification
|
||||||
|
=============
|
||||||
|
|
||||||
|
Consensus changes implied by this specification are applicable to the
|
||||||
|
Zcash Mainnet. Similar (but not necessarily identical) consensus changes
|
||||||
|
SHOULD be applied to the Zcash Testnet for testing purposes.
|
||||||
|
|
||||||
|
|
||||||
|
Dev Fund allocation
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Starting at the second Zcash halving in 2024, until the third halving in 2028,
|
||||||
|
15% of the block subsidy of each block SHALL be allocated to a "Dev Fund" that
|
||||||
|
consists of the following allocations:
|
||||||
|
|
||||||
|
* 5% for the Zcash Foundation (for internal work and grants);
|
||||||
|
* 4% for the Bootstrap Project (the parent of the Electric Coin Company) for the 1st year only;
|
||||||
|
* 4% for Zcash Community Grants for continuation of their current activities as-is;
|
||||||
|
* 2% for Qedit in support of their ZSA activities, and other Zcash protocol support;
|
||||||
|
|
||||||
|
Following the first year, when ECC will no longer receive their 4% allocation,
|
||||||
|
those block subsidies will be distributed as 1% to ZCG, 1% to ZecHub, 1% to FPF,
|
||||||
|
and 1% to ZF.
|
||||||
|
|
||||||
|
This proposal mandates the ecosystem to design and deploy a "non-direct funding model"
|
||||||
|
as generally recommended in Josh Swihart's proposal [#draft-swihart]_.
|
||||||
|
|
||||||
|
"Dev Fund" block subsidies will be administered through two organizations:
|
||||||
|
|
||||||
|
1. Zcash Foundation (✳️ for ECC, ZCG)
|
||||||
|
2. Financial Privacy Fund (✳️ for Qedit, ZecHub)
|
||||||
|
|
||||||
|
✳️ **ZF and FPF adminstration of block subsidy details, costs, et al are currently under debate**
|
||||||
|
[#zf-fpf-admin-details]_
|
||||||
|
|
||||||
|
The allocations are described in more detail below. The fund flow will be implemented
|
||||||
|
at the consensus-rule layer, by sending the corresponding ZEC to the designated
|
||||||
|
address(es) for each block. This Dev Fund will end at the third halving (unless
|
||||||
|
extended/modified by a future ZIP).
|
||||||
|
|
||||||
|
|
||||||
|
BP allocation (Bootstrap Project)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
✳️ These funds SHALL be received and administered by ZF.
|
||||||
|
|
||||||
|
This allocation of the Dev Fund will flow as charitable contributions from
|
||||||
|
the Zcash Community to the Bootstrap Project, the newly formed parent
|
||||||
|
organization to the Electric Coin Company. The Bootstrap Project is organized
|
||||||
|
for exempt educational, charitable, and scientific purposes in
|
||||||
|
compliance with Section 501(c)(3), including but not
|
||||||
|
limited to furthering education, information, resources, advocacy,
|
||||||
|
support, community, and research relating to cryptocurrency and
|
||||||
|
privacy, including Zcash. This allocation will be used at the discretion of
|
||||||
|
the Bootstrap Project for any purpose within its mandate to support financial
|
||||||
|
privacy and the Zcash platform as permitted under Section 501(c)(3). The
|
||||||
|
BP allocation will be treated as a charitable contribution from the
|
||||||
|
Community to support these educational, charitable, and scientific
|
||||||
|
purposes.
|
||||||
|
|
||||||
|
|
||||||
|
ZF allocation (Zcash Foundation's general use)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
This allocation of the Dev Fund will flow as charitable contributions from
|
||||||
|
the Zcash Community to ZF, to be used at its discretion for any
|
||||||
|
purpose within its mandate to support financial privacy and the Zcash
|
||||||
|
platform, including: development, education, supporting community
|
||||||
|
communication online and via events, gathering community sentiment,
|
||||||
|
and awarding external grants for all of the above, subject to the
|
||||||
|
requirements of Section 501(c)(3). The ZF allocation will be
|
||||||
|
treated as a charitable contribution from the Community to support
|
||||||
|
these educational, charitable, and scientific purposes.
|
||||||
|
|
||||||
|
|
||||||
|
Zcash Community Grants (ZCG)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
This allocation of the Dev Fund is intended to fund independent teams entering the
|
||||||
|
Zcash ecosystem, to perform major and minor ongoing development (or other work) for the
|
||||||
|
public good of the Zcash ecosystem, to the extent that such teams are available
|
||||||
|
and effective.
|
||||||
|
|
||||||
|
✳️ These funds SHALL be received and administered by ZF (or FPF, pending TBD outcomes
|
||||||
|
of FPF proposal: [#zf-fpf-admin-details]_).
|
||||||
|
ZF MUST disburse them for "Major Grants" and expenses reasonably related to
|
||||||
|
the administration of Major Grants, but subject to the following additional constraints:
|
||||||
|
|
||||||
|
1. These funds MUST only be used to issue Major Grants to external parties
|
||||||
|
that are independent of ZF, and to pay for expenses reasonably related to
|
||||||
|
the administration of Major Grants. They MUST NOT be used by ZF for its
|
||||||
|
internal operations and direct expenses not related to administration of
|
||||||
|
Major Grants. Additionally, BP, ECC, and ZF are ineligible to receive
|
||||||
|
Major Grants.
|
||||||
|
|
||||||
|
2. Major Grants SHOULD support well-specified work proposed by the grantee,
|
||||||
|
at reasonable market-rate costs. They can be of any duration or ongoing
|
||||||
|
without a duration limit. Grants of indefinite duration SHOULD have
|
||||||
|
semiannual review points for continuation of funding.
|
||||||
|
|
||||||
|
3. Priority SHOULD be given to Major Grants that bolster teams with
|
||||||
|
substantial (current or prospective) continual existence, and set them up
|
||||||
|
for long-term success, subject to the usual grant award considerations
|
||||||
|
(impact, ability, risks, team, cost-effectiveness, etc.). Priority SHOULD be
|
||||||
|
given to Major Grants that support ecosystem growth, for example through
|
||||||
|
mentorship, coaching, technical resources, creating entrepreneurial
|
||||||
|
opportunities, etc. If one proposal substantially duplicates another's
|
||||||
|
plans, priority SHOULD be given to the originator of the plans.
|
||||||
|
|
||||||
|
4. Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and
|
||||||
|
its ecosystem (which is more specific than furthering financial privacy in
|
||||||
|
general) as permitted under Section 501(c)(3).
|
||||||
|
|
||||||
|
5. Major Grants awards are subject to approval by a five-seat Major Grant
|
||||||
|
Review Committee. The Major Grant Review Committee SHALL be selected by the
|
||||||
|
ZF's Community Advisory Panel or successor process.
|
||||||
|
|
||||||
|
6. The Major Grant Review Committee's funding decisions will be final, requiring
|
||||||
|
no approval from the ZF Board, but are subject to veto if the Foundation
|
||||||
|
judges them to violate U.S. law or the ZF's reporting requirements and other
|
||||||
|
(current or future) obligations under U.S. IRS 501(c)(3).
|
||||||
|
|
||||||
|
7. Major Grant Review Committee members SHALL have a one-year term and MAY sit
|
||||||
|
for reelection. The Major Grant Review Committee is subject to the same
|
||||||
|
conflict of interest policy that governs the ZF Board of Directors (i.e. they
|
||||||
|
MUST recuse themselves when voting on proposals where they have a financial
|
||||||
|
interest). At most one person with association with the BP/ECC, and at most
|
||||||
|
one person with association with the ZF, are allowed to sit on the Major
|
||||||
|
Grant Review Committee. "Association" here means: having a financial
|
||||||
|
interest, full-time employment, being an officer, being a director, or having
|
||||||
|
an immediate family relationship with any of the above. The ZF SHALL continue
|
||||||
|
to operate the Community Advisory Panel and SHOULD work toward making it more
|
||||||
|
representative and independent (more on that below).
|
||||||
|
|
||||||
|
8. From 1st January 2022, a portion of the MG allocation shall be allocated to a
|
||||||
|
Discretionary Budget, which may be disbursed for expenses reasonably related
|
||||||
|
to the administration of Major Grants. The amount of funds allocated to the
|
||||||
|
Discretionary Budget SHALL be decided by the ZF's Community Advisory Panel or
|
||||||
|
successor process. Any disbursement of funds from the Discretionary Budget
|
||||||
|
MUST be approved by the Major Grant Review Committee. Expenses related to the
|
||||||
|
administration of Major Grants include, without limitation the following:
|
||||||
|
|
||||||
|
* Paying third party vendors for services related to domain name registration, or
|
||||||
|
the design, website hosting and administration of websites for the Major Grant
|
||||||
|
Review Committee.
|
||||||
|
* Paying independent consultants to develop requests for proposals that align
|
||||||
|
with the Major Grants program.
|
||||||
|
* Paying independent consultants for expert review of grant applications.
|
||||||
|
* Paying for sales and marketing services to promote the Major Grants
|
||||||
|
program.
|
||||||
|
* Paying third party consultants to undertake activities that support the
|
||||||
|
purpose of the Major Grants program.
|
||||||
|
* Reimbursement to members of the Major Grant Review Committee for reasonable
|
||||||
|
travel expenses, including transportation, hotel and meals allowance.
|
||||||
|
|
||||||
|
The Major Grant Review Committee's decisions relating to the allocation and
|
||||||
|
disbursement of funds from the Discretionary Budget will be final, requiring
|
||||||
|
no approval from the ZF Board, but are subject to veto if the Foundation
|
||||||
|
judges them to violate U.S. law or the ZF's reporting requirements and other
|
||||||
|
(current or future) obligations under U.S. IRS 501(c)(3).
|
||||||
|
|
||||||
|
ZF SHALL recognize the MG allocation of the Dev Fund as a Restricted Fund
|
||||||
|
donation under the above constraints (suitably formalized), and keep separate
|
||||||
|
accounting of its balance and usage under its `Transparency and Accountability`_
|
||||||
|
obligations defined below.
|
||||||
|
|
||||||
|
ZF SHALL strive to define target metrics and key performance indicators,
|
||||||
|
and the Major Grant Review Committee SHOULD utilize these in its funding
|
||||||
|
decisions.
|
||||||
|
|
||||||
|
|
||||||
|
Qedit
|
||||||
|
~~~~~
|
||||||
|
|
||||||
|
✳️ These funds SHALL be received and administered by FPF.
|
||||||
|
|
||||||
|
This allocation of the Dev Fund will flow as charitable contributions from
|
||||||
|
the Zcash Community to Qedit, for the purposes of supporting their ongoing
|
||||||
|
activities related to Zcash Shielded Assets, and related protocol/ application/
|
||||||
|
legal/ and other efforts.
|
||||||
|
|
||||||
|
ZecHub
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
|
✳️ These funds SHALL be received and administered by FPF.
|
||||||
|
|
||||||
|
This allocation of the Dev Fund will flow as charitable contributions from
|
||||||
|
the Zcash Community to ZecHub, for the purposes of continuing their
|
||||||
|
ongoing content contributions, community organizing, et al within the
|
||||||
|
Zcash ecosystem.
|
||||||
|
|
||||||
|
|
||||||
|
Transparency and Accountability
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
Obligations
|
||||||
|
~~~~~~~~~~~
|
||||||
|
|
||||||
|
BP, ECC, ZF, ZCG, Qedit, FPF and ZecHub are recommended to accept the obligations in this section.
|
||||||
|
|
||||||
|
Ongoing public reporting requirements:
|
||||||
|
|
||||||
|
* Quarterly reports, detailing future plans, execution on previous plans, and
|
||||||
|
finances (balances, and spending broken down by major categories).
|
||||||
|
* Monthly developer calls, or a brief report, on recent and forthcoming tasks.
|
||||||
|
(Developer calls may be shared.)
|
||||||
|
* Annual detailed review of the organization performance and future plans.
|
||||||
|
* Annual financial report (IRS Form 990, or substantially similar information).
|
||||||
|
|
||||||
|
These reports may be either organization-wide, or restricted to the income,
|
||||||
|
expenses, and work associated with the receipt of Dev Fund.
|
||||||
|
As BP is the parent organization of ECC it is expected they may publish
|
||||||
|
joint reports.
|
||||||
|
|
||||||
|
It is expected that ECC, ZF, and ZCG will be focused
|
||||||
|
primarily (in their attention and resources) on Zcash. Thus, they MUST
|
||||||
|
promptly disclose:
|
||||||
|
|
||||||
|
* Any major activity they perform (even if not supported by the Dev Fund) that
|
||||||
|
is not in the interest of the general Zcash ecosystem.
|
||||||
|
* Any conflict of interest with the general success of the Zcash ecosystem.
|
||||||
|
|
||||||
|
BP, ECC, ZF, and grant recipients MUST promptly disclose any security or privacy
|
||||||
|
risks that may affect users of Zcash (by responsible disclosure under
|
||||||
|
confidence to the pertinent developers, where applicable).
|
||||||
|
|
||||||
|
BP's reports, ECC's reports, and ZF's annual report on its non-grant operations,
|
||||||
|
SHOULD be at least as detailed as grant proposals/reports submitted by other
|
||||||
|
funded parties, and satisfy similar levels of public scrutiny.
|
||||||
|
|
||||||
|
All substantial software whose development was funded by the Dev Fund SHOULD
|
||||||
|
be released under an Open Source license (as defined by the Open Source
|
||||||
|
Initiative [#osd]_), preferably the MIT license.
|
||||||
|
|
||||||
|
|
||||||
|
Enforcement
|
||||||
|
~~~~~~~~~~~
|
||||||
|
|
||||||
|
For grant recipients, these conditions SHOULD be included in their contract
|
||||||
|
with ZF, such that substantial violation, not promptly remedied, will cause
|
||||||
|
forfeiture of their grant funds and their return to ZF.
|
||||||
|
|
||||||
|
BP, ECC, and ZF MUST contractually commit to each other to fulfill these
|
||||||
|
conditions, and the prescribed use of funds, such that substantial violation,
|
||||||
|
not promptly remedied, will permit the other party to issue a modified version
|
||||||
|
of Zcash node software that removes the violating party's Dev Fund allocation, and
|
||||||
|
use the Zcash trademark for this modified version. The allocation's funds will be
|
||||||
|
reassigned to MG (whose integrity is legally protected by the Restricted
|
||||||
|
Fund treatment).
|
||||||
|
|
||||||
|
|
||||||
|
Future Community Governance
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
It is highly desirable to develop robust means of decentralized community
|
||||||
|
voting and governance –either by expanding the Zcash Community Advisory Panel or a
|
||||||
|
successor mechanism– and to integrate them into this process by the end of
|
||||||
|
2025. BP, ECC, ZCG, and ZF SHOULD place high priority on such development and its
|
||||||
|
deployment, in their activities and grant selection.
|
||||||
|
|
||||||
|
|
||||||
|
ZF Board Composition
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current
|
||||||
|
business or employment relationships with ECC, except as provided for by the
|
||||||
|
grace period described below.
|
||||||
|
|
||||||
|
Grace period: members of the ZF board who hold ECC equity (but do not have other
|
||||||
|
current relationships to ECC) may dispose of their equity, or quit the Board,
|
||||||
|
by 21 November 2024. (The grace period is to allow for orderly replacement, and
|
||||||
|
also to allow time for ECC corporate reorganization related to Dev Fund
|
||||||
|
receipt, which may affect how disposition of equity would be executed.)
|
||||||
|
|
||||||
|
The Zcash Foundation SHOULD endeavor to use the Community Advisory Panel (or
|
||||||
|
successor mechanism) as advisory input for future board elections.
|
||||||
|
|
||||||
|
|
||||||
|
Acknowledgements
|
||||||
|
================
|
||||||
|
|
||||||
|
This proposal is a modification of ZIP 1014 [#zip-1014]_
|
||||||
|
and a modification from the original "Manufacturing Consent" proposal
|
||||||
|
as described in the Zcash Forum, in response to observable Zcash
|
||||||
|
community sentiment.
|
||||||
|
|
||||||
|
The author is grateful to everyone in the Zcash ecosystem.
|
||||||
|
|
||||||
|
|
||||||
|
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" <https://www.rfc-editor.org/info/bcp14>`_
|
||||||
|
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
||||||
|
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||||
|
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://electriccoin.co/wp-content/uploads/2019/11/Final-Consolidated-Version-ECC-Zcash-Trademark-Transfer-Documents-1.pdf>`_
|
||||||
|
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
|
||||||
|
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||||
|
.. [#zip-1003] `ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate <zip-1003.rst>`_
|
||||||
|
.. [#zip-1010] `ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams <zip-1010.rst>`_
|
||||||
|
.. [#zip-1011] `ZIP 1011: Decentralize the Dev Fee <zip-1011.rst>`_
|
||||||
|
.. [#zip-1014] `ZIP 1012: Dev Fund to ECC + ZF + Major Grants <zip-1014.rst>`_
|
||||||
|
.. [#zf-community] `ZF Community Advisory Panel <https://www.zfnd.org/governance/community-advisory-panel/>`_
|
||||||
|
.. [#section501c3] `U.S. Code, Title 26, Section 501(c)(3) <https://www.law.cornell.edu/uscode/text/26/501>`_
|
||||||
|
.. [#draft-swihart] `Zcash Funding Bloc : A Dev Fund Proposal from Josh at ECC <https://forum.zcashcommunity.com/t/zcash-funding-bloc-a-dev-fund-proposal-from-josh-at-ecc/47187>`_
|
||||||
|
.. [#zf-fpf-admin-details] `Proposal: ZCG under FPF <https://forum.zcashcommunity.com/t/proposal-zcg-under-fpf/48113/11>`_
|
||||||
|
|
@ -1,18 +1,19 @@
|
||||||
<!DOCTYPE html>
|
<!DOCTYPE html>
|
||||||
<html>
|
<html>
|
||||||
<head>
|
<head>
|
||||||
<title>Draft nuttycom-funding-allocation: Allocation of Block Rewards for Decentralized Development Funding</title>
|
<title>Draft nuttycom-funding-allocation: Block Reward Allocation for Non-Direct Development Funding</title>
|
||||||
<meta charset="utf-8" />
|
<meta charset="utf-8" />
|
||||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||||
<body>
|
<body>
|
||||||
<section>
|
<section>
|
||||||
<pre>ZIP: Unassigned
|
<pre>ZIP: Unassigned
|
||||||
Title: Allocation of Block Rewards for Decentralized Development Funding
|
Title: Block Reward Allocation for Non-Direct Development Funding
|
||||||
Owners: Kris Nuttycombe <kris@nutty.land>
|
Owners: Kris Nuttycombe <kris@nutty.land>
|
||||||
Jason McGee <aquietinvestor@gmail.com>
|
Jason McGee <aquietinvestor@gmail.com>
|
||||||
Original-Authors: Skylar Saveland <skylar@free2z.com>
|
Original-Authors: Skylar Saveland <skylar@free2z.com>
|
||||||
Credits: Daira-Emma Hopwood
|
Credits: Daira-Emma Hopwood
|
||||||
Jack Grigg
|
Jack Grigg
|
||||||
|
@Peacemonger (Zcash Forum)
|
||||||
Status: Draft
|
Status: Draft
|
||||||
Category: Consensus
|
Category: Consensus
|
||||||
Created: 2024-07-03
|
Created: 2024-07-03
|
||||||
|
|
@ -20,23 +21,13 @@ License: MIT
|
||||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://github.com/zcash/zips/pull/866</a>></pre>
|
Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://github.com/zcash/zips/pull/866</a>></pre>
|
||||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
|
<p>The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
|
||||||
<!-- {Avoid duplicating definitions from other ZIPs. Instead use wording like this:} -->
|
|
||||||
<!-- The terms "Mainnet" and "Testnet" in this document are to be interpreted as -->
|
|
||||||
<!-- defined in the Zcash protocol specification [#protocol-networks]_. -->
|
|
||||||
<!-- The term "full validator" in this document is to be interpreted as defined in -->
|
|
||||||
<!-- the Zcash protocol specification [#protocol-blockchain]_. -->
|
|
||||||
<!-- The terms below are to be interpreted as follows: -->
|
|
||||||
<!-- {Term to be defined} -->
|
|
||||||
<!-- {Definition.} -->
|
|
||||||
<!-- {Another term} -->
|
|
||||||
<!-- {Definition.} -->
|
|
||||||
</section>
|
</section>
|
||||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>This ZIP proposes several options for the allocation of a percentage of the Zcash block subsidy, post-November 2024 halving, to an in-protocol "lockbox." Currently, 80% of the block subsidy goes to miners, while 20% is distributed among the Major Grants Fund (ZCG), Electric Coin Company (ECC), and the Zcash Foundation (ZF). If no changes are made, this 20% dev fund will expire, resulting in the entire block subsidy going to miners, leaving no block-subsidy funds for essential protocol development, security, marketing, or legal expenses.</p>
|
<p>This ZIP proposes several options for the allocation of a percentage of the Zcash block subsidy, post-November 2024 halving, to an in-protocol "lockbox." The "lockbox" will be a separate pool of issued funds tracked by the protocol, as described in ZIP <TBD>: Lockbox Funding Streams <a id="footnote-reference-2" class="footnote_reference" href="#zip-lockbox-funding-streams">3</a>. 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.</p>
|
||||||
<p>The proposed lockbox addresses significant issues observed with <a id="footnote-reference-2" class="footnote_reference" href="#zip-1014">2</a>, such as regulatory risks, inefficiencies in funding 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.</p>
|
<p>The proposed lockbox addresses significant issues observed with ZIP 1014 <a id="footnote-reference-3" class="footnote_reference" href="#zip-1014">2</a>, such as regulatory risks, inefficiencies in funding 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.</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>Starting at Zcash's second halving in November 2024, by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, no substantial new funding may be available to existing teams dedicated to furthering charitable, educational, or scientific purposes, such as research, development, and outreach.</p>
|
<p>Starting at Zcash's second halving in November 2024, by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, 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 will 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.</p>
|
||||||
<p>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.</p>
|
<p>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.</p>
|
||||||
<p>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:</p>
|
<p>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:</p>
|
||||||
<ol type="1">
|
<ol type="1">
|
||||||
|
|
@ -50,7 +41,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://githu
|
||||||
</section>
|
</section>
|
||||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<ol type="1">
|
<ol type="1">
|
||||||
<li><strong>In-Protocol Lockbox</strong>: The alternatives presented in this ZIP depend upon the Lockbox Funding Streams proposal <a id="footnote-reference-3" class="footnote_reference" href="#zip-lockbox-funding-streams">3</a>.</li>
|
<li><strong>In-Protocol Lockbox</strong>: The alternatives presented in this ZIP depend upon the Lockbox Funding Streams proposal <a id="footnote-reference-4" class="footnote_reference" href="#zip-lockbox-funding-streams">3</a>.</li>
|
||||||
<li><strong>Regulatory Considerations</strong>: The allocation of funds should minimize regulatory risks by avoiding direct funding of specific organizations. The design should ensure compliance with applicable laws and regulations to support the long-term sustainability of the funding model.</li>
|
<li><strong>Regulatory Considerations</strong>: The allocation of funds should minimize regulatory risks by avoiding direct funding of specific organizations. The design should ensure compliance with applicable laws and regulations to support the long-term sustainability of the funding model.</li>
|
||||||
</ol>
|
</ol>
|
||||||
</section>
|
</section>
|
||||||
|
|
@ -63,11 +54,11 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://githu
|
||||||
</ol>
|
</ol>
|
||||||
</section>
|
</section>
|
||||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>The following alternatives all depend upon the Lockbox Funding Streams proposal <a id="footnote-reference-4" class="footnote_reference" href="#zip-lockbox-funding-streams">3</a> for storage of funds into a deferred value pool.</p>
|
<p>The following alternatives all depend upon the Lockbox Funding Streams proposal <a id="footnote-reference-5" class="footnote_reference" href="#zip-lockbox-funding-streams">3</a> for storage of funds into a deferred value pool.</p>
|
||||||
<p>Some of the alternatives described below do not specify a termination height for the funding streams they propose. In these cases, the termination height is set to <cite>u32::MAX_VALUE</cite>. A future network upgrade is required in order for these streams to be terminated.</p>
|
<p>Some of the alternatives described below do not specify a termination height for the funding streams they propose. In these cases, the termination height is set to <cite>u32::MAX_VALUE</cite>. A future network upgrade is required in order for these streams to be terminated.</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="alternatives"><h2><span class="section-heading">Alternatives</span><span class="section-anchor"> <a rel="bookmark" href="#alternatives"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="alternatives"><h2><span class="section-heading">Alternatives</span><span class="section-anchor"> <a rel="bookmark" href="#alternatives"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<section id="alternative-1"><h3><span class="section-heading">Alternative 1</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="alternative-1-lockbox-for-decentralized-grants-allocation-perpetual-50-option"><h3><span class="section-heading">Alternative 1: Lockbox For Decentralized Grants Allocation (perpetual 50% option)</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-1-lockbox-for-decentralized-grants-allocation-perpetual-50-option"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<p>Proposed by Skylar Saveland</p>
|
<p>Proposed by Skylar Saveland</p>
|
||||||
<ul>
|
<ul>
|
||||||
<li>50% of the block subsidy is to be distributed to the lockbox.</li>
|
<li>50% of the block subsidy is to be distributed to the lockbox.</li>
|
||||||
|
|
@ -82,8 +73,8 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://githu
|
||||||
<p>This alternative proposes a substantially larger slice of the block subsidy than is currently allocated for development funding, in order to provide a long-term source of funding for protocol improvements. It is intended that a future mechanism put in place for the disbursement of these funds to only release funds from the pool in relatively small increments and with a bounded upper value, to ensure that funding remains available for years to come.</p>
|
<p>This alternative proposes a substantially larger slice of the block subsidy than is currently allocated for development funding, in order to provide a long-term source of funding for protocol improvements. It is intended that a future mechanism put in place for the disbursement of these funds to only release funds from the pool in relatively small increments and with a bounded upper value, to ensure that funding remains available for years to come.</p>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="alternative-2"><h3><span class="section-heading">Alternative 2</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-2"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="alternative-2-hybrid-deferred-dev-fund-transitioning-to-a-non-direct-funding-model"><h3><span class="section-heading">Alternative 2: Hybrid Deferred Dev Fund: Transitioning to a Non-Direct Funding Model</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-2-hybrid-deferred-dev-fund-transitioning-to-a-non-direct-funding-model"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<p>Proposed by Jason McGee</p>
|
<p>Proposed by Jason McGee, Peacemonger, GGuy</p>
|
||||||
<ul>
|
<ul>
|
||||||
<li>12% of the block subsidy is to be distributed to the lockbox.</li>
|
<li>12% of the block subsidy is to be distributed to the lockbox.</li>
|
||||||
<li>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.</li>
|
<li>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.</li>
|
||||||
|
|
@ -99,11 +90,11 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://githu
|
||||||
<ul>
|
<ul>
|
||||||
<li><strong>Limited Runway</strong>: 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.</li>
|
<li><strong>Limited Runway</strong>: 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.</li>
|
||||||
<li><strong>Promoting Decentralization</strong>: 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.</li>
|
<li><strong>Promoting Decentralization</strong>: 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.</li>
|
||||||
<li><strong>Mitigating Regulatory Risks</strong>: By minimizing direct funding of US-based organizations, the lockbox helps to reduce potential regulatory scrutiny and legal risks.</li>
|
<li><strong>Mitigating Regulatory Risks</strong>: 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.</li>
|
||||||
</ul>
|
</ul>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="alternative-3"><h3><span class="section-heading">Alternative 3</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-3"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="alternative-3-lockbox-for-decentralized-grants-allocation-20-option"><h3><span class="section-heading">Alternative 3: Lockbox For Decentralized Grants Allocation (20% option)</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-3-lockbox-for-decentralized-grants-allocation-20-option"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<p>Proposed by Kris Nuttycombe</p>
|
<p>Proposed by Kris Nuttycombe</p>
|
||||||
<ul>
|
<ul>
|
||||||
<li>20% of the block subsidy is to be distributed to the lockbox.</li>
|
<li>20% of the block subsidy is to be distributed to the lockbox.</li>
|
||||||
|
|
@ -118,7 +109,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://githu
|
||||||
<p>This alternative is presented as the simplest allocation of block rewards to a lockbox for future disbursement that is consistent with results of community polling.</p>
|
<p>This alternative is presented as the simplest allocation of block rewards to a lockbox for future disbursement that is consistent with results of community polling.</p>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="alternative-4"><h3><span class="section-heading">Alternative 4</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-4"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="alternative-4-masters-of-the-universe"><h3><span class="section-heading">Alternative 4: Masters Of The Universe</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-4-masters-of-the-universe"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<p>Proposed by NoamChom (Zcash forum)</p>
|
<p>Proposed by NoamChom (Zcash forum)</p>
|
||||||
<ul>
|
<ul>
|
||||||
<li>17% of the block subsidy is to be distributed to the lockbox.</li>
|
<li>17% of the block subsidy is to be distributed to the lockbox.</li>
|
||||||
|
|
@ -150,7 +141,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://githu
|
||||||
<li>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.</li>
|
<li>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.</li>
|
||||||
<li>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:
|
<li>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:
|
||||||
<div>
|
<div>
|
||||||
<h1>System Message: ERROR/3 (draft-nuttycom-funding-allocation.rst line 354)</h1>
|
<h1>System Message: ERROR/3 (draft-nuttycom-funding-allocation.rst line 345)</h1>
|
||||||
<p>Unexpected indentation.</p>
|
<p>Unexpected indentation.</p>
|
||||||
</div>
|
</div>
|
||||||
<ul>
|
<ul>
|
||||||
|
|
@ -178,14 +169,14 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/866">https://githu
|
||||||
<section id="transparency-and-accountability"><h3><span class="section-heading">Transparency and Accountability</span><span class="section-anchor"> <a rel="bookmark" href="#transparency-and-accountability"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="transparency-and-accountability"><h3><span class="section-heading">Transparency and Accountability</span><span class="section-anchor"> <a rel="bookmark" href="#transparency-and-accountability"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<p>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</p>
|
<p>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</p>
|
||||||
<div>
|
<div>
|
||||||
<h1>System Message: ERROR/3 (draft-nuttycom-funding-allocation.rst line 428)</h1>
|
<h1>System Message: ERROR/3 (draft-nuttycom-funding-allocation.rst line 419)</h1>
|
||||||
<p>Unexpected indentation.</p>
|
<p>Unexpected indentation.</p>
|
||||||
</div>
|
</div>
|
||||||
<blockquote>
|
<blockquote>
|
||||||
<p>financials and any disbursements made to grantees.</p>
|
<p>financials and any disbursements made to grantees.</p>
|
||||||
</blockquote>
|
</blockquote>
|
||||||
<div>
|
<div>
|
||||||
<h1>System Message: WARNING/2 (draft-nuttycom-funding-allocation.rst line 429)</h1>
|
<h1>System Message: WARNING/2 (draft-nuttycom-funding-allocation.rst line 420)</h1>
|
||||||
<p>Block quote ends without a blank line; unexpected unindent.</p>
|
<p>Block quote ends without a blank line; unexpected unindent.</p>
|
||||||
</div>
|
</div>
|
||||||
<ul>
|
<ul>
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,288 @@
|
||||||
|
<!DOCTYPE html>
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Draft zf-community-dev-fund-2-proposal: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve</title>
|
||||||
|
<meta charset="utf-8" />
|
||||||
|
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||||
|
<body>
|
||||||
|
<section>
|
||||||
|
<pre>ZIP: Unassigned
|
||||||
|
Title: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
|
||||||
|
Owners: Jack Gavigan <jack@zfnd.org>
|
||||||
|
Credits: Eran Tromer
|
||||||
|
Andrew Miller
|
||||||
|
Zooko Wilcox
|
||||||
|
Matt Luongo
|
||||||
|
@aristarchus
|
||||||
|
@dontbeevil
|
||||||
|
Daira Emma Hopwood
|
||||||
|
George Tankersley
|
||||||
|
Josh Cincinnati
|
||||||
|
Status: Draft
|
||||||
|
Category: Consensus Process
|
||||||
|
Created: 2024-07-01
|
||||||
|
License: MIT
|
||||||
|
Discussions-To:
|
||||||
|
Pull-Request:</pre>
|
||||||
|
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
|
||||||
|
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">6</a> and the Zcash Trademark Donation and License Agreement (<a id="footnote-reference-3" class="footnote_reference" href="#trademark">4</a> or successor agreement).</p>
|
||||||
|
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a></p>
|
||||||
|
<p>"Electric Coin Company", also called "ECC", refers to the US-incorporated Zerocoin Electric Coin Company, LLC.</p>
|
||||||
|
<p>"Bootstrap Project", also called "BP", refers to the US-incorporated 501(c)(3) nonprofit corporation of that name.</p>
|
||||||
|
<p>"Zcash Foundation", also called "ZF", refers to the US-incorporated 501(c)(3) nonprofit corporation of that name.</p>
|
||||||
|
<p>"Financial Privacy Foundation", also called "FPF", refers to the Cayman Islands-incorporated non-profit foundation company limited by guarantee of that name.</p>
|
||||||
|
<p>"Autonomous Entities" refers to committees, DAOs, teams or other groups to which FPF provides operations, administrative, and financial management support.</p>
|
||||||
|
<p>"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). <a id="footnote-reference-5" class="footnote_reference" href="#section501c3">14</a></p>
|
||||||
|
<p>"Zcash Community Advisory Panel", also called "ZCAP", refers to the panel of community members assembled by the Zcash Foundation and described at <a id="footnote-reference-6" class="footnote_reference" href="#zcap">13</a>.</p>
|
||||||
|
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-7" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||||
|
<p>“Lockbox” refers to a deferred funding pool of issued Zcash value as described in <a id="footnote-reference-8" class="footnote_reference" href="#draft-nuttycom-lockbox-streams">12</a>.</p>
|
||||||
|
<p>“Dev Fund Reserve”, also called “DFR”, refers to the funds that are to be stored in the Lockbox as a result of the changes described in this ZIP.</p>
|
||||||
|
</section>
|
||||||
|
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>This proposal describes a structure for a new Zcash Development Fund (“Dev Fund”), to be enacted in Network Upgrade 6 and last for 2 years. This Dev Fund shall consist of 20% of the block subsidies.</p>
|
||||||
|
<p>The Dev Fund shall be split into 3 slices:</p>
|
||||||
|
<ul>
|
||||||
|
<li>32% for Zcash Foundation;</li>
|
||||||
|
<li>40% for "Zcash Community Grants", intended to fund large-scale long-term Projects (administered by the Financial Privacy Foundation, with extra community input and scrutiny).</li>
|
||||||
|
<li>28% for a Dev Fund Reserve, to be stored in a Lockbox.</li>
|
||||||
|
</ul>
|
||||||
|
<p>The Lockbox will securely store funds until a disbursement mechanism is established in a future ZIP.</p>
|
||||||
|
<p>Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged.</p>
|
||||||
|
</section>
|
||||||
|
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>Starting at Zcash's second halving in November 2024, the first Dev Fund will expire, meaning that by default 100% of the block subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, no substantial new funding may be available to existing teams dedicated to furthering charitable, educational, or scientific purposes, such as research, development, and outreach: the Electric Coin Company (ECC), the Zcash Foundation (ZF), and the many entities funded by the ZF grants and Zcash Community Grants programs.</p>
|
||||||
|
<p>There is a need to continue to strike a balance between incentivizing the security of the consensus protocol (i.e., mining) versus crucial charitable, educational, and/or scientific aspects, such as research, development and outreach.</p>
|
||||||
|
<p>Furthermore, there is a need to balance the sustenance of ongoing work by the current teams dedicated to Zcash, with encouraging decentralization and growth of independent development teams.</p>
|
||||||
|
<p>For these reasons, the Zcash Community desires to allocate and contribute a slice of the block subsidies otherwise allocated to miners as a donation to support charitable, educational, and scientific activities within the meaning of Section 501(c)(3) of Title 26 of the United States Code, and the Cayman Islands’ Foundation Companies Law, 2017.</p>
|
||||||
|
<p>The Zcash Community also supports the concept of a non-direct funding model, and desires to allocate a slice of the block subsidies otherwise allocated to miners to a Lockbox, with the expectation that those funds will be distributed under a non-direct funding model, which may be implemented in a future network upgrade.</p>
|
||||||
|
<p>For these reasons, the Zcash Community wishes to establish a Hybrid Development Fund after the second halving in November 2024, and apportion it among ZF, ZCG, and a Dev Fund Reserve to be held in a Lockbox.</p>
|
||||||
|
</section>
|
||||||
|
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>The Dev Fund should encourage decentralization of the Zcash ecosystem, by supporting new teams dedicated to Zcash.</p>
|
||||||
|
<p>The Dev Fund should maintain the existing teams and capabilities in the Zcash ecosystem, unless and until concrete opportunities arise to create even greater value for the Zcash ecosystem.</p>
|
||||||
|
<p>There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.</p>
|
||||||
|
<p>Major funding decisions should be based, to the extent feasible, on inputs from domain experts and pertinent stakeholders.</p>
|
||||||
|
<p>The Dev Fund mechanism itself should not modify the monetary emission curve (and in particular, should not irrevocably burn coins).</p>
|
||||||
|
<p>In case the value of ZEC jumps, the Dev Fund recipients should not wastefully use excessive amounts of funds. Conversely, given market volatility and eventual halvings, it is desirable to create rainy-day reserves.</p>
|
||||||
|
<p>The Dev Fund mechanism should not reduce users' financial privacy or security. In particular, it should not cause them to expose their coin holdings, nor cause them to maintain access to secret keys for much longer than they would otherwise. (This rules out some forms of voting, and of disbursing coins to past/future miners.)</p>
|
||||||
|
<p>The new Dev Fund system should be simple to understand and realistic to implement. In particular, it should not assume the creation of new mechanisms (e.g., election systems) or entities (for governance or development) for its execution; but it should strive to support and use these once they are built.</p>
|
||||||
|
<p>The Dev Fund should comply with legal, regulatory, and taxation constraints in pertinent jurisdictions.</p>
|
||||||
|
<p>The Lockbox must be prepared to allocate resources efficiently once the disbursement mechanism is defined. This includes ensuring that funds are readily available for future projects and not tied up in organizational overhead.</p>
|
||||||
|
<p>The Lockbox must implement robust security measures to protect against unauthorized access or misuse of funds. It must not be possible to disburse funds from the Lockbox until the Zcash Community reaches consensus on the design of a disbursement mechanism that is defined in a ZIP and implemented as part of a future Network Upgrade.</p>
|
||||||
|
</section>
|
||||||
|
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>General on-chain governance is outside the scope of this proposal.</p>
|
||||||
|
<p>Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or one-person-one-vote) are outside the scope of this proposal, though there is prescribed room for integrating them once available.</p>
|
||||||
|
<p>The mechanism by which funds held in the Dev Fund Reserve Lockbox are to be distributed is outside the scope of this proposal.</p>
|
||||||
|
</section>
|
||||||
|
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>Consensus changes implied by this specification are applicable to the Zcash Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be applied to the Zcash Testnet for testing purposes.</p>
|
||||||
|
<section id="dev-fund-allocation"><h3><span class="section-heading">Dev Fund allocation</span><span class="section-anchor"> <a rel="bookmark" href="#dev-fund-allocation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<p>Starting at the second Zcash halving in 2024, until block height 3566400 (which is expected to occur approximately two years after the second Zcash halving), 20% of the block subsidy of each block SHALL be allocated to a Dev Fund that consists of the following three slices:</p>
|
||||||
|
<ul>
|
||||||
|
<li>32% for the Zcash Foundation (denoted <strong>ZF slice</strong>);</li>
|
||||||
|
<li>40% for the Financial Privacy Foundation, for "Zcash Community Grants" for large-scale long-term projects (denoted <strong>ZCG slice</strong>);</li>
|
||||||
|
<li>28% for the Dev Fund Reserve (denoted <strong>DFR slice</strong>).</li>
|
||||||
|
</ul>
|
||||||
|
<p>The slices are described in more detail below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address(es) for each block. This Dev Fund will end at block height 3566400 (unless extended/modified by a future ZIP).</p>
|
||||||
|
<section id="zf-slice-zcash-foundation"><h4><span class="section-heading">ZF slice (Zcash Foundation)</span><span class="section-anchor"> <a rel="bookmark" href="#zf-slice-zcash-foundation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>This slice of the Dev Fund will flow as charitable contributions from the Zcash Community to ZF, to be used at its discretion for any purpose within its mandate to support financial privacy and the Zcash platform, including: development, education, supporting community communication online and via events, gathering community sentiment, and awarding external grants for all of the above, subject to the requirements of Section 501(c)(3). The ZF slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.</p>
|
||||||
|
</section>
|
||||||
|
<section id="zcg-slice-zcash-community-grants"><h4><span class="section-heading">ZCG slice (Zcash Community Grants)</span><span class="section-anchor"> <a rel="bookmark" href="#zcg-slice-zcash-community-grants"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>This slice of the Dev Fund 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.</p>
|
||||||
|
<p>The funds SHALL be received and administered by FPF. FPF MUST disburse them for "Zcash Community Grants" and expenses reasonably related to the administration of Zcash Community Grants, but subject to the following additional constraints:</p>
|
||||||
|
<ol type="1">
|
||||||
|
<li>These funds MUST only be used to issue Zcash Community Grants to external parties that are independent of FPF or to Autonomous Entities that operate under the FPF umbrella, and to pay for expenses reasonably related to the administration of Zcash Community Grants. They MUST NOT be used by FPF for its internal operations and direct expenses not related to administration of Zcash Community Grants. Additionally, ZF is ineligible to receive Zcash Community Grants while ZF is receiving a slice of the Dev Fund.</li>
|
||||||
|
<li>Zcash Community Grants SHOULD support well-specified work proposed by the grantee, at reasonable market-rate costs. They can be of any duration or ongoing without a duration limit. Grants of indefinite duration SHOULD be reviewed periodically (on a schedule that the Zcash Community Grants Committee considers appropriate for the value and complexity of the grant) for continuation of funding.</li>
|
||||||
|
<li>Priority SHOULD be given to Zcash Community 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 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.</li>
|
||||||
|
<li>Zcash Community Grants SHOULD be restricted to furthering the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general).</li>
|
||||||
|
<li>Zcash Community Grants awards are subject to approval by a five-seat Zcash Community Grants Committee. The Zcash Community Grants Committee SHALL be selected by the ZF's Zcash Community Advisory Panel (ZCAP) or successor process.</li>
|
||||||
|
<li>The Zcash Community Grants Committee's funding decisions will be final, requiring no approval from the FPF Board, but are subject to veto if FPF judges them to violate Cayman law or the FPF's reporting requirements and other (current or future) obligations under the Cayman Islands’ Companies Act (2023 Revision) and Foundation Companies Law, 2017.</li>
|
||||||
|
<li>Zcash Community Grants Committee members SHALL have a one-year term and MAY sit for reelection. The Zcash Community Grants 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 the FPF, are allowed to sit on the Zcash Community Grants 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.</li>
|
||||||
|
<li>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 Zcash Community Grants. The amount of funds allocated to the Discretionary Budget SHALL be decided by the ZF's Zcash Community Advisory Panel or successor process. Any disbursement of funds from the Discretionary Budget MUST be approved by the Zcash Community Grants Committee. Expenses related to the administration of Zcash Community Grants include, without limitation the following:
|
||||||
|
<ul>
|
||||||
|
<li>Paying for operational management and administration services that support the purpose of the Zcash Community Grants program, including administration services provided by FPF.</li>
|
||||||
|
<li>Paying third party vendors for services related to domain name registration, or the design, website hosting and administration of websites for the Zcash Community Grants Committee.</li>
|
||||||
|
<li>Paying independent consultants to develop requests for proposals that align with the Zcash Community Grants program.</li>
|
||||||
|
<li>Paying independent consultants for expert review of grant applications.</li>
|
||||||
|
<li>Paying for sales and marketing services to promote the Zcash Community Grants program.</li>
|
||||||
|
<li>Paying third party consultants to undertake activities that support the purpose of the Zcash Community Grants program.</li>
|
||||||
|
<li>Reimbursement to members of the Zcash Community Grants Committee for reasonable travel expenses, including transportation, hotel and meals allowance.</li>
|
||||||
|
</ul>
|
||||||
|
<p>The Zcash Community Grants 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 FPF judges them to violate Cayman law or the FPF's reporting requirements and other (current or future) obligations under Cayman Islands law.</p>
|
||||||
|
</li>
|
||||||
|
<li>A portion of the Discretionary Budget MAY be allocated to provide reasonable compensation to members of the Zcash Community Grants Committee. The time for which each Committee member is compensated SHALL be limited to the hours needed to successfully perform their positions, up to a maximum of 15 hours in each month, and MUST align with the scope and responsibilities of that member's role. The compensation rate for each Committee member SHALL be $115 per hour (and therefore the maximum compensation for a Committee member is $1725 per month). The allocation and distribution of compensation to committee members SHALL be administered by FPF. Changes to the hours or rate SHALL be determined by the ZF’s Zcash Community Advisory Panel or successor process.</li>
|
||||||
|
</ol>
|
||||||
|
<p>As part of the contractual commitment specified under the <a href="#enforcement">Enforcement</a> section below, FPF SHALL be contractually required to 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 <a href="#transparency-and-accountability">Transparency and Accountability</a> obligations defined below.</p>
|
||||||
|
</section>
|
||||||
|
<section id="dfr-slice-dev-fund-reserve"><h4><span class="section-heading">DFR slice (Dev Fund Reserve)</span><span class="section-anchor"> <a rel="bookmark" href="#dfr-slice-dev-fund-reserve"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>This slice of the Dev Fund is to be stored in a Lockbox until such time as the Zcash Community reaches consensus on the design of a disbursement mechanism that is defined in a ZIP and implemented as part of a future Network Upgrade.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section id="transparency-and-accountability"><h3><span class="section-heading">Transparency and Accountability</span><span class="section-anchor"> <a rel="bookmark" href="#transparency-and-accountability"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<section id="obligations"><h4><span class="section-heading">Obligations</span><span class="section-anchor"> <a rel="bookmark" href="#obligations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>ZF, FPF and Zcash Community Grant recipients (during and leading to their award period) SHALL all accept the obligations in this section.</p>
|
||||||
|
<p>Ongoing public reporting requirements:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Quarterly reports, detailing future plans, execution on previous plans, and finances (balances, and spending broken down by major categories).</li>
|
||||||
|
<li>Monthly developer calls, or a brief report, on recent and forthcoming tasks. (Developer calls may be shared.)</li>
|
||||||
|
<li>Annual detailed review of the organization performance and future plans.</li>
|
||||||
|
<li>Annual financial report (IRS Form 990, or substantially similar information).</li>
|
||||||
|
</ul>
|
||||||
|
<p>These reports may be either organization-wide, or restricted to the income, expenses, and work associated with the receipt of Dev Fund.</p>
|
||||||
|
<p>It is expected that ZF, FPF and Zcash Community Grant recipients will be focused primarily (in their attention and resources) on Zcash. Thus, they MUST promptly disclose:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Any major activity they perform (even if not supported by the Dev Fund) that is not in the interest of the general Zcash ecosystem.</li>
|
||||||
|
<li>Any conflict of interest with the general success of the Zcash ecosystem.</li>
|
||||||
|
</ul>
|
||||||
|
<p>BP, ECC, ZF, FPF 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).</p>
|
||||||
|
<p>ZF's and FPF's annual reports on its non-grant operations, SHOULD be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.</p>
|
||||||
|
<p>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 <a id="footnote-reference-9" class="footnote_reference" href="#osd">5</a>), preferably the MIT license.</p>
|
||||||
|
<p>The ZF SHALL continue to operate the Zcash Community Advisory Panel and SHOULD work toward making it more representative and independent (more on that below).</p>
|
||||||
|
</section>
|
||||||
|
<section id="enforcement"><h4><span class="section-heading">Enforcement</span><span class="section-anchor"> <a rel="bookmark" href="#enforcement"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||||
|
<p>For grant recipients, these conditions SHOULD be included in their contract with FPF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to FPF.</p>
|
||||||
|
<p>ZF and FPF MUST contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other parties to issue a modified version of Zcash node software that removes the violating party's Dev Fund slice, and use the Zcash trademark for this modified version. The slice's funds will be reassigned to ZCG (whose integrity is legally protected by the Restricted Fund treatment).</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section id="amendments-and-replacement-of-the-dev-fund"><h3><span class="section-heading">Amendments and Replacement of the Dev Fund</span><span class="section-anchor"> <a rel="bookmark" href="#amendments-and-replacement-of-the-dev-fund"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<p>Nothing in this ZIP is intended to preclude any amendments to the Dev Fund (including but not limited to, changes to the Dev Fund allocation and/or the addition of new Dev Fund recipients), if such amendments enjoy the consensus support of the Zcash community.</p>
|
||||||
|
<p>Nothing in this ZIP is intended to preclude replacement of the Dev Fund with a different mechanism for ecosystem development funding.</p>
|
||||||
|
<p>ZF and FPF SHOULD facilitate the amendment or replacement of the Dev Fund if there is sufficient community support for doing so.</p>
|
||||||
|
<p>This ZIP recognizes there is strong community support for a non-direct funding model. As such, ZF MUST collaborate with the Zcash community to research and explore the establishment of a non-direct funding model. The research should consider potential designs as well as possible legal and regulatory risks.</p>
|
||||||
|
</section>
|
||||||
|
<section id="future-community-governance"><h3><span class="section-heading">Future Community Governance</span><span class="section-anchor"> <a rel="bookmark" href="#future-community-governance"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<p>Decentralized community governance is used in this proposal via the Zcash Community Advisory Panel as input into the Zcash Community Grants Committee which governs the <a href="#zcg-slice-zcash-community-grants">ZCG slice (Zcash Community Grants)</a>.</p>
|
||||||
|
<p>It is highly desirable to develop robust means of decentralized community voting and governance, either by expanding the Zcash Community Advisory Panel or a successor mechanism. ZF, FPF and ZCG SHOULD place high priority on such development and its deployment, in their activities and grant selection.</p>
|
||||||
|
</section>
|
||||||
|
<section id="zf-board-composition"><h3><span class="section-heading">ZF Board Composition</span><span class="section-anchor"> <a rel="bookmark" href="#zf-board-composition"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<p>Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC or BP.</p>
|
||||||
|
<p>The Zcash Foundation SHOULD endeavor to use the Zcash Community Advisory Panel (or successor mechanism) as advisory input for future board elections.</p>
|
||||||
|
</section>
|
||||||
|
<section id="fpf-board-composition"><h3><span class="section-heading">FPF Board Composition</span><span class="section-anchor"> <a rel="bookmark" href="#fpf-board-composition"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
|
<p>Members of FPF's Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC or BP.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<p>This proposal is a modification of ZIP 1014 <a id="footnote-reference-10" class="footnote_reference" href="#zip-1014">11</a> by the Zcash Foundation based on feedback and suggestions from the community, and incorporating elements of draft ZIPs by community members Jason McGee and Skylar.</p>
|
||||||
|
<p>ZIP 1014 is a limited modification of Eran Tromer's ZIP 1012 <a id="footnote-reference-11" class="footnote_reference" href="#zip-1012">10</a> by the Zcash Foundation and ECC, further modified by feedback from the community.</p>
|
||||||
|
<p>Eran's proposal is most closely based on the Matt Luongo 'Decentralize the Dev Fee' proposal (ZIP 1011) <a id="footnote-reference-12" class="footnote_reference" href="#zip-1011">9</a>. Relative to ZIP 1011 there are substantial changes and mixing in of elements from <em>@aristarchus</em>'s '20% Split Evenly Between the ECC and the Zcash Foundation' (ZIP 1003) <a id="footnote-reference-13" class="footnote_reference" href="#zip-1003">7</a>, Josh Cincinnati's 'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) <a id="footnote-reference-14" class="footnote_reference" href="#zip-1010">8</a>, and extensive discussions in the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>, including valuable comments from forum users <em>@aristarchus</em> and <em>@dontbeevil</em>.</p>
|
||||||
|
</section>
|
||||||
|
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
|
<table id="bcp14" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>1</th>
|
||||||
|
<td><a href="https://www.rfc-editor.org/info/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"</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="protocol" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>2</th>
|
||||||
|
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="protocol-networks" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>3</th>
|
||||||
|
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="trademark" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>4</th>
|
||||||
|
<td><a href="https://electriccoin.co/wp-content/uploads/2019/11/Final-Consolidated-Version-ECC-Zcash-Trademark-Transfer-Documents-1.pdf">Zcash Trademark Donation and License Agreement</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="osd" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>5</th>
|
||||||
|
<td><a href="https://opensource.org/osd">The Open Source Definition</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-0200" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>6</th>
|
||||||
|
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1003" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>7</th>
|
||||||
|
<td><a href="zip-1003">ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1010" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>8</th>
|
||||||
|
<td><a href="zip-1010">ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1011" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>9</th>
|
||||||
|
<td><a href="zip-1011">ZIP 1011: Decentralize the Dev Fee</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1012" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>10</th>
|
||||||
|
<td><a href="zip-1012">ZIP 1012: Dev Fund to ECC + ZF + Major Grants</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zip-1014" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>11</th>
|
||||||
|
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="draft-nuttycom-lockbox-streams" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>12</th>
|
||||||
|
<td><a href="draft-nuttycom-lockbox-streams">Draft ZIP: Lockbox for Decentralized Grants Allocation</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="zcap" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>13</th>
|
||||||
|
<td><a href="https://zfnd.org/zcap/">Zcash Community Advisory Panel</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="section501c3" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>14</th>
|
||||||
|
<td><a href="https://www.law.cornell.edu/uscode/text/26/501">U.S. Code, Title 26, Section 501(c)(3)</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
|
@ -0,0 +1,507 @@
|
||||||
|
::
|
||||||
|
|
||||||
|
ZIP: Unassigned
|
||||||
|
Title: Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
|
||||||
|
Owners: Jack Gavigan <jack@zfnd.org>
|
||||||
|
Credits: Eran Tromer
|
||||||
|
Andrew Miller
|
||||||
|
Zooko Wilcox
|
||||||
|
Matt Luongo
|
||||||
|
@aristarchus
|
||||||
|
@dontbeevil
|
||||||
|
Daira Emma Hopwood
|
||||||
|
George Tankersley
|
||||||
|
Josh Cincinnati
|
||||||
|
Status: Draft
|
||||||
|
Category: Consensus Process
|
||||||
|
Created: 2024-07-01
|
||||||
|
License: MIT
|
||||||
|
Discussions-To:
|
||||||
|
Pull-Request:
|
||||||
|
|
||||||
|
|
||||||
|
Terminology
|
||||||
|
===========
|
||||||
|
|
||||||
|
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY"
|
||||||
|
in this document are to be interpreted as described in BCP 14 [#BCP14]_ when,
|
||||||
|
and only when, they appear in all capitals.
|
||||||
|
|
||||||
|
The term "network upgrade" in this document is to be interpreted as described
|
||||||
|
in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License Agreement
|
||||||
|
([#trademark]_ or successor agreement).
|
||||||
|
|
||||||
|
The terms "block subsidy" and "halving" in this document are to be interpreted
|
||||||
|
as described in sections 3.10 and 7.8 of the Zcash Protocol Specification.
|
||||||
|
[#protocol]_
|
||||||
|
|
||||||
|
"Electric Coin Company", also called "ECC", refers to the US-incorporated
|
||||||
|
Zerocoin Electric Coin Company, LLC.
|
||||||
|
|
||||||
|
"Bootstrap Project", also called "BP", refers to the US-incorporated 501(c)(3)
|
||||||
|
nonprofit corporation of that name.
|
||||||
|
|
||||||
|
"Zcash Foundation", also called "ZF", refers to the US-incorporated 501(c)(3)
|
||||||
|
nonprofit corporation of that name.
|
||||||
|
|
||||||
|
"Financial Privacy Foundation", also called "FPF", refers to the Cayman
|
||||||
|
Islands-incorporated non-profit foundation company limited by guarantee of
|
||||||
|
that name.
|
||||||
|
|
||||||
|
"Autonomous Entities" refers to committees, DAOs, teams or other groups to
|
||||||
|
which FPF provides operations, administrative, and financial management
|
||||||
|
support.
|
||||||
|
|
||||||
|
"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code
|
||||||
|
(Title 26 of the U.S. Code). [#section501c3]_
|
||||||
|
|
||||||
|
"Zcash Community Advisory Panel", also called "ZCAP", refers to the panel of
|
||||||
|
community members assembled by the Zcash Foundation and described at [#zcap]_.
|
||||||
|
|
||||||
|
The terms "Testnet" and "Mainnet" are to be interpreted as described in
|
||||||
|
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
|
||||||
|
|
||||||
|
“Lockbox” refers to a deferred funding pool of issued Zcash value as described
|
||||||
|
in [#draft-nuttycom-lockbox-streams]_.
|
||||||
|
|
||||||
|
“Dev Fund Reserve”, also called “DFR”, refers to the funds that are to be
|
||||||
|
stored in the Lockbox as a result of the changes described in this ZIP.
|
||||||
|
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
========
|
||||||
|
|
||||||
|
This proposal describes a structure for a new Zcash Development Fund (“Dev
|
||||||
|
Fund”), to be enacted in Network Upgrade 6 and last for 2 years. This Dev
|
||||||
|
Fund shall consist of 20% of the block subsidies.
|
||||||
|
|
||||||
|
The Dev Fund shall be split into 3 slices:
|
||||||
|
|
||||||
|
* 32% for Zcash Foundation;
|
||||||
|
* 40% for "Zcash Community Grants", intended to fund large-scale long-term
|
||||||
|
Projects (administered by the Financial Privacy Foundation, with extra
|
||||||
|
community input and scrutiny).
|
||||||
|
* 28% for a Dev Fund Reserve, to be stored in a Lockbox.
|
||||||
|
|
||||||
|
The Lockbox will securely store funds until a disbursement mechanism is
|
||||||
|
established in a future ZIP.
|
||||||
|
|
||||||
|
Governance and accountability are based on existing entities and legal
|
||||||
|
mechanisms, and increasingly decentralized governance is encouraged.
|
||||||
|
|
||||||
|
|
||||||
|
Motivation
|
||||||
|
==========
|
||||||
|
|
||||||
|
Starting at Zcash's second halving in November 2024, the first Dev Fund will
|
||||||
|
expire, meaning that by default 100% of the block subsidies will be allocated
|
||||||
|
to miners, and no further funds will be automatically allocated to any other
|
||||||
|
entities. Consequently, no substantial new funding may be available to
|
||||||
|
existing teams dedicated to furthering charitable, educational, or scientific
|
||||||
|
purposes, such as research, development, and outreach: the Electric Coin
|
||||||
|
Company (ECC), the Zcash Foundation (ZF), and the many entities funded by the
|
||||||
|
ZF grants and Zcash Community Grants programs.
|
||||||
|
|
||||||
|
There is a need to continue to strike a balance between incentivizing the
|
||||||
|
security of the consensus protocol (i.e., mining) versus crucial charitable,
|
||||||
|
educational, and/or scientific aspects, such as research, development and
|
||||||
|
outreach.
|
||||||
|
|
||||||
|
Furthermore, there is a need to balance the sustenance of ongoing work by the
|
||||||
|
current teams dedicated to Zcash, with encouraging decentralization and growth
|
||||||
|
of independent development teams.
|
||||||
|
|
||||||
|
For these reasons, the Zcash Community desires to allocate and contribute a
|
||||||
|
slice of the block subsidies otherwise allocated to miners as a donation to
|
||||||
|
support charitable, educational, and scientific activities within the meaning
|
||||||
|
of Section 501(c)(3) of Title 26 of the United States Code, and the Cayman
|
||||||
|
Islands’ Foundation Companies Law, 2017.
|
||||||
|
|
||||||
|
The Zcash Community also supports the concept of a non-direct funding model,
|
||||||
|
and desires to allocate a slice of the block subsidies otherwise allocated
|
||||||
|
to miners to a Lockbox, with the expectation that those funds will be
|
||||||
|
distributed under a non-direct funding model, which may be implemented in a
|
||||||
|
future network upgrade.
|
||||||
|
|
||||||
|
For these reasons, the Zcash Community wishes to establish a Hybrid
|
||||||
|
Development Fund after the second halving in November 2024, and apportion it
|
||||||
|
among ZF, ZCG, and a Dev Fund Reserve to be held in a Lockbox.
|
||||||
|
|
||||||
|
|
||||||
|
Requirements
|
||||||
|
============
|
||||||
|
|
||||||
|
The Dev Fund should encourage decentralization of the Zcash ecosystem, by
|
||||||
|
supporting new teams dedicated to Zcash.
|
||||||
|
|
||||||
|
The Dev Fund should maintain the existing teams and capabilities in the Zcash
|
||||||
|
ecosystem, unless and until concrete opportunities arise to create even
|
||||||
|
greater value for the Zcash ecosystem.
|
||||||
|
|
||||||
|
There should not be any single entity which is a single point of failure,
|
||||||
|
i.e., whose capture or failure will effectively prevent effective use of the
|
||||||
|
funds.
|
||||||
|
|
||||||
|
Major funding decisions should be based, to the extent feasible, on inputs
|
||||||
|
from domain experts and pertinent stakeholders.
|
||||||
|
|
||||||
|
The Dev Fund mechanism itself should not modify the monetary emission curve
|
||||||
|
(and in particular, should not irrevocably burn coins).
|
||||||
|
|
||||||
|
In case the value of ZEC jumps, the Dev Fund recipients should not wastefully
|
||||||
|
use excessive amounts of funds. Conversely, given market volatility and
|
||||||
|
eventual halvings, it is desirable to create rainy-day reserves.
|
||||||
|
|
||||||
|
The Dev Fund mechanism should not reduce users' financial privacy or security.
|
||||||
|
In particular, it should not cause them to expose their coin holdings, nor
|
||||||
|
cause them to maintain access to secret keys for much longer than they would
|
||||||
|
otherwise. (This rules out some forms of voting, and of disbursing coins to
|
||||||
|
past/future miners.)
|
||||||
|
|
||||||
|
The new Dev Fund system should be simple to understand and realistic to
|
||||||
|
implement. In particular, it should not assume the creation of new mechanisms
|
||||||
|
(e.g., election systems) or entities (for governance or development) for its
|
||||||
|
execution; but it should strive to support and use these once they are built.
|
||||||
|
|
||||||
|
The Dev Fund should comply with legal, regulatory, and taxation constraints in
|
||||||
|
pertinent jurisdictions.
|
||||||
|
|
||||||
|
The Lockbox must be prepared to allocate resources efficiently once the
|
||||||
|
disbursement mechanism is defined. This includes ensuring that funds are
|
||||||
|
readily available for future projects and not tied up in organizational
|
||||||
|
overhead.
|
||||||
|
|
||||||
|
The Lockbox must implement robust security measures to protect against
|
||||||
|
unauthorized access or misuse of funds. It must not be possible to disburse
|
||||||
|
funds from the Lockbox until the Zcash Community reaches consensus on the
|
||||||
|
design of a disbursement mechanism that is defined in a ZIP and implemented as
|
||||||
|
part of a future Network Upgrade.
|
||||||
|
|
||||||
|
|
||||||
|
Non-requirements
|
||||||
|
================
|
||||||
|
|
||||||
|
General on-chain governance is outside the scope of this proposal.
|
||||||
|
|
||||||
|
Rigorous voting mechanisms (whether coin-weighted, holding-time-weighted or
|
||||||
|
one-person-one-vote) are outside the scope of this proposal, though there is
|
||||||
|
prescribed room for integrating them once available.
|
||||||
|
|
||||||
|
The mechanism by which funds held in the Dev Fund Reserve Lockbox are to be
|
||||||
|
distributed is outside the scope of this proposal.
|
||||||
|
|
||||||
|
|
||||||
|
Specification
|
||||||
|
=============
|
||||||
|
|
||||||
|
Consensus changes implied by this specification are applicable to the Zcash
|
||||||
|
Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be
|
||||||
|
applied to the Zcash Testnet for testing purposes.
|
||||||
|
|
||||||
|
|
||||||
|
Dev Fund allocation
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Starting at the second Zcash halving in 2024, until block height 3566400
|
||||||
|
(which is expected to occur approximately two years after the second Zcash
|
||||||
|
halving), 20% of the block subsidy of each block SHALL be allocated to a Dev
|
||||||
|
Fund that consists of the following three slices:
|
||||||
|
|
||||||
|
* 32% for the Zcash Foundation (denoted **ZF slice**);
|
||||||
|
* 40% for the Financial Privacy Foundation, for "Zcash Community Grants" for
|
||||||
|
large-scale long-term projects (denoted **ZCG slice**);
|
||||||
|
* 28% for the Dev Fund Reserve (denoted **DFR slice**).
|
||||||
|
|
||||||
|
The slices are described in more detail below. The fund flow will be
|
||||||
|
implemented at the consensus-rule layer, by sending the corresponding ZEC to
|
||||||
|
the designated address(es) for each block. This Dev Fund will end at block
|
||||||
|
height 3566400 (unless extended/modified by a future ZIP).
|
||||||
|
|
||||||
|
|
||||||
|
ZF slice (Zcash Foundation)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
This slice of the Dev Fund will flow as charitable contributions from the
|
||||||
|
Zcash Community to ZF, to be used at its discretion for any purpose within its
|
||||||
|
mandate to support financial privacy and the Zcash platform, including:
|
||||||
|
development, education, supporting community communication online and via
|
||||||
|
events, gathering community sentiment, and awarding external grants for all of
|
||||||
|
the above, subject to the requirements of Section 501(c)(3). The ZF slice will
|
||||||
|
be treated as a charitable contribution from the Community to support these
|
||||||
|
educational, charitable, and scientific purposes.
|
||||||
|
|
||||||
|
|
||||||
|
ZCG slice (Zcash Community Grants)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
This slice of the Dev Fund 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 funds SHALL be received and administered by FPF. FPF MUST disburse them
|
||||||
|
for "Zcash Community Grants" and expenses reasonably related to the
|
||||||
|
administration of Zcash Community Grants, but subject to the following
|
||||||
|
additional constraints:
|
||||||
|
|
||||||
|
1. These funds MUST only be used to issue Zcash Community Grants to external
|
||||||
|
parties that are independent of FPF or to Autonomous Entities that operate
|
||||||
|
under the FPF umbrella, and to pay for expenses reasonably related to
|
||||||
|
the administration of Zcash Community Grants. They MUST NOT be used by FPF
|
||||||
|
for its internal operations and direct expenses not related to
|
||||||
|
administration of Zcash Community Grants. Additionally, ZF is ineligible to
|
||||||
|
receive Zcash Community Grants while ZF is receiving a slice of the Dev
|
||||||
|
Fund.
|
||||||
|
|
||||||
|
2. Zcash Community Grants SHOULD support well-specified work proposed by the
|
||||||
|
grantee, at reasonable market-rate costs. They can be of any duration or
|
||||||
|
ongoing without a duration limit. Grants of indefinite duration SHOULD be
|
||||||
|
reviewed periodically (on a schedule that the Zcash Community Grants
|
||||||
|
Committee considers appropriate for the value and complexity of the grant)
|
||||||
|
for continuation of funding.
|
||||||
|
|
||||||
|
3. Priority SHOULD be given to Zcash Community 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 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. Zcash Community Grants SHOULD be restricted to furthering the Zcash
|
||||||
|
cryptocurrency and its ecosystem (which is more specific than furthering
|
||||||
|
financial privacy in general).
|
||||||
|
|
||||||
|
5. Zcash Community Grants awards are subject to approval by a five-seat Zcash
|
||||||
|
Community Grants Committee. The Zcash Community Grants Committee SHALL be
|
||||||
|
selected by the ZF's Zcash Community Advisory Panel (ZCAP) or successor
|
||||||
|
process.
|
||||||
|
|
||||||
|
6. The Zcash Community Grants Committee's funding decisions will be final,
|
||||||
|
requiring no approval from the FPF Board, but are subject to veto if FPF
|
||||||
|
judges them to violate Cayman law or the FPF's reporting requirements and
|
||||||
|
other (current or future) obligations under the Cayman Islands’ Companies
|
||||||
|
Act (2023 Revision) and Foundation Companies Law, 2017.
|
||||||
|
|
||||||
|
7. Zcash Community Grants Committee members SHALL have a one-year term and MAY
|
||||||
|
sit for reelection. The Zcash Community Grants 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 the FPF, are allowed to sit on the Zcash Community Grants
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 Zcash Community Grants. The amount of funds allocated to
|
||||||
|
the Discretionary Budget SHALL be decided by the ZF's Zcash Community
|
||||||
|
Advisory Panel or successor process. Any disbursement of funds from the
|
||||||
|
Discretionary Budget MUST be approved by the Zcash Community Grants
|
||||||
|
Committee. Expenses related to the administration of Zcash Community Grants
|
||||||
|
include, without limitation the following:
|
||||||
|
|
||||||
|
* Paying for operational management and administration services that
|
||||||
|
support the purpose of the Zcash Community Grants program, including
|
||||||
|
administration services provided by FPF.
|
||||||
|
* Paying third party vendors for services related to domain name
|
||||||
|
registration, or the design, website hosting and administration of
|
||||||
|
websites for the Zcash Community Grants Committee.
|
||||||
|
* Paying independent consultants to develop requests for proposals that
|
||||||
|
align with the Zcash Community Grants program.
|
||||||
|
* Paying independent consultants for expert review of grant applications.
|
||||||
|
* Paying for sales and marketing services to promote the Zcash Community
|
||||||
|
Grants program.
|
||||||
|
* Paying third party consultants to undertake activities that support the
|
||||||
|
purpose of the Zcash Community Grants program.
|
||||||
|
* Reimbursement to members of the Zcash Community Grants Committee for
|
||||||
|
reasonable travel expenses, including transportation, hotel and meals
|
||||||
|
allowance.
|
||||||
|
|
||||||
|
The Zcash Community Grants 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 FPF
|
||||||
|
judges them to violate Cayman law or the FPF's reporting requirements and
|
||||||
|
other (current or future) obligations under Cayman Islands law.
|
||||||
|
|
||||||
|
|
||||||
|
9. A portion of the Discretionary Budget MAY be allocated to provide
|
||||||
|
reasonable compensation to members of the Zcash Community Grants Committee.
|
||||||
|
The time for which each Committee member is compensated SHALL be limited to
|
||||||
|
the hours needed to successfully perform their positions, up to a maximum
|
||||||
|
of 15 hours in each month, and MUST align with the scope and
|
||||||
|
responsibilities of that member's role. The compensation rate for each
|
||||||
|
Committee member SHALL be $115 per hour (and therefore the maximum
|
||||||
|
compensation for a Committee member is $1725 per month). The allocation and
|
||||||
|
distribution of compensation to committee members SHALL be administered by
|
||||||
|
FPF. Changes to the hours or rate SHALL be determined by the ZF’s Zcash
|
||||||
|
Community Advisory Panel or successor process.
|
||||||
|
|
||||||
|
As part of the contractual commitment specified under the `Enforcement`_ section
|
||||||
|
below, FPF SHALL be contractually required to 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.
|
||||||
|
|
||||||
|
|
||||||
|
DFR slice (Dev Fund Reserve)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
This slice of the Dev Fund is to be stored in a Lockbox until such time as the
|
||||||
|
Zcash Community reaches consensus on the design of a disbursement mechanism
|
||||||
|
that is defined in a ZIP and implemented as part of a future Network Upgrade.
|
||||||
|
|
||||||
|
|
||||||
|
Transparency and Accountability
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
Obligations
|
||||||
|
~~~~~~~~~~~
|
||||||
|
|
||||||
|
ZF, FPF and Zcash Community Grant recipients (during and leading to their award
|
||||||
|
period) SHALL all accept the obligations in this section.
|
||||||
|
|
||||||
|
Ongoing public reporting requirements:
|
||||||
|
|
||||||
|
* Quarterly reports, detailing future plans, execution on previous plans, and
|
||||||
|
finances (balances, and spending broken down by major categories).
|
||||||
|
* Monthly developer calls, or a brief report, on recent and forthcoming tasks.
|
||||||
|
(Developer calls may be shared.)
|
||||||
|
* Annual detailed review of the organization performance and future plans.
|
||||||
|
* Annual financial report (IRS Form 990, or substantially similar
|
||||||
|
information).
|
||||||
|
|
||||||
|
These reports may be either organization-wide, or restricted to the income,
|
||||||
|
expenses, and work associated with the receipt of Dev Fund.
|
||||||
|
|
||||||
|
It is expected that ZF, FPF and Zcash Community Grant recipients will be
|
||||||
|
focused primarily (in their attention and resources) on Zcash. Thus, they MUST
|
||||||
|
promptly disclose:
|
||||||
|
|
||||||
|
* Any major activity they perform (even if not supported by the Dev Fund) that
|
||||||
|
is not in the interest of the general Zcash ecosystem.
|
||||||
|
* Any conflict of interest with the general success of the Zcash ecosystem.
|
||||||
|
|
||||||
|
BP, ECC, ZF, FPF 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).
|
||||||
|
|
||||||
|
ZF's and FPF's annual reports on its non-grant operations, SHOULD be at least
|
||||||
|
as detailed as grant proposals/reports submitted by other funded parties, and
|
||||||
|
satisfy similar levels of public scrutiny.
|
||||||
|
|
||||||
|
All substantial software whose development was funded by the Dev Fund SHOULD
|
||||||
|
be released under an Open Source license (as defined by the Open Source
|
||||||
|
Initiative [#osd]_), preferably the MIT license.
|
||||||
|
|
||||||
|
The ZF SHALL continue to operate the Zcash Community Advisory Panel and SHOULD
|
||||||
|
work toward making it more representative and independent (more on that below).
|
||||||
|
|
||||||
|
Enforcement
|
||||||
|
~~~~~~~~~~~
|
||||||
|
|
||||||
|
For grant recipients, these conditions SHOULD be included in their contract
|
||||||
|
with FPF, such that substantial violation, not promptly remedied, will cause
|
||||||
|
forfeiture of their grant funds and their return to FPF.
|
||||||
|
|
||||||
|
ZF and FPF MUST contractually commit to each other to fulfill these conditions,
|
||||||
|
and the prescribed use of funds, such that substantial violation, not promptly
|
||||||
|
remedied, will permit the other parties to issue a modified version of Zcash
|
||||||
|
node software that removes the violating party's Dev Fund slice, and use the
|
||||||
|
Zcash trademark for this modified version. The slice's funds will be reassigned
|
||||||
|
to ZCG (whose integrity is legally protected by the Restricted Fund treatment).
|
||||||
|
|
||||||
|
|
||||||
|
Amendments and Replacement of the Dev Fund
|
||||||
|
------------------------------------------
|
||||||
|
|
||||||
|
Nothing in this ZIP is intended to preclude any amendments to the Dev Fund
|
||||||
|
(including but not limited to, changes to the Dev Fund allocation and/or the
|
||||||
|
addition of new Dev Fund recipients), if such amendments enjoy the consensus
|
||||||
|
support of the Zcash community.
|
||||||
|
|
||||||
|
Nothing in this ZIP is intended to preclude replacement of the Dev Fund with a
|
||||||
|
different mechanism for ecosystem development funding.
|
||||||
|
|
||||||
|
ZF and FPF SHOULD facilitate the amendment or replacement of the Dev Fund if
|
||||||
|
there is sufficient community support for doing so.
|
||||||
|
|
||||||
|
This ZIP recognizes there is strong community support for a non-direct funding
|
||||||
|
model. As such, ZF MUST collaborate with the Zcash community to research and
|
||||||
|
explore the establishment of a non-direct funding model. The research should
|
||||||
|
consider potential designs as well as possible legal and regulatory risks.
|
||||||
|
|
||||||
|
|
||||||
|
Future Community Governance
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
Decentralized community governance is used in this proposal via the Zcash
|
||||||
|
Community Advisory Panel as input into the Zcash Community Grants Committee
|
||||||
|
which governs the `ZCG slice (Zcash Community Grants)`_.
|
||||||
|
|
||||||
|
It is highly desirable to develop robust means of decentralized community
|
||||||
|
voting and governance, either by expanding the Zcash Community Advisory Panel
|
||||||
|
or a successor mechanism. ZF, FPF and ZCG SHOULD place high priority on such
|
||||||
|
development and its deployment, in their activities and grant selection.
|
||||||
|
|
||||||
|
|
||||||
|
ZF Board Composition
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current
|
||||||
|
business or employment relationships with ECC or BP.
|
||||||
|
|
||||||
|
The Zcash Foundation SHOULD endeavor to use the Zcash Community Advisory Panel
|
||||||
|
(or successor mechanism) as advisory input for future board elections.
|
||||||
|
|
||||||
|
|
||||||
|
FPF Board Composition
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Members of FPF's Board of Directors MUST NOT hold equity in ECC or have current
|
||||||
|
business or employment relationships with ECC or BP.
|
||||||
|
|
||||||
|
|
||||||
|
Acknowledgements
|
||||||
|
================
|
||||||
|
|
||||||
|
This proposal is a modification of ZIP 1014 [#zip-1014]_ by the Zcash Foundation based on
|
||||||
|
feedback and suggestions from the community, and incorporating elements of draft ZIPs by
|
||||||
|
community members Jason McGee and Skylar.
|
||||||
|
|
||||||
|
ZIP 1014 is a limited modification of Eran Tromer's ZIP 1012 [#zip-1012]_
|
||||||
|
by the Zcash
|
||||||
|
Foundation and ECC, further modified by feedback from the community.
|
||||||
|
|
||||||
|
Eran's proposal is most closely based on the Matt Luongo 'Decentralize the
|
||||||
|
Dev Fee' proposal (ZIP 1011) [#zip-1011]_. Relative to ZIP 1011 there are substantial
|
||||||
|
changes and mixing in of elements from *@aristarchus*'s '20% Split Evenly
|
||||||
|
Between the ECC and the Zcash Foundation' (ZIP 1003) [#zip-1003]_, Josh Cincinnati's
|
||||||
|
'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) [#zip-1010]_, and
|
||||||
|
extensive discussions in the `Zcash Community Forum`_, including valuable comments
|
||||||
|
from forum users *@aristarchus* and *@dontbeevil*.
|
||||||
|
|
||||||
|
.. _Zcash Community Forum: https://forum.zcashcommunity.com/
|
||||||
|
|
||||||
|
|
||||||
|
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" <https://www.rfc-editor.org/info/bcp14>`_
|
||||||
|
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
||||||
|
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||||
|
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://electriccoin.co/wp-content/uploads/2019/11/Final-Consolidated-Version-ECC-Zcash-Trademark-Transfer-Documents-1.pdf>`_
|
||||||
|
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
|
||||||
|
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||||
|
.. [#zip-1003] `ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate <zip-1003.rst>`_
|
||||||
|
.. [#zip-1010] `ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams <zip-1010.rst>`_
|
||||||
|
.. [#zip-1011] `ZIP 1011: Decentralize the Dev Fee <zip-1011.rst>`_
|
||||||
|
.. [#zip-1012] `ZIP 1012: Dev Fund to ECC + ZF + Major Grants <zip-1012.rst>`_
|
||||||
|
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_
|
||||||
|
.. [#draft-nuttycom-lockbox-streams] `Draft ZIP: Lockbox for Decentralized Grants Allocation <draft-nuttycom-lockbox-streams.rst>`_
|
||||||
|
.. [#zcap] `Zcash Community Advisory Panel <https://zfnd.org/zcap/>`_
|
||||||
|
.. [#section501c3] `U.S. Code, Title 26, Section 501(c)(3) <https://www.law.cornell.edu/uscode/text/26/501>`_
|
||||||
|
|
||||||
|
|
@ -128,8 +128,11 @@
|
||||||
<p>These are works-in-progress, and may never be assigned ZIP numbers if their ideas become obsoleted or abandoned. Do not assume that these drafts will exist in perpetuity; instead assume that they will either move to a numbered ZIP, or be deleted.</p>
|
<p>These are works-in-progress, and may never be assigned ZIP numbers if their ideas become obsoleted or abandoned. Do not assume that these drafts will exist in perpetuity; instead assume that they will either move to a numbered ZIP, or be deleted.</p>
|
||||||
<embed><table>
|
<embed><table>
|
||||||
<tr> <th>Title</th> </tr>
|
<tr> <th>Title</th> </tr>
|
||||||
<tr> <td class="left"><a href="draft-nuttycom-funding-allocation">Allocation of Block Rewards for Decentralized Development Funding</a></td>
|
<tr> <td class="left"><a href="draft-hopwood-coinbase-balance">Blocks should balance exactly</a></td>
|
||||||
|
<tr> <td class="left"><a href="draft-noamchom67-manufacturing-consent">Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub</a></td>
|
||||||
|
<tr> <td class="left"><a href="draft-nuttycom-funding-allocation">Block Reward Allocation for Non-Direct Development Funding</a></td>
|
||||||
<tr> <td class="left"><a href="draft-nuttycom-lockbox-streams">Lockbox Funding Streams</a></td>
|
<tr> <td class="left"><a href="draft-nuttycom-lockbox-streams">Lockbox Funding Streams</a></td>
|
||||||
|
<tr> <td class="left"><a href="draft-zf-community-dev-fund-2-proposal">Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve</a></td>
|
||||||
</table></embed></section>
|
</table></embed></section>
|
||||||
</section>
|
</section>
|
||||||
</body>
|
</body>
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue