A Grand Compromise/Synthesis ZIP Proposal

I’ve heard this concern mentioned a few times, but I don’t think anyone described any bad gaming of this metric.

The worst “gaming” I can think of is: the Dev Fund recipients just convince some whales to move their millions of ZEC to a z-address. And my response is: excellent! That means crucial, long-waited progress has been achieved on secure storage of shielded ZEC (namely: hardware wallets and/or shielded multisig). That’s a good cause for celebration and incentivization! And then enough ZEC is not held by those few whales to further incentivize shielded adoption, so what’s not to like?

1 Like

Consider the flip side of the coin: what if a whale moves/holds in t-addrs to prevent the funding goals being met? E.g., whale acquires lots of ZEC, potentially from users who previously had it in the shielded pool, then purposefully moves into exchanges/their own keys without shielded support, reducing funding. With enough ZEC they could “veto” the full-shielded clause indefinitely.


Ah! I wasn’t even thinking in that direction. Agreed, that’s a problem.


I feel like if any single entity acquires more than a % or two of the supply then that’s a bigger problem than the bonus not getting released…


I have significantly updated this proposal, mostly to reflect the great discussion happening on @mhluongo and @tromer’s recent proposals. Full text of that update in next reply.

Summary here: the shielded adoption metric was removed, some accountability metrics were relaxed, and I’ve defined the ZF Grants Review Committee to reflect the makeup suggested by @mhluongo for the Foundation’s board (while keeping the Foundation’s board operating as it currently does) while adding a focus on “large-scale grants” for that process to encourage the kind of focused, big-picture third party development teams suggested in that proposal as well.

The funding streams are pretty similar to @mhluongo’s (with 60% going to ECC/ZF and 40% going to external devs via ZF Grants as opposed to 50-50 in his proposal). Where they differ is in implementation of the funding streams. In a sense, they occupy different approaches on the risk/decentralization spectrum (as @JacobPPhillips put it in the other thread).

For quick take on the differences, here’s how I view them:

  • My proposal’s accountability requirements are more stringent for the ZF/ECC
  • My proposal restricts the ECC’s activities as a for-profit commensurately…
  • …but as a trade-off there, the cap to the disbursement only applies to the Foundation’s full endowment and not the ECC (mainly to allow ECC employees to see upside for their efforts, just as outside developers would, but not outside investors during the period of the dev fund)
  • the ZF board composition continues to be self-determined (as is standard practice for nonprofits) while the ZF Grant Review Committee would take on the board composition suggested by @mhluongo. Note that this doesn’t preclude a similar advisory process as last year’s for the ZF board, it simply leaves it to the ZF’s discretion.
  • It uses a trust with a single address for funds disbursement rather than rotating dev fund addresses

While I originally was interested in merging proposals, I think it’s worth keeping them both as polling options to see how people feel about the differences above. Looking forward to any further comments today/tomorrow and will integrate feedback as much as I can until Friday!

  ZIP: ???
  Title: Compromise Dev Fund Proposal With Diverse Funding Streams
  Owner: Josh Cincinnati <josh@zfnd.org>
  Credits: Matt Luongo, Eran Tromer, Andrew Miller, mistfpga, lex-node, and many others
  Status: Draft
  Category: Consensus
  Discussions-To: https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812/
  Created: 2019-08-31
  License: MIT


“OPTIONAL”, and “REQUIRED” in this document are to be interpreted as
described in RFC 2119. #RFC2119

The term “network upgrade” in this document is to be interpreted as
described in ZIP 200. #zip-0200


I try to put the best pieces of various proposals together. A 20% of the block reward for a 4 year dev fund that disburses to a trust controlled by both the ECC and Zcash Foundation but with stringent controls on how funds may be allocated. It sidesteps code complexity in implementation by off-loading disbursements to a legal trust, funds the ECC/ZF, ECC stays a for-profit with restrictions, funds external parties through ZF Grants, all while carving out a limited-scoped opportunity for extending governance to more groups than the ECC/ZF.


Zcash won’t thrive without a dev fund. I wish this wasn’t true (I really do), and for the longest time I was against the idea. But I’ve come to fear the alternative without one; I fear the privacy technology pioneered by Zcash may never reach its true potential — not just for our community, but for others interested in novel approaches to private money.

The Foundation, ECC, and broader community has offered many suggestions and guidelines for a potential dev fund, below is my attempt at synthesizing them into a compromise that’s greater than the sum of its parts:

  • The ECC and Zcash Foundation shouldn’t get a blank check; accountability is a prerequisite for any disbursement, based on the Foundation’s statement and other proposals being suggested.
  • It’s possible for the ECC to remain a for-profit, but with (legally enforced) restrictions that ensure accountability and add teeth to their claim that no early investors are enriched by a new dev fund / no new investors are beneficiaries.
  • A nontrivial portion of the funds should be directed to users/orgs outside of the ECC/Zcash Foundation, and the ECC/Zcash Foundation should be in the minority in deciding how these funds are disbursed (e.g. through some process with broader input beyond ECC/Zcash Foundation employees, like a more constrained version of Placeholder or Blocktower’s “third party” proposal).
  • The actual code changes for the NU4 network upgrade should be minimal and the “governance complexity” should be offloaded to legal agreements, not engineering hours. The dev fund would be deposited into a single address for the fund (ideally shielded with a viewing key) controlled through a trust (originally Andrew Miller’s idea), disbursed quarterly based on the accountability requirements and shielded adoption metrics described below. Trustees will be mutually agreed upon by the ECC and Zcash Foundation, and the Zcash Foundation will bear the cost of operating the trust.
  • The gross amount of the dev fund should still be 20% of the block reward, and it should end in 4 years. (Unless we go through another process like this one to extend it, though I personally hope we don’t)

Please note: a previous version of this proposal included a portion of the funds being tied to shielded adoption based on ideas brought forward by Eran Tromer. After many discussions I came to worry about the gameability of the metric and decided to drop it entirely.


Upon the NU4 network activation, 20% of the mining reward (post-Blossom/post-halvening = 0.625 ZEC per block) MUST go to a single shielded address with a view key widely distributed and known to the community and controlled by a trust established by the ECC and Zcash Foundation. If the trust and associated address aren’t established by the NU4 activation deadline, then there MUST NOT be any change to the mining reward. Every 105,000 blocks (a quarter of the year) until 1,680,000 blocks after activation (the next halvening), the trust SHOULD disburse funds the following way, requiring a public report with every disbursement:

  • 30% of the fund to the ECC, if they meet the accountability requirements set by the trust/described below

  • 30% to the fund to the Zcash Foundation, if they meet the accountability requirements set by the trust/described below

  • 40% to the fund to the Zcash Foundation as a RESTRICTED donation purely for disbursement through ZF Grants, with additional restrictions and stipulations described below

Example disbursements by the trust for a hypothetical 105000 block period

0.625ZEC * 105000 = 65625 ZEC accrued in the trust every quarter. If both the ECC and Zcash Foundation met the accountability requirements set by the trust, then disbursements would look like this:

  • 19687.5 ZEC to the ECC for meeting accountability requirements

  • 19687.5 ZEC to the Zcash Foundation for meeting accountability requirements

  • 26250 ZEC to ZF Grants to be disbursed to external individuals and organizations (via the Zcash Foundation as a restricted donation, but determined by an independent body to both organizations)

The trust’s accountability requirements

Here I’m borrowing from the Foundation’s guidance but adding some stipulations to cement the Foundation’s independence, prevent the Foundation from hoarding its endowment, and handle the ECC as a for-profit. Before disbursing funds each quarter, the trust MUST validate that both the ECC and Zcash Foundation:

  • Published quarterly tech roadmap reports and financial reports, detailing spending levels/burn rate and cash/ZEC on hand

  • (if beginning of calendar year) Published a yearly review of organization performance, along the lines of the Zcash Foundation’s “State of the Foundation” report

For the Zcash Foundation, the trust MUST further require:

  • No board member may have an interest in the ECC (current board members with an interest would need to divest of their ECC holdings prior to the beginning of this dev fund or leave the board)

  • Excluding money restricted for ZF Grants, the Foundation’s total assets must stay below $100mm (if its assets ever exceeded this amount from a disbursement, the trust could direct the funds toward an additional restricted ZF Grants donation)

Additionally, for the ECC, the trust MUST validate the following before each disbursement:

  • (if the beginning of fiscal year) The ECC published yearly audited financial statements at the same level of detail as a public company (to mirror the Foundation’s Form 990 requirement as 501(c)(3))

  • No outside investment was received while they are obligatory recipients of this dev fund

  • No portion of the dev fund went to dividends, profit-sharing, or share/equity buybacks while they are obligatory recipients of this dev fund

  • No dilution of ECC’s equity except in the case of options/RSUs for new/existing employees while they are obligatory recipients of this dev fund

  • There’s no change-of-control (majority control changes) at the ECC while they are obligatory recipients of this dev fund

The ECC MUST share necessary information with the trust to ascertain no violations of the above, but the information itself (i.e. cap table and detailed financials) SHOULD remain private between the ECC and the trustees unless there is a violation that is not cured.

What happens in the case of a violation

The violating party has 30 days to attempt to cure the violation (if it’s possible). If they cannot, future funds MUST be redirected to ZF Grants via a restricted donation to the Zcash Foundation. (aka not usable by either the Zcash Foundation or ECC, more on that below)

The ZF Grants portion

A portion of the dev fund goes to the Foundation but with the express (and restricted) purpose of being distributed via ZF Grants (a restriction that MUST be legally enforced by the trust). The Foundation would continue to administer ZF Grants and distribute funds, but it SHOULDN’T decide where those funds go and would not allowed to be recipients of these funds; instead, the trust MUST demand that the ZF Grants process include broader input in the manner described below. In the discussions around the various “third party” proposals, some have suggested a 3-of-5 approach where the ECC and Zcash Foundation are in the minority; I think that structure would work well for these funds. It’s not the full dev fund so we are limiting the downside risk of selecting the “wrong” third parties, which also means we can give those third parties more voice (by making them outnumber the ECC/Zcash Foundation). The Foundation could also chose to fund ZF Grants beyond the restricted donations from the trust, but doing so would be at their discretion.

Thanks to the discussion on Matt Luongo’s proposal there’s a good blueprint for how this group would work. I’m borrowing some comments I made on Matt’s proposal thread and modifying them to apply to a ZF Grants-specific Grant Review Committee, rather than the Foundation’s board.

The ZF Grant Review Committee would be compromised of five members, voted on in the following manner:

  • 1 seat for the ECC. Though the appointed member may change, they retain power to choose the seat for 4 years.
  • 1 seat for the Zcash Foundation. Though the appointed member may change, they retain power to choose the seat for 4 years.
  • 2 seats voted on by ZEC holders directly, elected every year. There would be open elections held by the Foundation similar to the 2018 advisory process which resulted in Ian and Amber’s election, except using a ZEC coin-staked vote directly.
  • 1 seat held by a technical member, elected every year. This member would be selected by the combined group (2 coin-staked seats + ZF/ECC seat) with an express focus on ability to evaluate technical proposals.

The group would meet biweekly to make funding decisions, the results of which will be made public on ZF Grants. Taking a note from Eran Tromer’s recent proposal, the group would have a goal of making at least two “Large Grants” every year. A “Large Grant” would have an expected scope of six months and 1/4th to 1/3rd of the total ZF Grants yearly budget, with the goal of getting more dedicated external teams involved.


There are scores of great ideas on the forums, and I took the (subjective, mind you) best parts of each into a proposal that hopefully meets the standards of the ECC, the Zcash Foundation, and the broader community.

A word on the enigmatic “third party” floating around

With all due respect to the proposers behind some variant of a “2-of-3 multisig” decision-making process for all disbursement decisions: I think this is a bad idea. To quote a previous forum post of mine:

…2-of-3 multisig [is] better if we find the right third party. That in and of itself requires an additional process/mutual agreement between the three parties (which is much more difficult than a bilateral agreement), and as I’ve mentioned before in presentations in the past, 2-of-2 with known entities dedicated to Zcash is better than jumping straight to 2-of-3 with a third party hastily decided or staying with 1-of-1 entity trademarks and software development processes.

As for why 2-of-2 is still strictly better than 1-of-1: in the case of cryptocurrency governance, I believe that inaction in the case of disagreement is a better outcome than one party unilaterally exercising power.

More to the point, I worry that the “third party” in question is being idolized into some Platonic ideal, and in reality either the ECC or the Zcash Foundation would spend a great deal of their time currying favor in either the process or selection of the party in question in the limited time between now and that party’s selection. Given that the Zcash Foundation is charged with representing community interests, I’m not sure why another community-focused representative would really make sense from the ECC’s perspective — they’d be constantly outvoted if interests clashed, so from a balance of power perspective I’m not sure why the ECC would find that tenable. And I’m not sure the community would want the “third party” to be another profit-generating enterprise, like a VC or another startup, which would tip power another way.

The crux of this proposal still centers around the idea that the Zcash Foundation and ECC share responsibility for protocol development, which is now bolstered by the 2-of-2 agreement on the trademark. It assumes and expects that both continue developing consensus-compatible node software that interacts with the Zcash network. But it mandates accountability for disbursement of funds to the ECC/Zcash Foundation, and expands outside stakeholder input on funds that wouldn’t be earmarked for the ECC/Zcash Foundation (similar to Placeholder’s earlier version of their proposal and Matt Luongo’s current proposal), while it doesn’t preclude the possibility of migrating to broader “2-of-3” later on future governance decisions.

Why a trust?

The main reason: reducing complexity creep in consensus code. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 with the simplest possible code-change and spend more time ironing out the details of the trust “off-chain.” Since both the ECC and the Zcash Foundation are based in the US, using a trust with well-specified criteria for disbursements is a reasonable path. This also fits in nicely with lex-node’s proposal for legal covenants on funding.

Security and Privacy Considerations

The biggest issue is custody of the funds under the trust’s control, but I suspect this can be managed with a partnership with a custody partner. There’s also the issue that non-public information would need to be verified and validated by the trust, but I view this as a net positive for the community. (“transparency for organizations, privacy for individuals”)

Reference implementation

TBD, but it should be relatively simple to code in both zebra and zcashd.

Issues and further discussion

  • What are the tax implications for setting up the trust?
  • Are the amounts reasonable? Should the dev fund be less than 20% in aggregate?
  • Should this or other proposals seek to change the ECC and Zcash Foundation’s board/makeup, or should we keep those organizations running as they are and sandbox a new process to a specific disbursement of the dev fund? (This proposal assumes the latter via ZF Grants)

@acityinohio, this is an excellent integration of the latest ideas, thinking and feedback.

The one fundamental difference between your revised proposals and mine is the use of a human-operated Trust, which my proposal avoids (with the obvious benefits, but also downsides). If a workable Trust can really be established, then your proposal is a great approach!

Would your proposal’s ZF Grant Review Committee be allowed to choose to award grants to ECC, beyond ECC’s 30% (with ECC’s seat recused from that decision, presumably)? Note that my proposal explicitly allows this, but de-prioritizies ECC compared to other candidates; I’ve explained the rationale elsewhere.

There are many second-order details which can be picked from either of our proposals. Ideally, we would harmonize all of those, resulting in two proposals that differ just by presence of a Trust or things that replace it, to make community analysis easier. Unfortunately there’s not enough time for that (especially since I’m already busy integrating new recent community feedback). So for now I’ll just focus on optimizing my “Trust-less” proposal separately from yours. I hope there will be opportunities later to compare and hone the details.


@acityinohio @tromer Great work on both proposals! I understand that creating / not creating the Trust and having / not having a decision body separate from the existing ZF board for directing the non-ECC/ZF part of the fund are two major differences. But with all these final minute changes, it’ll be quite a challenge for everyone to quickly/clearly comprehend key differences between these and all other proposals.

Would it make sense to create literally a table comparing all active proposals on key points (mining reward allocation, who gets what by default, who decides what happens with the rest, what’s the voting mechanism, reporting requirements, role of coinholders, etc.)?


I would do this, but I am offline for a few days. It would be really amazing if someone else could though.

1 Like

Thanks @tromer, I’m grateful for all the public feedback on this and other proposals that brought this proposal here.

It would explicitly forbid them (and the ZF) from receiving ZF Grants funds, which is less than their requested levels of funding…but (at least to me) it seems like an easier way to avoid the conflict and highly encourage qualified external teams to contribute. By allowing ECC (and specifically ECC employees) to benefit from potential ZEC upside I hope it balances this concern.

I think this is a good strategy, as there are still a few subtle differences here or there and it’s worth keeping them on separate paths for optimization.

1 Like

This is a great idea @mlphresearch, maybe we can do so on the post we make tomorrow to describe all the possible ZIPs for polling purposes? @sonya and I could attempt to do so, though it may be difficult to summarize all the differences succinctly.


I tried to do this before and it was overly complex to sort out, but I think it might be more doable now that there are somewhat fewer and better-specified proposals. Josh, let’s try it in our upcoming meeting.


It doesn’t have to cover every minor detail, just the most important ones such as fund size, basic allocation, caps, who decides, are there elections, role of coinholders, reporting requirements, and unique features, if any. I know that’s already a lot but I think it would be very helpful for everyone.


this is a really great proposal and does indeed dovetail with mine; the terms of the trust could embody the various proposed disbursement conditions

I’d be happy to support this proposal


It doesn’t make sense for those whales to veto when fully shielded landing would be help ZEC price

@mlphresearch brought up some questions to me privately about the authorities/differences of various parties in this proposal and I just thought I’d share here what I shared with him to clarify if there is any confusion.

The trust, the ZF Grant Review Committee, the ZF Board, and the ECC Board are all distinct entities with different members.

The trust is really meant to be “set and forget” and the trustees are only meant to validate that the ECC/ZF are meeting their accountability requirements before disbursement. Their purpose is to validate what can’t be validated on-chain, and to do so in a straightforward way. By virtue of the trust they will be legally restricted on how they can disburse those funds. Think of the trust as a “dumb” smart contract, in a way.

The ZF Grant Review Committee itself will function as part of the Foundation, but with explicit authority over all grant funding from the Foundation (aka the 40% of the fund earmarked for ZF Grants). If this proposal is adopted I expect the Foundation will change the bylaws to reflect this to provide legal backing for the Grant Review Committee’s authority…but even without that change the transparency requirements to the trust will dictate that the Foundation follow through on this promise or face themselves getting defunded.

The ZF Board remains unchanged from my proposal, and remains the ultimate authority for the Zcash Foundation…much like the ECC Board remains unchanged, and is the ultimate authority for the ECC’s internal governance. The ZF Board, like most 501(c)(3)s, has a self-selecting board (board members vote for new members). We previously used an advisory panel to guide the selection of new board members (for Ian and Amber in 2018) and I suspect we’d do something similar again in the future…but it’s at the ZF board’s discretion.


The presence of an ECC member causes difficulties in assigning grants to ECC (even in the absence of competitive third-party proposals). Is that supposed to be allowed?

The “ZEC holders” vote is problematic, and I’m wary about having it determine two seats in a binding way. Especially since, if these are two seats captured (which takes no more than paying interest on a ZEC loan), then the others two seats don’t suffice to mitigate the damage (and there would be a deadlock on electing the 5th, technical member).

This committee, controlling the largest slice (40%) of the Dev Fund, would be of utmost importance, but it seems very difficult to create a robust, independent and qualified one.


One way to do it - of which this proposal is an example - is to try and find a balance between guaranteed pre-allocation (e.g. to ECC and/or ZF), self-selection, coinholder (possibly stake-weighted or identity-based), and perhaps Advisory Panel votes.

Handing all decision-making power to a small group of self-selecting people is definitely an option. It can work, just like relatively more authoritarian societies can work, but only under a special set of assumptions and circumstances. But we should also keep in mind that concentrating too much power out of fear or because the current best alternative is not ideal may easily lead to the broader community feeling powerless and increasingly disinterested. The design of the decision-making mechanism is going to send a signal to everyone who is not part of the core group but still interested in Zcash and its governance. And that signal will influence how they feel and act moving forward.


For additional recent discussion of problems with coinholder voting, see:

1 Like

This proposal has been published as ZIP 1010.