Placeholder Considerations: Resources, Governance, and Legitimacy in NU4

Attention! This proposal has morphed into a ZIP draft, discussed in a separate thread.

Original primer post below:

In October 2020 the Zcash network will undergo its first halving, slicing the annual rate of ZEC inflation in half. Halvings are important moments in any cryptomoney’s maturation as they double the marginal cost of producing each incremental unit (at constant hash rate), moving the asset further along the scarcity curve. Concurrent with this halving, Zcash will undergo its fourth network upgrade (NU4), in which key decisions (especially re: the Founders Reward) need to be made that will shape the next four years of Zcash’s life.

For those new to Zcash (not many noobs on the forum, but just in case!), the Founders Reward refers to the 20% of newly minted ZEC supply that goes towards Zcash founders and software development, with the other 80% going to miners who maintain the network’s hardware and ensure its security. This bifurcation differs from Bitcoin’s choice to allocate 100% of newly minted BTC to hardware security. The term Founders Reward is not entirely representative of how the 20% ZEC is used, as witnessed in the breakdown of Zcash’s monetary policy below:

Right now, the default plan for NU4 is to discontinue any allocation for software development and revert to Bitcoin’s design of 100% newly issued ZEC to miners. If, however, the community decides it would prefer to continue allocating 20% of the block reward to software development during the 2nd coinbase reward epoch (totalling 5% of fully-diluted ZEC supply), then a number of decisions need to be made about the allocation and governance of those funds [1].

As ZEC coin holders, Placeholder recognizes that NU4 will be a critical upgrade for the Zcash network, and therefore have chosen to submit our thoughts about its contents. Since it’s our first “formal” participation in the Zcash community, some explanation could be helpful:

While members of the Zcash and Placeholder teams have known each other for years, only in 1H 2019 did Placeholder build a position in ZEC. The timing of our ZEC purchases was market driven, but the choice to work with Zcash was underpinned by the belief that privacy will become a critical feature for users, retail and institutional, by the end of crypto’s second decade. Zcash’s privacy team is second to none amongst its cryptonetwork peers, and given the Electric Coin Company (ECC) and the Zcash Foundation (ZF) have demonstrated a credible commitment to fairly evolve network governance, participation seemed like a natural fit for Placeholder. Prior to the purchase of ZEC in the open market, Placeholder had no formal relationships with the ECC or the ZF, and nor do we plan to pursue any. We’ve been engaged in conversations with both, but are not here to pick sides. We view our interests and governance rights as identical with that of other coin holders, big and small, and hope that together we can come to agree on the best upgrades for the network.

In our efforts to understand the current state of the community leading up to NU4, we found ourselves resonating with the sentiment behind Andrew Miller’s recent Notes on reaching agreement about a potential Zcash dev fund [2]. We encourage anyone who hasn’t read that to do so before proceeding here. What’s important to take from Miller’s piece is that Zcash is in a strong position after its first four years, and so we have the liberty to make clear-headed decisions in NU4. Most importantly for Placeholder, and here we echo Miller, decisions around NU4 need to be legitimate in the eyes of the community as a whole.

Beyond legitimate, we also hope to be able to approach NU4 as exactly that, an upgrade. With this upgrade the community has an opportunity to re-evaluate and redesign parts of the network’s policies to work best for all members. It is only natural that, as the network matures, the optimal allocation of its resources also evolves. Optimal allocation means that funds are disbursed efficiently and with purpose, without excessive allocations to any single party, to ensure that work necessary for the long-term success of the network is appropriately compensated.

If this conversation is of interest to you, it’s important you weigh in sooner rather than later, as August 31, 2019 is the deadline for Zcash Improvement Proposals (ZIPs) that want to be considered for NU4, and October 31, 2019 marks the date when the feature selection for NU4 must be completed. For network upgrade pipelines and dates, see here.

Placing Zcash in Context

Zcash sits comfortably in the spectrum of monetary and fiscal policy experiments currently visible in leading cryptomonies. Placeholder has taken an interest in Zcash in the context of already being highly active participants in the Decred network and passive hodlers of bitcoin. The image below depicts the differences between the three in terms of supply-side compensation:

Bitcoin is the most minimalist with its incentive structure, optimizing for hardware security in the form of miners only. As witnessed in the SegWit saga and the emergence of user-activated soft-forks, governance of the Bitcoin network appears to be controlled by full node operators, though some would still contend it’s the miners with the upper hand.

Zcash considers both miners and builders to be supply-siders of the network and makes room for the builder incentive by cutting miner’s incentives by 20% from Bitcoin’s benchmark. On a relative basis, between the three networks, Zcash allocates the lowest percentage of coinbase rewards to security, but it does so by allocating the most to the builders and protocol development. That means we, as ZEC holders, should be getting the most out of the Zcash builders as we are paying for it with supply inflation.

To date, governance of the distribution of the builder subsidy has been transparent but without community’s participation. The controls of the ECC and the ZF are still in the process of being decentralized and encoded (the extent to which they are on-chain is still to be determined). While allocating the least to security may sound alarming, Zcash still allocates 80% of all newly minted ZEC and all transaction fees to security which, judging by the healthy hash rate growth depicted below, does not appear to be insufficient:

Turning to Decred, it has three sets of supply-siders it compensates: the miners as with Bitcoin and Zcash, builders as with Zcash, and a new entity in the form of the stakers. Decred’s stakers put a voting check on miners per Decred’s hybrid PoW / PoS security design, and also govern protocol upgrades and disbursement of the network treasury financed by the 10% that is allocated for builders.

While Zcash has a significant amount of “off-chain governance” between the ECC and the ZF, Decred has more of its governance made explicit in the code. As part of NU4, we expect Zcash to begin walking the path towards increased decentralization and governance formalization, with the ECC reducing its control and becoming one contractor among others. That said, between Bitcoin, Zcash, and Decred, Zcash’s current governance design is the most familiar to existing institutions, potentially making them more comfortable using Zcash’s public network or collaborating with the team, as evidenced by the JPMorgan research partnership. Institutions wanting to use public networks will likely need to do so while keeping transaction data private, making Zcash a natural fit. Therefore, while maintaining a more traditional governance structure may be interpreted as a systemic risk by crypto-anarchists, it might actually be a strategic advantage for Zcash and therefore should be a background point of consideration in these conversations.

A side note about Zcash’s Founders Reward: we’ve noticed a tendency for polarizing conversations around the compensation of Zcash’s founders. In the hopes of de-polarizing, we will turn to numbers which we can all agree to as fact. In the 4 years leading up to this first halving, 50% of ZEC’s total supply of 21 million units will be issued, meaning Founders and Vested Employees are slated to earn 6.4% of the ZEC that will ever be in existence (50% of 12.8%). However, in June 2019, all Founders and Vested Employees took a dilution to provide more funds for protocol development (at that time ZEC was in oversold territory at $40-60 per unit, placing the ECC in an operating deficit). In total, the dilution places Founders and Vested Employees as slated to receive 5.8% of the fully-diluted ZEC, as described in detail on p. 13 of the ECC’s Q2 2019 Transparency Report.

To place Zcash compensation in the context of the rest of crypto, we can use Nic Carter’s University of Edinburgh Master’s Thesis, A Cross-Sectional Overview of Cryptoasset Governance and Implications for Investors, which analyzed the launch types, founder allocations, corporate support and more, of the top 50 cryptoassets by network value on July 29, 2017.

Below is a table from Nic’s cross-sectional survey, which includes Zcash and a column dedicated to investigating Founder Reserve norms [3]. In his analysis, Nic found the median for founder’s reserves to be 15% of total supply and the mean to be 19.68%, ~2.5x and ~3.4x greater than Zcash’s Founders Reward [4]. When we overlay the fact that some of Zcash’s founders have been working on digital currency implementations for longer than many crypto participants have been alive, we find complaints about their 5.8% allocation to lack perspective.

Lastly, for those who can’t stand the idea of more than 10% fully-diluted ZEC being allocated to funding protocol development, there is Ycash (YEC), an upcoming “friendly fork.” Slated to occur on Zcash’s 570,000th block (roughly July 18, 2019), the Ycash network “will reduce the Founders Reward rate from 20% to a perpetual 5%, which will exactly preserve the original 2.1 million coin cap on the Founders Reward.” If people believe the Ycash model is better, they are of course open to convert their ZEC into YEC.

With the above as context, let’s turn to the practical decisions the Zcash community must make in the coming months.

Making the Decision about the Decision

As we mentioned at the beginning, it’s important to the network’s long term health that there be general consensus on the legitimacy of the decision-making process, as well as the decisions themselves. As part of a legitimate process, the community’s opinions should be collected and quantified so that the network can get a decent snapshot of its preference before NU4 decisions are made final.

Obvious possibilities for gauging community preference include miner signaling, Twitter polling, email or forum surveys, but none of these information sources are trustworthy or representative enough to be binding. While using more complex voting systems such as Decred’s Politeia has been discussed, designing and implementing such a system in time for NU4 is not realistic given these decisions need to be made in the coming months. Therefore, until a more complete and credible solution is developed, the focus should be on polling as opposed to voting.

The design of the polling system should be carefully considered to ensure that the outcome is as informative as possible. For example, as has already been suggested, a one-time poll in which each respondent has to choose between a potentially large number of options runs the risk of not identifying the most widely supported proposal. In theory, a series of elimination polls in which the least supported proposal is dropped after each round until only two remain would more accurately highlight the community’s preferences, all things considered. Of course, introducing such additional complexity must be weighed against technical, time and other constraints, but given the importance of the decision at hand, a basic one-time poll to gauge relative majority could be insufficient.

Once polling is complete, we expect decisions about NU4 to be made via the 2-of-2 multisig controlled by the ECC and ZF. It would be preferable for the two organizations to gather and quantify community input independently, but there are practical considerations regarding community fatigue and ECC + ZF resource-constraints. Regardless of how information is gathered and quantified, we’d expect both organizations to provide public statements on the rationale behind their votes, taking into account the community’s expressed preferences.

For those that may object to the 2-of-2 multisig being too centralized, we would point out that the ZF has done a “notably good job” (our words and Zooko’s) of remaining independent and avoiding governance capture by the same individuals who control the ECC. This has been clear in both public communications and private conversations we’ve had with both groups.

Now that we’ve covered the process, we turn to the details of the 2020 decision.

Revert to Bitcoin’s approach: 100% to miners

If 100% of supply were to go to miners, then from 2020 onward the network would have opted for a rules-based monetary policy with little discretion. With no new funds coming in, there is less discussion that would need to be had about the governance of funds set aside for protocol development. Some would argue this is a strength as it leaves fewer vectors open for attack, but we think it would create more problems than it solves at this stage of Zcash’s development.

Modest funds would remain on the balance sheet of the ZF, but the most important discussions would need to revolve around the path forward for protocol development as there would no longer be explicit compensation for the work being done (for ECC or anyone else). While Zooko has expressed he intends to remain committed to Zcash protocol development regardless of the outcome, the ECC would inevitably need to supplant the income that it had been receiving from coinbase rewards with diversified business models. This would inevitably pull focus and resources from Zcash R&D and maintenance.

Non-block reward based, non-profit funding (e.g., donation) for development is also possible, as witnessed in Ethereum’s current MolochDAO efforts or Grin’s recent call for financial support. But as pointed out by Lane Rettig at Zcon1, Zcash’s NU4 choices placed in the context of Ethereum represents a somewhat ironic symmetry, as Ethereum is currently working through how to properly compensate their core developers precisely because they lack a recurring and native funding pool. Many other mining based networks have also turned to the donation avenue over the years, and while quality projects typically find a way to make ends meet, we do not view these situations as optimal as they tend to be resource constrained.

In our opinion, therefore, reverting to Bitcoin’s approach and sacrificing block-reward funding is not the optimal path. Not only does it make Zcash look awfully similar to Ycash (putting the two more directly in competition), but it also concedes control over an available incentive pool for some of the world’s best cryptography talent to continue work on Zcash.

Provided there’s proper governance over the treasury, a partial allocation of the coinbase reward to software development feels like the cleanest solution. It’s denominated in the network’s own asset, thus aligning interests better than external, fiat-denominated funding. Since the network becomes better capitalized the greater its utility and asset value, the community 's resources grow with network success. In other words, it rewards success with more resources for further success. On the other hand, if the network is hardly used and ZEC plummets in value, there will be very little value to fund development and few people that the ECC or ZF can employ-- incentive alignment!

Stay the Zcash Course: 80% to miners, 20% (?) to builders, evolve fund governance

In this case, 20% would continue to be allocated to protocol development, but control over these resources could be re-designed as part of NU4. In particular, areas where the governors are able to direct capital back to themselves must be given special attention, as incentives may skew towards the governors’ best interests as opposed to the network’s. One can view this as a principal-agent problem between coin holders, the ECC, and the ZF.

If the community agrees with this path forward, then by the end of October 2024 (Zcash’s eighth year), 15% of the fully-diluted 21 million ZEC will have been allocated to software development, with the remaining 85% destined to be earned by miners. Of course, if a decision to extend this 20% allocation is made as the community approaches Zcash’s third coinbase reward epoch, then it would mean 17.5% of all supply would end up being allocated to protocol development. At this cadence ad infinitum, the theoretical maximum is that 20% of all ZEC supply ultimately goes to the entities behind software development.

That said, as has been raised numerous times on the Zcash forum, it is still an open question of whether 20% of the coinbase reward is the right allocation for software development in the second coinbase reward epoch, or if it should be dropped to 10%, with 90% going to miners. At current market prices of ZEC, a drop to 10% when the rate of supply inflation is already getting cut in half due to the halving would place the ECC and ZF under operating constraints and require scaling back current efforts.

Lastly, we would be remiss to not mention that part of the opportunity here is the ability to adjust the balance between rules and discretion in Zcash’s governance, in the hopes of solidifying its long-term legitimacy. Rules help establish time-consistent credibility of any monetary asset, while discretion optimizes for short-to-medium term flexibility.

With these factors in mind, we submit the following for consideration:

  • 20% of the coinbase reward continues to be allocated to software development, but is split into “Protocol Development” (70%) and “Growth Funds” (30%). It’s an open discussion of whether these two funds should be governed through the same or different mechanisms. Additionally, we’re not attached to the 70/30 split. In fact, better analysis of what the optimal split would be based on anticipated ECC and Zebra budgets (protocol development costs), versus anticipated demand for growth funds, would be helpful in the search for the optimal split. Should it turn out that one pool is significantly overfunded in time, there is also always the opportunity for that pool to vote part of its funds over to the other pool.

  • Governing Protocol Development funds: We’re comfortable with this initially being governed by the aforementioned 2-of-2 ECC and ZF multisig, though encourage exploring more representative designs. Zooko’s recent Zcon1 comment that he “likes proof-of-stake” combined with active community conversation re: PoW / PoS hybrid designs, leaves open the possibility of future governance involving voting stakeholders beyond the ECC and ZF.

    • In each period the applying teams should include key research, development, and maintenance milestones, which are not only reviewed prior to the current funding, but also returned to in the proximate funding to keep track of how credible each team has been over time.
    • Funding should be approved on a semi-annual or annual basis to provide stability for the core development teams. It’s also possible to align each funding period with NU’s, where if a NU is delayed the team doesn’t automatically get more funding, but would have to apply for an extension with explanation of why target dates weren’t hit for that NU.
    • Importantly, the ECC - responsible for zcashd - is not the only team that should have access to these funds. For example Zebra, a recent Rust implementation of Zcash written by the Parity team and handed over to the ZF to develop and maintain, will also require resources. Security audits and any other expenses strictly related to protocol development should also be covered by this pool.
    • Since each approval of funding should be for a concrete USD amount, were ZEC to appreciate considerably, the developer funds could accrue significant value beyond the current cost of development. In this case, the excess ZEC would not be claimable or allocated as a bonus, but rather saved for future rounds of funding. This would address the concern around the development teams getting under- or over-funded due to swings in ZEC/USD exchange rate, and ensure a more efficient use of funds.
  • Governing Growth funds: The governance of these funds could follow the same path and principles as that of protocol development funds, but given this represents a minority of the coinbase reward, we also believe a more experimental design could be chosen. If effective, and once hardened, such a design could then be used to also govern the “Protocol Development” funds.

    • There’s already the ZF Grants Program, and the proposed 30% growth allocation could be routed to this existing program, which already has a defined process.
    • If there’s appetite for experimenting beyond the 2-of-2 multisig or ZF Grants’ existing process, such experimentation could involve:
      • A small committee of diverse and identifiable individuals with a 3-of-5 (or similar) multisig. Many examples of this exist in the crypto market today.
      • A 2-of-3 multisig with a seat for the ECC, ZF, and aggregate coin holder vote. This is a hybrid option between the above and below, where the community serves as tiebreaker in cases where the ECC and ZF diverge.
      • An implementation of purely on-chain voting, with Decred’s Politeia and decentralized treasury management the best example. This design is the most complex, and warrants an entire post / discussion of its own if ultimately chosen.
    • While the cadence of decision making will vary depending on the governance design chosen, it’s important these funds be adaptive to market needs, making a quarterly decision likely the slowest desirable cadence.
    • Ideas for growth funds are vast and fall into broad categories such as wallets, application interfaces, liquidity/exchanges, education, marketing, events, and more. The ZF has some good first blush needs here as part of its ZF Grants Program. We note that there’s the possibility for contention/confusion over where the “protocol ends and the growth begins.” For example, is the currently listed “Lightning Network integration for Zcash” a protocol fund proposal or a growth fund proposal? The potential confusion is one argument against two funds. An alternative would be to focus instead on bolstering the process around a single fund that has two focuses.
    • Growth funds could be disbursed in the form of grants, prizes, or investments. Thus far the ZF has chosen grants as its preferred model, but for the sake of completeness we’ve included a summary of the key differences between the three below. We hope this invites more discussion from the community on what’s optimal for these funds from here on out, as a mixture of strategies can be used:
      • Grants: individual entities apply with proposals for work they deem important and are approved/rejected before the work has been submitted. Assets go one way from the fund to the accepted team(s), and while control over funds can be metered according to milestones, there is typically little recourse in the case work is left incomplete or below expected quality.
      • Prizes: the governing group runs competitions around needed work, with one team selected for compensation after the work has been submitted. A benefit to this approach is more work is submitted per dollar allocated, as multiple teams submit solutions to the same problem, and due to the nature of the competition incomplete work is simply not considered for compensation. Assets again go one way from the fund to the accepted team(s).
      • Investments: individual entities are funded but assets are exchanged between the fund and the team, be they traditional equity instruments, cryptoassets, etc. While there is more governance and recourse in these arrangements, and they can compound the growth fund’s balance sheet, they also come with more complications than the other two options, which again would warrant dedicated discussion. That said, it’s common for foundations to grow or maintain their principal via investments, while concurrently doling out grants to fund mission-related efforts and meet tax obligations (more on that here). Managing the principal of the growth fund (and protocol development fund, for that matter), could be important for the long term sustainability of software development as Zcash’s rate of inflation continues to halve every four years.
  • No further “investment allocations” to Zcash founders in the 2nd coinbase reward epoch: As already discussed, the Zcash network is four years old and those that helped get it off the ground have been sufficiently compensated with 5.8% of fully-diluted ZEC supply.

  • We expect the process around NU4 to inform the design of standard, semi-formal methods for gathering input, measuring sentiment, and implementing the preferences of the Zcash community. While not every decision will require as formal a process as NU4, it is important to have the appropriate structures in place for future situations in which broader participation is required. There will be no excuse for not having these systems if we are at a similar crossroads leading up to Zcash’s second halving.


In the ZF’s own words, “Governance fundamentally consists of three questions: What should we do, who gets to decide, and how are the deciders chosen and held accountable?” As we ponder Zcash’s next four years, everything boils down to answering these three questions in a way that the community as a whole accepts as legitimate.

If the above proposal is well received, there’s the possibility Placeholder converts it into a ZIP, incorporating community feedback in the process. If this came to pass, it would be our preference to collaborate with others on the ZIP (or hand over the ZIP entirely). We’ve never navigated the ZIP process before, which feels less than ideal given the gravity of the decisions that are likely to be made.

Thanks for reading to the end, and let the discussion continue!

[1] A coinbase reward does not refer to the company, Coinbase, but rather to the coins issued as reward for new block production. The term block reward is more common, though the two are not synonymous. A block reward refers to both the coinbase reward and the transaction fees associated with the transactions included in a given block. This paper is primarily concerned with the coinbase reward, not the block reward, as we believe miners should continue to receive all transaction fees, though there has been some discussion on the Zcash forum about using transaction fees to finance software development.
[2] Andrew Miller is an Associate Professor at the University of Illinois in Electrical and Computer Engineering, Associate Director of the Initiative for Cryptocurrencies and Contracts (IC3) and a board member of the Zcash Foundation.
[3] The Zcash column for Founder Reserve reads 0% in Nic’s report but in reality should be 5.8% – for a future college student to incorporate :slight_smile:
[4] Not even pure mining networks can always claim a more equitable distribution than Zcash. Especially as earlier in crypto’s history (when lots of the currently dominant cryptomonies were born), pioneering miners or founders would amass large amounts of the coin by mining extremely early or before broader release. These positions sometimes represented double-digit percentages of fully-diluted supply, and the network received little in compensation beyond a massive mining whale or covertly enriched founder(s).


As you formulated and wrote a very well written proposal, or condiderations as you name it i hope it’s ok to ask some questions and comment.

1.) Currently with the Founders Reward the Founders/Employees receive the Founders Reward and than donate a percentage to the ECC. In my opinion this is an interesting experiment but it has more flaws than it has positive points. What would be the distribution of a new developement reward? Same?

2.) Isn’t it of any concern for “placeholder” that there is an ongoing law suite with an ex-employee where shares/distribution of the Founders reward is part of it? And of course the dilution of the founders reward towards ECC?

Nic’s whole research is a must read and we can find a lot of usefull information there, without doubt. But there is as well a lack of deeper or wider research, mostly because it’s from 2017.
Some questions that arise with the cross -sectional survey I and II are:

  • it doesn’t sum up how much a given founders reward, ICO, whatever funding, has generated in US$.
    Means in theory a given ICO at the start of 50% (just as an example) could have generated $10M for example, but a 5% continous Block Reward (Founders Reward) could have generated $500M. As ssaid, just as an example. This means while the percentage of Nic’s Chart than back have been mostly correct than back it doesn’t tell us anything about the amount of funds a development team has received to reach it’s target. Without this factor this chart has only limited value.

It’s not that easy for the community. Just because someone or a group of people doesn’t like the whole idea of a contioued dev fee, and/or propose to consider other funding sources or even a hybrid mix of different proposals as well shouldn’t mean exactly the Ycash one-man-show should be the alternative.

+1, absolutly agree on this one. This should be a MUST having in mind the importance of such decision.

A project without own tech can’t be called competition seriously. Just as a sidenote. If you replace Ycash with another privacy project and own tech like Monero i fully agree of course.

How is this provided and controlled havine a for-profit company as the recepient with limited transparency? An important factor in the whole dev fee discussion (at least for some).
Why not the foundation with bigger transparency options having the recepient and having the foundation allocating needed funds to the ECC? What are the arguments against this variation to ensure proper governance over treasury and control from/through the community?

There are several points why i don’t fully agree to this argument:

  • When the ECC run with a deficit the ZEC exchange rate was $60 or lower if i remember right, currently we are $100.
  • With the current Founders Reward there are expenses that shouldn’t be anymore the case with the new dev free, for example advisor, early founders and so on … This should mean more funds in % are available for the ECC development anyway compared to the current situation with the Founders Reward.
  • The halving won’t cut only block rewards, there is a big chance, even i’am not yet a believer of this, that the effect would/could be compensated by a price rise. Or at least partially, which again would lead to at leat partially more funds available for the ECC even if it’s just 10% or any given number.

Of course we do not know where the price goes so it could work out either way. Having way too much funds available or not enough funds. Wouldn’t here some kind of dynamic funding system versus US$ fit better and have the ECC safe? For example the Dev Fund gets adjusted monthly and correspondents to a $1M value per month from the generated dev fund. $1M can be replaced with whatever value the community thinks is fine.

Makes me remind Nic’s figure 4:

Any improvement to this governance model or should it stay like this?

+1, absolutly agree on this one!!!

It was an interesting read for sure, no matter i don’t agree to some points or have some concerns, much if not most makes just sense. Interesting to see if there will be indeed a discussion.


Hi @cburniske, thank you for contributing to the Zcash community!

This is an excellent post and I really appreciate how you’ve positioned Zcash within the ecosystem for context.

I hear you that participating in the ZIP process seems like it may be too heavyweight or involved. In fact, that’s a concern expressed in many of the dev-fund related proposals found in the protocol proposals section of the Forum.

One of my intentions is to ensure that we don’t let the ZIP process be a barrier to anyone in the community formulating and advocating for their own proposals, so we’ll be reaching back out to you and other proposers to simplify and clarify that process.


Thank you for these. Below I address most all of them, in order:

The distribution of a new development reward could be 70% Protocol Development Fund (2 of 2 multisig for now), 30% Growth Fund (2 of 2 multisig or sleeved into ZF Grants Process, with more experimental structures available). The 70% Protocol Development will be open for ECC to apply to, as well as the team from the ZF that maintains Zebra, not to mention any other full node implementations in alternative languages. As mentioned in the doc, “Security audits and any other expenses strictly related to protocol development should also be covered by this pool,” which is likely another independent set of entities.

The 30% Growth Fund is then even more widely available to the public, with Decred’s Politeia as a good example of what is possible here (sans the protocol / Company0 proposals that go through Politeia).

(this is all described in more detail in the Stay the Zcash Course: 80% to miners, 20% (?) to builders, evolve fund governance section)

We can discuss with the ECC the current state of affairs, but atm this is not a concern.

Nic Carter’s Research

Re: your points for improvements of Nic’s cross-sectional survey, I appreciate the thoroughness but am going to leave that conversation for elsewhere :slight_smile:

Fair enough, I agree a community divorce/fork is tough and shouldn’t be referenced as an option as casually as I did.

We agree. IMO the series of elimination polls for boiling down to the community’s proposal of choice is one of the most important recommendations we make about a practical yet accurate approach to distilling the community’s preference****

Wasn’t my suggestion, was Mario’s (Placeholeder’s Governance Researcher), who may have got it from somewhere else…

For legal reasons the ZF does not want sole discretion over the movement of the network’s funds, therefore it has to at least be a two signature situation. We think having the ZF and ECC vote together is better than just the ECC, and do not believe the ECC has “captured the ZF.” In cases where there is a similar Foundation + for-profit Core Company structure in crypto (which we all know is common after 2017!), Zcash’s Foundation is one of the most independent Foundations I’ve encountered in crypto

Beyond that though, you are getting at important points. I do think we should push for the Growth Funds to be more decentralized in their governance first (with a path to on-chain voting?), and then move on to further decentralized the Protocol Funds second (perhaps with the Growth Fund model which has by that time been hardened within the Zcash system).

Part of Placeholder’s push in this proposal is precisely to increase the controls and transparency of resource flows within Zcash. This is not to knock the effort thus far, ongoing examples (with the Q2 2019 Transparency Report a good recent one) are part of what convinced the Placeholder team that the ECC and ZF are committed to credibly evolving the governance and transparency of the system over time, and thus got us involved.

You raise a few points but they all seem to boil down to fear about an inefficient allocation of ZEC (either deficiency or excess). I think it’s an interesting idea to have a dynamic monetary policy based on USD spend of the different entities tapping the funding pool(s). That said, my fear at this stage is dynamic but automated monetary policies are still at the forefront of research and I’m not sure that this coinbase reward epoch is the right one to try to implement such an approach. But maybe funds could be allocated from the Growth Fund to R&D around this effort (or would it come from the Protocol Fund? Guess it’s at the applicants discretion…)

A second option, though not as nifty as yours, is the fixed division of resources again between hardware (miners) and software development (builders). I like sticking with this (for now) for its simplicity, and also time-consistent assurance to different economic agents (this includes both the miners and builders) of the resources they stand to gain from contributing to the system.

We cannot possibly speculate on ZEC’s price with precision, but we can know the budget of the teams pretty well in advance in USD terms. My thinking is after each period, and in a macro sense at the end of the 2nd coinbase reward epoch, if there is a situation where either fund has leftover ZEC, then it will just roll over into future years of allocation. The funds are never zeroed out (nor are “investment allocations” given past this 1st coinbase reward epoch, as we reference). I think it would be healthy if we start to think of and work towards these funds as endowments - eventually they need to be designed to compound capital, dole out interest without drawing down the principal, and support Zcash for decades (centuries?) to come.

Love this graphic, think it can be a helpful reference as we work towards NU4, but FWIW I don’t think Zcash is a benevolent dictatorship. As much as Zooko is revered in crypto, there are a lot of rockstars on the Zcash team, and as noted prior, the ZF is stolidly independent.

Okay, I think that’s everything of greatest relevance (for now) - thanks @boxalex!


thanks @nathan-at-least! we’re happy to explore the ZIP process, but also don’t want to jam anything up on account of being relative noobs to the Zcash process.

That said, if you could have DC connect us via email that would be great.


Chris, the ZIP process is described in depth here: zips/zip-0000.rst at main · zcash/zips · GitHub

It’s a lot to dig into, but pretty thorough.

Please let us (the community) and the ZIP editors ( know what your questions are, or if anything is unclear in ZIP 0! The ZIP on-boarding experience definitely has room for improvement, especially now that more people will be participating in the creation and evaluation of ZIPs.

In fact, I just opened a PR to add a link to ZIP 0 to the readme.

cc @daira @acityinohio (the current ZIP editors)


I am currently working on a template. should hopefully be ready in a couple of days.

It is going to be based off feedback I have received from the ECC, other zips and the RUST model.

Am I wasting my time? I was going to collate a post that could hopefully be pinned that tells people what is needed to write a zip. (like going into detail about rfc language and why it is important, how to use it, etc) the post will be specifically designed for non technical people to be able to express their ideas and directly compare them to others.

And remove a lot of the ‘heavy lifting’ of getting to grips with the zip process from a community standpoint.

This post is a basic outline. of the format, but I have not made the template yet. (and wont for at least a day)

@daira @acityinohio

Should I still continue? or wait?



will do, thanks sonya.

love this!

1 Like

i shouldn’t be the final authority here, but so long as the work is not duplicative it sounds helpful.

on the duplicative part, i would follow up with sonya per mention of intro materials in ZIP 0.


I think a “crash course on the ZIP process” guide would be incredibly helpful, even if it overlapped with ZIP 0. I would be happy to offer feedback or contribute, when / if you’re ready for more input!


Just want to ACK that we agree with your sentiments here at Amentum, Chris. And too have amassed a holding of ZEC over the last year of our operation during ideal market conditions.

We look forward to reading others feedback.


A follow up and some more thoughts on your answers/comments:

Seeems on this point, due my bad non-native-English we speak about different things.
What i have in mind is how the current founders reward is distributed:
==> Block reward % goes to a Zcash adress
==> from the Zcash adress it’s distributed to the different recepients, founders, employees, whomemver.
==> From exactly these founders, employees, whomever ECC gets the “donations” or funding.
That’s my impression how it currently works and in my book this is an absolutly wrong setup.

Or in case you exactly have this in mind the the protocol change should modified and 70% go to Protocol Development and 30% to Growth Fund by default? Still, who will be in charge to decide what gets used for what?

Seriously? A multi-million dollar on-going lawsuite is not a concern? Just in case the law-suite is begin lost others could follow and this should at very least be a concern in my opinion. And in case one or more such law-suites are lost in future, who is paying these multi-million dollar fines/compensations?

Why? It’s your chart you posted with the funding percentages and comparision to other project.
But it’s less than half of the story to use NIC’s numbers without US$ conversations in how much a given funding has generated.
Interesting enough we have no clear confirmed numbers on how much funds the ongoing FR has allready generated and my personal calculation/estiminate that it will have generated at current exchange rate (for the outstanding period) at least $300M, mostly around $400 is just that, an estiminate.
This raises some questions:

  • How many crypto projects are you/we aware that have ~$300-$400M raised within 4 years?
  • Was/is the current Founders Reward really distributed good enough to favour R&D, the product itsellf and development or should this be improved. Avoiding this question automaticly leads to unability to improve whatever.
  • My personal opinion is that it’s at least strange to talk about a new dev fee or modified founders reward without analyzing the current one. And you has a financial investment company for sure have done such analysis allready, but i guess that this point doesn’t favour the discussion with a 20% new fee.

Not that this matters, but it was my suggestion in another proposal to use this kind of election to get the best result (you even linked it in your first post).

However, even such very fair “election process” isn’t worth 2 cents if for-up the opinion gets manipulated. In my opinion posting your and only your proposal on the 76k followers Twitter account of the ECC is not fair towards all other proposals and someone can allready consider this manipulation of opinios to get a higher support for a given proposal.

This said, the best election process is worth nothing if things are decided (manipulated) from start.

I didn’t read such statement yet, even more suprising not in my own proposal which has the foundation as the whole recepient of a new dev fee. IF this is true than:
1.) At least this should have mentioned allready in my proposal which favours the Foundation as the recepient.
2.) Some people know way more than the forum community.

And of course some following questions in this scenario, do we need a foundation than at all if the foundation itself wants only very limited (legal) responsibility and accountness. I mean if the whole role of the foundation is just or mainly here and there some grant approving than this could be implented as well in the ECC and at least safe some funds.

I could discuss this point further but this would go into another thematic mostly, but it’s worth thinking about if the foundation should have more control than now over funds or not in the name of more transparency, fairer distribution and eventually even generating competition with the Zcash projects development.

Why over time and not within the introduction of a new def fee or even bevor?
One of my main concerns is that there is lacking whatever control on how funds are used and as stated even more as we talk here about a for-profit-company which leaves less possibilities for transparency and control than a foundation in principe.
So what’s the idea on how to improve transparency and control further with a new dev fund?

If we have to choose from this figure there are only 2 options that would fit the current State of Zcash governance. Either it’s a Corporate control (which in my opinion as well fits better) or it’s a benevolent dictatorship.
The ZF doesn’t play a role here in my opinion as it has no direct influence at all on any Zcash decision. At best some day maybe they could be something decision-influencing but until that point their independence doesn’t affect anything at all.

Final word:

Your indeed well written proposal that for sure will convince a lot of people and with the help of the 76k ECC twitter account and spreading this exact proposal i doubt there are any problems in having it accepted by the wider community…Someone has to admit it’s a professional job in pushing something through…

1 Like

Here’s a link to the statement, which was made directly to the forum community:

I got aware allready about the Foundations stance of this:

The Foundation would only support proposals that:

a) don’t rely on the Foundation being a single gatekeeper of funds
b) don’t change the upper bound of ZEC supply
c) have some kind of opt in mechanism for choosing to disburse funds (from miners and/or users)

Will be interesting to see what the foundations stance is as there are not many proposals with an opt-in mechanism… And this one is lacking one as well…

This is incorrect since one of the ZIP editors represents the Zcash Foundation. We have an effective veto on protocol changes, and it would be pretty disastrous in terms of reputation for ECC to go around the ZIP process after committing to it publicly.

Granted, once a trademark agreement is in place, that will carry more legal weight.



Welcome to the forums.

As you stated this is a contentious topic, I hope you can appreciate my frustration with the situation, it is not directed at you.

Having said that though it has reached a point where I need to take a step back for the politics and concentrate on writing the proposals, and my work on RandomX. I will be around to reply to things but less opinion.

You have brought some very good ideas to the table and I really do not want to discourage you.

I would like to pick up on one point in particular in your post/proposal. This is more to clear things up for the newbies and people who might be drawn here by your post.

The way you have framed this argument saddens me. You seem to understand crypto currency on a deep level, so I am not sure why you would phrase that the way you have.

The argument against a continual development fund from block distribution is a strong one:

  • There was a promise that was made by the ECC was that after 4 years they would no longer received 10% of the total mineable supply of zec from block distribution (not block reward, block distribution) and all block distribution will go to miners (this is baked into the protocol like bitcoin) This is not a 20% tax it is a 10% tax frontloaded to be 20% there is a important distinction. Any adjustment to block distribution would be being taxed twice, for supporting the network and processing transactions, i get to pay twice and enrich everyone else.

  • There was a promise that their will be an emission curve and that curve was set in stone (by algo, like bitcoin)

  • There was a promise that the total number of issued zec would be 21 million (fixed cap like bitcoin)

  • There was a promise of finacial privacy

If zcash can break one of the 4 pillars, then how can they be trusted not to break others?

edit: zcash in the sentence above is a reference to the technology and community. not the ECC. I wanted to make this point doubly clear because my post is aimed at more of the newer crowd who might not be as aware of the difference.

  • There was no mention of any form of ability to change these rules via community consesus.

  • There is a mechasim via zip’s but they are not decided upon by community consensus. No one votes on zips. That would be a crazy way to run a company.

  • There is no definition of who or what the community is

I cannot stress enough how there is no mechanism for people to come to a consensus, zec simply isnt designed like that. Could we use the same consensus mechanism for changing emission? how about depreciating z-addresses? These things have to be fundamentals right? So we can never have voting - bitcoin got that right completely by accident. (the 1 cpu 1 vote design is broken)

I am not trying to be negative, but these are real issues that are stopping this from progressing any further. The best we have so far is some really good suggestions from zooko about implementation aspects of possible ideas whatever ideas they maybe

However once you think about any one of the points he has raised with any one of the ‘change things ideas’ then, the downstream impact on the rest of the community (exchanges, mining pools, miners, people who accept for value) is so non trivial things start to melt (like my mind)

As someone who lives in a country that is governed by such a mechanism. It doesn’t work. Look at Brexit and the elimination polls in the house of commons. (not rigged - no outcome)

Then look at the tory pary leadership, (that was rigged). boris was always going to win but Gove was the best candidate against him, Boris out right stated he got his voters to back hunt so he wouldnt have to face Gove in the final race. (Hunt was never going to win gove had an outside chance, similar things happened in every round of that selection process)

With this mechanism, with a zip like “Dont change things” it will lose in the first round, it only benefits one kind of change, it doesn’t benefit changes that do not make changes.

What this boils down to is I did not opt-in [as I was made fully aware of what I did and did not opt-in to in the ASIC war of 2018] to having the rules changed after they are set in motion.

welcome to our world. none of us have. Sonya has started a megathread (that was on my todo list - only just got regular status back to enable me to do it though), that with daira and str4ds ideas on my proposal I think will help everyone be able to use their voice. All voices have to have the same weight. No voting, no polling, only voices.

I am trying to write a zip that says we dont need voting, then people are going to vote on it. How does that work? (I shake my head and go do something else every time i try to type it up)

Please dont flippantly dismiss my opinions by just saying “go play with yec” - I didnt opt-in to yec, i opted into zec. (I saw you already apologised, its just a very hot topic at the moment)

Thanks for your time.


thank you for the thoughtfulness @mistfpga

out of curiosity, are you a miner? couldn’t help but notice your name includes FPGA

to address some of the good concerns you laid out:

this speaks directly to the points i tried to make around legitimacy. legitimacy and trust can be used interchangeably here, and both are built over time by adhering to a community-endorsed decision-making framework (ie, governance). that framework can choose to balance rules and discretion, so long as it is time-consistent. i’m of the opinion that strictly rules-based frameworks are likely too inflexible (except for maybe bitcoin) to allow most cryptonetworks to optimally innovate and adapt to market opportunities.

therefore, zcash is currently in the search for its governance balance between rules and discretion. i can see some people feeling violated if they felt the “2016 launch promise” was that 4 years later zcash would fall in line with bitcoin and move forward with a rules-based system, because this very conversation violates that perceived promise. the PoV i’m most sympathetic to here is a miner’s, which is partly why i asked if you were a miner :slight_smile:

that said, 2019 is not 2016, and i think our learnings over the last 3 years need to be incorporated into how we govern and evolve zcash - there is no reason in attempting to be bitcoin. imo bitcoin has already won as the reserve asset of crypto, and its strategy cannot be replicated, because its strategy involved birthing the entire crypto space (and being the first asset to price all other cryptoassets).

if we can set in place the right governance framework, and one which the community largely agrees with, then we can agree on using that process to make all future decisions. so long as that process is adhered to, with plenty of checks-and-balances to counteract human nature, we can have trust in it. but until we agree on the process, we will always have contention like what we’re currently facing.

if you look at decred, for example, there is less contention because everyone is clear on what the process is for making new decisions.

much of my response above is applicable here, but to summarize:

right now there is no mechanism for people to come to consensus on such changes, but that may not always be the case for zcash - and to be very frank, i wouldn’t be here if i didn’t think the ECC + ZF was moving towards formalizing means for people to come to consensus on these very contentious decisions.

the way i see it, decisions will always need to be made. one of the biggest first decisions that must be made is how the decisions will be made. choosing to not make a decision about how decisions are made, is a decision in itself, and typically one with messy results. given what bitcoin is, it’s been able to get away without much of a decision-making framework, but that doesn’t mean other projects will be able to so successfully do the same.

agree though that the downstream impacts are serious and hence any implementations here cannot be taken lightly.

i’ll let @mlphresearch weigh in here as he has more background in the topic than i do.

i appreciate your opinions and am sorry for the discomfort this process is causing you.



Sorry I do not address a lot of the governance stuff, that is beyond my skill level.

Yes I mine Monero. I am primarily in this for the tech though. I have been in cryptography since before bitcoin was a twinkle in statoshis eye (hashcash was the first project that I took notice of in the kind of crypto currency sphere)

I am not that involved with the monero community though, ring signatures don’t really interest me that much. I am glad they were proven secure (although I cant find that paper now) ZK proofs, that really does interest me, it could fundamentally change how cryptography works.

The FPGA in my name refers to the initial bitcoin fpga another member and myself started (miSt FPGA - the St is for steve) but the teams speciality is in hardware cryptography and bespoke devices. (it is more than just me)

Partially quoting you. Because my interest is from a technical perspective legitimacy is sticking to the rules.

It is why this governance stuff is so tricky for me. I get a bit personally invested, and I don’t want to have to be involved. I have more interesting things to do, like play with NoBL Sram , RandomX, Hardware wallets, reverse engineering bugs, etc.

It just upsets me from time to time when I see talk of “oh we can change this, or that”

This is why I got involved in the very first place.

Yes this is the point of view I am coming from. In numbers we trust. but don’t get me wrong I am not salty about it.

I have offered to write up proposals and help with all proposals that people ask me for, I may not agree with it but everyone should have a voice and have a chance to get that voice heard. - if the thing stopping that is time or not knowing the right format/language then I can and will help.

I was disappointed that I could no longer mine zec and the implications that ASIC’s reduce the ability of the network to dynamically adapt, potentially limiting the technology.

I agree, and they should be made by a benevolent dictator. I thought we would have moved to that being the foundation by this point. I really am not good at governance or finance. So I will leave that for others to work out. All my proposals will be governance less. I don’t have the skillset to deal with it.

heheh, it is not you its me :smiley: - I think the issue more was you declared a large holding in zec, which would make you a large holder of yec, so telling people to mine yec might not have been the best idea to an already contentious subject. suggesting monero whilst it might have seemed strange it was exactly what zooko did in the asic thread [that was before yec though]

I hope this gives you a bit more insight in to where I am coming from and why I hold my positions.



Sorry for the double post. but the edit got too long and it seemed better to make a new post.


In my last post, I didn’t mean my initial statement to come off as flippant. I had read your proposals and ideas in depth, and I like them and what you bring to the table. I just don’t feel I can comment on them and add value, I just don’t understand it enough. which is why it is good that we have people that do. hopefully my last post explained my simplistic stance.

My main reason for posting this new message was to ask

  • do your plans for governance include what will be in NU4 - or are they for NU5 - because funding needs to be worked out for NU4 and that deadline is in 6 weeks.

Given that timeframe, and experience, what would you think would be the best course of action? My best attempt is over here.

Please read zookos responses at the end of the thread, they brought whole new insight onto this issue for me.

I would really like your feedback or input. Or anyone’s for that matter. Governance will be important. I just don’t want to have to vote, especially on the future outcome of a private company. So I really hope those who know about this stuff can work something out. Please check out that thread.

Hopefully you will see I am not anti funding ECC I am anti breaking core values. I think my stance is pretty much the same as the foundations. I believe both can be achieved without the need for voting. Mainly through a true opt-in protocol level adjustment. Greatly simplifying the issue for downstream and users. (primarily because of my limited understanding governance). But we now have greater community engagement again, after the topic going a bit stale for a week or so and people might get reinvigorated in funding ideas.

I have been thinking about this, and yes I agree to an extent. bitcoin is the coin to hold. However I believe that strategy could be replicated, in the sense of distribution of coins. One thing bitcoin did was get lots of coins out to lots of people quickly. If you can keep ASICS off your network for 2 halving’s then I think you will be safe as a legitimate assets store of value, or whatever the right word is. but this is just speculation and probably out of scope. Get it in as many hands as possible and you are in the right place.

1 Like

I work as a governance researcher at Placeholder and this is my first post on the Zcash forum. Happy to explain the thought process behind our proposal, as well as provide personal opinions on open questions. I hope the community welcomes the relative newcomer that I am :slight_smile:

Thank you @boxalex for your comments and questions.

Yes, the 70/30 split between “Protocol Development” and “Growth Funds” could be written into the protocol. Your question about who decides how the funds are used thereafter is of course absolutely critical and central to our proposal.

As discussed in the initial post by @cburniske, the “Protocol Development” funds could be controlled - similarly to trademark-related decisions - by a 2-of-2 multisig shared between the ECC and the ZF, subject to semi-formalized input from the Zcash community as a whole. Prior to each funding period, both the ECC and the ZF (and potentially other teams supporting development or working on alternative implementations) could publish past progress reports and future work plans that are reviewed by the miners, ZEC holders, and other interested community members with access to various feedback mechanisms that allow them to signal their approval/disapproval and concerns. It is my understanding after attending Zcon1 that both the ECC and the ZF are committed to putting in place the necessary systems for measuring community sentiment and publishing justifications for their decisions.

Could the ECC and the ZF decide against the measured preferences of certain parts of the community? Strictly speaking - yes. But such action would not be without consequences and I would expect both organizations to treat community feedback with great care and consideration. The described governance mechanism guarantees continued funding, but introduces certain checks and balances, allows increased community involvement in decision-making, and democratizes access to the funds. Depending on one’s point of view, it may not feel ideal, but all things considered, we hope it is also seen as a reasonable compromise given our current understanding of the challenges faced by decentralized projects/networks such as Zcash.

We are in conversations with the ECC to better understand this issue.

I agree, although it’s important to note that these allocations are made under a lot of uncertainty. No one can accurately predict the future value of assets tied to the development of innovative technologies like Zcash. Of course the relative percentages don’t tell the whole story in retrospect, but they do provide context for a comparison in which Zcash falls well below the average in the set considered.

Such information should not be too difficult to find, especially in the context of the crazyness of 2017 and early 2018.

I think there are several proposals, including ours, that aim to address this question and suggest ways to improve the management of developer funds.

I think that’s a completely valid opinion and is clearly part of the public discussion/consideration. But let’s assume, simply for the sake of argument, that we decide to spend time digging further into the details of how funds have been used thus far and arrive at a conclusion that it has been done in a suboptimal way and there is considerable room for improvement. Assuming that there’s sufficient agreement for some type of protocol-level funding to remain in place, the next step would be to come up with ways to increase community involvement in governance and improve transparency and accountability, correct? It appears to me that this is what we are already working on.

Correct. It was an interesting suggestion and we thus decided to mention it in our analysis. I will reply separately to concerns raised in this thread about the possible shortcomings of such a system.

In my opinion, community members should be informed about all proposals. This is a good moment to come up with some procedural rules that everyone can accept as fair, thus adding to the legitimacy of the final outcome.

I think having two separate and independent entities (potentially more in the future) is important and, based on my impressions thus far, I see the Foundation’s role as clearly distinct from the ECC. There is obviously some overlap (e.g. in development work) but this is by design. For example, the ZF is responsible for maintaining an alternative implementation of the protocol which makes the network less dependent on the ECC.

I completely agree. The 2-of-2 multisig that was suggested at Zcon1 and that we support in our proposal gives the ZF considerable power. It is my understanding that this effectively includes the right to veto certain decisions that the ZF sees as misaligned with the common and long-term interest of the network as a whole.

We have suggested that funding decisions should be subject to community feedback and approved/justified on a semi-annual or annual basis, potentially tied to the NU schedule. The granularity of regularly submitted progress reports and road maps is an open question. Should a new developer fund be introduced as part of NU4, the most recent Transparency Report (or subsequent ones before the 2020 halving) could serve as the baseline for the first round of funding proposals under the new governance mechanism. The exact details of this can be worked out over time but a basic description of what constitutes “sufficient transparency” should be included in the ZIPs put on table at the end of August.

As pointed out by @sonya, this is not an accurate description of the de facto rights and power the ZF already holds. These would be enlarged under a 2-of-2 multisig system where decisions concerning the trademark and potentially the use of developer funds would have to be confirmed by both the ECC and the ZF to go through. Each decision would be preceded by a community review/feedback period and both organizations would accompany their decisions with a public statement on how/why they arrived at a particular outcome. At least that was my takeaway from discussions at Zcon1 and we’ve broadly supported such a vision in our proposal as well.

1 Like