Decentralizing the Dev Fee

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!


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

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.


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

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

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

Sustainably attracting talent to Zcash is critical to maintain innovation and
build resilience.


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

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


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.


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

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

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.


In the interest of transparency, I’d like to make a few professional

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.


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.


Hi @mhluongo and welcome to the forums! This proposal seems very well thought out, I look forward to seeing the community feedback.

I have changed the category to be with all the other ZIPs. Based on info I have heard from Josh S. that the TM agreement between ECC and ZFND is nearing completion. Once that is done hopefully we can begin the process of moving forward to voting on the ZIPs.


Thanks for posting this here, I was reading the GitHub version. :slight_smile: I think non profits can get
paid but cannot make a company profit (although I only know uk law)

Will read this more thoroughly and give you some feedback. Thank you for being involved.

Are you going to be in the next zcash foundation community call to talk about this?

I forget if you were in the last one (If you listen to it, im the English bloke in the call.)

1 Like

Thanks @Shawn! Appreciate the mod work, I chose a random ZIP and stuck with the same category heh

Based on info I have heard from Josh S. that the TM agreement between ECC and ZFND is nearing completion

Excited to hear that!


I think non profits can get paid but cannot make a company profit (although I only know uk law)

Correct, but board members can’t – that was my mistake in the original. It’s worth pointing out that we also avoid Zfnd directly paying dev fee recipients in this proposal, as that causes all sorts of problems and means the structure can’t survive eg the capture of Zfnd or meddling by regulators.

Are you going to be in the next zcash foundation community call to talk about this?

Definitely! I’m the uppity guy that goes on about narratives and strategy :crazy_face:


Personally (speaking only for myself), this is my favorite proposal so far.

@mhluongo one thing I’m not clear on is whether you intend for ZF to continue in-house engineering work, or to step back into a pure arbiter role.


Longer term, I think the client dev should go elsewhere, though I think there’s still a place for in-house engineering across multiple clients as well as for dev fee and grant diligence.

Rationale is that “leading” a particular client’s dev in this structure gives Zfnd an extra soft veto on network upgrades, which skews the governance and puts the foundation in competition with other implementations.

I could see a rough timeline where zebrad gets to a good spot, another client is written (we’re interested in maintaining a Go client, for example), zcashd is deprecated, and zebrad is handed to the ECC or another dev fee recipient for active dev. Then the foundation works across those


Nice work. Overall there is a lot to like here and it’s very thoughtful.

Few thoughts:
1/ I worry that having a principal developer is too much centralization and we should be striving for multiple such developers who are able to focus primarily on Zcash and drive progress

2/ I am torn on whether evolving the ZF to have a board with different focus is better than just creating a new organization. I can see arguments either way. I personally think it’s better to reboot it rather than try to evolve it because the nature of the decision making is very different – allocating funding from the dev pool and running an efficient process around that is a different mandate than the current ZF mandate in my opinion.

3/ Minor point but I think we should drop some of the constraints for fund recipients around having a CFO. I think requiring a legal agreement to deliver is fine – we can pick a neutral jurisdiction such as Switzerland

Overall this feels quite compatible with my proposal around 6 month iterations, quarterly progress checkins, submitting proposals to earn grants to a board, having board members not have financial interests, etc. I’m interested to see how the community responds to this variant. There are likely components here from each that we could merge together based on community feedback.


Note: there’s additional discussion within the GitHub pull request.


Thanks @avichal! Going point by point here

I agree we need many developers, but it’s hard for me to imagine teams that aren’t already working in crypto jumping into action and learning all this stuff. If we don’t require exclusivity, we can bring in teams from Ethereum, Bitcoin, etc.

Running a candidate team myself, I couldn’t divest us of all other projects… but I could stop any work on competitors.

Other benefits – in the case where the ECC can’t fit into the allocation here due to the market, they could split and take part in this proposal as two arms-length entities, one with say in governance, one without.

Agreed, this one is tricky. I think if we took the full “strategic council” approach, where a strategy is set by a single trust or other entity, the ZF isn’t a good candidate. On the other hand, if the ZF is doing community engagement and diligence for dev fee candidates – and letting them set the direction, together – it makes more sense, and I believe it’s more resilient to future regulatory issues (if the ZF dies, the teams can continue work).

Very interested in feedback here. I don’t want to make the process onerous, but hoping for some level of “professionally run org” here. Note that the CFO req is just the principal dev, not all recipients, as I figure we need some longer-term survival guarantees from the principal dev.



Hi Matt,

Thanks for your thoughtful contribution. I have a few off-the-cuff clarifying questions, many of which are basically “can you provide more rationale for this bit”. (See my laundry list of disclaimers at the end.)

The truth of the first sentence here is evident to me given my position. The second sentence is confusing to me, and so I assume it would be confusing to most other readers without more context.

I believe the best way to improve this would be to link to specific public statements from those involved so that all readers of this post can understand the challenges you allude to. I believe this is especially true since we’re striving for decentralization and transparency, which means we need to do our best to include readers far outside of our social graph, who won’t understand the current (unlinked) references.

Would you be willing to do that?

I’m confused about the math here. Can you describe in English the case where the Max is larger than 500,000?

What is the rationale of limiting growth of the Foundation with respect to the exchange price?

Is the rationale for limiting the Principal Developer with the same formula the same rationale or different in any way?

What is the rationale for not limiting these recipients as with the other cases?

I’m concerned that this is a financial disincentive for potential developers to be a “principle developer” which has capped upside, versus any other selected developer, which has no upside. Is this intentional? Is there a counterbalancing benefit that could be spelled out?

What is the rationale for having two categories of dev fee recipients?

What is the rationale for an indefinite dev fee allocation and board seat?

Again, thanks for taking the time to develop this proposal!


Laundry List of Disclaimers:

  • This post comes directly from me and I haven’t sync’d with ECC leadership.
  • Nothing here represents ECC evaluations / stances.
  • The fact that I’m responding to this post relative to any other DF proposal posts or any other forum threads is completely solely due to me seeing someone retweet Matt Luongo’s tweet about this thread, and doesn’t represent any intentional plan of ECC. I wasn’t tasked to review or respond to this within ECC.
  • This does represent my personal bias, since I have collaborated with Matt just a bit in person at Zcon1 and found it enjoyable and productive and I was very curious what he would propose.

Excellent disclaimers!

Double-checking that I have a link to back this up. I’d thought James’ post on the dev fee covered it, but wanted to avoid linking because I think a lot of it is besides the point… will find another one or see if he’d like to jump in here to make that an open conversation.

Whoops, good catch! I LaTeX-ified this from a Python snippet and missed a coefficient- it should read

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

I’ll get that in the PR :blush:

There are a couple ideas here.

For both, limiting the upside per-month should incentivize captial-efficiency and saving ZEC now to get better upside down the road.

For the ZF, that to me should keep it from becoming a huge fund without direction and an opsec nightmare – I’m skeptical that the ZF would ever be making many millions per month and deploying that productively, versus “giving back” to the holders with a burn.

For the principal developer, the idea is that an appointment that’s 4 years by default, including a say in governance, can limit some month-to-month upside to favor saving for the long term. Not only is it pro financial discipline, it’s good for holders in the case of extraordinary price growth.

In the case of significant price growth for other dev fee recipients, there’s a periodic adjustment that happens every network upgrade. Other recipients are taking a larger risk than the principal developer, as they don’t know how long they’ll receive an allocation, and can’t, for example, borrow against future ZEC earnings in case of a rainy day.

Finally, the whole mechanism means that at some price point, the dev fee is “reduced” relative to issuance.

  1. “First among equals” implies a deference and natural leadership position, enabling a greater voice in setting cadence and direction amongst dev teams.
  2. The governance participation underscores that greater voice. Obviously that seat would be conflicted out of discussions around the principal developer.
  3. I believe there’s a place for an exclusive, longer-term allocation with more freedom from oversight. Principal developer would more easily be able to focus on research a year out, for example, versus other recipients which would need to justify their progress semi-annually.
  4. And finally, I don’t believe we can attract a diverse set of skilled crypto teams whilst requiring them all to be exclusive on Zcash. Many of the candidates that come to mind (us, Parity, etc) work in complementary ecosystems. I don’t think that’s wrong, as long as they’re held accountable and aren’t working against Zcash’s interests.

I hope that covers most of your questions - I’m going to revisit this with fresh eyes in the morning.

1 Like

As currently specified and the current ~$37/ZEC price, this proposal would defund and dismantle most of the existing Zcash development efforts:

  • ECC would need to cut down its expenditures from the current ~$700k/month to ~$200k/month, i.e., cease most activity.
  • Zfnd would be prohibited from doing in-house development, and would need to dismantle the stellar development team that it has recently built up and trained on the Zcash internals.

(See related discussion in the GitHub pull request.)

While decentralization is important, this proposal would destroy existing capabilities in vague hope that the resources thus freed may find a better use.

@mhluongo, I have a suggestion here. You seem to have strong opinions and big plans for development work you could do if funded. Perhaps you would like to explain your own plans (technical, timeline, team, etc.) and make the case for becoming a direct Dev Fund recipient? This will help the community gauge the potential upside of removing resources from ECC and Zfnd (whether under this proposals or others). Let’s do this in a dedicate forum topic. This would have the added benefit that we’d be talking about neat development plans and maybe brainstorming ideas, instead of haggling about the dev fund! We can revisit the funding later, with the plan’s needs in mind.


No prohibition against in-house development is included in this proposal. That’s a longer-term hope for the role of the Foundation, not an immediate requirement in the draft.

Frankly, I expect resolving these issues and getting back to business will improve the price as well.

There are a number of ways to address this. The ECC could split into two entities and net $400k / month, for example. It requires a little imagination, but using the ECC’s current burn as the sole number to optimize for here is putting the cart before the horse.

The halving is happening either way, and without a change in how things are done and the outlook for the coin, there won’t be well-funded development. We need a strong structure.

To be clear, the capabilities go unfunded by default – the founder’s reward expires, and there is no replacement. This proposal certainly isn’t to destroy anything, and I’d suggest we avoid emotional language like that to get to better clarity and outcomes.

We need to design something here that will last for the next 4 years, maybe longer, that’s resilient against a number of adversaries. I don’t think easy choices and carte blanche funding will cut it.

I’m intentionally holding off my own development proposals for a little while so we can discuss the merits of this structure – I figure this proposal shouldn’t be primarily about me or my team, and I’d rather not get into a situation where we’re designing for our needs versus the ECC or similar 0-sum thinking. I’d rather get this governance piece right.

Happy to answer questions about us as a candidate recipient, especially if they help clarify my rationale for this proposal. I just don’t want that to take the main stage until we agree about some things in principle.


I don’t want to go down too much of a rabbit hole, but this proposal can’t “defund” what isn’t funded. I think assuming the community will agree to “funding by default” is looking at this the wrong way. Coin holders are people who have invested their hard earned money into ZEC – assuming this doesn’t come at a cost to them and is “already ours” is a bad take.

Sorry if that was just loose language, but I want to be clear about my stance there and how I hope the ZF, ECC, and any other dev fee recipients would feel about this.


I am completely for the approach that considers the continuation of work without ECC, and in order not to lose groundwork in the fund, key employees from ECC can and should be invited who are leading important directions and have achieved personal success, in the current situation there was no alternative, as it was correctly noted that both the fund and the ECC do not provide a real alternative to what is happening, many have already expressed the view that the meaning of the proposals that have been submitted is lost because they simply will not be accepted under any circumstances (the company will collapse or -with returns that the company was originally fully in the project, as it can turn around, it’s like a confession of failure, or just a game.)

And you need to directly compare your vision with ECC, because it will become clearer which specialists are not enough to get the same, but only from one fund and more when you are added as a development team.
To avoid inaccurate presentation of thoughts after the translation, I wanted to say in other words:
I’m for another organization only if ECC loses in competition, so as not to consider because of fear that efforts will collapse, it just takes more to succeed, and 3 years is a gigantic period for a company in the crypto industry, this is the time when you can succeed with the right approach and strategy, and stagnation means that someone is ahead of you. If ECC has the right strategy, then this should be seen by some criterion, until all efforts are just efforts, and even HALO is not seen as a real achievement (in theory, everything is fine, but no one will wait another 4-8 years for implementation)

I like this proposal the best. It attempts to do away with some of the centralization in Zcash development while straying away from getting Zcash stuck in the tyranny of structurelessness.

My main issues with the proposals are the heavy emphasis on the Zcash foundation to pay out particular dev teams/addresses and thus the resulting power the Zcash foundation would potentially have if this proposal went through. There’s a lot of potential for capture here not only from a regulatory standpoint but from the dev teams working on the protocol layer for Zcash.

1 Like
  1. why burn zcash?

  2. halo is one of the most important developments in the entire space. i don’t mind calling halo the “holy grail” of block chain technology. what concerns me is ECC could lose funding to develop/deploy halo.

think i’d be more comfortable with this if ECC was guaranteed 80-90% of funding at least until halo’s deployed.


Agreed, which is why the Foundation would only propose those payouts to the chain each network upgrade, rather than paying them itself. If the Foundation is captured or goes away, the chain and recipients keep moving forward.

If there were rough consensus and the trademark were resolved, the community could even directly propose recipients, falling back to a Bitcoin-style governance-by-fork.

1 Like

I’m also excited about Halo, but it’s not an either/or proposition. Cutting edge research and resilient engineering can be funded together.

We’ll have to agree to disagree on 80-90% funding.

Some of us are quite sensitive to issuance, and don’t want to see too many large players that can manipulate the price. The idea here is to only burn if the ZEC is worth “more than enough” to recipients. The actual parameters of that are up for debate- maybe $700k a month is the “right size” for the principle developer, maybe it’s the right size for the ZF – I’m not sure.


Instead of burning, it would be better if this money was used for development, increase of grants, conclusion of contracts with other companies, you can also consider investments, all that will affect the development of zcash, for the sake of a joke: to release a phone with integrated privacy.
Hardware wallets, cards, street zcash machines.
In addition, a reserve is needed that will allow you to work in difficult times. ECC has a reserve, by the way, it can be spent for the implementation of HALO.