Hey folks!
I’ve just opened a new ZIP (unnumbered) for how I think we should move Zcash forward in the next network upgrade. Pasting it roughly below to kick off conversation!
Abstract
This proposal describes a structure for Zcash governance, including funding and
managing new Zcash development, decentralizing those development efforts, and
resolving governance hangups between the Zcash Foundation and the Electric Coin
Company.
These goals are accomplished via a 20% dev fee, enacted in NU4, as much as half
of which is burned in the case of a robust ZEC price. This fee will fund a
diverse group of development teams to ensure Zcash maintains best-in-class
research and engineering talent while growing a robust ecosystem.
Motivation
Who am I?
My name is Matt Luongo. I’m an entrepreneur who’s been full-time in the crypto
space since 2014, co-founding Fold, a Bitcoin payments company, and more
recently Keep, a private computation startup built on Ethereum. At Keep, we’ve
done some work around Zcash,
and our parent company, Thesis, is considering investing
more heavily in Zcash development for our latest project.
I’m deeply interested in privacy tech. For me, privacy is about consent –
consent to share my habits, beliefs, and preferences – and I see privacy as
the inevitable next frontier in our pursuit of an economy that respects
individual choice.
My perspective is as the founder of a for-profit company focused on building
self-sovereign technology who wants to develop on Zcash. We work in this space
ideologically, but our work isn’t free; attracting and growing talent requires
funding.
If you’re interested in more on my background, I’ve introduced myself more
properly on the forum.
What’s this about?
Since Zcon1, I’ve been looking to fund work to build an Ethereum / Zcash bridge.
I’ve spoken to the ECC, the Zcash Foundation, and a number of early Zcash
community members on how best to move forward with this project, and in the
process I’ve learned a lot about how the community works and dev governance has
been structured thus far.
Inevitably, I’ve become interested in the community’s proposals for a new dev
fee, and thought about how the right structure might support work like ours.
I believe the Zcash community has an opportunity to deploy a new incentive
structure that will attract companies like ours to build and improve Zcash,
leading to a more resilient network, stronger technology, and wider usage.
The Zcash narrative
We’re all here to build a robust, private, decentralized currency. But in the
dev fee proposals I’ve seen so far, the idea of a Zcash narrative that
distinguishes it from the competition is absent.
Of the slew of ZIPs addressing Zcash’s future, there’s only been one strong
narrative case – the idea that Zcash exists purely as a hedge against Bitcoin’s
long-term privacy failure. Put simply, Zcash is “Bitcoin, but private”.
Zcash should aim higher. Bitcoin is the only coin that has successfully made a
store of value argument, which I like to call “worse is better”. Don’t upgrade
the network – the argument goes – stability is more important than solving
today’s problems. Bitcoin is chasing the Lindy
effect, where worse is better, and
the network becomes stronger every day it survives. That’s great for Bitcoin.
For the rest of us, though, better is better. Zcash should be better.
Zcash is known for having the best tech in the space, built by one of the best
team’s in the space. We should lean in to that reputation, nurturing the best
research and engineering talent to take Zcash to the next level, and leveraging
a Zcash dev fee as a differentiator to build the world’s best private medium of
exchange.
Principles of cryptocurrency governance
To understand Zcash governance, it’s worth reviewing “default” cryptocurrency
governance. Most proof-of-work chains today have three major governing roles:
- Miners validate and secure the chain. They do some work to earn a reward.
Miners are the first owners of newly minted coins, and are an integral part
of network upgrades. - Users buy, hold, and spend the currency. In networks like Bitcoin, they also
run full nodes, strengthening network resilience by decentralizing
validation. - Developers maintain clients to power and interact with the network. They
typically propose network upgrades.
On a chain like Bitcoin, any of these roles can veto a network upgrade.
- Miners can veto activating a new fork by refusing to build off blocks using
new network rules, orphaning a minority effort. They can also attack any fork
attempt that doesn’t change - Users can veto a fork by refusing to update their full nodes, rejecting
blocks as invalid – as demonstrated in the UASF movement successfully
countering the SegWit2x attempt to force a Bitcoin hardfork. Users can also
vote with their dollars, acting as a fork resolution of last resort via
market pressure. - Developers can refuse to update client codebases to follow a fork. While this
might not seem like a strong veto, in practice that means any fork will need
at least one additional development team, or the agreement of existing client
software developers.
These roles together form a balance of power that makes contentious forks
difficult – any change that a large swath of users disapproves of could split
the chain.
The state of play
In Zcash, the addition of the Electric Coin Company (ECC) and the Zcash
Foundation skew this balance.
Both organizations are comprised of Zcash founders, developers, researchers, and
privacy proponents who have driven this ecosystem forward and represent its
values. Nevertheless, their mode of operation today skews a healthy balance of
power in Zcash governance.
The mechanisms of that skew are the Zcash trademark, held jointly by the
Foundation and the ECC, and primary client software development, now split
between the ECC and the Foundation.
In a disagreement between miners, users, and developers, the Foundation and ECC
have the option of enforcing the Zcash trademark, effectively allowing them to
choose a winning fork against the will of users, miners, and other developers.
In addition, the Foundation’s sole maintenance of the zebrad client allows
them to “soft veto” a network upgrade.
Unfortunately, the Foundation and the ECC aren’t organized as arms-length
entities today.
This situation poses a number of problems for new and existing Zcash users, as
well as both entities.
- The threat of two entangled entities overriding (or being forced to override)
the will of users undermines self-sovereignty. - The ECC and Foundation are both put at legal risk. As entangled entities,
they’re remarkably similar to a single entity when trying to minimize
regulatory risk.
The “crowding out” problem
The Zcash ecosystem, as it exists today, leaves little incentive for outside
developers to participate.
Zcash development has a high learning curve.
- The reference client is a fork of the Bitcoin reference implementation,
building on a decade of poorly written legacy code. - What Zcash brings to the table involves a greater understanding of applied
cryptography than most projects. SNARKs are often still referred to as “moon
math”, after all. - As the recent network-level attack demonstrates, full-stack privacy is hard.
Most outside developers need to see a clear path to longer-term funding before
they can commit to the cost of that curve.
Even those developers who already have the expertise to work on this system are
frustrated by the lack of longer-term funding. For evidence, look at Parity’s
exit from Zcash after zebrad development, or Summa’s struggles to work on
Zcash.
Sustainably attracting talent to Zcash is critical to maintain innovation and
build resilience.
Requirements
The first requirement is a balanced governance structure. Developers should be
rewarded, without rewarding governance capture. What’s best for the chain and
ZEC holders should always come before commercial interests.
The second, and secondary, requirement is funding Zcash development. While the
chain shouldn’t be run by a commercial entity, it will need to be supported by
them.
The third requirement is the support of a more resilient ecosystem by:
- Ending the “crowding out” problem by paying development teams to work on and
for Zcash. - Building a dev fee management structure that’s resilient to the loss,
capture, or compromise of the Zcash Foundation. - Ensuring the ecosystem can survive the loss, capture, or compromise of the
ECC by encouraging developer diversity and strategic input.
Finally, avoid introducing unnecessary additional entities into the governance
process.
Non-requirements
General on-chain governance is outside the scope of this proposal. On-chain
governance is an exciting idea – what if we had an impartial arbiter funding
development? My experience with on-chain governance to date, however, leads me
to believe it’s still a risky direction. Zcash should focus on what it’s good at
– privacy – and leave proving on-chain governance models to other projects.
While this proposal attempts to outline a long-term structure for Zcash funding
and governance, specifying the structure beyond the next 4 years is out of
scope. Much will have changed in 4 years. Perhaps this structure will be
sufficient; perhaps we’ll be battling the Third Crypto War, and need to go back
to the drawing table.
Specification
The below proposal is an effort to cleanly resolve the problems with Zcash’s
current governance, while
- maintaining a balance of power between stakeholders
- removing single points of failure / control
- growing development and usage of Zcash
- and supporting the best interests of miners, users, and developers today.
Decentralizing development
A few proposals have suggested the introduction of a mysterious “third entity”
to resolve disagreements between the Foundation and the ECC.
I prefer a different approach, refocusing the role of the Foundation and making
room for the ECC to work with a robust developer ecosystem.
In this proposal, the Foundation shall support community development through
running the forum and events, gathering community sentiment, managing short-term
development grants, research and development, and conducting the diligence
behind the assignment and disbursement of a development fee. This development
fee shall be funded by 20% of the block reward, with as much as half of the fee
burned in case of extraordinary growth in the price of ZEC.
The Foundation shall receive 25% of the dev fee. If the volume-weighted average
price of ZEC over the month means the foundation would receive greater than
$500k that month, the Foundation shall set aside enough ZEC such that their max
monthly budget is
MaxBenefit(RewardDollarAmount) = Max(500000, \sqrt{\frac{RewardDollarAmount/500000}})
The excess ZEC should be purpose-restricted to the Foundation grants program,
ensuring the funds are earmarked to grow outside community talent and
involvement.
Capping the monthly expenses of the Foundation will limit growth, while
encouraging fiscal discipline.
The remaining 75% of the dev fee shall be distributed between development teams
working to maintain clients.
- Up to 35% of the total fee shall be reserved for the
role of the “principal developer”, a developer with assured long-term
alignment with the project. - The remaining 40% of the fee, called the “outside development fee”, shall be
distributed between at least two development teams, chosen semi-annually by
the Foundation, coinciding with network upgrades.
Prior to each network upgrade, the Foundation shall recommend a list of
addresses and a total number of ZEC per block each address is meant to receive
from the dev fee. The recommendation will be “ratified” by the miners as the
network upgrade activates.
The role of dev fee recipients
Dev fee recipients are distinguished from grant recipients in the scope and
timelines of their work, as well as the specificity of direction. The intent
is to allow teams to focus on a core competency, while encouraging research and
adjacent work.
Dev fee recipients are chosen semi-annually by the Foundation based on their
ability to move Zcash forward. Recipients will typically be development teams,
though “full stack” teams that can communicate well with the community, expand
Zcash usage, and widely share their work should be advantaged.
Recipients shall submit quarterly plans to the community for their efforts, as
well as monthly progress updates.
All work funded by the dev fee will be open source, under licenses compatible
with the existing Zcash clients.
Though the Foundation shall periodically judge the efficacy of dev fee
recipients, deciding on and driving roadmaps for Zcash is the role of dev fee
recipients, in partnership with the community. This role is neatly balanced by
users running full nodes and miners, either of which can veto a network upgrade.
While dev fee recipients are not required to work exclusively on Zcash,
considering the nature of their work, recipients must guarantee they aren’t
obliged to the interests of competing projects.
The role of the principal developer
The role of the principal developer is as a “first among equals” amongst the dev
fee recipients.
The principal developer shall make a number of guarantees.
- Zcash shall be their exclusive focus, submitting financials periodically to
the Foundation as assurance. - They shall maintain a well-run board and employ a qualified CFO.
- In addition to the existing open-source requirements, they shall agree to
assign any patents relevant to Zcash to the Foundation.
In exchange, the principal developer is granted an indefinite minimum dev fee
allocation of 20%, with a maximum allocation of 35% of the total fee, as
recommended annually by the Foundation.
The principal developer will have a wide remit to pursue longer-term research
relevant to Zcash, though it will submit the same plans required of other
recipients. The principal developer will only be recommended for removal by the
Foundation in extraordinary circumstances, including reneging on the above
guarantees or extreme negligence.
Minimum viable Foundation
To manage the dev fee and fulfill its community and diligence duties, the
Foundation shall maintain a board of 5 independent members. Rather than the
structure in the current bylaws, the board will consist of
- 1 seat voted on by ZEC holders directly.
- 1 seat representing a newly created research advisory board, whose primary
role will be technical diligence of potential recipients of the dev fee. - 1 seat for a member of the investment community.
- 2 seats elected by the board, as the board is currently selected according to
the bylaws. The board’s discretion here means these could be selected via a
community election, or via the remaining 3 seats’ direct vote.
The Foundation requires a professional board. Board member selection should
heavily favor candidates with existing formal public or private sector board
experience.
Board seats should rotate periodically, while maintaining long enough terms and
overlap for consistent governance.
Each board member should bring a unique network and set of skills to bear to
increase the impact of the Foundation.
No board members shall have an ongoing commercial interest in any recipients of
the dev fee.
Considering their expertise, the Foundation shall deliver a transition plan,
including a board election schedule and report on the feasibility of a future
coin vote process to determine a board seat.
The ECC as the principal developer
I propose that the ECC be considered as the initial principal developer,
receiving an indefinite dev fee allocation in exchange for their exclusive
focus on Zcash research and development, and assigning all patents and marks
relevant to Zcash to the Foundation.
I believe this arrangement is best for the Zcash ecosystem, and with proper
management of funds, should satisfy the ongoing needs of the ECC.
The dev call
The Foundation shall organize a bi-weekly call for all dev fee recipients and
other third party developers. The call will be live-streamed for community
participation, though the speaking participants will be invite only. At a
minimum, a single representative from each dev fee recipient should attend.
The Foundation shall also maintain a simple chat solution for development of
the protocol. While the chat logs should be publicly viewable, it need not be
open to public participation.
Moving forward
I believe this proposal can form the basis for a new way forward for Zcash –
a robust, decentralized ecosystem with fair governance. I also hope it can bring
together the stakeholders in this discussion, and allow us to get back to why
we’re all here – to protect the world’s financial privacy.
I look forward to feedback on GitHub and the Zcash forum.
Disclosures
In the interest of transparency, I’d like to make a few professional
disclosures.
I’m the largest shareholder of Thesis, the parent company and studio behind
Fold and Keep. Thesis is a for-profit company that might benefit from this
proposal as a dev fee recipient. While today I maintain exclusive control of
Thesis, the company has taken outside investment in the past.
As far as my financial interest in Zcash, I’ve held a small amount of ZEC since
shortly after launch. I’m in the process of building my personal ZEC position,
as well as a position at Thesis.
Acknowledgements
Thanks to my friends and colleagues Carolyn, Laura, Josh, James, Corbin,
and Antonio for early review of the text this proposal.
Thanks to my fellow dev fund ZIP authors, Avichal Garg at Electric Capital,
Antoinette Marie, Josh Cincinnati, ED at the Zcash Foundation,
Jacob Phillips at Autonomous Partners, Andrew Miller, Chris Burniske, Eran Tromer
and the fellows at Blocktown, each of whose ideas influenced this proposal.
And of course, thanks to Sonya Mann and the Foundation for coordinating
discussions around these different proposals.
Outside ongoing discussions in the forum and with other ZIP authors, I’ve spoken
with a number of prominent community members while developing this proposal,
though none were provided early access to the text of the proposal. I
appreciated the thoughtful discussions with Josh Cincinnati, Zooko Wilcox,
Josh Swihart, Ian Miers, and others.
I think non profits can get
