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.
Conclusion
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!
Footnotes:
[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 
[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).
- 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]