A Grand Compromise/Synthesis ZIP Proposal

Thanks to everyone for the feedback so far and consideration, and those that have offered their points of clarification. A few other points I wanted to address:

@dlubarov you are correct that this incentive would affect our work, which is intentional. Its design goal is to accelerate shielded adoption, with a clear protocol-validated accountability metric, while still giving both the ZF and ECC (and others through the ZF Grants platform) baseline funding for pursuing other important goals.

@mistfpga you bring up some good questions, some responses below:

  • Regarding sell pressure, I honestly am not sure a dev fund would have any effect, since otherwise the funds would go to miners who face the same “save or sell” decision for their operations. I will say that the Foundation has kept a significant portion of ZEC in its endowment and will continue to do so, only selling when necessary to fund USD operations — and the Foundation itself would likely want to hold on to as much as possible if Zcash migrates to PoS for a future potential funding stream.

  • Burning funds does have an effect of benefiting all existing ZEC holders, but the option to burn is a last resort in this proposal / meant only when ZF or ECC don’t meet their obligations set up by the trust. The other options (sent back to miners, earmarking to ZF Grants/not for use by ECC/ZF, sent to another unaligned org, etc.) carry incentive alignment risks that I think are sidestepped by burning (everyone who uses ZEC benefits equally). However I’m very open to hearing other suggestions here, I could have a blind spot here.

  • Re: outside investment restriction for ECC, there are a few reasons I included this but the main one comes down to incentive alignment. This precludes any fundraising activity during the dev fund and prevents outside investors from changing the ECC’s focus during the dev fund while benefiting from the dev fund subsidy. This restriction is meant to honor the ECC’s commitment to be “all in on ZEC.”

@sgp as @tromer and @imichaelmiers suggested, there’s second-order incentives that can benefit from this adoption metric. But it’s not perfect, and that’s part of why it’s diversified into other funding streams with strict accountability requirements.

@mika I’d encourage you to read about restricted donations in the context of 501(c)(3)s. As @tromer mentioned there can be strong legal restrictions in place that would prevent the Zcash Foundation from using these funds for its own or the ECC’s benefit. Moreover, as @Shawn mentioned these numbers are a starting point, but I suggested them based on the majority of other proposals and what I thought would be workable from the ECC and community’s perspective.

Again, really appreciative of the feedback (keep it coming!) and will likely turn this into a formal ZIP later today/tomorrow. :raised_hands:


To be more precise: Tromer is mentioning “a grey area” in the context of restricted donations.

1 Like

@mika, the same “gray area” applies just as well to ECC, which can likewise decide to encourage some activities to happen as external grants rather than undertaking them as in-house work. For example this is the position that ECC took in regard to Windows/Mac support and GUI/mobile wallets (tough it later decided to undertake some of that).

I don’t see any problem with that, as long as the work is valuable and gets done.


Right, ofc!

Why is there something like the Zfnd? What’s their purpose?
It’s there to split power, to prevent the abuse of power. That’s the idea behind decentralization.

So why does this not apply to the Zfnd itself?
You clearly violate these principles by this proposal.
This is something the community should be aware of - it has huge implications.

1 Like

I really get where you are coming from, but I don’t think burn is the right method to enforce/control this system.

That seems almost spiteful at the expense of the community. I know this is not how you mean it. but is it really realistic to expect a for profit entity to do x work, and fail because of y reason beyond their control so no one at the company gets paid, and no potential recompense for work done towards that goal so far?

Couldn’t rolling the fund still exist for when the work is complete, because at the end of the day that is what we want, those goals set out to be achieved.

As an example:
say the ECC failed by 3% on shielded adoption by whatever date, should that mean no one gets paid? if you roll the burn over then you can still award the funds when the work is finalised.

1 Like

Just to clarify the burns don’t apply to the shielded portion, which can be held in escrow until the conditions are met:

But in general thanks for suggesting this @mistfpga; in the case of burns in general (which should only occur if there’s a violation of the agreement set forth by the trust) maybe it’s better for those funds to be redirected to outside contributors? (i.e., to ZF Grants) Even if one of the violating parties is the Zcash Foundation, the grant funding would be earmarked/restricted (aka forbidden from being used for any other purpose) and it would still represent a punishment to the offending party. What do you think?


I like the idea because it does not take coins out of circulation. In another thread it was mentioned that the “trusted third party” system could be gamed. and Im still not sure if 1-1,2-2,1-2,2-3,57-96 etc is best. Could a portion of the funds (lets face it, yes we want things to happen in a timely manner, but stuff does happen.) be kept for the work done and given to the team.

So using my previous example:
3% adoption rate can be achieved within 2 months of actual deadline. The company/foundation should have the option to self fund and get all the funds. (which is why I saw an issue with the “no other revenue streams” - but your point makes sense on that)

If this is not realistic say only 50% adoption has happened, then 50% of the funds are held for when the condition is met and 50% of the funds goes to a grant to fund the rest of the development of feature x - the offending party is incentivised to do this and help the process because they will get a reward much greater than the assistance they will need to give, the new team is incentivised because of the reward. more people will learn the skills needed.

This is just spit balling now. I am trying to take my mind off the work I am supposed to be doing but am not doing.

no funds are taken out of circulation is the key thing for me.


Being a 501©3 nonprofit has some advantages here.


Just an update, agreed with this and will update my proposal above in a manner that is consistent with this philosophy. Working on reformatting for formal submission as well.


More formal proposal below:

  ZIP: ???
  Title: Compromise Dev Fund Proposal With Diverse Funding Streams
  Owner: Josh Cincinnati <josh@zfnd.org>
  Credits: 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 reward for 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, ties some of the payouts to shielded adoption, 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.
  • Based on the ideas brought forward by Eran Tromer, a portion of the funds directed to the ECC / Zcash Foundation should be based on shielded adoption, which is the most pressing issue facing Zcash today and unlike many other metrics is both easily measurable and less likely to be gamed. (compared to a miner-signaling proposal for example)
  • 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.
  • 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)


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:

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

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

  • Up to an additional 4% to the ECC proportionally based on average amount of shielded value (scaled to 80% shielded as “fully shielded”) over total supply over the last 105,000 blocks, with the remainder held in escrow until Zcash is “fully shielded” for at least a month

  • Up to an additional 4% to the Zcash Foundation proportionally based on average amount of shielded value (scaled to 80% shielded as “fully shielded”) over total supply for the last 105,000 blocks, with the remainder held in escrow until Zcash is “fully shielded” for at least a month

  • 4% 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. For the first quarter/simplicity’s sake, let’s assume that 20% of the total value was shielded on average and that both the ECC and Zcash Foundation met the accountability requirements set by the trust. Then disbursements would look like this:

  • 13125 ZEC to the ECC for meeting accountability requirements

  • 13125 ZEC to the Zcash Foundation for meeting accountability requirements

  • 13125 * minimum(0.2,0.8)/0.8 (80% considered “fully shielded”) shielded adoption = 3281.25 additional ZEC to the ECC for shielded adoption. 9843.75 ZEC would be held in escrow by the trust until Zcash is “fully shielded” whereupon the balance will be disbursed to the ECC.

  • 13125 * minimum(0.2,0.8)/0.8 (80% considered “fully shielded”) shielded adoption = 3281.25 additional ZEC to the Zcash Foundation for shielded adoption. 9843.75 ZEC would be held in escrow by the trust until Zcash is “fully shielded” whereupon the balance will be disbursed to the Zcash Foundation.

  • 13125 ZEC to ZF Grants to be disbursed to external individuals and organizations (via the Zcash Foundation as a restricted donation)

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 a 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)

  • 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 portion of the dev fund went into speculative investments in other companies 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.

The shielded adoption metric

I applaud Eran Tromer’s suggestion for tying some portion of the dev fund to shielded adoption. It’s a great tool for adding a protocol-verified accountability metric and I hope it’s considered in many of the other proposals as well. My particular adaptation of it provides for some floor of funding for both the ECC and Zcash Foundation, while providing a variable payout based on shielded uptake (scaled to 80% as “fully shielded” to incorporate the possibility of lost value in transparent balances and protect against a single entity holding veto power against shielded uptake). Rather than reward the remaining ZEC to miners — which could cause perverse behavior where miners might censor shielded transactions — the trust would hold the remaining ZEC in escrow, to be paid out to both organizations in lump sum upon reaching a “fully shielded” world during the next quarterly disbursement.

I define the “fully shielded” condition as follows: we have 35,000 sequential blocks where the shielded value pool is 80%+ shielded for that same time period. The bonus can be held until after the dev fund expires, though I certainly hope we’ll reach that condition before then.

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; instead, the trust MUST demand that the ZF Grants process expand its decision-making process and include broader input. 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).

In terms of selecting those third parties, I don’t have a silver bullet…which is very much the issue with “third party” selection in general. However, I think the Foundation’s Board election last year was a pretty good model. One possibility is to have a more open community advisory panel next year and follow the same steps for those three seats, and rotate them yearly — perhaps eventually changing the vote to originate from the shielded pool instead of an advisory panel. Those grant reviewers would be charged with judging new grants and selecting RFPs on a weekly basis, and the Foundation would be charged with administering their decisions. The Foundation could also chose to fund ZF Grants beyond the restricted donations from the trust, but doing so would be at their discretion.


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 finds 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, and assumes an eventual 2-of-2 agreement on the trademark and 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), while it doesn’t preclude the possibility of migrating to broader “2-of-3” later on.

Why a trust?

The main reason: reducing complexity creep in consensus code so the ECC and Zcash Foundation can budget for other features in NU4. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 deadline 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?
  • Who bears the cost of running the trust? (I think jointly split between the ECC and ZF makes sense)
  • Should the trust own the Zcash trademark? It could effectively function as a 2-of-2 agreement between the ECC and ZF.
  • Is there any way the shielded adoption metric could be gamed?
  • Are the amounts reasonable? Should the dev fund be less than 20% in aggregate?
  • How do we select representatives for the ZF Grants 3-of-5 body that aren’t from the ECC or ZF?

It would be I presume a split interest trust as an irrevocable charitable lead Trust, the miners should be able to claim the Development Fund to the foundation on their taxes as a charitable donation since the beneficiary payments would be recurring within those people’s lifetimes, the trustees would certainly have to file annually for records and operating costs (I think the split idea is neat :+1:)
The trustees would need subjected to a rigourous screening to ensure competence with trust oversight, legal consequences are good but avoidable mistakes do happen [Emphasis]
I (still) support %20
The trademark, shielded adoption metric and screening process (for the trustees and ZFgR’s) Ill think on, idk at this time

This proposal Is extremely well specified, answering these questions are the only input I could really think of (well done Jim!)

Something to consider however is the tax liability for the trustee of appreciated and depreciated value while it sits in the trust, this might have to be included in the split operating cost idea (or the trustees would allocate %X for costs which may or may not be more problematic I’m not sure)
This does present an interesting situation for the miner as well in regards to the value of their contributions in factoring when they actually occur, the easiest way would be to calculate it with the appropriate % to income fair market value but thats an assumption ( it seems pretty unrealistic for a pool Miner to calculate their individual per block micro contributions especially with the inconsistency of finding blocks and variable hashrate I don’t think it’s even feasible)
The trustees would have to adhere to perfectly recording every payment which we assume here is on a per block basis
Given the trustees never actually realize any gains or losses I wonder what their obligations actually are
Answer- they vary widely, this is complicated

So there are provisos that allow the trustee to deduct the full cost of capital gains or losses in their (the trusts) income from funds dispersed to charity organizations, non charitable recipients would be subject to the gift tax law where they would be responsible for calculating their own capital gains and losses depending on when the fair market value is determined (which isnt always at the same place)
The trustee might (depending on how an origin is determined) have a gift tax liability to fulfill which would need to be allocated for in expenses, this could come from corpus but would then not be deductible and should not be allocated against the unitrust amount which could disqualify the trusts status (need specification on that, also assuming a unitrust model, need specification)

“There are a few, uh, ''provisos” , a couple of quid pro quos!"

No, the money doesn’t come from the miners, it comes from all the coin-holders. The ZEC comes from nobody — it is created out of thin air by the protocol — but the value in the ZEC comes from all the buyers and sellers, and that means every added unit of value that the recipient receives means exactly one unit of value lost by all current coin-holders.

Bottom-line: the coin-holders should be able to claim the Development Fund to the foundation on their taxes as a charitable donation. :slight_smile:


Good luck with explaining this to the IRS in your tax declaration ,lol.


(Declaration, Alex)

I would argue that the value comes from the buyers and sellers but Zcash itself is created out of thin air by electricity and expenditure of this resource doing the work is what counts


Someone could even add hardware costs and working hours to these expenditures as electricty alone is not doing the job.

1 Like

Yes those things can be deducted, large miners especially will calculate those savings

1 Like

Economic value is created by demand. You can make hardware investments until your face turns blue, but they won’t translate into value unless people want to buy the coins. That’s where the value comes from — the demand on the other end.

It’s like how unearthing any random rock doesn’t make that rock valuable, no matter how much effort was required to find it. It has to be a rock that people want enough to pay for it.

Miners’ activity secures the network, which is prerequisite to ZEC having value. But miners are not the source of that value. Rather, ZEC’s functionality is, because you can use it as a tool or make a speculative bet that others will want to use it in the future.

Ergo the value comes from the coinholders (which does include miners who HODL rather than selling, whether partially or entirely).

Edit: After having written this, I’m not sure anymore. Counterarguments?


Then it would help if there arent any rocks like that laying everywhere around people, with truckload of new ones being unloaded every month

I’m simply arguing who would have claim to the charitable deduction from the allocated % of rewards would (probably) be those persons who have claim to the rest of the tax obligations

If I opted in to donate some of the money that I made from my job to a charitable cause it would not give you the right to claim it simply because you buy and sell things or use with the same kind of money
We would need to know everything about every zcash user in order to provide the necessary information to accurately calculate what their individual percentages would amount to

1 Like