Decentralizing the Dev Fee

Community Collaborations protocol
21

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
22

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
23

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
24

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.

25

@mhluongo, thanks for your replies! Some further comments:

So the Foundation is at liberty to continue in-house development, it just won’t be allowed to use the Dev Fund to pay for it?

To be clear, the capabilities go unfunded by default – the founder’s reward expires, and there is no replacement

We agree, the default would be to defund and thereby destroy (even more of) the existing development capabilities. That’s bad and is why we’re even discussing a new Dev Fund. My point is that your proposal would cause much of the same harm.

I see preservation of existing capabilities as a crucial consideration, given the difficulty and uncertainty of rebuilding them anew. So proposals that would preserve existing capabilities are IMO vastly preferable.

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.

I see your reasoning. However, for me it’s hard to speak of governance/funding in idealized hypothetical, without a solid grasp of the concrete issues that this governance/funding would resolve. Concretely, we would be trading off the loss of existing capabilities for… what? Are there enough projects and teams waiting in the wings to productively consume 75% or more of the Dev Fund, with better results than the existing teams? Or conversely, perhaps those hypothetical projects would actually fit nicely, in scope and nature, into the Foundation’s current granting system?

2 Likes
26

@Anton1, I don’t follow your reasoning here.

The facts are: We started with just ECC. Then Zfnd was created and offers “alternative” roads for Zcash development: both Zfnd’s in-house capabilities, and the many grants and contracts it has awarded. We have dozens of independent organizations of all sizes, and individuals, who are or were paid for their good work on Zcash.

So now you’re looking at this, saying it “not provide a real alternative to what is happening”, and therefore should be mostly dismantled?

2 Likes
27

No, I’m only talking about proposals for future financing, I don’t discuss the work of the company or the fund, and I don’t even say what should be destroyed, on the contrary, now all proposals are considered only with the ECC in the main organization, the developer, at the same time it was said that this is not necessary , I asked the fund “what will happen if there is not enough money to pay for ECC” in response I did not get a real answer, therefore I say that there is no alternative, there is only one option “money should be enough for us to continue,” but it should be vice versa - we continue and Studs success so we have enough funding.

1 Like
28

This concern applies to any governance mechanism that involves human discretion. Of course it applies to the Zcash Foundation. It also applies to the top-level 5-member committee instated in this proposal, and the various other top-level committees and Third Entities instated by other proposals.

Now here’s the thing. The Zcash Foundation’s Board of Directors already exists, and has served us very well so far. Conversely, those other envisioned committees and entities don’t exist, and none of the proposals requiring them (including the present one) even explains how exactly they will be populated and ran.

So it feels like there’s a lot of fear about the known-and-so-far-good, while being starry-eyed and idealistic about the unknown. That’s irrational.

4 Likes
29

I have some problems with this sentence.
First, i don’t think it sounds good if the foundation praises itself, this should come from outside the foundation if people/community are happy with the work the foundation so far did or didn’t do so far.

Second, while i see some good attempts by the foundation i wouldn’t go as far as calling these as a really good job. Much more could have been done by the foundation in time. The Trademark issue is an good example. This should have been solve way bevor beginning of any dev fund discussion. Same goes for many other issues where in my opinion the foundation is more than lagging.

Third, i never have hidden that i have a “strange” feeling towards the founders within the ZF. From the huge Founders Reward, which is x times bigger than the dev funding, from which the ZF is “financed/sponsored”, the same people (founders) that are as well shareholders within the ECC have a big say in the ZF. That’s such a strange setup than i still have problems honestly to believe that all what they do and want is best for the community/holders with such tight connections to the ECC. The choosen distribution of the Founders Reward which ensured way more personal profit for the founders than spending for development doesn’t make things better at all.

And last but not least, i’am pretty sure that all the above mentioned is exactly, or at least part, of the reasons why a broader part of the community/holders want an additional entity for good reason.

Talking about irrational. It was more than irrational to choose such an issuance rate, it is in my opinion more than irrational having choosen by default only 4 years dev funding at the mercy of the founders, it’s more than irrational to me that the founders get x times more than the whole funding for ECC/ZF togehter.
Isn’t it irrational to have the main part of the funding at a time when the highest inflation is set? Isn’t it somehow irrational to have a community funding a for-profit company? Isn’t it irrational to have a for profit company giving away it’s product for free? The list goes on and on about irrationals that i still don’t understand …

One thing that leaves often a bad taste at my end is that the community was asked to make proposals and more than often i see either the ECC or the ZF or both together interfering these, especially the ones that are not 20% funding and include another entity or a shift of power. On the other side, often questions that need to be answered to push a proposal forward stay unanswered forever.

3 Likes
30

why not just add it on to ether the current halving schedule, give it to miners (as initially promised) or tack it on to the curve at the end?

Wouldn’t your wording make the market very predictable and gameable for speculators?

31

Most of those schemes require on-chain price data or other implementation complexity. I have some experience there and it’s not something we want to do with Zcash in the foreseeable future IMO.

Burning does exactly what we want here, economically – benefit all existing coin holders equally by reducing the supply.

I’m sympathetic to the idea that miners are “losing out” on the fee, but that’s not quite what’s going on here. Burning should do just as well if the miner’s are aligned with Zcash and hold ZEC, rather than selling to cover op/ex.

Monthly VWAP means speculators would have to manipulate the entire market for a month… It’s a pretty tall order, and should be negative expected value

32

I want everyone to be clear on what Alex is referring to:

  • ZF is funded by donations from Founders’ Reward recipients, made via legal agreements that cannot be unilaterally changed. (Consequently, donors cannot withdraw their donations in order to pressure ZF.)

  • Two of our board members, Matthew Green and Ian Miers, are “Founding Scientists” of Zcash. Neither is employed by ECC but both have done advisor-type things (I don’t think in a formal capacity, but I’m not 100% positive about that). Same situation with @tromer, who is not a board member but ZF’s advisor.

I’ll see if @amiller or @acityinohio can chime in with details about our conflict-of-interest policy.

3 Likes
33

It’s worth noting that Matthew Green has been publicly open to a significant board change.

I haven’t seen any evidence of conflict-of-interest issues with the current board, to be clear @boxalex

I just believe the ZF and ECC (and any other dev fee recipients) should be at arm’s length, with only an explicit single board seat as an exception, conflicted out when necessary.

2 Likes
34

That is your opinion and I humbly disagree. I think what we want is as many zec in as many peoples hands as possible. Deliberately reducing the supply would run counter to this. Especially at a formalised/protocol level.

Why? When you go to burn the coins, don’t. put them back via extending the next halving by x number of blocks.

Enrichening holders and early adopters is one way of looking at this issue. I disagree with looking at it this way. We should be encouraging usage and diversity of holders.

I care about future coin holders, not so much about existing ones. (not that I don’t care about them at all, but their wealth and risk model is their business, not the protocols - the protocol distributes coins.)

I will reread your proposal. I think I must be missing something. It almost feels like we are talking cross purposes (which is normally my fault). - after rereading I don’t think I am.

edit:

hey matt,

I am just directly responding to things that impact me. I would like to say apart from burn - which I can never support - I like the general idea and the gist. we will need something like this eventually. Personally I would be happier with this being a NU5/6 proposal. something to transition to. I am worried about reducing the impact of the foundation though and feel they would have to have a controlling interest if their is no ECC.

This is possible with the current technology, it just needs a few tweaks. Hopefully I will get time to discuss this with @tromer soon. It would work for any custodian. (it also allows a whole bunch of secure custodial services and other fun stuff.) on chain governance not so much, but certainly release of funds and “dead mans switches”. The nuance of how the rules will work is a governance thing tho.

So what happens to the current grant program, is this trying to fix that? because this seems to stop people like myself from getting involved. (And it is already hard enough)

The foundation says they have enough money to keep them going for about 5 years, so they will be here until at least the next halving. I really think the only reason the proposals dont give the foundation all the money is because the foundation stated numerous times they dont want that. (but really can they stop us? @sonya :p)

Can you please define what you mean by the community, and how you are envisaging the partnership with the community working?

There is currently a mechanism for this, but it is seldom used. The community governance panel. However, im not sure it is fit for this purpose.

I feel there is a lot more in this statement that initially appears. If you are going through all this trouble to create this extra layers [which i support the idea of the ECC will not be around forever] I think you really need to encourage developers like radix. - How does this help individuals get involved? wont the dev free recipients just take and implement the ideas themselves?

I would like to hear what @ttmariemia thinks.

It seems the zcash tech should help enable startups, she knows a lot more about start ups than me.

is this really first amongst equals? or is it is more a monarchy? (maybe i am misunderstanding first among equals, it might be a uk/usa thing)

cheers,

steve

35

All 3 are NOT employed by the ECC, but they are share holders of the ECC and as such i would go as far as going to say they are employers at the ECC. Hence why i refer to close ties.

That’s indeed thin ice here with the conflict of interest and it might be often a subjective one. There are possibilities we are near a conflict of interest in generally in my opinion. I don’t want to mention all possibilites i see personally borderline so the discussion doesn’t get de-railed but it should be obvious that such tight connection leaves a lot of room for conflict of interest in generally:

founders => Shareholder of ECC
founders => funding the ZF
founders => funding the ECC
founders => board members at the ZF
founders => advisors at the ECC and ZF

From all actions i have seen by founders Matthew Green seems to be the one most open to improve changes. And i personally really like him and his approach but i have to put the facts as i see them on the table as they are currently, so hopefully nobody takes my comments as a personal attack.

I wasn’t referring neither saying that they could defund the ZF, but that they have a big say and 2 board members + 1 advisor from the founders is a Big say in my books:

36

Very good point. I’m assuming the eventual cartelization of mining, and that as the coin matures it’s acting less and less as a “fair distribution mechanism” and more and more rewarding oligopolists for securing the network. I am, however, open to being wrong on this :slight_smile:

I now get what you’re saying re: supply – we were at odds ha. If we would rather support new distribution than price, there are a couple different mechanisms, some via mining, some not.

I saw this as an opportunity to compromise with folks who are pushing for a reduced dev fee or who believe in a store-of-value thesis, ala @Blocktown.

I actually believe we can do this without any fancy tech at all – just by upgrading to a new allocation / address config recommended by the ZF each NU. That way if the ZF falls, the most recent allocations stand, or the community can fork away.

Not at all. This is to encourage more long-term players, similar to the ECC, who are maintaining a client or doing other long-term Zcash ecosystem work. It’s complementary to the grant program, and should require deeper diligence on the team and maybe entity, and less around their specific plans (as dev fee recipients would be part of shaping strategy).

This is trying to incentivize a transition to a multi-client multi-dev-team ecosystem. The dev fee as I’m looking at it isn’t for individuals, unless they’re really stellar – it’s for organizations that can work alongside the ECC in an ongoing research or engineering capacity.

Oh, the ZF would have plenty of unilateral control, including around dev fee allocations. It’s the principal developer (potentially the ECC) that would be first among equals to other dev fee recipients, and share some governance (thus the “first”) with the ZF.

1 Like
37

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!

2 Likes
38

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: https://www.zfnd.org/about/incorporation-docs/bylaws_amendment_2/ ).

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

Anyway,

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.

4 Likes
39

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]

cheers

2 Likes
40

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:

01%20AM
01%20AM2058×550 30.1 KB

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