Decentralizing the Dev Fee

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:

3 Likes

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.

4 Likes

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

2 Likes

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.

3 Likes

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

4 Likes

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.

Agreed.

2 Likes

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!

regards,
Nathan
CTO @ ECC

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.
3 Likes

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.

4 Likes

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.

EDIT:

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.

4 Likes

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.

2 Likes

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.

2 Likes

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.

2 Likes

Rephrasing tha – tell me if you like it just as well.

“Instead of returning excess value to coin holders, it would be better if the excess ZEC was sold on the open market.”

What do you think?

The idea here is that there’s only so much ZEC that a team can deploy effectively and responsibly, and that every dollar deployed poorly is at the expense of coin holders and the market price.

If there is a strong belief that it should all be deployed (cart before horse IMO), I’d lean toward capping all recipients, and adding a longer-term chain-managed dev fund for the excess fee. But that’s complex, and I’m not sure it would be better managed, just differently managed. It’d also be also quite similar to the existing grants program, so I question what that models brings to the table.

1 Like

Not exactly what I had in mind, investments, including in zec and not in dollars, which will increase the chances of massive adoption, as well as make it possible to develop over the budget. The idea is not to stop the growth of the sale of the fund’s bag, but to improve the ecosystem at the expense of free funds (the salary and costs are prescribed in the accounts department, the rest goes beyond the plan)
Do I understand your point correctly?
I’ll clarify my vision of the situation, even if you limit the sale, price and popularity will not increase, but if you increase the need for zec, both price and popularity will grow regardless of sales.

1 Like

Is this an additional entity? I’m loathe to propose putting a bunch of money somewhere without a compelling team, vision, or governance.

Note that “investments in ZEC” will always turn into “investments in dollars/euros/pesos/etc” if the investment is to fund someone’s small operation. Small teams have to liquidate incoming crypto to cover expenses. Breaking out of this requires a robust circular economy. I’m really excited about this piece, but I don’t think we can wish it into existence.

1 Like

No, this will be the work of the accounting fund.
Yes, I understand, but the percentage of the total supply will be small, so this will not affect the price. In addition, during the development of the ecosystem, it will be possible to get something in zec and not in dollars, so it is not necessary to sell immediately (in the future).
Agree with my thought that sometimes development determines the price and not the offer on the market, therefore if the investment or development will influence the development, then the price will only increase.
Let’s take as an example ETH at the time of launch there was a high emission and problems with launching, but this did not affect the rapid development of the project, for zec there is still a large part in the real world, you need to find and master it.
The first thing you can do is direct transactions, for example, an investor wants to get zec at a current price in a certain amount, he makes an application and if the application covers the need for financing, he transfers the amount in dollars to the amount in zec without moving on the market.