diff --git a/README.rst b/README.rst index c71a903c..4660cd68 100644 --- a/README.rst +++ b/README.rst @@ -204,6 +204,10 @@ be deleted. + + + + diff --git a/rendered/draft-ecc-community-and-coinholder.html b/rendered/draft-ecc-community-and-coinholder.html new file mode 100644 index 00000000..dbd98386 --- /dev/null +++ b/rendered/draft-ecc-community-and-coinholder.html @@ -0,0 +1,227 @@ + + + + Draft ecc-community-and-coinholder: Community and Coinholder Funding Model + + + + + + + +
ZIP: XXX
+Title: Community and Coinholder Funding Model
+Owners: Josh Swihart <josh@electriccoin.co>
+Credits: Daira-Emma Hopwood
+         Kris Nuttycombe
+         Jack Grigg
+         Tatyana Peacemonger
+Status: Draft
+Category: Consensus / Process
+Created: 2025-02-19
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/???>
+
+ +

Terminology

+ +

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

+ +

The terms “Mainnet” and “Testnet” in this document are to be interpreted as defined in the Zcash protocol specification 2.

+ +

The terms “Electric Coin Company” (or “ECC”), “Bootstrap Project” (or “BP”) and “Zcash Foundation” (or “ZF”) in this document are to be interpreted as described in ZIP 1014 3.

+ +

The terms “Zcash Community Grants” (or “ZCG”), “ZCG Committee”, “Financial Privacy Foundation” (or “FPF”), and “Deferred Dev Fund Lockbox” in this document are to be interpreted as defined in ZIP 1015 4.

+ +

“Shielded Labs” refers to the Assocation of that name registered in the Swiss canton of Zug under the Unique Identifier CHE-243.302.798.

+ +

Protocol-defined Ecosystem Funding is funding from sources defined by the Zcash Protocol for development of the Zcash ecosystem. At the time of writing, Protocol-defined Ecosystem Funding is allocated from a portion of block rewards via Funding Streams 5 and Lockbox Funding Streams 6.

+ +

“ZEC” refers to the native currency of Zcash on Mainnet.

+ +

Abstract

+ +

This proposal outlines a funding model that gives the community and coin holders distinct voices in determining what, if any, grants are provided to support Zcash’s development and community efforts.

+ +

In this model:

+ + + +

The Coinholder-Controlled Fund may be used to distribute larger grants to ecosystem participants, or left at rest.

+ +

This model would be activated through until the 3rd halving, allowing enough time to determine whether it should be changed or codified for longer.

+ +

Motivation

+ +

If no action is taken, in November 2025 funds from block subsidies will stop being directed to Zcash Community Grants 7 and to the Deferred Dev Fund Lockbox established by ZIP 2001 6. If the block subsidies stop, it will risk a gap in funding of Zcash development organisations, either via ZCG grants or via potential future disbursements from the Deferred Dev Fund Lockbox.

+ +

This proposal aims to:

+ + + +

It would immediately increase coinholders’ voice, minimize governance confusion, and simplify decision-making.

+ +

Requirements

+ + + +

Non-requirements

+ + + +

Specification

+ +

This proposal empowers both the community (through ZCG) and coin holders to independently determine what, if anything, should be funded through development fund grants.

+ +

The funding streams described below will be defined in a new revision of ZIP 214 9.

+ +

Zcash Community Grants

+ +

A funding stream will be established for Zcash Community Grants, consisting of 8% of the block subsidy, and subject to all of the same rules currently specified in ZIP 1015 7.

+ +

This funding stream will start on expiry of the existing FS_FPF_ZCG funding stream 10, and last for a further 1,260,000 blocks (approximately 3 years), ending at Zcash’s 3rd halving.

+ +

Coinholder-Controlled Fund

+ +

A pool of multisig-controlled funds, seeded from the existing contents of the ZIP 1015 Deferred Dev Fund Lockbox 8 and supplemented with a funding stream consising of 12% of the block subsidy for the same time period as the Zcash Community Grants stream, forms a new Coinholder-Controlled Fund. The mechanisms for the creation and management of this fund are described by the Deferred Dev Fund Lockbox Disbursement proposal 11. This proposal sets the \(\mathsf{stream\_value}\) parameter of that proposal to 12%, and the \(\mathsf{stream\_end\_height}\) parameter to mainnet block height 4406400, equal to that of the Zcash Community Grants stream so that both streams end at Zcash’s 3rd halving.

+ +

Requirements on use of the Coinholder-Controlled Fund

+ +

The Key-Holder Organizations SHALL be bound by a legal agreement to only use funds held in the Coinholder-Controlled Fund according to the specifications in this ZIP, expressed in suitable legal language. In particular, all requirements on the use of Deferred Dev Fund Lockbox funds in ZIP 1015 8 MUST be followed for Coinholder-Controlled Fund.

+ +

The Key-Holder Organizations collectively administer the Coinholder-Controlled Fund based on decisions taken by coinholder voting, following a model decided by the community and specified in another ZIP [TBD].

+ +

Disbursement process

+ +
    +
  1. Anyone can submit a grant application via a process agreed upon by the Key-Holder Organizations.
    2. +
  2. Grant applications with total below USD 500,000 (or equivalent in another currency) are directed to ZCG.
    3. +
  3. For grant applications above this threshold, a 30-day community review and feedback period will start.
    4. +
  4. If a grant application is not vetoed and proceeds to a coinholder vote according to the agreed process, then coinholders will be asked to vote on it.
    5. +
  5. If the vote passes, then as payments are scheduled for the grant, then (subject to the Veto process) the Key-Holder Organizations SHOULD sign the corresponding transactions for disbursement from the Coinholder-Controlled Fund.
    6. +
+ +

For coinholder votes, a minimum of 420,000 ZEC (2% of the total eventual supply) MUST be voted, with a simple majority cast in favor, for a grant proposal to be approved. Upon approval, the grants are paid to the recipient per the terms of the grant proposal. In the case that multiple grant proposals are submitted that are in competition with one another, a single winner will be selected by holding a separate coinholder vote for each proposal, with the approved proposal having the highest total ZEC value committed in support being the winner. It is the responsibility of the Key-Holder Organizations to determine whether proposals are in competition with one another when organizing coinholder votes.

+ +

Each coinholder vote (including in cases where multiple grants are in competition) is independent, and coins used in one vote are also allowed to be used in another; this approach is necessary to avoid vote-splitting scenarios that can result in an option being selected that achieves only a plurality (not a majority) of coinholder support.

+ +

Coinholders SHOULD take account of the same factors considered by the ZCG Committee (described in points 2, 3, and 4 of 7) in deciding whether to fund a grant. If any contentious issue arises in connection with a grant (such as milestones not being met), or periodically for grants of indefinite duration, the Key-Holder Organizations SHOULD hold additional coinholder votes to determine whether funding should continue.

+ +

Coinholders are not obligated to fund any grants and MAY leave the funds at rest.

+ +

No organizations or individuals are restricted from voting their coins.

+ +

Veto process

+ +

A grant is vetoed if:

+ + + +

If a grant is vetoed after passing a coinholder vote, then payments for it MUST be stopped. This is expected to be an unusual situation that would only occur if new adverse information came to light, or in the case of a change in the law or unanticipated legal proceedings.

+ +

The Key-holder Organizations cannot veto coinholder rejection of a proposal.

+ +

Vetos are intended for exceptional cases and SHOULD be accompanied by a thorough rationale.

+ +

Administrative obligations and constraints

+ +

All provisions of ZIP 1015 imposing obligations and constraints on Bootstrap Project, Electric Coin Company, Zcash Foundation, Financial Privacy Foundation, the ZCG Committee, and grant recipients relating to the previous FS_FPF_ZCG funding stream, SHALL continue in effect for Zcash Community Grants.

+ +

These obligations and constraints will be extended to all Key-Holder Organizations in respect of the Coinholder-Controlled Fund.

+ +

The provisions after the first paragraph of the section “Zcash Community Grants (ZCG)” also apply to the Key-Holder Organizations' administration of the Coinholder-Controlled Fund, with coinholder voting replacing the role of the ZCG Committee.

+ +

Note: Nothing forces developers of Zcash consensus node software to implement any particular proposal. The aim of a process specification like this one is only to social consensus. It fundamentally cannot affect the autonomy of developers of Zcash consensus node software to publish (or not) the software they want to publish, or the autonomy of node operators to run (or not) the software they want to run.

+ +

Security precautions

+ +

The Key-Holder Organizations and the ZCG Committee MUST take appropriate precautions to safeguard funds from theft or accidental loss. Any theft or loss of funds, or any loss or compromise of key material MUST be reported to the Zcash community as promptly as possible after applying necessary mitigations.

+ +

Testnet-specific considerations

+ +

In order to allow the mechanism and process for coinholder voting to be tested, this process SHOULD be rehearsed on Testnet. The threshold of 420,000 ZEC applied to Mainnet coinholder votes does not apply to these rehearsals.

+ +

Open questions

+ + + +

References

+ +
+
+
    + +
  1. +

    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”  ↩︎

    +
    2. + +
  2. +

    Zcash Protocol Specification, Version 2024.5.1. Section 3.12: Mainnet and Testnet  ↩︎

    +
    3. + +
  3. +

    ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants  ↩︎

    +
    4. + +
  4. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding  ↩︎

    +
    5. + +
  5. +

    ZIP 207: Funding Streams  ↩︎

    +
    6. + +
  6. +

    ZIP 2001: Lockbox Funding Streams  ↩︎

    +
    7. + +
  7. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Zcash Community Grants  ↩︎

    +
    8. + +
  8. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Lockbox  ↩︎

    +
    9. + +
  9. +

    ZIP 214: Consensus rules for a Zcash Development Fund  ↩︎

    +
    10. + +
  10. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Funding Streams  ↩︎

    +
    11. + +
  11. +

    draft-ecc-lockbox-disbursement: Deferred Dev Fund Lockbox Disbursement  ↩︎

    +
    12. + +
+
+ + diff --git a/rendered/draft-ecc-lockbox-disbursement.html b/rendered/draft-ecc-lockbox-disbursement.html new file mode 100644 index 00000000..7b636459 --- /dev/null +++ b/rendered/draft-ecc-lockbox-disbursement.html @@ -0,0 +1,292 @@ + + + + Draft ecc-lockbox-disbursement: Deferred Dev Fund Lockbox Disbursement + + + + + + + +
ZIP: XXX
+Title: Deferred Dev Fund Lockbox Disbursement
+Owners: Daira-Emma Hopwood <daira@jacaranda.org>
+        Kris Nuttycombe <kris@nutty.land>
+        Jack Grigg <jack@electriccoin.co>
+Status: Draft
+Category: Consensus / Process
+Created: 2025-02-19
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/???>
+
+ +

Terminology

+ +

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

+ +

Abstract

+ +

This ZIP proposes an extension of protocol-based development funding, in the +context of multiple alternatives for distributing funds that have accrued to +the Deferred Dev Fund Lockbox. This proposal is intended to be evaluated in the +context of the Community And Coinholder Funding Model +2 and Zcash Governance Bloc +3 proposals; the mechanisms it describes are applicable to +both of these and may be applicable to other similar proposals as well.

+ +

At a high level, this ZIP proposes:

+ + + +

Requirements

+ + + +

Specification

+ +

This ZIP proposes the creation of a new Zcash Development Fund. The balance of +this Fund consists of the contents of the ZIP 1015 Deferred Development Fund +Lockbox as of the activation height of this ZIP, plus any funds that later +accrue to either the lockbox or to one or more transparent multisig addresses +as specified by this ZIP.

+ +

One-time lockbox disbursement

+ +

The coinbase transaction of the activation block of this ZIP MUST include an +additional output to a 3-of-5 P2SH multisig with keys held by the following +“Key-Holder Organizations”: Zcash Foundation, the Electric Coin Company, +Shielded Labs, and two other organizations yet to be decided.

+ +

Let \(v\) be the zatoshi amount in the Deferred Dev Fund Lockbox at the +activation height. (\(v\) can be predicted in advance given that height.)

+ +

The additional coinbase output MUST follow the same consensus rules as apply to +funding stream outputs 5. That is, the coinbase +transaction MUST contain at least one output that pays \(v\) zatoshi, in the +prescribed way defined in ZIP 207, to the above P2SH multisig address. \(v\) +zatoshi are added to the transparent transaction value pool to fund this +output, and subtracted from the balance of the Deferred Dev Fund Lockbox (i.e. +the latter balance is reset to zero).

+ +

Exactly one of the following options will also be taken. The proposal that +activates this ZIP must define values for the following two parameters:

+ + + +

Option 1: Extend the lockbox funding stream

+ +

The FS_DEFERRED lockbox funding stream is set to receive +\(\mathsf{stream\_value}\%\) of the block subsidy and is extended until block +height \(\mathsf{stream\_end\_height}\) Both of these parameters must must be +specified by the proposal under which this ZIP is activated.

+ +

Rationale for Option 1

+ +

Performing a one-time disbursement to a P2SH multisig address will provide a +source of grant funding for a limited period, allowing time for a lockbox +disbursement mechanism to be specified and deployed, as originally intended by +ZIP 1015 6.

+ +

In particular, this provides an opportunity for transaction format changes that +may be required for such a mechanism to be included in the v6 transaction +format 7. It is desirable to limit the frequency of transaction +format changes because such changes are disruptive to the ecosystem. It is not +necessary that protocol rules for disbursement actually be implemented until +after the transaction format changes are live on the network. It is RECOMMENDED +that any such transaction format changes be included in the upcoming V6 +transaction format in order to avoid such disruption.

+ +

By implementing a one-time disbursement along with a continuation of the +FS_DEFERRED stream, we prioritize both the availability of grant funding +and the implementation of a more flexible and secure mechanism for disbursement +from the lockbox — making it possible to address the need to rotate keys and/or +alter the set of key holders in a way that reverting to hard-coded output +addresses for repeated disbursements would not.

+ +

Option 2: Revert to hard-coded output address

+ +

A new funding stream consisting of \(\mathsf{stream\_value}\%\) of the block +subsidy is defined to begin when the existing ZIP 1015 funding streams +4 end. The new streams will distribute funds to a +3-of-5 P2SH multisig with keys held by the same Key-Holder Organizations as +above. The resulting Fund is considered to include both this stream of funds, +and funds from the one-time lockbox disbursement described above.

+ +

Option 2 can be realized by either of the following mechanisms:

+ +

Mechanism 2a: Classic funding stream

+ +

A new funding stream is definedthat pays directly to the above-mentioned 3-of-5 +multisig address on a block-by-block basis. It is defined to start at the end +height of the existing FS_DEFERRED funding stream and end at +\(\mathsf{stream\_end\_height}\) and consists of \(\mathsf{stream\_value}\%\) of the +block subsidy.

+ +

Mechanism 2b: Periodic lockbox disbursement

+ +

Constant parameter \(N = 35000\) blocks \(= +\mathsf{PostBlossomHalvingInterval}/48\) (i.e. approximately one month of +blocks).

+ +

The FS_DEFERRED lockbox funding stream is extended to end at height +\(\mathsf{stream\_end\_height}\) and has its per-block output value set to +\(\mathsf{stream\_value}\%\) A consensus rule is added to disburse from the +Deferred Dev Fund Lockbox to a 3-of-5 P2SH multisig with keys held by the same +Key-Holder Organizations as above, starting at block height +\(\mathsf{activation\_height} + N\) and continuing at periodic intervals of \(N\) +blocks until \(\mathsf{stream\_end\_height}\). Each disbursement empties the +lockbox.

+ +

This is equivalent to specifying +\(\frac{\mathstrut\mathsf{stream\_end\_height} \,-\, \mathsf{activation\_height}}{N}\) One-time lockbox disbursements, +that all output to the same address.

+ +

Rationale for periodic disbursement

+ +

Classic funding streams 8 produce many small output values, due to +only being able to direct funds from a single block’s subsidy at a time. This +creates operational burdens to utilizing the funds — in particular due to block +and transaction sizes limiting how many outputs can be combined at once, which +increases the number of required transactions and correspondingly the overall +fee.

+ +

The periodic lockbox disbursement mechanism can produce the same effective +funding stream, but with aggregation performed for free: the output to the +funding stream recipient is aggregated into larger outputs every \(N\) blocks. In +the specific case of Mechanism 2b, the recipient multisig address would receive +around 40 outputs, instead of around 1,300,000.

+ +

Privacy and Security Implications

+ +

As development funding is a public good on the Zcash network, there are not +relevant privacy concerns related to this proposal; all disbursement of +(but not necessarily subsequent distribution) of development funds is +transparent and auditable by any participant in the network.

+ +

Security implications of the One-Time Lockbox Disbursement

+ +

After the activation block of this ZIP has been mined, all development funds +previously accrued to the in-protocol lockbox will be held instead by a 3-of-5 +multisig address. The key-holders for this address will have the capability to +spend these funds. Compromise or loss of 3 of these 5 keys would result in +total loss of funds; as such, in the event of the compromise or loss of a +single key, the Key-Holders MUST establish a new multisig key set and address, +and transfer remaining unspent funds held by the original address before +additional loss or compromise occurs.

+ +

Because this is a one-time disbursement, additional key rotation infrastructure +is not required.

+ +

Security implications for Option 1

+ +

Funds will continue to securely accrue to the Deferred Development Lockbox +until a disbursement mechanism for the lockbox is implemented in a future +network upgrade. Such a disbursement mechanism should be designed to include an +in-protocol option for key rotation, such that it is not necessary to perform a +network upgrade to recover from key loss or compromise, or to change the size +of the signing set or the number of signatures required to reach threshold.

+ +

Security implications for Option 2a

+ +

As of the activation height of this ZIP, development funds will begin accruing +as additional outputs spendable by a 3-of-5 multisig address on a +block-by-block basis. Key-Holders will need to perform regular multiparty +signing ceremonies in order to shield the resulting coinbase outputs. Each such +signing ceremony involves shared spending authority being used to sign +thousands of inputs to large shielding transactions; for practical reasons, +this is often handled using a scripted process that has spending authority over +these funds. This process is an attractive target for compromise; for this +reason it is RECOMMENDED that address rotation (in this case, by means of +hard-coding a sequence of addresses, each of which receives a time-bounded +subset of the block reward fractional outputs) be implemented, as was done +for the ECC funding stream described in ZIP 1014 9.

+ +

In the case of key compromise or loss, it may be necessary to perform an +emergency Network Upgrade to perform a manual key rotation to ensure that +future development funds are not lost.

+ +

Security implications for Option 2b

+ +

Due to the aggregation of funds recommended by Option 2b, it is no longer +necessary use scripts with elevated privileges to perform shielding and/or +distribution operations; instead, these operations can be performed by human +operators using an interactive protocol that does not require sharing spending +key material.

+ +

As with Option 2a, key compromise or loss would require an emergency Network +Upgrade to perform manual key rotation to mitigate the potential for loss of +funds.

+ +

References

+ +
+
+
    + +
  1. +

    BCP14  ↩︎

    +
    2. + +
  2. +

    draft-ecc-community-and-coinholder: Community and Coinholder Funding Model  ↩︎

    +
    3. + +
  3. +

    draft-ecc-zbloc: Zcash Governance Bloc  ↩︎

    +
    4. + +
  4. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Funding Streams  ↩︎

    +
    5. + +
  5. +

    ZIP 207: Funding Streams — Consensus Rules  ↩︎

    +
    6. + +
  6. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding  ↩︎

    +
    7. + +
  7. +

    ZIP 230: Version 6 Transaction Format  ↩︎

    +
    8. + +
  8. +

    ZIP 207: Funding Streams  ↩︎

    +
    9. + +
  9. +

    zip-1014  ↩︎

    +
    10. + +
+
+ + diff --git a/rendered/draft-ecc-onchain-accountable-voting.html b/rendered/draft-ecc-onchain-accountable-voting.html new file mode 100644 index 00000000..a29017d0 --- /dev/null +++ b/rendered/draft-ecc-onchain-accountable-voting.html @@ -0,0 +1,215 @@ + + + + Draft ecc-onchain-accountable-voting: On-chain Accountable Voting + + + + + + + +
ZIP: XXX
+Title: On-chain Accountable Voting
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Status: Draft
+Credits: Josh Swihart
+         Kris Nuttycombe
+         Jack Grigg
+Category: Consensus / Process
+Created: 2025-02-21
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/???>
+
+ +

Terminology

+ +

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

+ +

The terms “Mainnet” and “Testnet” in this document are to be interpreted as defined in the Zcash protocol specification 2.

+ +

TODO: Consider defining “Proposal”, “Decision”, “Approval”, “Rejection”, etc.

+ +

Abstract

+ +

This proposal specifies a mechanism for on-chain accountable voting that is available for use by Zcash governance and funding proposals.

+ +

Motivation

+ +

Several proposals that have been made for the future of Zcash governance, including the Zcash Governance Bloc 3 and Loan-Directed Retroactive Grants 4, require similar mechanisms. In particular they require some form of on-chain accountable voting.

+ +

The details of these mechanisms matter for security and robust oversight. Separating the concerns of governance and funding policy on the one hand, and the mechanisms used to enact this policy on the other, frees initial policy proposals (and proposers) from having to specify unnecessary detail, while ensuring that implementability and security concerns are nonetheless thoroughly considered.

+ +

Using a shared vocabulary and repertoire of implementation mechanisms can also facilitate comparison of governance and funding proposals, by focussing attention on their higher-level differences.

+ +

It is possible that these mechanisms may also have wider usefulness in the Zcash ecosystem beyond governance and development funding.

+ +

Requirements

+ + + +

Non-requirements

+ +

The on-chain accountable voting mechanism does not need to directly support coinholder voting. If that is required, it should be performed via a separate protocol. The results of that protocol might then feed into votes cast in on-chain accountable voting, as suggested by the Zcash Governance Bloc 3 proposal, for example.

+ +

Specification

+ +

A Proposal to be decided using On-chain Accountable Voting is represented as Proposal Transaction, which references a human-readable Description of what is to happen on its Approval. The Proposal Transaction MAY also lock up funds that are to be granted on Approval [TODO].

+ +

The scope of possible Proposals is left to be specified by the high-level policy that uses this mechanism.

+ +

A Decision is represented by spending the Approval Output or Rejection Output of the Proposal, as described in Decisions. This can signal either an Approval, recording the fact that the Approval Threshold has been met, or a Rejection, recording the fact that sufficient voting units have been cast against the Proposal that its Approval Threshold cannot be met.

+ +

More concretely, if there are \(V\) voting units overall and \(A = \mathsf{ceiling}(V \cdot \mathsf{threshold})\) of them are required for approval, then \(V - A + 1\) voting units suffice for Rejection.

+ +

A Proposal also has a Deadline Height. It is Implicitly Rejected if no Approval or Rejection occurs on the consensus chain at or before the Deadline Height (that is, the Deadline Height is inclusive).

+ +

Honestly constructed Proposals SHOULD take into account any planned change in the block target spacing when setting the Deadline Height (see Block Target Spacing changes).

+ +

Proposal Transactions

+ +

A transaction is considered to be a Proposal Transaction if and only if it includes exactly one Specification Output, exactly one Approval Output, and exactly one Rejection Output, as specified below.

+ +

Description Output

+ +

A Proposal Transaction MUST reference a human-readable Description of what is being voted on. This is represented by a Description Output encrypted to the zero \(\mathsf{ovk}\), in the same way as for shielded coinbase transactions 5. The plaintext memo of the Description Output MUST use the following format:

+ + + +

The URL MUST be encoded as US-ASCII, but MAY use %-encoding to specify UTF-8 characters as described in 6.

+ +

For example, to refer to the contents of ZIP 1015 at time of writing:

+ +
"b2-256:bacb0d5430968e4ce77246523d0e6f29c442f8fce0f3656462fdf5a5c4b8c656:" ||
+"https://raw.githubusercontent.com/zcash/zips/38e4501a2c3bf90f6057872db497295a0a76eb35/zips/zip-1015.rst"
+
+ +

Since a memo field can be a maximum of 512 bytes, this currently allows a maximum of 440 bytes for the URL, which should be enough. If and when memo bundles 7 are supported, this will increase the allowed size, and potentially allow the text of the proposal to be encoded directly in the memo.

+ +

The contents of the file at the given URL MUST NOT be automatically downloaded unless that is requested by an explicit user action.

+ +

Approval and Rejection Outputs

+ +

Let DeadlineHeight be the last block height at which a Decision can be made for this Proposal.

+ +

An Approval Output is a P2SH output with a script of the following form:

+ + + +

A Rejection Output is a P2SH output with a script of the following form:

+ + + +

Decisions

+ +

Approval of a Proposal Transaction is signalled by spending its Approval Output in a transaction mined at or before the Deadline Height.

+ +

Rejection of a Proposal Transaction is signalled by spending its Rejection Output in a transaction mined at or before the Deadline Height.

+ +

A spend of an Approval or Rejection Output that occurs in a transaction mined strictly after the Proposal’s Deadline Height has no effect.

+ +

A spend of an Approval or Rejection Output is performative 8 in the sense that, even if it does not directly transfer funds, it records that the decision has been made.

+ +

A holder of voting units SHOULD NOT sign transactions that spend both the Approval Output and the Rejection Output of a given Proposal Transaction. However, if this does occur, then it is interpreted as follows:

+ + + +

As stated earlier, a Proposal is Implicitly Rejected if no Approval or Rejection occurs on the consensus chain at or before the Deadline Height.

+ +

Finality of Decisions

+ +

Zcash’s current consensus layer provides only eventual consistency. A Decision SHOULD be considered “final” when it has 100 confirmations. (In the case where the Decision transaction also directly transfers funds to a recipient, this does not constrain the recipient’s ability to spend the funds.)

+ +

An Implicit Rejection SHOULD be considered final if a transaction in a block at the Deadline Height would have 100 confirmations.

+ +

If and when a mechanism for “assured finality” 9 of transactions is adopted by the Zcash network, it is expected to be possible to redefine “finality” of Decisions accordingly.

+ +

Testnet-specific considerations

+ +

Proposal Transactions on Testnet MUST only be used to test this mechanism, and have no significance for Zcash governance.

+ +

Rationale

+ +

Block Target Spacing changes

+ +

The block target spacing of the Zcash network is currently 75 seconds, but is not necessarily fixed. For example, the current value was established at activation of the Blossom network upgrade, halving the previous value of 150 seconds. This potentially has implications for the use of block heights to specify deadlines, but in practice we believe that block heights will suffice:

+ + + +

Reference implementation

+ +

TBD

+ +

Acknowledgements

+ +

Thank you to Josh Swihart and Kris Nuttycombe for discussions about 3 and 10 that led to the idea for this ZIP.

+ +

References

+ +
+
+
    + +
  1. +

    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”  ↩︎

    +
    2. + +
  2. +

    Zcash Protocol Specification, Version 2024.5.1. Section 3.12: Mainnet and Testnet  ↩︎

    +
    3. + +
  3. +

    draft-ecc-zbloc: Zcash Governance Bloc  ↩︎

    +
    4. + +
  4. +

    Zcash forum: Loan-Directed Retroactive Grants  ↩︎

    +
    5. + +
  5. +

    ZIP 213: Shielded Coinbase  ↩︎

    +
    6. + +
  6. +

    RFC 3986: Uniform Resource Identifier (URI). Section 2.5: Identifying Data  ↩︎

    +
    7. + +
  7. +

    ZIP 231: Memo Bundles  ↩︎

    +
    8. + +
  8. +

    Wikipedia: Performative utterance  ↩︎

    +
    9. + +
  9. +

    Zcash Trailing Finality Layer. Section 2: Terminology — Assured Finality  ↩︎

    +
    10. + +
  10. +

    draft-ecc-community-and-coinholder: Community and Coinholder Funding Model  ↩︎

    +
    11. + +
+
+ + diff --git a/rendered/draft-ecc-zbloc.html b/rendered/draft-ecc-zbloc.html new file mode 100644 index 00000000..dc21e921 --- /dev/null +++ b/rendered/draft-ecc-zbloc.html @@ -0,0 +1,325 @@ + + + + Draft ecc-zbloc: Zcash Governance Bloc + + + + + + + +
ZIP: XXX
+Title: Zcash Governance Bloc
+Owners: Josh Swihart <josh@electriccoin.co>
+        Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Credits: Kris Nuttycombe
+         Jack Grigg
+         Tatyana Peacemonger
+         Chris Tomeo
+Status: Draft
+Category: Consensus / Process
+Created: 2025-01-28
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/???>
+
+ +

Terminology

+ +

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

+ +

The terms “Mainnet” and “Testnet” in this document are to be interpreted as defined in the Zcash protocol specification 2.

+ +

The terms “Electric Coin Company” (or “ECC”) and “Zcash Foundation” (or “ZF”) in this document are to be interpreted as described in ZIP 1014 3.

+ +

The terms “Zcash Community Grants” (or “ZCG”), “Financial Privacy Foundation” (or “FPF”), and “Deferred Dev Fund Lockbox” in this document are to be interpreted as defined in ZIP 1015 4.

+ +

“Shielded Labs” refers to the Assocation of that name registered in the Swiss canton of Zug under the Unique Identifier CHE-243.302.798.

+ +

“Zcash Core Engineers” refers to the current set of engineers whose primary job is to make changes to consensus node software and libraries.

+ +

TODO: define “Zechub”.

+ +

“Zcash Governance” refers to the social consensus of the Zcash community on specifications, procedures, agreements (legal or otherwise), and decision-making processes for operation and use of the Zcash Protocol on the Zcash Mainnet and (as applicable) Testnet networks.

+ +

“Protocol-defined Ecosystem Funding” is funding from sources defined by the Zcash Protocol for development of the Zcash ecosystem. At the time of writing, these sources are a portion of block rewards defined by Funding Streams 5 and Lockbox Funding Streams 6.

+ +

A “Proposal” is either a proposed change in Zcash Governance (“Governance Proposal”) or a proposed disbursement of Protocol-defined Ecosystem Funding (“Funding Proposal”) to be approved or rejected by a vote of the zBloc Constituencies.

+ +

A “Decision” is the approval or rejection of a Proposal.

+ +

Abstract

+ +

In recent polls about the future of Zcash development funding, the community signaled a strong preference for a non-direct funding model. It also decided on a temporary one-year continuation of a development fund, starting at the second halving in November 2024, where ZCG would continue to be funded and the remainder would be temporarily placed in a Deferred Dev Fund Lockbox, while the community determines next steps.

+ +

This ZIP outlines a more detailed proposal for non-direct funding, based on voting among a group of Constituencies with a stake in Zcash and its protocol. It has 80% of the block rewards given to miners and 20% to a Zcash Community Fund, in perpetuity. The current balance of the Deferred Dev Fund Lockbox is used to seed the Zcash Community Fund. This fund is initially split into two Funding Pools, with different rules for each: the Large Grant Fund and the Minor Grant Fund. Other specialized pools could be added over time.

+ +

This model allows for the community to guide its evolution and possible replacement via Governance Decisions, and so would be activated indefinitely.

+ +

Motivation

+ +

Zcash governance must represent voices from all over the world, who need digital cash for their security and for their dignity. It must not be dependent on individuals who, despite their best intentions, are flawed and prone to temptations to control and coerce. It must be durable and withstand attempted capture of all forms.

+ +

zBloc is a governance model that is designed for decentralization and accountability, to include more voices and ensure results from those who receive Protocol-defined Ecosystem Funding.

+ +

It is built to allow new innovative and positive voices to rise up and carry the flag of the Zcash community forward, in recognition of the risk that any one group may become captured or ineffective.

+ +

Requirements

+ + + +

Non-requirements

+ +

Any changes to the ZCG or its governance, such as its expansion to include more members, may be desired but are specifically outside this proposal’s scope.

+ +

Specification

+ +

zBloc Membership

+ +

The zBloc would distribute decision-making authority for both Zcash governance and funding decisions, potentially to any number of Constituencies.

+ +

A zBloc Constituency is a group representing a trusted subsection of the Zcash community.

+ +

The Initial Structure section below proposes a set of initial Constituencies, but the model allows for changes over time, enabling the zBloc to evolve. New zBloc Constituencies may be added as they gain trust and removed if they are no longer operating or trust is eroded. The means for this is described in the [Governance Decisions] section below.

+ +

zBloc Constituencies may be granted different levels of authority, receiving less or more say over time. This is done by allocating or removing “Voting Units” to reflect the amount of voting power allocated to each Constituency. For example, if the community wishes to increase the weight of coinholder voice over time, it could increase the number of Voting Units allocated to coinholder representatives, which would dilute the relative power of other Constituencies.

+ +

Decision-making policies

+ +

To be considered a Constituency, each must pre-commit to an internal policy for decision-making that all other Constituencies approve of (i.e. greater than one decision maker, means of assessing community sentiment, etc.). This could be by polling, majority vote within the Constituency, coinholder signaling, technical feasibility, mission alignment, etc.

+ +

In order for a Constituency to change its decision-making policy, the change MUST be expressed as a [Governance Proposal] and Approved before it comes into effect. The Constituency that is proposing to change its policy is eligible to vote, but it MUST make its decision according to its pre-existing policy (if it does not abstain).

+ +

Initial Structure

+ +

The initial group of Constituencies will be (if they are willing and approved by the others and by the Zcash community):

+ + + +

Each Constituency initially receives three Voting Units. This MAY be changed by a Governance Proposal.

+ +

Constituencies other than the Coinholder Constituency above are called Organizational Constituencies. The Organizational Constituencies will together elect a representative responsible for establishing a clear process and mechanism for gathering coinholder sentiment, which will then be used as the decision-making process of the Coinholder Constituency.

+ +

TODO: as Organizational Constituencies make commitments about their decision-making policies, link to those commitments here.

+ +

Initial zBloc members MUST take on the responsibility to encourage, nurture, and welcome potential new Constituencies.

+ +

Rationale: Relentless decentralization is zBloc’s core value and mission. It is the unifying ethos that will keep zBloc’s doors open to new contributors. This continuous expansion is in the best interests of the growing Zcash community.

+ +

Voting

+ +

A suitable voting mechanism is needed that —among other design requirements— makes the votes cast by each Constituency (i.e. the number of Voting Units cast for Approval and for Rejection) publically visible. A possible design that meets this requirement is suggested in 8 (“On-chain Accountable Voting”). In addition, the chosen voting mechanism MUST support the situation where voting entities must choose among multiple competing proposals to select a single grant recipient. The voting system selected MUST avoid vote-splitting scenarios that can result in an option being selected that achieves only a plurality (not a majority) of Consituencies supporting it.

+ +

Each independent zBloc Constituency decides how to cast its Voting Units for each Governance or Funding Proposal, provided it is eligible to vote on that proposal (see the next section). If its decision-making policy permits, it MAY cast fewer than its total number of Voting Units, and MAY cast some Voting Units for Approval and some for Rejection. This might be used to publically acknowledge internal dispute over a decision, for example.

+ +

Conflicts of interest

+ +

If a Constituency has a conflict of interest for a given decision, such as potentially being the recipient of funds or additional authority, then its Voting Units are not eligible to be cast for that vote. This affects the [Approval Threshold] discussed below, which is calculated as a proportion of the remaining Eligible Voting Units.

+ +

A Constituency is not automatically considered to have a conflict of interest merely because the decision affects it — for example, when changing its decision-making policy, or because it would need to make changes to software if the Proposal were Approved.

+ +

Approval Thresholds

+ +

The Approval Threshold is the absolute majority, as a proportion of the total number of Eligible Voting Units, required for a Proposal to be Approved. As stated earlier, Eligible Voting Units do not include those of Constituencies that have a conflict of interest for this Proposal. However, they do include the Voting Units of Constituencies that have no conflict of interest but choose to abstain.

+ +

By default, a Governance Proposal requires a three-fifths Approval Threshold, and MUST have a Deadline at least two weeks from when the Proposal is published on-chain.

+ +

All Consituencies MUST be consulted in order to determine whether they consider a draft Proposal to be “controversial”, before it is published on-chain. If any Constituency decides that a Proposal should be treated as controversial, it is then subject to a higher Approval Threshold of three quarters, and a Deadline at least four weeks from when the Proposal is published on-chain. (In the case of the Coinholder constituency, a coinholder vote is not necessarily required to establish this; it is likely sufficient to decide based on forum discussions for example.)

+ +

The following categories of Governance Proposal are automatically subject to the three-quarters Approval Threshold and 4-week Deadline:

+ + + +

In the case of Governance Proposals that affect consensus, final ratification occurs when node operators adopt the software implementing the changes.

+ +

Note: Nothing forces developers of Zcash consensus node software to implement any particular proposal. The aim of a process specification like this one is only to establish a social consensus. It fundamentally cannot affect the autonomy of developers of Zcash consensus node software to publish (or not) the software they want to publish, or the autonomy of node operators to run (or not) the software they want to run.

+ +

Proposals

+ +

As stated in Terminology, there are two categories of Proposal that can be put to a vote of the zBloc Constituencies:

+ + + +

Proposals have a Deadline (expressed as a Deadline Height if 8 is used). If the Deadline is reached, they are implicitly Rejected. This does not necessarily preclude reintroducing the same or a similar Proposal.

+ +

Governance Proposals

+ +

At least the following changes to Zcash Governance MUST be proposed and approved by a Governance Proposal before they can take effect:

+ + + +

The ZIP Editors will modify ZIP 0 to define other categories of change to Zcash Governance that MUST or SHOULD require Approval of a Governance Proposal.

+ +

Unrelated changes SHOULD NOT be bundled into a single Governance Proposal. This does not prevent a single Governance Proposal from being used to decide whether to adopt a proposed Network Upgrade involving multiple consensus and/or process changes, since those are considered related. During the process of drafting Governance Proposals, the ZIP Editors MAY request that proposals be split in order to satisfy this rule, or merged if they are sufficiently interdependent.

+ +

Disputes

+ +

If any zBloc Constituency, or the ZIP Editors, have concerns relating to the conduct of any vote, they MAY raise a dispute. Possible reasons to raise a dispute include believing that:

+ + + +

If a dispute is raised, the Constituencies SHALL first resolve any technical issues as far as possible (e.g. by rotating keys), and then make one or more Governance Proposals intended to resolve the situation to the satisfaction of the community.

+ +

Exceptional decisions to remediate security vulnerabilities

+ +

The governance processes specified in this ZIP are not intended to prevent consensus node implementors from making consensus changes that they reasonably believe are critical to maintain the security of the Zcash Mainnet network and/or Zcash users. Such changes might need to be developed and released according to a controlled disclosure process that precludes public voting.

+ +

In cases where the zBloc governance processes could not be used for this reason, the consensus node implementors MUST, once the risk of exploitation has passed, publish a thorough post-mortem analysis that explains why this was the case.

+ +

Funding

+ +

Zcash Community Fund

+ +

A pool of multisig-controlled funds, seeded from the existing contents of the ZIP 1015 Deferred Dev Fund Lockbox 7 and supplemented with a funding stream consising of 20% of the block subsidy starting at block 3146400 that will continue until modified by a future ZIP, forms a new Zcash Community Fund. The mechanisms for the creation and management of this fund are described by the Deferred Dev Fund Lockbox Disbursement proposal 10, with the \(\mathsf{stream\_value}\) parameter set to 20%, and the \(\mathsf{stream\_end\_height}\) parameter set to the height at which the Zcash block subsidy diminishes to zero.

+ +

The Zcash Community Fund will be controlled by a multisig with keys held by the Financial Privacy Foundation, the Zcash Foundation and the Electric Coin Company, along with two other entities yet to be determined (“Key-Holder Organisations”).

+ +

If Option 1 of the Deferred Dev Fund Lockbox Disbursement proposal is selected, the community SHOULD prioritize the development of a mechanism for disbursement of funds from the Deferred Dev Fund Lockbox. It is assumed here that lockbox funds would be controlled via a similar multisig with keys held by the same Key-Holder Organisations.

+ +

The Key-Holder Organisations would be bound by a legal agreement to only use funds held in the Zcash Community Fund according to the specifications in this ZIP, expressed in suitable legal language.

+ +

The Zcash Community Fund will be subject to rules similar to those currently in effect for ZCG and specified in ZIP 1015, as described under Administrative obligations and constraints.

+ +

Funding Pools

+ +

This proposal initially sets up two Funding Pools, with different rules for each. These are the Large Grant Fund and Minor Grant Fund. Over time, it is worthwhile to consider other specialized pools. This might include novel ideas, such as Loan-Directed Retroactive Grants 11 suggested by @nuttycom, or other retroactive or speculative grant pools.

+ +

Who may apply for grants is not restricted. It is highly encouraged for all participating organizations to seek outside funding and not solely rely on the Zcash Community Fund.

+ +

The Large Grant Fund will include 80% of the Zcash Community Fund.

+ + + +

The Small Grant Fund will include 20% of the Zcash Community Fund.

+ + + +

Administrative obligations and constraints

+ +

Provisions of ZIP 1015 imposing obligations and constraints on the Financial Privacy Foundation, Electric Coin Company, the Zcash Foundation, and grant recipients relating to the previous FS_FPF_ZCG funding stream, SHALL continue in effect for the Zcash Community Fund. In particular this includes the following:

+ + + +

TODO: use the same veto process as 13.

+ +

Security precautions

+ +

The Key-Holder Organizations and the Organizational Consituencies MUST take appropriate precautions to safeguard funds from theft or accidental loss. Any theft or loss of funds, or any loss or compromise of key material MUST be reported to the Zcash community as promptly as possible after applying necessary mitigations.

+ +

Acknowledgements

+ +

Thank you to Tatyana Peacemonger, Kris Nuttycombe, and Chris Tomeo for the reviews, feedback, questions, and suggestions needed to make this a strong proposal.

+ +

References

+ +
+
+
    + +
  1. +

    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”  ↩︎

    +
    2. + +
  2. +

    Zcash Protocol Specification, Version 2024.5.1. Section 3.12: Mainnet and Testnet  ↩︎

    +
    3. + +
  3. +

    ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants  ↩︎

    +
    4. + +
  4. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding  ↩︎

    +
    5. + +
  5. +

    ZIP 207: Funding Streams  ↩︎

    +
    6. + +
  6. +

    ZIP 2001: Lockbox Funding Streams  ↩︎

    +
    7. + +
  7. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Lockbox  ↩︎

    +
    8. + +
  8. +

    draft-ecc-onchain-accountable-voting: On-chain Accountable Voting  ↩︎

    +
    9. + +
  9. +

    ZIP 0: ZIP Process  ↩︎

    +
    10. + +
  10. +

    draft-ecc-lockbox-disbursement: Deferred Dev Fund Lockbox Disbursement  ↩︎

    +
    11. + +
  11. +

    Zcash Forum: Loan-Directed Retroactive Grants  ↩︎

    +
    12. + +
  12. +

    ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Transparency and Accountability  ↩︎

    +
    13. + +
  13. +

    draft-ecc-community-and-coinholder: Community and Coinholder Funding Model  ↩︎

    +
    14. + +
+
+ + diff --git a/rendered/index.html b/rendered/index.html index c28eea53..e4828153 100644 --- a/rendered/index.html +++ b/rendered/index.html @@ -150,6 +150,10 @@

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.

Title
Community and Coinholder Funding Model
Deferred Dev Fund Lockbox Disbursement
On-chain Accountable Voting
Zcash Governance Bloc
Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
Block Reward Allocation for Non-Direct Development Funding
Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
+ + + + diff --git a/zips/draft-ecc-community-and-coinholder.md b/zips/draft-ecc-community-and-coinholder.md new file mode 100644 index 00000000..d4a5d81a --- /dev/null +++ b/zips/draft-ecc-community-and-coinholder.md @@ -0,0 +1,178 @@ + ZIP: XXX + Title: Community and Coinholder Funding Model + Owners: Josh Swihart + Credits: Daira-Emma Hopwood + Kris Nuttycombe + Jack Grigg + Tatyana Peacemonger + Status: Draft + Category: Consensus / Process + Created: 2025-02-19 + License: MIT + Pull-Request: + + +# Terminology + +The key words "MUST", "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 terms "Mainnet" and "Testnet" in this document are to be interpreted as defined in the Zcash protocol specification [^protocol-networks]. + +The terms "Electric Coin Company" (or "ECC"), "Bootstrap Project" (or "BP") and "Zcash Foundation" (or "ZF") in this document are to be interpreted as described in ZIP 1014 [^zip-1014]. + +The terms "Zcash Community Grants" (or "ZCG"), "ZCG Committee", "Financial Privacy Foundation" (or "FPF"), and "Deferred Dev Fund Lockbox" in this document are to be interpreted as defined in ZIP 1015 [^zip-1015]. + +"Shielded Labs" refers to the Assocation of that name registered in the Swiss canton of Zug under the Unique Identifier CHE-243.302.798. + +Protocol-defined Ecosystem Funding is funding from sources defined by the Zcash Protocol for development of the Zcash ecosystem. At the time of writing, Protocol-defined Ecosystem Funding is allocated from a portion of block rewards via Funding Streams [^zip-0207] and Lockbox Funding Streams [^zip-2001]. + +“ZEC” refers to the native currency of Zcash on Mainnet. + + +# Abstract + +This proposal outlines a funding model that gives the community and coin holders distinct voices in determining what, if any, grants are provided to support Zcash’s development and community efforts. + +In this model: + +* 8% of the block rewards will be allocated to the ZCG for grants by and for the Zcash Community. +* 12% of the block rewards will accrue to a fund controlled by decisions of coin holders, seeded by the Deferred Dev Fund Lockbox. + +The Coinholder-Controlled Fund may be used to distribute larger grants to ecosystem participants, or left at rest. + +This model would be activated through until the 3rd halving, allowing enough time to determine whether it should be changed or codified for longer. + + +# Motivation + +If no action is taken, in November 2025 funds from block subsidies will stop being directed to Zcash Community Grants [^zip-1015-zcg] and to the Deferred Dev Fund Lockbox established by ZIP 2001 [^zip-2001]. If the block subsidies stop, it will risk a gap in funding of Zcash development organisations, either via ZCG grants or via potential future disbursements from the Deferred Dev Fund Lockbox. + +This proposal aims to: +* decentralize decision-making, +* hold stakeholders accountable for outcomes, +* be dynamic enough to allow for change, and +* provide clarity on decision-making. + +It would immediately increase coinholders’ voice, minimize governance confusion, and simplify decision-making. + +# Requirements + +* There is a well-defined, publically agreed, process for evaluation and community feedback on grant proposals. +* Funds are held in a multisig resistant to compromise of some of the parties' keys, up to a given threshold. +* No single party's non-cooperation or loss of keys is able to cause any Protocol-defined Ecosystem Funding to be locked up unrecoverably. +* During the period of this proposal, the block rewards are distributed as described in the [Abstract] above. +* The funds from the 8% funding stream will be usable immediately on activation of this ZIP. +* The funds in the Deferred Dev Fund Lockbox will be usable immediately on activation of this ZIP. +* Any use of Deferred Dev Fund Lockbox funds is consistent with the purpose specified in [^zip-1015-lockbox] of "funding grants to ecosystem participants". + +# Non-requirements + +* Any changes to the ZCG or its governance, such as its expansion to include more members, may be desired but are specifically outside this proposal’s scope. +* Any changes to Zcash protocol governance, specifically what changes are made to consensus node software, are outside this proposal’s scope. + +# Specification + +This proposal empowers both the community (through ZCG) and coin holders to independently determine what, if anything, should be funded through development fund grants. + +The funding streams described below will be defined in a new revision of ZIP 214 [^zip-0214]. + +## Zcash Community Grants + +A funding stream will be established for Zcash Community Grants, consisting of 8% of the block subsidy, and subject to all of the same rules currently specified in ZIP 1015 [^zip-1015-zcg]. + +This funding stream will start on expiry of the existing ``FS_FPF_ZCG`` funding stream [^zip-1015-funding-streams], and last for a further 1,260,000 blocks (approximately 3 years), ending at Zcash's 3rd halving. + +## Coinholder-Controlled Fund + +A pool of multisig-controlled funds, seeded from the existing contents of the ZIP 1015 Deferred Dev Fund Lockbox [^zip-1015-lockbox] and supplemented with a funding stream consising of 12% of the block subsidy for the same time period as the Zcash Community Grants stream, forms a new Coinholder-Controlled Fund. The mechanisms for the creation and management of this fund are described by the Deferred Dev Fund Lockbox Disbursement proposal [^draft-ecc-lockbox-disbursement]. This proposal sets the $\mathsf{stream\_value}$ parameter of that proposal to 12%, and the $\mathsf{stream\_end\_height}$ parameter to mainnet block height 4406400, equal to that of the Zcash Community Grants stream so that both streams end at Zcash's 3rd halving. + +### Requirements on use of the Coinholder-Controlled Fund + +The Key-Holder Organizations SHALL be bound by a legal agreement to only use funds held in the Coinholder-Controlled Fund according to the specifications in this ZIP, expressed in suitable legal language. In particular, all requirements on the use of Deferred Dev Fund Lockbox funds in ZIP 1015 [^zip-1015-lockbox] MUST be followed for Coinholder-Controlled Fund. + +The Key-Holder Organizations collectively administer the Coinholder-Controlled Fund based on decisions taken by coinholder voting, following a model decided by the community and specified in another ZIP [TBD]. + +### Disbursement process + +1. Anyone can submit a grant application via a process agreed upon by the Key-Holder Organizations. +2. Grant applications with total below USD 500,000 (or equivalent in another currency) are directed to ZCG. +3. For grant applications above this threshold, a 30-day community review and feedback period will start. +4. If a grant application is not [vetoed](#veto-process) and proceeds to a coinholder vote according to the agreed process, then coinholders will be asked to vote on it. +5. If the vote passes, then as payments are scheduled for the grant, then (subject to the [Veto process]) the Key-Holder Organizations SHOULD sign the corresponding transactions for disbursement from the Coinholder-Controlled Fund. + +For coinholder votes, a minimum of 420,000 ZEC (2% of the total eventual supply) MUST be voted, with a simple majority cast in favor, for a grant proposal to be approved. Upon approval, the grants are paid to the recipient per the terms of the grant proposal. In the case that multiple grant proposals are submitted that are in competition with one another, a single winner will be selected by holding a separate coinholder vote for each proposal, with the approved proposal having the highest total ZEC value committed in support being the winner. It is the responsibility of the Key-Holder Organizations to determine whether proposals are in competition with one another when organizing coinholder votes. + +Each coinholder vote (including in cases where multiple grants are in competition) is independent, and coins used in one vote are also allowed to be used in another; this approach is necessary to avoid vote-splitting scenarios that can result in an option being selected that achieves only a plurality (not a majority) of coinholder support. + +Coinholders SHOULD take account of the same factors considered by the ZCG Committee (described in points 2, 3, and 4 of [^zip-1015-zcg]) in deciding whether to fund a grant. If any contentious issue arises in connection with a grant (such as milestones not being met), or periodically for grants of indefinite duration, the Key-Holder Organizations SHOULD hold additional coinholder votes to determine whether funding should continue. + +Coinholders are not obligated to fund any grants and MAY leave the funds at rest. + +No organizations or individuals are restricted from voting their coins. + +### Veto process + +A grant is vetoed if: + +* any Key-Holder Organization declares that funding the grant would violate any of its legal or reporting obligations; or +* two or more Key-Holder Organizations declare that they have a principled objection to it on the basis of potential harm to Zcash users, or because it is antithetical to the values of the Zcash community. + +If a grant is vetoed after passing a coinholder vote, then payments for it MUST be stopped. This is expected to be an unusual situation that would only occur if new adverse information came to light, or in the case of a change in the law or unanticipated legal proceedings. + +The Key-holder Organizations cannot veto coinholder rejection of a proposal. + +Vetos are intended for exceptional cases and SHOULD be accompanied by a thorough rationale. + +## Administrative obligations and constraints + +All provisions of ZIP 1015 imposing obligations and constraints on Bootstrap Project, Electric Coin Company, Zcash Foundation, Financial Privacy Foundation, the ZCG Committee, and grant recipients relating to the previous ``FS_FPF_ZCG`` funding stream, SHALL continue in effect for Zcash Community Grants. + +These obligations and constraints will be extended to all Key-Holder Organizations in respect of the Coinholder-Controlled Fund. + +The provisions after the first paragraph of the section "Zcash Community Grants (ZCG)" also apply to the Key-Holder Organizations' administration of the Coinholder-Controlled Fund, with coinholder voting replacing the role of the ZCG Committee. + +Note: Nothing forces developers of Zcash consensus node software to implement any particular proposal. The aim of a process specification like this one is only to social consensus. It fundamentally cannot affect the autonomy of developers of Zcash consensus node software to publish (or not) the software they want to publish, or the autonomy of node operators to run (or not) the software they want to run. + +## Security precautions + +The Key-Holder Organizations and the ZCG Committee MUST take appropriate precautions to safeguard funds from theft or accidental loss. Any theft or loss of funds, or any loss or compromise of key material MUST be reported to the Zcash community as promptly as possible after applying necessary mitigations. + +## Testnet-specific considerations + +In order to allow the mechanism and process for coinholder voting to be tested, this process SHOULD be rehearsed on Testnet. The threshold of 420,000 ZEC applied to Mainnet coinholder votes does not apply to these rehearsals. + +# Open questions + +* Is a 3-of-5 threshold appropriate? What should the other two Key-Holder Organizations be? +* Is 420,000 ZEC the right threshold for coinholder votes? +* Is USD 500,000 the right threshold for grants to be controlled by coinholder vote rather than ZCG? + +# 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 2024.5.1 or later](protocol/protocol.pdf) + +[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + +[^zip-0207]: [ZIP 207: Funding Streams](zip-0207.rst) + +[^zip-0214]: [ZIP 214: Consensus rules for a Zcash Development Fund](zip-0214.rst) + +[^zip-1014]: [ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants](zip-1014.rst) + +[^zip-1015]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding](zip-1015.rst) + +[^zip-1015-lockbox]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Lockbox](zip-1015#lockbox) + +[^zip-1015-zcg]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Zcash Community Grants](zip-1015#zcash-community-grants-zcg) + +[^zip-1015-funding-streams]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Funding Streams](zip-1015#funding-streams) + +[^draft-ecc-lockbox-disbursement]: [draft-ecc-lockbox-disbursement: Deferred Dev Fund Lockbox Disbursement](draft-ecc-zbloc.md) + +[^zip-1015-transparency-and-accountability]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Transparency and Accountability](zip-1015#transparency-and-accountability) + +[^zip-2001]: [ZIP 2001: Lockbox Funding Streams](zip-2001.rst) + +[^draft-ecc-zbloc]: [draft-ecc-zbloc: Zcash Governance Bloc](draft-ecc-zbloc.md) diff --git a/zips/draft-ecc-lockbox-disbursement.md b/zips/draft-ecc-lockbox-disbursement.md new file mode 100644 index 00000000..10fa08ae --- /dev/null +++ b/zips/draft-ecc-lockbox-disbursement.md @@ -0,0 +1,245 @@ + ZIP: XXX + Title: Deferred Dev Fund Lockbox Disbursement + Owners: Daira-Emma Hopwood + Kris Nuttycombe + Jack Grigg + Status: Draft + Category: Consensus / Process + Created: 2025-02-19 + License: MIT + Pull-Request: + +# Terminology + +The key words "MUST", "SHOULD", "MAY", and "RECOMMENDED" in this document are +to be interpreted as described in BCP 14 [^BCP14] when, and only when, they +appear in all capitals. + +# Abstract + +This ZIP proposes an extension of protocol-based development funding, in the +context of multiple alternatives for distributing funds that have accrued to +the Deferred Dev Fund Lockbox. This proposal is intended to be evaluated in the +context of the Community And Coinholder Funding Model +[^draft-ecc-community-and-coinholder] and Zcash Governance Bloc +[^draft-ecc-zbloc] proposals; the mechanisms it describes are applicable to +both of these and may be applicable to other similar proposals as well. + +At a high level, this ZIP proposes: +* A one-time disbursement of the full contents of the lockbox to a transparent + P2SH multisig address, at the time of the activation of this ZIP. The + key-holders for that address are then responsible for distributing the + resulting funds in the form of development grants, according to the rules set + by either [^draft-ecc-community-and-coinholder] or [^draft-ecc-zbloc], or + another similar proposal. +* Extension of protocol-based development funding blocks starting from the + scheduled end height of the current ``FS_DEFERRED`` and ``FS_FPF_ZCG`` + funding streams defined in ZIP 1015 [^zip-1015-funding-streams]. +* A variety of different mechanisms that may be used for distributing funds + that accrue during the period of the extension, which may vary depending upon + which proposal this mechanism is used. + +# Requirements + +* Funds are held in a multisig resistant to compromise of some of the parties' + keys, up to a given threshold. +* No single party's non-cooperation or loss of keys is able to cause any + Protocol-defined Ecosystem Funding to be locked up unrecoverably. +* The funds previously accrued the Deferred Dev Fund Lockbox as the activation + height of this ZIP will be usable immediately on activation. + +# Specification + +This ZIP proposes the creation of a new Zcash Development Fund. The balance of +this Fund consists of the contents of the ZIP 1015 Deferred Development Fund +Lockbox as of the activation height of this ZIP, plus any funds that later +accrue to either the lockbox or to one or more transparent multisig addresses +as specified by this ZIP. + +### One-time lockbox disbursement + +The coinbase transaction of the activation block of this ZIP MUST include an +additional output to a 3-of-5 P2SH multisig with keys held by the following +"Key-Holder Organizations": Zcash Foundation, the Electric Coin Company, +Shielded Labs, and two other organizations yet to be decided. + +Let $v$ be the zatoshi amount in the Deferred Dev Fund Lockbox at the +activation height. ($v$ can be predicted in advance given that height.) + +The additional coinbase output MUST follow the same consensus rules as apply to +funding stream outputs [^zip-0207-consensus-rules]. That is, the coinbase +transaction MUST contain at least one output that pays $v$ zatoshi, in the +prescribed way defined in ZIP 207, to the above P2SH multisig address. $v$ +zatoshi are added to the transparent transaction value pool to fund this +output, and subtracted from the balance of the Deferred Dev Fund Lockbox (i.e. +the latter balance is reset to zero). + +Exactly one of the following options will also be taken. The proposal that +activates this ZIP must define values for the following two parameters: + +* $\mathsf{stream\_value}$: the percentage of the block subsidy to send to + a new funding stream, as described in the options below. +* $\mathsf{stream\_end\_height}$: The ending block height of that stream. + +### Option 1: Extend the lockbox funding stream + +The ``FS_DEFERRED`` lockbox funding stream is set to receive +$\mathsf{stream\_value}\%$ of the block subsidy and is extended until block +height $\mathsf{stream\_end\_height}$ Both of these parameters must must be +specified by the proposal under which this ZIP is activated. + +#### Rationale for Option 1 + +Performing a one-time disbursement to a P2SH multisig address will provide a +source of grant funding for a limited period, allowing time for a lockbox +disbursement mechanism to be specified and deployed, as originally intended by +ZIP 1015 [^zip-1015]. + +In particular, this provides an opportunity for transaction format changes that +may be required for such a mechanism to be included in the v6 transaction +format [^zip-0230]. It is desirable to limit the frequency of transaction +format changes because such changes are disruptive to the ecosystem. It is not +necessary that protocol rules for disbursement actually be implemented until +after the transaction format changes are live on the network. It is RECOMMENDED +that any such transaction format changes be included in the upcoming V6 +transaction format in order to avoid such disruption. + +By implementing a one-time disbursement along with a continuation of the +``FS_DEFERRED`` stream, we prioritize both the availability of grant funding +and the implementation of a more flexible and secure mechanism for disbursement +from the lockbox — making it possible to address the need to rotate keys and/or +alter the set of key holders in a way that reverting to hard-coded output +addresses for repeated disbursements would not. + +### Option 2: Revert to hard-coded output address + +A new funding stream consisting of $\mathsf{stream\_value}\%$ of the block +subsidy is defined to begin when the existing ZIP 1015 funding streams +[^zip-1015-funding-streams] end. The new streams will distribute funds to a +3-of-5 P2SH multisig with keys held by the same Key-Holder Organizations as +above. The resulting Fund is considered to include both this stream of funds, +and funds from the one-time lockbox disbursement described above. + +Option 2 can be realized by either of the following mechanisms: + +#### Mechanism 2a: Classic funding stream + +A new funding stream is definedthat pays directly to the above-mentioned 3-of-5 +multisig address on a block-by-block basis. It is defined to start at the end +height of the existing ``FS_DEFERRED`` funding stream and end at +$\mathsf{stream\_end\_height}$ and consists of $\mathsf{stream\_value}\%$ of the +block subsidy. + +#### Mechanism 2b: Periodic lockbox disbursement + +Constant parameter $N = 35000$ blocks $= +\mathsf{PostBlossomHalvingInterval}/48$ (i.e. approximately one month of +blocks). + +The ``FS_DEFERRED`` lockbox funding stream is extended to end at height +$\mathsf{stream\_end\_height}$ and has its per-block output value set to +$\mathsf{stream\_value}\%$ A consensus rule is added to disburse from the +Deferred Dev Fund Lockbox to a 3-of-5 P2SH multisig with keys held by the same +Key-Holder Organizations as above, starting at block height +$\mathsf{activation\_height} + N$ and continuing at periodic intervals of $N$ +blocks until $\mathsf{stream\_end\_height}$. Each disbursement empties the +lockbox. + +This is equivalent to specifying +$\frac{\mathstrut\mathsf{stream\_end\_height} \,-\, \mathsf{activation\_height}}{N}$ [One-time lockbox disbursement]s, +that all output to the same address. + +#### Rationale for periodic disbursement + +Classic funding streams [^zip-0207] produce many small output values, due to +only being able to direct funds from a single block's subsidy at a time. This +creates operational burdens to utilizing the funds — in particular due to block +and transaction sizes limiting how many outputs can be combined at once, which +increases the number of required transactions and correspondingly the overall +fee. + +The periodic lockbox disbursement mechanism can produce the same effective +funding stream, but with aggregation performed for free: the output to the +funding stream recipient is aggregated into larger outputs every $N$ blocks. In +the specific case of Mechanism 2b, the recipient multisig address would receive +around 40 outputs, instead of around 1,300,000. + +# Privacy and Security Implications + +As development funding is a public good on the Zcash network, there are not +relevant privacy concerns related to this proposal; all disbursement of +(but not necessarily subsequent distribution) of development funds is +transparent and auditable by any participant in the network. + +#### Security implications of the One-Time Lockbox Disbursement + +After the activation block of this ZIP has been mined, all development funds +previously accrued to the in-protocol lockbox will be held instead by a 3-of-5 +multisig address. The key-holders for this address will have the capability to +spend these funds. Compromise or loss of 3 of these 5 keys would result in +total loss of funds; as such, in the event of the compromise or loss of a +single key, the Key-Holders MUST establish a new multisig key set and address, +and transfer remaining unspent funds held by the original address before +additional loss or compromise occurs. + +Because this is a one-time disbursement, additional key rotation infrastructure +is not required. + +#### Security implications for Option 1 + +Funds will continue to securely accrue to the Deferred Development Lockbox +until a disbursement mechanism for the lockbox is implemented in a future +network upgrade. Such a disbursement mechanism should be designed to include an +in-protocol option for key rotation, such that it is not necessary to perform a +network upgrade to recover from key loss or compromise, or to change the size +of the signing set or the number of signatures required to reach threshold. + +#### Security implications for Option 2a + +As of the activation height of this ZIP, development funds will begin accruing +as additional outputs spendable by a 3-of-5 multisig address on a +block-by-block basis. Key-Holders will need to perform regular multiparty +signing ceremonies in order to shield the resulting coinbase outputs. Each such +signing ceremony involves shared spending authority being used to sign +thousands of inputs to large shielding transactions; for practical reasons, +this is often handled using a scripted process that has spending authority over +these funds. This process is an attractive target for compromise; for this +reason it is RECOMMENDED that address rotation (in this case, by means of +hard-coding a sequence of addresses, each of which receives a time-bounded +subset of the block reward fractional outputs) be implemented, as was done +for the ECC funding stream described in ZIP 1014 [^zip-1014]. + +In the case of key compromise or loss, it may be necessary to perform an +emergency Network Upgrade to perform a manual key rotation to ensure that +future development funds are not lost. + +#### Security implications for Option 2b + +Due to the aggregation of funds recommended by Option 2b, it is no longer +necessary use scripts with elevated privileges to perform shielding and/or +distribution operations; instead, these operations can be performed by human +operators using an interactive protocol that does not require sharing spending +key material. + +As with Option 2a, key compromise or loss would require an emergency Network +Upgrade to perform manual key rotation to mitigate the potential for loss of +funds. + +# References + +[^zip-0207]: [ZIP 207: Funding Streams](zip-0207.rst) + +[^zip-0207-consensus-rules]: [ZIP 207: Funding Streams — Consensus Rules](zip-0207#consensus-rules) + +[^zip-0230]: [ZIP 230: Version 6 Transaction Format](zip-0230.rst) + +[^zip-0214]: [ZIP 214: Consensus rules for a Zcash Development Fund](zip-0214.rst) + +[^zip-1015]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding](zip-1015.rst) + +[^zip-1015-funding-streams]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Funding Streams](zip-1015#funding-streams) + +[^draft-ecc-zbloc]: [draft-ecc-zbloc: Zcash Governance Bloc](draft-ecc-zbloc.md) + +[^draft-ecc-community-and-coinholder]: [draft-ecc-community-and-coinholder: Community and Coinholder Funding Model](draft-ecc-community-and-coinholder.md) + diff --git a/zips/draft-ecc-onchain-accountable-voting.md b/zips/draft-ecc-onchain-accountable-voting.md new file mode 100644 index 00000000..8ce88f13 --- /dev/null +++ b/zips/draft-ecc-onchain-accountable-voting.md @@ -0,0 +1,173 @@ + ZIP: XXX + Title: On-chain Accountable Voting + Owners: Daira-Emma Hopwood + Status: Draft + Credits: Josh Swihart + Kris Nuttycombe + Jack Grigg + Category: Consensus / Process + Created: 2025-02-21 + License: MIT + Pull-Request: + + +# Terminology + +The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 [^BCP14] when, and only when, they appear in all capitals. + +The terms "Mainnet" and "Testnet" in this document are to be interpreted as defined in the Zcash protocol specification [^protocol-networks]. + +TODO: Consider defining "Proposal", "Decision", "Approval", "Rejection", etc. + + +# Abstract + +This proposal specifies a mechanism for on-chain accountable voting that is available for use by Zcash governance and funding proposals. + + +# Motivation + +Several proposals that have been made for the future of Zcash governance, including the Zcash Governance Bloc [^draft-ecc-zbloc] and Loan-Directed Retroactive Grants [^forum-loan-directed-retroactive-grants], require similar mechanisms. In particular they require some form of on-chain accountable voting. + +The details of these mechanisms matter for security and robust oversight. Separating the concerns of governance and funding policy on the one hand, and the mechanisms used to enact this policy on the other, frees initial policy proposals (and proposers) from having to specify unnecessary detail, while ensuring that implementability and security concerns are nonetheless thoroughly considered. + +Using a shared vocabulary and repertoire of implementation mechanisms can also facilitate comparison of governance and funding proposals, by focussing attention on their higher-level differences. + +It is possible that these mechanisms may also have wider usefulness in the Zcash ecosystem beyond governance and development funding. + + +# Requirements + +* This specification should avoid, as far as possible, over-constraining how decisions about governance and funding are made, if and when they use this mechanism. +* The mechanism is resistant to compromise of some of the parties' keys, up to a given threshold. +* No single party's non-cooperation or loss of keys is able to cause further decisions to be blocked indefinitely. + + +# Non-requirements + +The on-chain accountable voting mechanism does not need to directly support coinholder voting. If that is required, it should be performed via a separate protocol. The results of that protocol might then feed into votes cast in on-chain accountable voting, as suggested by the Zcash Governance Bloc [^draft-ecc-zbloc] proposal, for example. + + +# Specification + +A Proposal to be decided using On-chain Accountable Voting is represented as Proposal Transaction, which references a human-readable Description of what is to happen on its Approval. The Proposal Transaction MAY also lock up funds that are to be granted on Approval [TODO]. + +The scope of possible Proposals is left to be specified by the high-level policy that uses this mechanism. + +A Decision is represented by spending the Approval Output or Rejection Output of the Proposal, as described in [Decisions]. This can signal either an Approval, recording the fact that the Approval Threshold has been met, or a Rejection, recording the fact that sufficient voting units have been cast against the Proposal that its Approval Threshold *cannot* be met. + +More concretely, if there are $V$ voting units overall and $A = \mathsf{ceiling}(V \cdot \mathsf{threshold})$ of them are required for approval, then $V - A + 1$ voting units suffice for Rejection. + +A Proposal also has a Deadline Height. It is Implicitly Rejected if no Approval or Rejection occurs on the consensus chain *at or before* the Deadline Height (that is, the Deadline Height is inclusive). + +Honestly constructed Proposals SHOULD take into account any planned change in the block target spacing when setting the Deadline Height (see [Block Target Spacing changes]). + +## Proposal Transactions + +A transaction is considered to be a Proposal Transaction if and only if it includes exactly one Specification Output, exactly one Approval Output, and exactly one Rejection Output, as specified below. + +### Description Output + +A Proposal Transaction MUST reference a human-readable Description of what is being voted on. This is represented by a Description Output encrypted to the zero $\mathsf{ovk}$, in the same way as for shielded coinbase transactions [^zip-0213]. The plaintext memo of the Description Output MUST use the following format: + +* the string $\texttt{“b2-256:”}$ +* a hex-encoded BLAKE2b-256 hash of the contents of the file specifying the proposal +* the string $\texttt{“:”}$ +* a stable URL to the contents of that file. + +The URL MUST be encoded as US-ASCII, but MAY use %-encoding to specify UTF-8 characters as described in [^uri-utf8]. + +For example, to refer to the contents of ZIP 1015 at time of writing: + + "b2-256:bacb0d5430968e4ce77246523d0e6f29c442f8fce0f3656462fdf5a5c4b8c656:" || + "https://raw.githubusercontent.com/zcash/zips/38e4501a2c3bf90f6057872db497295a0a76eb35/zips/zip-1015.rst" + +Since a memo field can be a maximum of 512 bytes, this currently allows a maximum of 440 bytes for the URL, which should be enough. If and when memo bundles [^zip-0231] are supported, this will increase the allowed size, and potentially allow the text of the proposal to be encoded directly in the memo. + +The contents of the file at the given URL MUST NOT be automatically downloaded unless that is requested by an explicit user action. + +## Approval and Rejection Outputs + +Let DeadlineHeight be the last block height at which a Decision can be made for this Proposal. + +An Approval Output is a P2SH output with a script of the following form: + +* TBD + +A Rejection Output is a P2SH output with a script of the following form: + +* TBD + +## Decisions + +Approval of a Proposal Transaction is signalled by spending its Approval Output in a transaction mined at or before the Deadline Height. + +Rejection of a Proposal Transaction is signalled by spending its Rejection Output in a transaction mined at or before the Deadline Height. + +A spend of an Approval or Rejection Output that occurs in a transaction mined strictly after the Proposal's Deadline Height has no effect. + +A spend of an Approval or Rejection Output is performative [^wikipedia-performative-utterance] in the sense that, even if it does not directly transfer funds, it records that the decision has been made. + +A holder of voting units SHOULD NOT sign transactions that spend both the Approval Output and the Rejection Output of a given Proposal Transaction. However, if this does occur, then it is interpreted as follows: + +* If Approval and Rejection occur in the same transaction, then the proposal is rejected. +* Otherwise, the outcome is determined by which of the Approval and Rejection outputs is spent first (i.e. in the earlier transaction). + +As stated earlier, a Proposal is Implicitly Rejected if no Approval or Rejection occurs on the consensus chain at or before the Deadline Height. + +### Finality of Decisions + +Zcash's current consensus layer provides only eventual consistency. A Decision SHOULD be considered "final" when it has 100 confirmations. (In the case where the Decision transaction also directly transfers funds to a recipient, this does not constrain the recipient's ability to spend the funds.) + +An Implicit Rejection SHOULD be considered final if a transaction in a block at the Deadline Height would have 100 confirmations. + +If and when a mechanism for "assured finality" [^tfl-book-assured-finality] of transactions is adopted by the Zcash network, it is expected to be possible to redefine "finality" of Decisions accordingly. + +## Testnet-specific considerations + +Proposal Transactions on Testnet MUST only be used to test this mechanism, and have no significance for Zcash governance. + + +# Rationale + +## Block Target Spacing changes + +The block target spacing of the Zcash network is currently 75 seconds, but is not necessarily fixed. For example, the current value was established at activation of the Blossom network upgrade, halving the previous value of 150 seconds. This potentially has implications for the use of block heights to specify deadlines, but in practice we believe that block heights will suffice: + +* If the block target spacing decreases, then this can only bring a deadline closer. This is not a problem because the Proposal can always be resubmitted if it expires sooner than intended. +* Changes that increase the block target spacing are usually signalled well in advance. It is therefore very unlikely that a deadline will unintentionally be extended. In any case, it is always possible to explicitly Reject any proposal for which the deadline is unintentionally extended. + + +# Reference implementation + +TBD + + +# Acknowledgements + +Thank you to Josh Swihart and Kris Nuttycombe for discussions about [^draft-ecc-zbloc] and [^draft-ecc-community-and-coinholder] that led to the idea for 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 2024.5.1 or later](protocol/protocol.pdf) + +[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + +[^zip-0213]: [ZIP 213: Shielded Coinbase](zip-0213.rst) + +[^zip-0231]: [ZIP 231: Memo Bundles](zip-0231.rst) + +[^draft-ecc-zbloc]: [draft-ecc-zbloc: Zcash Governance Bloc](draft-ecc-zbloc.md) + +[^draft-ecc-community-and-coinholder]: [draft-ecc-community-and-coinholder: Community and Coinholder Funding Model](draft-ecc-community-and-coinholder.md) + +[^forum-loan-directed-retroactive-grants]: [Zcash forum: Loan-Directed Retroactive Grants](https://forum.zcashcommunity.com/t/loan-directed-retroactive-grants/48230) + +[^tfl-book-assured-finality]: [Zcash Trailing Finality Layer. Section 2: Terminology — Assured Finality](https://electric-coin-company.github.io/tfl-book/terminology.html#definition-assured-finality) + +[^uri-utf8]: [RFC 3986: Uniform Resource Identifier (URI). Section 2.5: Identifying Data](https://www.rfc-editor.org/rfc/rfc3986.html#section-2.5) + +[^wikipedia-performative-utterance]: [Wikipedia: Performative utterance](https://en.wikipedia.org/wiki/Performative_utterance) diff --git a/zips/draft-ecc-zbloc.md b/zips/draft-ecc-zbloc.md new file mode 100644 index 00000000..f1900cfa --- /dev/null +++ b/zips/draft-ecc-zbloc.md @@ -0,0 +1,267 @@ + ZIP: XXX + Title: Zcash Governance Bloc + Owners: Josh Swihart + Daira-Emma Hopwood + Credits: Kris Nuttycombe + Jack Grigg + Tatyana Peacemonger + Chris Tomeo + Status: Draft + Category: Consensus / Process + Created: 2025-01-28 + License: MIT + Pull-Request: + + +# Terminology + +The key words "MUST", "REQUIRED", "SHALL", "SHOULD", "SHOULD NOT", 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 terms "Mainnet" and "Testnet" in this document are to be interpreted as defined in the Zcash protocol specification [^protocol-networks]. + +The terms "Electric Coin Company" (or "ECC") and "Zcash Foundation" (or "ZF") in this document are to be interpreted as described in ZIP 1014 [^zip-1014]. + +The terms "Zcash Community Grants" (or "ZCG"), "Financial Privacy Foundation" (or "FPF"), and "Deferred Dev Fund Lockbox" in this document are to be interpreted as defined in ZIP 1015 [^zip-1015]. + +"Shielded Labs" refers to the Assocation of that name registered in the Swiss canton of Zug under the Unique Identifier CHE-243.302.798. + +"Zcash Core Engineers" refers to the current set of engineers whose primary job is to make changes to consensus node software and libraries. + +TODO: define "Zechub". + +"Zcash Governance" refers to the social consensus of the Zcash community on specifications, procedures, agreements (legal or otherwise), and decision-making processes for operation and use of the Zcash Protocol on the Zcash Mainnet and (as applicable) Testnet networks. + +"Protocol-defined Ecosystem Funding" is funding from sources defined by the Zcash Protocol for development of the Zcash ecosystem. At the time of writing, these sources are a portion of block rewards defined by Funding Streams [^zip-0207] and Lockbox Funding Streams [^zip-2001]. + +A "Proposal" is either a proposed change in Zcash Governance ("Governance Proposal") or a proposed disbursement of Protocol-defined Ecosystem Funding ("Funding Proposal") to be approved or rejected by a vote of the [zBloc Constituencies](#zbloc-membership). + +A "Decision" is the approval or rejection of a Proposal. + + +# Abstract + +In recent polls about the future of Zcash development funding, the community signaled a strong preference for a non-direct funding model. It also decided on a temporary one-year continuation of a development fund, starting at the second halving in November 2024, where ZCG would continue to be funded and the remainder would be temporarily placed in a Deferred Dev Fund Lockbox, while the community determines next steps. + +This ZIP outlines a more detailed proposal for non-direct funding, based on voting among a group of Constituencies with a stake in Zcash and its protocol. It has 80% of the block rewards given to miners and 20% to a Zcash Community Fund, in perpetuity. The current balance of the Deferred Dev Fund Lockbox is used to seed the Zcash Community Fund. This fund is initially split into two Funding Pools, with different rules for each: the Large Grant Fund and the Minor Grant Fund. Other specialized pools could be added over time. + +This model allows for the community to guide its evolution and possible replacement via Governance Decisions, and so would be activated indefinitely. + + +# Motivation + +Zcash governance must represent voices from all over the world, who need digital cash for their security and for their dignity. It must not be dependent on individuals who, despite their best intentions, are flawed and prone to temptations to control and coerce. It must be durable and withstand attempted capture of all forms. + +zBloc is a governance model that is designed for decentralization and accountability, to include more voices and ensure results from those who receive Protocol-defined Ecosystem Funding. + +It is built to allow new innovative and positive voices to rise up and carry the flag of the Zcash community forward, in recognition of the risk that any one group may become captured or ineffective. + + +# Requirements + +* This ZIP covers how to decide on Proposals for potential changes to Zcash Governance and/or disbursement of Protocol-defined Ecosystem Funding. +* There is a well-defined, publically agreed, process for evaluation and community feedback on both Governance Proposals and Grant Proposals. +* Funds are held in a multisig resistant to compromise of some of the parties' keys, up to a given threshold. +* The voting mechanism used for decision-making is similarly resistant to compromise of some of the parties' keys, up to a given threshold. +* No single party's non-cooperation or loss of keys is able to cause any Protocol-defined Ecosystem Funding to be locked up unrecoverably. +* 80% of the block rewards are given to miners, and 20% to a Zcash Community Fund seeded from the Deferred Dev Fund Lockbox. +* The funds from the 20% funding stream will be usable immediately. +* The funds in the Deferred Dev Fund Lockbox will be usable once a mechanism is available for disbursing them. +* Any use of Deferred Dev Fund Lockbox funds is consistent with the purpose specified in [^zip-1015-lockbox] of "funding grants to ecosystem participants". + + +# Non-requirements + +Any changes to the ZCG or its governance, such as its expansion to include more members, may be desired but are specifically outside this proposal’s scope. + +# Specification + +## zBloc Membership + +The zBloc would distribute decision-making authority for both Zcash governance and funding decisions, potentially to any number of Constituencies. + +A zBloc Constituency is a group representing a trusted subsection of the Zcash community. + +The [Initial Structure] section below proposes a set of initial Constituencies, but the model allows for changes over time, enabling the zBloc to evolve. New zBloc Constituencies may be added as they gain trust and removed if they are no longer operating or trust is eroded. The means for this is described in the [Governance Decisions] section below. + +zBloc Constituencies may be granted different levels of authority, receiving less or more say over time. This is done by allocating or removing "Voting Units" to reflect the amount of voting power allocated to each Constituency. For example, if the community wishes to increase the weight of coinholder voice over time, it could increase the number of Voting Units allocated to coinholder representatives, which would dilute the relative power of other Constituencies. + +### Decision-making policies + +To be considered a Constituency, each must pre-commit to an internal policy for decision-making that all other Constituencies approve of (i.e. greater than one decision maker, means of assessing community sentiment, etc.). This could be by polling, majority vote within the Constituency, coinholder signaling, technical feasibility, mission alignment, etc. + +In order for a Constituency to change its decision-making policy, the change MUST be expressed as a [Governance Proposal] and Approved before it comes into effect. The Constituency that is proposing to change its policy is eligible to vote, but it MUST make its decision according to its *pre-existing* policy (if it does not abstain). + +## Initial Structure + +The initial group of Constituencies will be (if they are willing and approved by the others and by the Zcash community): + +* Coinholders +* Electric Coin Company +* Zcash Foundation +* Shielded Labs +* Zcash Community Grants +* Zcash Core Engineers +* ZecHub + +Each Constituency initially receives three Voting Units. This MAY be changed by a Governance Proposal. + +Constituencies other than the Coinholder Constituency above are called Organizational Constituencies. The Organizational Constituencies will together elect a representative responsible for establishing a clear process and mechanism for gathering coinholder sentiment, which will then be used as the decision-making process of the Coinholder Constituency. + +TODO: as Organizational Constituencies make commitments about their decision-making policies, link to those commitments here. + +Initial zBloc members MUST take on the responsibility to encourage, nurture, and welcome potential new Constituencies. + +**Rationale:** Relentless decentralization is zBloc’s core value and mission. It is the unifying ethos that will keep zBloc’s doors open to new contributors. This continuous expansion is in the best interests of the growing Zcash community. + +## Voting + +A suitable voting mechanism is needed that —among other design requirements— makes the votes cast by each Constituency (i.e. the number of Voting Units cast for Approval and for Rejection) publically visible. A possible design that meets this requirement is suggested in [^draft-ecc-onchain-accountable-voting] ("On-chain Accountable Voting"). In addition, the chosen voting mechanism MUST support the situation where voting entities must choose among multiple competing proposals to select a single grant recipient. The voting system selected MUST avoid vote-splitting scenarios that can result in an option being selected that achieves only a plurality (not a majority) of Consituencies supporting it. + +Each independent zBloc Constituency decides how to cast its Voting Units for each Governance or Funding Proposal, provided it is eligible to vote on that proposal (see the next section). If its decision-making policy permits, it MAY cast fewer than its total number of Voting Units, and MAY cast some Voting Units for Approval and some for Rejection. This might be used to publically acknowledge internal dispute over a decision, for example. + +### Conflicts of interest + +If a Constituency has a conflict of interest for a given decision, such as potentially being the recipient of funds or additional authority, then its Voting Units are not eligible to be cast for that vote. This affects the [Approval Threshold] discussed below, which is calculated as a proportion of the remaining Eligible Voting Units. + +A Constituency is not automatically considered to have a conflict of interest merely because the decision affects it — for example, when changing its decision-making policy, or because it would need to make changes to software if the Proposal were Approved. + +### Approval Thresholds + +The Approval Threshold is the absolute majority, as a proportion of the total number of Eligible Voting Units, required for a Proposal to be Approved. As stated earlier, Eligible Voting Units do not include those of Constituencies that have a conflict of interest for this Proposal. However, they do include the Voting Units of Constituencies that have no conflict of interest but choose to abstain. + +By default, a [Governance Proposal](#governanceproposals) requires a three-fifths Approval Threshold, and MUST have a Deadline at least two weeks from when the Proposal is published on-chain. + +All Consituencies MUST be consulted in order to determine whether they consider a draft Proposal to be "controversial", before it is published on-chain. If *any* Constituency decides that a Proposal should be treated as controversial, it is then subject to a higher Approval Threshold of three quarters, and a Deadline at least four weeks from when the Proposal is published on-chain. (In the case of the Coinholder constituency, a coinholder vote is not necessarily required to establish this; it is likely sufficient to decide based on forum discussions for example.) + +The following categories of [Governance Proposal](#governanceproposals) are automatically subject to the three-quarters Approval Threshold and 4-week Deadline: + +* Increasing or decreasing the voting power of zBloc Constituencies by adjusting how many Voting Units they hold. +* Increasing or decreasing the number of Funding Pools, the rules that govern them, and the amounts allocated. + +In the case of [Governance Proposals] that affect consensus, final ratification occurs when node operators adopt the software implementing the changes. + +Note: Nothing forces developers of Zcash consensus node software to implement any particular proposal. The aim of a process specification like this one is only to establish a social consensus. It fundamentally cannot affect the autonomy of developers of Zcash consensus node software to publish (or not) the software they want to publish, or the autonomy of node operators to run (or not) the software they want to run. + +## Proposals + +As stated in [Terminology], there are two categories of Proposal that can be put to a vote of the [zBloc Constituencies](#zbloc-membership): + +* a "Governance Proposal", expressing a proposed change in Zcash Governance; +* a "Funding Proposal", expressing a proposed disbursement of Protocol-defined Ecosystem Funding. + +Proposals have a Deadline (expressed as a Deadline Height if [^draft-ecc-onchain-accountable-voting] is used). If the Deadline is reached, they are implicitly Rejected. This does not necessarily preclude reintroducing the same or a similar Proposal. + +### Governance Proposals + +At least the following changes to Zcash Governance MUST be proposed and approved by a Governance Proposal before they can take effect: + +* Changes to Zcash consensus rules. In this case Approval is REQUIRED in order for an activation height to be set. +* Substantive changes to the ZIP Process defined in ZIP 0 [^zip-0000]. +* Substantive changes to this ZIP defining the zBloc. +* Changes to the set of zBloc Constituencies and/or the distribution of Voting Units among those Constituencies. +* Changes to the policy a Constituency uses for its decision-making. + +The ZIP Editors will modify ZIP 0 to define other categories of change to Zcash Governance that MUST or SHOULD require Approval of a Governance Proposal. + +Unrelated changes SHOULD NOT be bundled into a single Governance Proposal. This does not prevent a single Governance Proposal from being used to decide whether to adopt a proposed Network Upgrade involving multiple consensus and/or process changes, since those are considered related. During the process of drafting Governance Proposals, the ZIP Editors MAY request that proposals be split in order to satisfy this rule, or merged if they are sufficiently interdependent. + +### Disputes + +If any zBloc Constituency, or the ZIP Editors, have concerns relating to the conduct of any vote, they MAY raise a dispute. Possible reasons to raise a dispute include believing that: + +* A Constituency or any holders of keys for its Voting Units were unduly pressured or coerced. +* A Constituency voted contrary to its intended position (due to key compromise or error, for instance), or contrary to its stated decision-making policy. +* A Constituency failed to disclose a relevant conflict of interest. +* There were technical irregularities in the use of the voting mechanism. + +If a dispute is raised, the Constituencies SHALL first resolve any technical issues as far as possible (e.g. by rotating keys), and then make one or more Governance Proposals intended to resolve the situation to the satisfaction of the community. + +### Exceptional decisions to remediate security vulnerabilities + +The governance processes specified in this ZIP are not intended to prevent consensus node implementors from making consensus changes that they reasonably believe are critical to maintain the security of the Zcash Mainnet network and/or Zcash users. Such changes might need to be developed and released according to a controlled disclosure process that precludes public voting. + +In cases where the zBloc governance processes could not be used for this reason, the consensus node implementors MUST, once the risk of exploitation has passed, publish a thorough post-mortem analysis that explains why this was the case. + +## Funding + +### Zcash Community Fund + +A pool of multisig-controlled funds, seeded from the existing contents of the ZIP 1015 Deferred Dev Fund Lockbox [^zip-1015-lockbox] and supplemented with a funding stream consising of 20% of the block subsidy starting at block 3146400 that will continue until modified by a future ZIP, forms a new Zcash Community Fund. The mechanisms for the creation and management of this fund are described by the Deferred Dev Fund Lockbox Disbursement proposal [^draft-ecc-lockbox-disbursement], with the $\mathsf{stream\_value}$ parameter set to 20%, and the $\mathsf{stream\_end\_height}$ parameter set to the height at which the Zcash block subsidy diminishes to zero. + +The Zcash Community Fund will be controlled by a multisig with keys held by the Financial Privacy Foundation, the Zcash Foundation and the Electric Coin Company, along with two other entities yet to be determined ("Key-Holder Organisations"). + +If Option 1 of the Deferred Dev Fund Lockbox Disbursement proposal is selected, the community SHOULD prioritize the development of a mechanism for disbursement of funds from the Deferred Dev Fund Lockbox. It is assumed here that lockbox funds would be controlled via a similar multisig with keys held by the same Key-Holder Organisations. + +The Key-Holder Organisations would be bound by a legal agreement to only use funds held in the Zcash Community Fund according to the specifications in this ZIP, expressed in suitable legal language. + +The Zcash Community Fund will be subject to rules similar to those currently in effect for ZCG and specified in ZIP 1015, as described under [Administrative obligations and constraints]. + +### Funding Pools + +This proposal initially sets up two Funding Pools, with different rules for each. These are the Large Grant Fund and Minor Grant Fund. Over time, it is worthwhile to consider other specialized pools. This might include novel ideas, such as Loan-Directed Retroactive Grants [^forum-loan-directed-retroactive-grants] suggested by @nuttycom, or other retroactive or speculative grant pools. + +Who may apply for grants is not restricted. It is highly encouraged for all participating organizations to seek outside funding and not solely rely on the Zcash Community Fund. + +The Large Grant Fund will include 80% of the Zcash Community Fund. + +* The Large Grant Fund is used for grants at or above USD 100,000 (or equivalent in another currency). An Approved Governance Proposal can change this threshold. +* The zBloc makes funding decisions and disbursements via Funding Proposals with an Approval Threshold of one half (i.e. an absolute majority of Eligible Voting Units is sufficient for Approval). The Deadline SHOULD be at least two weeks from when a Proposal is published on-chain. +* Proposals are submitted to a dedicated section of the Zcash forum. Each zBloc Constituency SHOULD monitor the forum and engage with participants. If a Constituency does not cast their vote for Approval, they SHOULD explain why they are not supporting the grant. +* If the grant is Approved, disbursements are made when the recipient successfully demonstrates completion of a milestone to the satisfaction of Constituencies holding a simple majority of Eligible Voting Units. + +The Small Grant Fund will include 20% of the Zcash Community Fund. + +* The Small Grant Fund is used for grants under USD 100,000 (or equivalent in another currency). An Approved Governance Proposal can change this threshold. +* A designated organization, or perhaps different organizations with areas of specialization (engineering, marketing, etc.) will administer decisions and disbursements in exchange for an annual fee. +* The organization(s) will be elected by the zBloc, and can be changed or removed by Approving a Governance Proposal. +* The fee will be proposed by the organization and approved by the zBloc. +* The organization will self-govern and manage the process for grant submissions, approvals, and disbursements. +* ZCG could be a candidate for this role initially. +* The role is open to competition. For example, rather than ZCG splitting off as an independent organization, perhaps this function could be rolled under the Financial Privacy Foundation or third parties that may be interested in managing the fund in exchange for a fee. + +## Administrative obligations and constraints + +Provisions of ZIP 1015 imposing obligations and constraints on the Financial Privacy Foundation, Electric Coin Company, the Zcash Foundation, and grant recipients relating to the previous ``FS_FPF_ZCG`` funding stream, SHALL continue in effect for the Zcash Community Fund. In particular this includes the following: + +* A decision to disburse funds is subject to veto if any Key-Holder Organization judges it to violate applicable law or reporting requirements. +* The Key-Holder Organizations SHALL be contractually required to recognize the Zcash Community Fund as a Restricted Fund donation or equivalent [TBD], and keep separate accounting of its balance and usage under its Transparency and Accountability obligations defined in ZIP 1015 [^zip-1015-transparency-and-accountability]. + +TODO: use the same veto process as [^draft-ecc-community-and-coinholder]. + +## Security precautions + +The Key-Holder Organizations and the Organizational Consituencies MUST take appropriate precautions to safeguard funds from theft or accidental loss. Any theft or loss of funds, or any loss or compromise of key material MUST be reported to the Zcash community as promptly as possible after applying necessary mitigations. + +# Acknowledgements + +Thank you to Tatyana Peacemonger, Kris Nuttycombe, and Chris Tomeo for the reviews, feedback, questions, and suggestions needed to make this a strong proposal. + +# 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 2024.5.1 or later](protocol/protocol.pdf) + +[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + +[^zip-0000]: [ZIP 0: ZIP Process](zip-0000.rst) + +[^zip-0207]: [ZIP 207: Funding Streams](zip-0207.rst) + +[^zip-1014]: [ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants](zip-1014.rst) + +[^zip-1015]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding](zip-1015.rst) + +[^zip-1015-lockbox]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Lockbox](zip-1015#lockbox) + +[^zip-1015-transparency-and-accountability]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Transparency and Accountability](zip-1015#transparency-and-accountability) + +[^zip-2001]: [ZIP 2001: Lockbox Funding Streams](zip-2001.rst) + +[^draft-ecc-lockbox-disbursement]: [draft-ecc-lockbox-disbursement: Deferred Dev Fund Lockbox Disbursement](draft-ecc-zbloc.md) + +[^draft-ecc-community-and-coinholder]: [draft-ecc-community-and-coinholder: Community and Coinholder Funding Model](draft-ecc-community-and-coinholder.md) + +[^draft-ecc-onchain-accountable-voting]: [draft-ecc-onchain-accountable-voting: On-chain Accountable Voting](draft-ecc-onchain-accountable-voting.md) + +[^forum-loan-directed-retroactive-grants]: [Zcash Forum: Loan-Directed Retroactive Grants](https://forum.zcashcommunity.com/t/loan-directed-retroactive-grants/48230)
Title
Community and Coinholder Funding Model
Deferred Dev Fund Lockbox Disbursement
On-chain Accountable Voting
Zcash Governance Bloc
Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
Block Reward Allocation for Non-Direct Development Funding
Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve