zips/zip-1011.rst

::

  ZIP: 1011
  Title: Decentralize the Dev Fee
  Owner: Matt Luongo <matt@thesis.co>
  Status: Obsolete
  Category: Consensus Process
  Created: 2019-09-27
  License: MIT
  Discussions-To: <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252>
  Pull-Request: <https://github.com/zcash/zips/pull/278>


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 and continuing
for one halving period. 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, funding the Zcash Foundation with 25% of
the dev fee, and a newly established principal developer role with 35% of the
dev fee.


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`_, 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
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.


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, 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

.. math::

  \mathsf{MaxBenefit}(\mathsf{RewardDollarAmount}) = \mathsf{min}\left(500000, 500000 * \sqrt{\frac{\mathsf{RewardDollarAmount}}{500000}}\right)

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.


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.

.. _Thesis: https://thesis.co
.. _Fold: https://foldapp.com
.. _Keep: https://keep.network


Acknowledgements
================

Thanks to my friends and colleagues Carolyn_, Laura_, Josh_, James_, Corbin_,
and Antonio_ for early review of the text this proposal.

.. _Carolyn: https://twitter.com/CReckhow
.. _Laura: https://twitter.com/LauraWallendal
.. _Josh: https://twitter.com/JoshSRosenblatt
.. _James: https://twitter.com/_prestwich
.. _Corbin: https://twitter.com/CorbinPon
.. _Antonio: https://github.com/shadowfiend

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.

.. _Avichal Garg: https://forum.zcashcommunity.com/t/dev-fund-proposal-5-entity-strategic-council-approach/34801
.. _Antoinette Marie: https://forum.zcashcommunity.com/t/zcash-dev-fund-results-based-financing-equity-proposal-amendment/35052/31
.. _Josh Cincinnati, ED: https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812
.. _Jacob Phillips: https://forum.zcashcommunity.com/t/asp-founders-reward-positioning-support-for-avichal-garg-s-proposal-with-amendments/35184
.. _Andrew Miller: https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864
.. _Blocktown: https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782
.. _Chris Burniske: https://twitter.com/cburniske
.. _Eran Tromer: https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364/15
.. _Sonya Mann: https://github.com/sonyamann

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.

.. _Josh Cincinnati: https://twitter.com/acityinohio
.. _Zooko Wilcox: https://twitter.com/zooko
.. _Josh Swihart: https://twitter.com/jswihart
.. _Ian Miers: https://twitter.com/secparam