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 teams 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:

1. 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.
2. Users buy, hold, and spend the currency. In networks like Bitcoin, they also run full nodes, strengthening network resilience by decentralizing validation.
3. 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.

1. 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
2. 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.
3. 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.

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

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.

1. Zcash shall be their exclusive focus, submitting financials periodically to the Foundation as assurance.
2. They shall maintain a well-run board and employ a qualified CFO.
3. 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 periodically 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.