On the Future of Zcash Funding

A Fork in -Z- Road

This piece covers the topic of funding Zcash R&D into the foreseeable future. If you want to join the ongoing discussion, you may do so at the community forum here.

___________________

In October of 2020, the revenue stream that has funded research and development for the open source project Zcash expires. The task for project leadership now is to help shape the conversation of how Zcash development will be funded beyond this date.

First, for some context on what we are discussing; most proof of work cryptocurrencies have a deflationary design with a set amount of new tokens, a.k.a. ‘coins,’ being created every n-minutes and gradually tapering over time. These new coins are created by powerful computers through a process called mining. These miners are in turn rewarded for their work with the newly minted coins.

Bitcoin for example, is structured so that 100% of its new supply goes to these miners who are contributing to the network. Zcash on the other hand, chose to slightly alter this structure and allocate 80% of new supply to miners, with the remaining 20% going to founders, early investors, and the Zcash Foundation to help fund development efforts. So the question now is what comes next for the project? Should steps be taken to continue a modified version of this revenue stream, or should direct funding be allowed to cease in the hopes that development can be funded through primarily charitable contributions?

This problem is not new to open source development, however cryptocurrencies do offer unique incentive mechanisms that do not exist for projects outside the blockchain space. Part of what makes this new type of open source project so interesting is that cryptocurrencies can bootstrap funding for development through the value created by their underlying tokens (so long as the market deems them of value that is).

Source: Zcash Transparency Report Q2–2019

The most contentiously debated aspect of Zcash’s launch was not necessarily that a mining reward ‘haircut’ was imposed, but that significant allocations were earmarked for the founders and early investors. The concern here being that allocating these funds in such a way, especially to members who might not contribute directly to the project, equates to a free subsidy for a privileged few. A far-cry from the open and level playing field that Bitcoin lauded from day one.

While this method does indeed have its risks, those risks rest largely on the actions of the founders and investors. If they were to abandon the project then this payment would be a net negative, but if that were to happen then the value of the project would likely plummet, rendering their payments worthless anyway. If they were to continue to work and contribute value to the project however, then the allocation would have been well placed and the value added would reflect in the price which further benefits the stakeholders, creating a positive feedback loop. When considering the game theory of the situation, it becomes evident what path a rational actor would choose. This second scenario is essentially what has manifested over the last 3 years.

If you’re unfamiliar with this topic in general and would like to know more I would highly recommend the following material:

• Zcash & The Founder Incentive Trilemma by Arjun Balaji
• Why Funding Open Source is Hard by Eric Berry
• Roads and Bridges: The Unseen Labor Behind our Digital Infrastructure (long-form) by Nadia Eghbal

The ‘Why’ of Funding R&D

The term ‘Open Source’ denotes software for which the original source code is made freely available and may be redistributed and modified. As such, many open source projects have a history of starting at a grassroots level and being developed by those willing to donate their time and effort to the project free of charge. While this strategy certainly works at fostering collaboration and innovation, it does not scale well without funding and structure. Most typically this takes the form of a corporation that uses the software in their business, and as such is incentivized to hire developers to maintain the code. As we have seen with OpenSSL however, even open source projects that are widely used can quietly fall victim to the bystander effect.

Much as with OpenSSL, Zcash leverages cryptography as a cornerstone to its architecture. Cryptographic systems, especially highly advanced ones such as zero-knowledge proofs, are inherently difficult codify and debug. We have already seen examples of critical bugs in Bitcoin’s code base several times in the past, as we have with Zcash more recently. These bugs require teams of experienced computer scientists and applied cryptography engineers to work quickly to resolve such problems, and to ideally be able to dedicate resources to finding these types of issues before they are exploited by malicious actors or even widely known.

8:47 AM — 5 Feb 2019

What makes Zcash one of, if not the most technically interesting cryptocurrencies is the cryptography that it is built upon. Zero-knowledge proofs have been around since the late 1980’s but their complexity is not for the faint of heart, which is precisely why armchair hobbyists are not a plausible fit for continued development of the Zcash protocol. And while Zcash has certainly come a long way since its inception, it still has a long way to go to achieve things like scalability, private transactions by default, a replacement to the trusted setup, lighter weight mobile clients etc.

Why Not Just Emulate Bitcoin?

Many may accurately note that Bitcoin’s development has continued unimpeded without direct funding over the last decade. Projects that have come after it have primarily resorted to token pre-sales (aka ICO’s) to generate enough forward funding to provide runway. While this method does indeed work, it is arguably skews the fairness of distribution and incentives over the long term.

There are a few points worth noting in relation to the subject of Bitcoin’s development funding (or lack thereof) to date:

1. As a first mover, Bitcoin attracted ethos driven ‘die-hards’. Many of the early libertarian leaning developers still remain with the project. They have skin in the game and a sense of ownership over a cause that compel them to stay active. This aspect is not unique and has been seen in other open source projects before, for example, Stephen Henson’s work on the OpenSSL project that over half of the internet uses and yet is developed by a ragtag group of volunteers with only enough runway for several years, thanks largely to donations spurred after Heartbleed hit the news in 2014.
2. A non-negligible number of these longer term developers no longer have to be overly concerned with ‘working to live’ due to the rapid rise in Bitcoins price over less than a decade. This is an aspect of the projects intended positive feedback loops.
3. Blockstream (a private company, not entirely dissimilar to the ECC) supplements funding for multiple high-profile Bitcoin core contributors and is the closest equivalent to an R&D arm for the Bitcoin project.
4. With all this said, even prominent Bitcoin developers have still had to resort to soliciting donations to help fund their contributions.

So, are there any examples of projects that followed Bitcoin’s ‘fair launch’ model that might provide better reference? Yes — Grin, a recently launched privacy-centric protocol that leverages the Mimblewimble framework and is also a proof of work project has already run into funding pains of its own.

If we acknowledge that purely emulating Bitcoin’s grassroots development structure is a lofty, if not impossible goal for ensuing projects, where does that leave us in terms of solving the problem at hand?

A Few Possibilities

Before covering some of the options, it’s worth noting that…

• Cryptocurrencies are still very much in the experimentation phase.
• There will always be a vocal minority in opposition to any proposed solution.
• The path towards progress is through trial and error.

Option 1 — Continue Dev / Founders Allocations Indefinitely

This option would simply extend the current allocation model by another 4 years, or perhaps even indefinitely. The most contentious aspect of this model is, and has always been, the allocation of value directly to founders and early investors, regardless of their contributions or lack thereof.

I personally see this option as a non-starter in terms of garnering a meaningful amount of community support.

Option 2 — Remove All Allocations (a.k.a. 100% of ZEC Goes to Miners)

This option would cease all ZEC allocations from newly mined blocks and divert 100% of mining rewards directly back to miners. This would leave funding for R&D of the Zcash protocol to community altruism (donations etc) or self-funding from the founders, developers and possibly self-motivated private parties such as the Foundation and larger stake holders etc.

I do not think this method is ideal, as we have already seen with Grin as well as countless other niche open source projects, depending exclusively on community contributions to provide runway is not a reliable means of operational funding.

For other examples of high-profile crypto projects with lackluster development due to no official funding, see: Litecoin and Dogecoin. While this is a better option than Option 1, I personally think there is a better middle-ground to be found.

Option 3 — Continue Allocation for R&D Only

This option would essentially be the same allocation % as today, but with the exclusion of founder and early investor rewards. The majority of the allocation would either go to the foundation and/or the Electric Coin Company, with the intent of solely funding R&D and community outreach.

What I think is most important with this option is coalescing on how the allocation would be split between both the Foundation (the ones doing community outreach) and the Electric Coin Company (the ones doing the R&D). Some have suggested that all funding should go directly to the foundation, however this is not ideal as it would concentrate the funds with a single entity which induces a host of alternate risks.

An idea here might be something along the lines of a 40/40/20 split. With 40% for ECC to fund R&D, 40% for the Foundation to allocate to the grant pool as well as community outreach, and the remaining 20% being allocated to the Foundation with the exclusive agreement that it is to directly fund ECC’s R&D initiative. This final 20% would act as a balance that could be revoked by the foundation should there be significant community push back on a specific direction that the ECC might wish to pursue (i.e. incentive misalignment). Perhaps once better distributed voting systems arise this floating 20% could act as a community controlled tie-breaker of sorts between the two organizations.

While the %’s above may need some adjustment, some form of this option seems to me at present to be the most logical path forward.

Option 4 —The Friendly Fork

This option would be for the ECC & founding Zcash scientists to fork Zcash into a new project umbrella (Z2.0) that would continue the funding model, or be funded by venture capital, or possibly some combination of both. Regardless, this would be an ETH/ETC redux of sorts, however with likely more impactful perception ramifications to the both legacy and new chains.

Zcash has always had its work cut out for it in terms of engendering good faith from the community given the founders reward and the setup of the ECC. To abandon the legacy project and fork to a new one would, regardless of merit, be seen as an attempt to bypass the social contract entered when Zcash launched. What slim chance the Zcash project might have had after its 4 years would risk being relegated to a status of doomed experiment. Of course, I have no way of knowing if this would lead to such a bleak an outcome, but I would hate to see what momentum has already been built to be swept away.

As of right now, I am of the opinion that Zcash should continue funding solely for development on the legacy chain for at least 4 more years. No more founder or early investor rewards, and no friendly forks by current or former ECC members. A donation pool might also be considered. One that is not to be used until 2024, at which point it goes to the foundation for as much development funding as is possible. This pool may also act as a litmus of sorts in determining community support for the success of the project, as well as to prevent a hard landing when funding from the block subsidy inevitably ceases.

How Often Is This Discussion Necessary?

After coming to terms with a plan of action for the future of funding for the Zcash project, one important aspect remains, and that is how long exactly does the decided on structure stay in place?

Do we architect a plan that might be looked to as a constitution of sorts, existing as a cornerstone in perpetuity, or do we have periodic reviews incrementally such as with each update or block halving? My support would be for the latter, however there may well be merits to the former in many ways. Times change and people will come and go from this project, so its important to not drift too deeply towards inflexibility.

What matters most here is that whatever is decided on, that it is done with the interest of the many (the network, the current & future users etc.) over the few.

Closing Thoughts

In summary, no matter what decision is made going forward, the emphasis for this post is for the Zcash project leadership to:

• Be as open as possible with the decision process.
• Proactively solicit community engagement.
• Set a decision deadline as far in advance as possible. This date should ideally be no less than 4 to 6 months prior to the 2020 reward halving.
• Put the needs of the many ahead of the needs of the few. (R&D > FR)
• Stay true to the founding ethos: Privacy is a human right — this project was built on a foundation of empowering everyone with economic freedom and opportunity.
• Act decisively!

Thanks for reading. My hope with this post is to further solicit engagement and the sharing of ideas on this subject. Please leave a comment below or at the Zcash forum if you would like to contribute to the discussion.