zips/zip-XXXX.rst

::

  ZIP: Unassigned
  Title: Decentralize the Dev Fee
  Owners: Matt Luongo <matt@thesis.co>
  Status: Draft
  Category: Process
  Created: 2019-09-27
  License: MIT

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 <https://github.com/ethereum/EIPs/pull/2129>`_,
and our parent company, `Thesis <https://thesis.co>`_, 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
<https://forum.zcashcommunity.com/t/introducing-matt-luongo-from-keep/34947>`_.

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<https://en.wikipedia.org/wiki/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:

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 fiasco resulting from 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 by the ECC, and
primary client software development, now split between the ECC and the
Foundation.

In a disagreement between miners, users, and developers, the ECC has the
unilateral option of enforcing the Zcash trademark, effectively allowing them
to choose a winning fork against the will of users, miners, and other
developers.

While the Foundation's maintenance of the `zebrad` client would normally allow
them to "soft veto" a network upgrade, they don't have a similar veto on the
Zcash trademark enforcement.

Compounding these issues, the Foundation and the ECC aren't arms-length entities
as they're organized today.

This situation poses a number of problems for new and existing Zcash users, as
well as both entities.

* The threat of a central entity 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.
* Power between the two entites *hasn't* been decentralized. The ECC remains
  a unilateral power, as well as a single point of failure.

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:

1. Ending the "crowding out" problem by paying development teams to work on and
   for Zcash.
2. Building a dev fee management structure that's resilient to the loss,
   capture, or compromise of the Zcash Foundation.
3. 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, 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 burn enough ZEC such that their max
benefit is

.. math::

  MaxBenefit(RewardDollarAmount) = Max(500000, \sqrt{\frac{RewardDollarAmount/500000}})

Capping the monthly upside 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.

* One third of the remaining fee (25% of the total) shall be reserved for the
  role of the "principal developer", a developer with additional voice in Zcash
  governance. The principal developer allocation shall be capped similarly to
  the Foundation's, based on the monthly volume-weighted average price.
* The remaining two thirds of the fee (50% of the total), called the "outside
  development fee", shall be distributed between at least two development teams,
  chosen semi-annually by the Foundation, coinciding with network upgrades.
  Unlike those of the Foundation and principal developer, these allocations
  aren't affected by market conditions, and don't carry a burn requirement.

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 trademarks or patents relevant to Zcash to the Foundation.

In exchange, the principal developer is granted an indefinite dev fee allocation
and a wide remit to pursue longer-term research relevant to Zcash, as well as
a voice on the board of the Foundation. The principal developer will not be
subject to semi-annual review, 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 the "principal developer", a privileged recipient of the Zcash
  dev fee acting as "first among equals" amongst a variety of dev fee recipients
  building on Zcash.
* 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. Each board member shall be paid reasonably by the Foundation.

Each board member should bring a unique network and set of skills to bear to
increase the impact of the Foundation.

Outside the seat for the principal developer, no board members shall have an
ongoing commercial interest in any recipients of the dev fee.

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.