Decentralizing the Dev Fee

I don’t believe being accusatory or litigating the implying potential misbehavior of the board as it stands is the point of this process. It’s not productive. Instead, I hope we can use this process to agree on a structure that’s accountable, and removes these issues from being a possibility in the future.

EDIT: I misread a bit the first time!


Thanks for linking me on this @sonya. In case anyone is interested in how the Zcash Foundation currently deals with conflicts, I suggest reading this thread from the last time @boxalex brought it up. Quoting myself there:

Re: Board Members, no one on the Board is currently employed at the ECC, though you are right to be concerned about conflicts. In the case where the Board believes there is conflict, they need to exclude themselves from votes (see this amendment to the bylaws of the Foundation: ).

Later in the thread:

…in the case where ECC’s interests are conflicted with the Foundation [then Board members who are ECC shareholders] are conflicted out of Board votes. This has not happened yet, but if it does it will be reflected in the minutes per the bylaws.

In any event, I would strongly oppose removing this policy, and everything I’ve seen about this proposal suggests it would reduce the likelihood of conflicts by broadening the board composition (though I have some concerns on that, more on that below) and requiring that “no board members have an ongoing commercial interest in any recipient of the dev fee.” (which is a great restriction!)


I’m going to refocus on proposal feedback. In general, there’s really a lot to like here @mhluongo, and I think you’ve done a better job synthesizing than (my now less aptly named!) attempt at a synthesis ZIP. A few caveats to anyone reading:

  • This is my personal opinion and not anything official from the Foundation
  • Matt talked to me about his in-process ideas at Devcon5 and I provided some limited feedback
  • I’m biased because I’m currently employed by the Foundation (and thus the Foundation’s current board)

In broad strokes, here’s what I like:

  • The goals and amount of funds to disburse makes sense to me, as does the idea behind a max cap for the ZF/principal developer disbursements (though like @mistfpga I’d really prefer not burning funds, more on that in a minute)
  • As I’ve mentioned before I agree that rather than a new, untested body, any entity controlling disbursement should either be a Zcash Foundation with new restrictions or a minimalist trust, and I’m glad to see that here
  • I like the intent behind the board changes to the Foundation to broaden stakeholder input, but like @tromer I have some concerns about the transition and maintaining consistency in current Foundation efforts
  • I suspect it would greatly broaden external developer contribution, which is a Very Good Thing™ for Zcash
  • Creating an opportunity for (accountable) continuity through a Principal Developer is a good idea
  • It’s well thought out and incorporates good ideas from many other proposals on the table

Some areas where there are open questions/concerns for me:

To Burn or Not to Burn

This is a less critical issue for me than my other open questions, but I have a mild preference for not burning coins — are there any other palatable options here? How about the coins above that amount are required donated to a an orthogonal but mission-aligned nonprofit that accepts Zcash (Tails, Tor, Open Privacy, etc.) at the board’s discretion? Then it wouldn’t affect supply while benefiting the broader aims of the Zcash ecosystem.

Incentivizing shielded adoption

My favorite part of my proposal was the idea of linking payout percentages to shielded adoption, which was something @tromer had brought up in the forums some time ago. I think there’s still room for that here but perhaps it can be enshrined in the criteria used by the new board to judge future dev fund recipients.

Accountability details and Foundation + Principal Developer requirements

My second favorite part of my proposal is the requirements surrounding disbursement for obligatory recipients of a fund described here. I’d love to see some of these integrated here…maybe not all of them, but focusing on reducing the risk that a Principal Developer may buy out or guarantee some flow of the dev fund to pre-dev fund/non-employee shareholders is really important IMHO.

On the principal developer’s board seat

A board member with any financial interest in the principal developer is a potentially existential risk, due to concerns around inurements in US-based nonprofits. An easy way to fix this is simply remove “outside the seat for the principal developer” — they can still choose a friendly representative outside the organization/principal developer shareholders, but we’d avoid the self-dealing risk. (Note that this hasn’t been an issue today even with the Foundation board having three ECC shareholders; the Foundation has never retained the ECC for any work or directly funded their efforts)

On the research seat

It’s not clear to me how the “research advisory board” would be created or how those members are selected…which is a smaller version of my issues with the other strategic council approaches. I think we could simply make this a “technical member” of the board with the same goal but dispense with requiring the creation of another board-like entity and leave it to the rest of the new board created by this proposal.

Board details and Foundation continuity

My biggest concerns are here. I’m not opposed to fundamentally re-imagining how the Foundation board is selected — but this proposal suggests a rather rapid shift. It’s understandable given the new scale of the Foundation’s duties, but it’s also very risky to do all at once and immediately after the dev fund is established. If this board structure were to be required immediately after activation, it’s conceivable that the board is completely refreshed (e.g. 3 new board members join, vote off the 2 remaining board members and select 2 of their own based on the way the bylaws currently work). Given that this proposal selects the Foundation for this body because it’s already established and has been working for the Zcash ecosystem for many years with reputation and trust, the possibility of a complete board shift worries me. It’s also not clear to me how frequent these elections are supposed to happen.

This is not an insurmountable issue, but it’s a critical one. Here’s my suggestion on how to fix it through board composition and election frequency:

  • 1 seat voted on by ZEC holders directly, elected every year (or sooner if the member resigns. In any case, this seat must be elected by ZEC holders through a coin-staked vote). There would be open elections held by the Foundation similar to the 2018 advisory process which resulted in Ian and Amber’s election, except using a ZEC coin-staked vote directly.
  • 1 seat for the “Principal Developer” with the non-shareholding restriction above. This seat stays for 4 years. (if they resign, the Principal Developer and only the Principal Developer can elect a new representative)
  • 1 seat held by a technical member for doing due diligence on dev teams. Initially this member will be selected by the Foundation’s legacy board, then every year they will be elected by the other members of the board. (their vote does not count!)
  • 2 at-large seats elected by the board, as the board is currently selected according to the bylaws, with a modification to make it a 2 (instead of the current 3) year term. Initially these two members will be selected by the Foundation’s legacy board.

Here’s how these modifications enable a smoother transition to a broader board:

  • At beginning of year 1 (e.g. October 2020 to October 2021) there is guaranteed to be a slight board majority supplied by the legacy Foundation board. (3 members elected by Foundation Board) This grants the Foundation an opportunity to transition into a new board structure while acclimating to its expanded role.
  • At beginning of year 2 (e.g. October 2021 to October 2022) the 2 non-legacy members (ZEC-voted seat, which may or may not have a new member, and the Principal Developer seat) and 2 legacy members would have to elect (or re-elect) the technical member. In this case it’s possible it will transition to a board where there are 3 new members and 2 legacy-selected members.
  • By beginning of year 3 it’s possible that the entire board has changed its makeup (as four seats will be up for election then).

This ensures a smoother transition but ultimately leads to a board that will eventually be much more influenced by the Principal Developer and the rotating ZEC holder and technical seat. There are some intricacies on the timing of elections here but I do think it’s preferable to do something like this (even when trying to remove my admittedly extremely high bias for Foundation stability).

On combining proposals

Great work Matt! If my concerns are addressed above, I’d actually feel more comfortable supporting your proposal over mine — or modifying mine to fit yours.


Hi Matt,

Thanks for the detailed response. :slight_smile:

To be clear at the outset, I am one of the people against continuation of funding “for profit companies” from mining distribution. (I am unsure if I am in the minority or not though)

That being said I am giving a lot of attention to this proposal because it seems to have broad support. I see a few minor tweaks to make me happy.

I still think it would be better in NU5 or 6 though - more time for hand over and more time for coins to be distributed.

This is part of the problem, I could also be wrong. I think we are speculating on an untested area of game theory. We are not at the first halving yet (and even then only 80% have been issued to miners).

The gameification I was talking about was something along the lines of we know the dev team failed to meet a target, so x coins are going to be sold in y days. - I believe this would cause a run on the coin price. The UK did something very similar when Gordon Brown (then chancellor of the exchequer) announced on a Friday that next week the UK would sell half its gold reserves. - yeah you can imagine what happened. (but with hindsight, it was his intention all along to force the price of gold down. cost the UK billions. saved a country or 5 though, cough)

The % seemed a little strange to me, but if the foundation says “nah, they are fine, we like them”, then I am not going to argue (paraphrasing @acityinohio) - I will let others work out those details.

Adding additional distribution mechanisms would be great. Although I was more saying “please don’t break the current model”

This isn’t really what I meant. I was and am still concerned that this might take resources away from small teams/individuals from participating because either there is not the reward there for them (it has already been given to the dev fund recipients) or the work gets rejected because one of the 3 companies says “oh we are already doing that”.

Then you have the people who will add to opensource projects “just because” the initial dev fee proved to be a bit of a sticking point for these people. (based of principles) I would like that to stop.

there is something inside me that just feels “dirty” about deliberately enriching for profits companies for free. - I know this is a “me problem” but it is a problem a lot of “me’s” have. Is there any mechanism you can think of that might help address this? I am trying to think of some too.

Okay, so who has control of the trademark? the ZF and ?

I pretty much have similar concerns to @acityinohio so I wont ask those questions, I imagine your responses to his post will cover a lot of the stuff I was going to ask.

Thanks for the time, and feel to answer my questions in the same post as answering josh c.

Are you sure about this? like really sure? dilution is not the solution to pollution? idk. im not getting involved. just making sure that you are sure you are sure. (that reads really well, go me!) [no need to answer just highlighting it]



Hi Matt, nice proposal. Seems very reasonable to me. I like the discussion at the beginning about taking Zcash to the next level and think it would be awesome to get Keep, Summa, and other teams more involved in Zcash.

Here’s the big question for me: How necessary are the hard coded allocations — do we need an allocation structure this rigid? Could the percentages instead be determined by the Council on an annual or biannual basis? I’m totally for getting more dev teams involved, but I think the focus should be on leveling the playing field for organizations looking to compete for Zcash community funds, rather than forcing funds to go to new teams. If the ECC is the best team for the job, they should receive funding. If there is another team better for the role, funding should go to that team.

Just as there are risks from an abrupt shift in governance, there are risks associated with an abrupt shift in the allocation of funds — e.g. using 10% of block reward to shop around for new dev teams could choke the progress of existing Zcash developers & researchers. I would lean in favor of a more flexible funding structure that allows for a smoother transition to decentralized development.

I heed your point on the difficulty for new teams to commit to working on Zcash, so if you think it’s necessary to hardcode allocations (especially a % to new dev teams), might it make sense to reduce the new dev team allocation to 5%? The additional 5% could then go to anyone (including ECC/ZF), as the council sees fit.

Also, any plans for evolving the council? Curious if you had anything in mind here. I see a clear path to replacement for council members as an attractive feature to have.

Also, just a comment on council seat allocation. Here’s how I map out the different proposals:

There is a tradeoff at play between the risk of the transition and the level of decentralization in the initial construction of the council.

Provided that council members have a clear path to replacement, less risky is probably a better bet. Matt’s and Josh’s proposals both sound reasonable, and it makes sense to use the ZF board as a foundation for the establishment of the council. If members on the council underperform, they can always be replaced.

1 Like

The closest I’ve seen is @mistfpga’s idea to “extend” the supply curve rather than burn. I personally want to avoid donations to a centralized org or anything that could be seen as political, as I see this mechanism as “close to the chain” – if it were easy to accomplish on-chain without a bunch of consensus work, I’d prefer the allocation were made smaller rather than any entity burning or doing anything else with the proceeds.

Today’s noble cause is tomorrow’s villain, so we should avoid specifying outside orgs to receive donations at this level IMO.

I went in the opposite direction here, intentionally. I’d rather leave the Principal Dev the ability to hedge against future proceeds, etc, and give the ZF a “bad faith” ripcord to pull to end the Principal Developer’s allocation.

The sort of restrictions I’ve seen proposed can always be subverted, and seem to obstruct some responsible decisions the company might want to make. Better to avoid detailed overspecification and instead focus on the happy path, with a remedy for extraordinary situations.

I like this a lot. On the other hand my hope here was to make sure this seat was conflicted out in any discussions around the Principal Developer’s allocation or performance… is that still achievable?

I’m open to suggestions here. The research advisory board was an effort to have a place to “put” all of the technical advisory talent that’s working with the ZF, maintaining a formal relationship and an opportunity for governance participation. I left a lot as an exercise to the reader here. Thoughts on how we could achieve better first-class representation of research and technical interests on the board?

Heh, I should’ve mentioned that I expected a transition plan from the ZF in the proposal. Looking for a good spot to drop that.

I like your take after a couple reads – if we align on this proposal I think it could lightly formalized and included. In the meantime, I’ll try to make transition expectations more clear in the proposal, likely under “non-requirements”.


Thank you @mhluongo for your contribution (and for the shout out), it was a great read! I like it.

I’m going to comment via other’s comments first as some of my own initial sentiments have already been expressed.

Question, @mistfpga would this not reduce the value accrual of ZEC over time? Basic supply/demand economics, halving typically drives pricing upwards, if we put back ZEC and extend the next halving, wouldn’t that contribute to a slow growth?

I disagree, I think this is pretty feasible in the short term, conditional that ECC agrees to receive 1/3 of the remaining 20% dev fee (i.e 25% of the 75%)
and that ECC agrees to solely work on ZEC - two conditions which I glean have been a strong point of contention for ECC.

I’ll refer back to my proposal - I agree that this is a gap in @mhluongo’s proposal.


The Zcash , Zcash Foundation, and ECC must work together to develop and achieve consensus on auditable metrics that:

  • Show quantitative value to the ZEC economy
  • Track against the strategic roadmap
  • Can be measured and audited by anyone
  • Allows for flexibility in terms of failures, pivots, and adjustments

The Zcash Foundation will contract or hire[4] an individual(s) with the proper pre-requisites (background in blockchain, data, analytics, and design) who will solely be responsible for working with the Zcash Foundation, Electric Coin Company, and external developers to:

  • working with the community to define and communicate auditable metrics with product developers (i.e. ECC and external developers)
  • communicate with the Zcash community and host live votes
  • consolidate and publish voting results, feedback, and suggestions at a defined time interval
  • host Quarterly hangouts for discussions

The independent authority who will be responsible for ensuring the legitimacy and validity of reporting will be the Zcash community .

Moving along…

I also agree that there is another gap, @mhluongo, in terms of how to fix the existing grant funding mechanism.

I had a few ideas, but they did require more of a governance procedure/ application… @mistfpga on-chain governance was out of scope for @mhluongo proposal, which makes sense to me. It may be a phase II item: Priority #1 figure out how to allocate funds
Priority #2 figure out how to manage fund disbursement and metrics
Priority #3 figure out decentralized decision-making applications (both on-chain and off-chain)
With a dedicated team and active community, I’m hoping that a lot of ground on these three priority items can be covered in 1 year’s time.

@mhluongo curious to know what you think about my Vesting idea. Decentralized Participatory Voting through VESTING

@mistfpga you lost me here. Isn’t the point for the teams to 1. get funded and 2. build/ implement the ideas

On this, @mhluongo there’s a gap on entry-level participation for teams and/or individuals to begin to learn the code-base. Your 75% Dev Fund mirrors my Endowment Fund, but my ‘Zertilizer’ attempts to address flaws within the existing granting mechanism. Maybe there’s a blended approach that could be explored?

@mistfpga in response to this:

I think it’s a well-balanced meritocracy due to the inherent veto abilities of the network:

and the structure of the ZFND board, as proposed:

I am a little concerned about this:

@mhluongo could you explain to me why a team could receive Dev Fund money but also be justified in not working on ZEC?

Things I really liked with this proposal:

  • It’s well balanced between addressing short-term, immediate needs and nodding to longer-term governance
  • It proposes a roadmap to inclusion of external developers (despite not necessarily addressing the current issues with grants)
  • while also preserving stable funding for the principle developer (aka: the ECC)
  • It’s clear, actionable, and able to implement immediately.
  • It moves ZEC towards a Meritocratic and more decentralized governance structure

Things I would like to address:

  • It’s fully dependent on the 20% fee from miner’s rewards, I’d prefer a blended approach (like my endowment mechanism) to hedge against risk (aka: temporary reduction in ZEC value and/or hash rate.)
  • It does not address how metrics will be determined and by whom and how much weight they will carry in decision-making.
  • It proposes a Burn Rate

More on Burn Rate
Burn-rate seems like a misalignment of incentive. Metrics, roadmaps, and milestones should keep stakeholders financially responsible and accountable.

Using burn rate to ensure financial responsibility can be uninspiring and thus hamper motivation which can drive developers to other projects which do not cap their return on time/ effort/ capital investment.

If a burn rate is nonetheless decided upon, I’m against discarding the coin. I’m also against moving the halving, as suggested by @mistfpga. This is probably crazy, but I rather distribute the burned coin to all ZEC holders (yeah, even if it’s only fractions) and encourage the network to hold on to them.

Finally, I agree with @avichal here:

And would like to eventually see ECC compete for Dev fund allocation like all other principal developers - something like my Equity fund proposal whereby a track-record of excellent work can make eligible an external team to apply for that 25% reserved for the principal developer.

However, I do disagree here:

I think the suggestion of eligibility around a CFO is fantastic and I would actually extend it to all applicants, with a caveat to make things less onerous, that the requirement of a CFO is only triggered at a certain level of funding.

There are a few comments/threads that I’m still working through- and that some of my questions/comments may have already been addressed- but I’ll continue to post along as I get through the rest of it.


@mhluongo, can you please clarify whether the Foundation would be allowed to use its 25% of the Dev Fund to conduct in-hourse R&D work, as it’s currently doing?

The phrasing above implies, by omission, that the answer is no. You seem to have confirmed that here, but then denied it here, and did not respond to my question here, so I’m confused…)

Also, can you clarify what is the intended difference between the two kinds of 3rd-party funding: “short-term development grants” coming from the Foundation’s 25% of the Dev Fund, versus the other 50% specified in the following?

(50% of the total), called the “outside development fee”, shall be distributed between at least two development teams, chosen semi-annually by the Foundation

(Recall that most Foundation grants are already on a time scale of half a year.)

Lastly, revising an earlier question:

ECC would need to cut down its expenditures from the current ~$700k/month to ~$200k/month, i.e., cease most activity.

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.

ECC’s current burn rate is the best factual indication we have, at present, for the amount of funding needed to do the corresponding work. This is not gospel, and you can cast doubts, but the onus is on you to argue with this factual information, because by default it is reasonable to assume that reducing funding from $700k to $200k/month will cause great harm.

If you doubt it, please make your case. Do you believe there are ways to do the same work as ECC more efficiently, or that some of ECC’s work is not needed, or that ECC can be broken up without harming its productivity? How?

Frankly, I find the attitude here to be dissonant. On one hand, we have plenty of factual data on ECC’s burn rate and work, but this is dismissed offhand (“requires a little imagination”). Conversely, without any factual information, the proposal allocates at least twice that amount to unknown new independent parties, that will be doing god-knows-what, with heaven-knows-what-teams, in faith that this money will be better utilized.

I’m all for decentralization, but not for cutting off limbs in hope that better ones will grow out.


I’m not sure I understand this. Could you please provide a little spreadsheet-style table showing how much USD-worth of coins the Principal Developer would get at various levels of the ZEC coin price?



Im a bit sick at the moment. So I will try to keep this brief.

agree. I think that the algo taking care of the distribution is best. there are several mechanisms I have thought of that don’t require much fiddling to get working, it is just picking which suits. I will post my burn thread in a bit, when I feel less sick.

No, I cannot see a reason why [I know nothing of economics]. burning coins effectively drives total issuance down and the emission supply down (and maybe the rate up, but that’s the same as total issuance down isn’t it? idk. I cant think properly)

I think taking coins out of circulation is a bad idea. extending the halving or tail emission is a simpler task, and makes sure ~21million are issued to spendable keys.

It only puts back the halving by the number of “burnt” coins. If the halving block number schedule is imperative then put it on the tail end of the emission, there are no rules for that, just it will end eventually. I will elaborate more in a separate thread.

This just seems like such a big chunk of money to take away from the ECC, can they realistically keep the lights on with that amount of funding? I do believe we need to transition to a model that allows the ECC to develop other revenue streams and bigger “full chain” or whatever its called, development teams to enter the space.

They either have to be replaced entirely buy… idk, I have yet to see a proposal from any company that says what they would do with the funds, just proposals that say funds should be allocated in a certain direction. (which is cool, but if the ECC is going to be replaced I would really like to see concrete development plans from these teams and be able to evaluate them myself before cutting out the ECC completely - The only people I can really see who are able to judge this is the zfnd. we have what has been promised and what got delivered, but these two things never match up - feature creep and unexpected things always make stuff changeable, so id love to hear how the ECC thinks they have done.)

The ECC’s lack of position on this topic is frustrating, but they have laid out a plan and a cost base. To be fair I cant really see them being able to stay open if the price stays this low. that makes me sad.

I will start a separate thread about this. Someone else asked me to do this too. I think it would be better in its own thread. as not to mess this one up.

No, this isn’t about teams for me. It is more trying to get the open source feel back in. I will expand on this in the new thread. but the essence of it is to allow “contractors” to work on the protocol. after they have done the work. I guess the best likeness is bounties, but no one asked for the bounty.

The issue I was trying to highlight is if xyz comes along to and says, “I think this is a great idea, I have already started to implement it, will you pay me?” the company could just say “no, we are already working on it” - when they were not. this pushes out people with the skillset to add to the community from tailoring it to zcash, their is little incentive.

That’s all I was trying to get across. If a big company can get paid, can they assure that individuals cant too?

Im going back to coughing. :slight_smile:

if this seems a little odd, blame the bottle of cough syrup.

1 Like

Confirmed, in-house R&D is fine. The balance I’d like to strike is this

  • Eventually, the ZF should hand primary maintenance of zebrad to another team, as there’s a soft veto power distorting this system- and spread development efforts across clients.
  • The ZF should take care to not discourage other dev fee recipients with their choice of work.

I’m not trying to stop R&D at the ZF, I am trying to focus it in support of a strategy chosen by the client teams.

Indeed. Dev fee funding is worthwhile for longer-term efforts, and is meant to attract longer-term talent. The funding isn’t less strictly scoped to deliverables, and is suitable for work like building and maintaining an entire Zcash client and other ongoing concern in the ecosystem. Recipients of this fee should be party to setting strategy for Zcash as well as execution.

To make this concrete, I’d like to see this funding mechanism draw a client team from Ethereum, Tezos, or another full-stack team of similar skill to make Zcash a priority.

Compare this to a grant, which has a scoped deliverable. If it helps, you could think of this as a “fellowship for dev teams”.

I’m struggling here. I’d personally rather focus on moving forward, but as someone quite familiar with software engineering, of course I believe we could get similar results more cheaply. At bare minimum, by focusing on the things that matter most, and doing less.

I appreciate that you’d like me to pitch an alternative to the ECC rather than a structure, but as I’ve said, I don’t believe comparing companies is appropriate at this phase. We’re talking about governing a cryptocurrency for the next 4 years, and bringing it back to “which company is better” is… well, it’s backwards and demonstrates the problem.

We need to build a robust, decentralized ecosystem. To me that’s a given – this is about values. If we disagree here, I’m not sure we can have a productive conversation.

Certainly. Split the ECC into research and execution components. Have the research component act as the Principal Developer. A separate entity can take on all engineering and marketing work currently done by the ECC, and maintain zcashd. Make the second entity a 25% recipient of the dev fee.

The entities now get $400k / month, under a strong accountability regime. If the execution-focused entity needs more funding, it can work outside Zcash. Outside developers can compete with the execution-focused entity, and the ZF can decide allocations periodically.

can be broken up without harming its productivity? How?

A decentralized governance system will be slower than a centralized one, but it will move forward with greater community interest, public buy-in, and public support.

You might want to check your priorities. A centralized privacy coin will eventually be challenged, and destroyed. I’d like to see Zcash survive long-term, against powerful antagonists, and this attitude won’t cut it.

1 Like

Yes! If you’re at a point where the idea is so fleshed out that you’ve actually started implementing it, and it is indeed a great idea, then you’re in great position to apply for a Zcash Foundation grant!

And since the Foundation explicitly strives for diversity and decentralization (e.g., the “zebra” node), it’s fine if ECC works on similar things.


Hey @JacobPPhillips, thanks for joining the forum!

Absolutely! I was rigid here to help fight the monopoly we currently have, which I believe has some negative secondary consequences. I have no issue with eg the folks at the ECC splitting up and taking all of the dev fee, so long as they’re economically distinct entities.

Allowing competition means allowing competition to grow, and I think we need an active constraint against today’s “monoculture” to support that.

I agree with you, and I tried to leave a bunch of space for the ZF to introduce a transition plan or otherwise adjust their board structure (eg by binding the free seats to other community votes). They have that latitude today, so I see this as a starting point

1 Like

Data point: when fellowships were discussed in the context of the prior grant program, there was a lot of resistance from community members and within the grant review committee to giving such carte blanche funding (even on a much smaller scale). Strong sentiments were expressed in favor of deliverable-oriented funding. Note that the committees did not have anyone employed by ECC or Zfnd, and did have people from other communities (Ethereum, Cosmos etc.). We did end up awarding some fairly open-ended grants, but only as a tiny fraction of the total budget.

The proposal at hand would go against that, by forcing at least two thirds of the funding to be carte blanche “fellowships”. Moreover, it would force such funding regardless of how the merit of those fellowship-seeking teams compares to that of worked-out, well-reasoned, deliverable-oriented proposals.

Split the ECC into research and execution components. Have the research component act as the Principal Developer. A separate entity can take on all engineering and marketing work currently done by the ECC, and maintain zcashd .

This is infeasible. The people doing research at ECC are the core cryptographic engineers that are also maintaining zcashd, protocol specifications and critical libraries. Similarly, the marketing and engineering are closely intertwined (e.g., outreach and hand-holding of ecosystem developers).

1 Like

Sure! I’ve flubbed the actual formula twice now, thanks for asking. Here’s a Google sheet you can copy and play with.

At 12.5 ZEC / block, that’s

Price of ZEC Principal Dev Allocation (monthly)
$30 $324,000.00
$50 $519,615.24
$80 $657,267.07
$160 $929,516.00
$320.00 $1,314,534.14
$640.00 $1,859,032.01
$1,280.00 $2,629,068.28

Post-halving at 6.25 ZEC / block, that’s

Price of ZEC Principal Dev Allocation (monthly)
$30 $162,000.00
$50 $270,000.00
$80 $432,000.00
$160 $657,267.07
$320.00 $929,516.00
$640.00 $1,314,534.14
$1,280.00 $1,859,032.01

EDIT: Updated to include post-halving numbers, thanks @tromer!

1 Like

[edit: ignore this, the table above has been fixed]

@mhluongo I think the numbers are half that. Post halving, the block reward is down from 12.5 to 6.25 ZEC/block.

(There’s also Blossom’s reduced block time and proportional reduction in block reward, but these cancel out.)


Most proposals on the table now fund the ECC the same way. All this proposal is doing is bringing multiple interested parties in to compete for the privilege of serving the chain and coin holders. I disagree with the “carte blanche” characterization, as it’s the role of the ZF in this proposal to do diligence and hold recipients accountable, but if you believe that characterization is correct, are you also against any proposals that fund the ECC without detailed grant-writing for all of their efforts?

There’s nothing to stop two separate entities from working closely together. I’d be interested in why you believe cross-entity collaboration is a non-starter

1 Like

Thanks, they are – my givens are in the spreadsheet, but I just copied them over. Editing for clarity, and to show the pre and post halving numbers

Excellent point. Indeed, I and others have said many times on this forum that ECC should explain its strategy and plans going forward. Several of the proposals explicitly include this element. I think it’s healthy to think of this as a “grant application”, to be judged either by the community as part of the Dev Fund decision, or by a higher-level governing body (in the proposals that have one).

As you already recognize, ECC does have a special role and track record, making flexibility and discretion easier to justify. Still, I would agree that many of its activities could have been funded by deliverable-oriented grants. The difficulty is: grants awarded by whom? The only body we have with the requisite structure and expertise is the Zcash Foundation, and for the sake of decentralization, we probably don’t want to put ECC’s funding completely at the discretion of the Zcash Foundation. And so we’re forced to compromise on this point, whether by giving ECC a carte blanche to execute its “grant proposal”, or by instating key-performance-metrics consensus mechanisms for incentivization (as in my idea, that got integrated into @acityinohio’s proposal).

Neither of these special circumstances arises for the hypothetical new teams, so ECC’s situation does not reflect on whether those should receive fellowship/carte-blanche funding.

1 Like

It’s also worth mentioning – there’s no reason the ZF can’t have a much higher standard for anyone accepting a dev fee allocation than what I’ve outlined so far. This proposal isn’t meant to limit the rights of the ZF (except of course where it explicitly does), it’s meant to provide a structure that’s amenable to community participation, failover to a rougher crypto-native consensus in case of hostile intervention, and to encourage longer-term participation by professional development teams.

The board could certainly iterate on a legal accountability framework that’s consistent, but further reaching, than this proposal. In fact I’d hope it does.

EDIT: The only edge case I think this point calls into question is how to enforce a “use it or lose it” type structure on the 10% outside dev fee allocation.

@mhluongo, so the Foundation would be allowed to make those “50% outside devs” funds be deliverable-driven grants/contracts? Well that changes the calculus [1], and allays that concern of mine (and the past grant view committees…). But then, going back to my original question — it becomes unclear what’s the difference between the 25% grants and the 50% “outside devs” funding.

More importantly, I’m still struggling to see a satisfying answer to the following. Consider the following possible scenario:

  1. ZEC stays around the current price, so about $600k/month (75%) are available to the “big” developers.
  2. ECC gets just $200k/month and is starved, but cannot be broken up (yes, you think it can be; based on deep familiarity, I disagree).
  3. Not enough good new teams show up with good proposals to use $400k/month (at a level of efficiency close to ECC).

Then what? Do we waste the Dev Fund on bad teams, or burn it, or save it for later? While ECC is forced to fire most of its employees and halt most development and outreach?

I’m especially worried about this scenario because it’s not a remote hypothetical; it’s the default if your proposal is implemented.

[1] Could you please clarify this point in your proposal? As well as adding “development” to the list of things the Foundation can do with its 25%?

(To be clear, I don’t mean to imply anything about your team. I have no idea what’s your team, and even assuming it’s wonderful, whether it can productively use $400k/month.)