Moving the Dev Fund discussion forward

[Dodger]

@daira

As you’ve stated it, that suggests that we support those as the only options, which is not correct…

So what other options will ECC support beyond the two I described?

Maybe we need to be more specific because “support” can have many different meanings, randing from saying “Yeah, we think that’s a good idea.” to “Yes, we will implement that in zcashd.”

• Under what conditions will Bootstrap/ECC accept funding from a new Dev Fund?
• Under what conditions will ECC engineers implement a new Dev Fund?

For both these questions, let’s define a “new Dev Fund” as one that begins at the next Halvening in November 2024, and define the conditions as relating to the duration, % of issuance, recipients, % split amongst those recipients, and potentially a declining schedule as described by @GGuy.

And for the avoidance of doubt, for the purposes of this discussion, Josh’s proposal is a new Dev Fund.

@daira

ECC (via Bootstrap) currently receives 35% of dev funding. That is less than the Major Grants slice (40%), so it is not a “lion’s share”.

The Major Grants slice is redistributed amongst many grant recipients, none of whom receive anywhere near the amount of funding that ECC has received under the current Dev Fund. That’s why I used the term “lion’s share”.

@daira

The community has many possible choices. For example:

• It could collectively accept @joshs’ proposal either as-is, or with modifications to the slice proportions.

If there were modifications to the slice proportions, would Bootstrap/ECC accept funding (assuming the duration of Bootstrap’s funding is no longer that one year)?

What if the community wanted to add more Dev Fund recipients?

What if the community wanted to adopt @GGuy’s declining schedule and Unissued Reserve?

@daira

• It could collectively accept any proposal that either doesn’t allocate funds to Bootstrap, or that allocates them for a period less than or equal to one year after the 2024 halving (and similarly complies with any restriction that other entities express on the funds that they receive).
• For instance, it could truncate Bootstrap’s allocation to one year in any of the existing proposals that include a Bootstrap slice, as long as it is clear what the allocations are after that.

This seems to suggests that Bootstrap/ECC’s on condition for receiving funding under a new Dev Fund is that the funding should last no longer than a year (whether or not the Dev Fund would, absent a change, continue for longer than a year). Is that correct?

@daira

• It could collectively accept absolutely any other thing that is well-specified, realistically implementable and compatible with the technical and security constraints, and that has the consent of each recipient for its own allocation.

All of these options are clearly compatible with what we’ve said. There is easily sufficient time for implementation and audits of, I think, almost everything that has been proposed so far (but we are running out of time).

Will the ECC engineers implement whatever the community accepts in zcashd (assuming that it is well-specified, realistically implementable and compatible with the technical and security constraints, and that has the consent of each recipient for its own allocation)?

For example, if the community opts for a two-year Dev Fund of 23% of issuance, with only ZCG and ZecHub as the recipients, will the ECC engineers implement that in zcashd?

@daira

@GGuy’s proposal as it is has ECC receiving dev funds at a hard-coded address for more than one year after the 2024 halving. That is not acceptable as it stands. I explained why it’s appropriate for every recipient in a given proposal to have a veto on how it receives funds:

If @GGuy were to modify his proposal to remove Bootstrap/ECC as a recipient, and the community decided to adopt that proposal, would the ECC engineers implement it in zcashd?

ETA: @daira I hope you understand that I’m not trying to be confrontational here. I’m simply trying to obtain clarity regarding ECC’s intentions, and what constraints, if any, may be imposed on the community’s choices if ECC will not implement certain things in zcashd.

[therise]

Satoshi relinquished control of bitcoin and its rewards and these vampires thinking about how to continue withdrawing money and draining mining rewards. Karma is a beautiful artifact, they sold all the coins in the last 8 years, now regardless of the purpose, a decentralized model requires that if you want to control you have to have coins. So the ZF and any entity that wants to continue governing must go buy their coins, easy and simple, crypto is nothing without decentralization but go and be associates of the federal reserve and be what they “say they fight with privacy.”

You have to open the doors to any dev, team, organization of any ecosystem that wants to come and build, if the rewards if the proposals are good, they will be studied and their past will be reviewed. There are already successful subsidy models and over time they are modified so that they are refreshed and not damaged over time.

This is the only way, detachment, rebellion and chaos are the three components we need to break the chains of the past, whoever opposes will remain in history on the side of the enemies.

PS: the reserves must all be in ZEC and stable, especially going forward to preserve the privacy of our builders or what the hell are we going to do by paying people in bitcoin or tether, so that they can track them? For them to be frozen, we will need, if not a ZkStable, at least the shield technology to protect and keep anonymous the serious people who really care about building and advancing.

Less words, more actions, with this discussion everyone is uncovering their true intentions and there is no longer any doubt about who is who, the human coordination operation around privacy must begin soon or we will let another project take more advantage of all the information. that we have lost due to inefficiency.

Breaking the chains is the only way. Lunarpunks, cyperpunks.

[daira]

@Dodger

So what other options will ECC support beyond the two I described?

I have already been extremely clear about this. The hard constraint is that no entity receives funds from the protocol without their consent, at any point in time. Just that.

We could, in principle, support almost anything else. But how can we answer what options we will actively support without even seeing a draft of them that meets the above hard constraint? It’s a preposterous question.

@Dodger

• Under what conditions will Bootstrap/ECC accept funding from a new Dev Fund?

When it does not include Bootstrap/ECC receiving funds at a hard-coded address (that is, other than via a sufficiently decentralized mechanism with community consensus) more than one year after the 2024 halving.

@Dodger

• Under what conditions will ECC engineers implement a new Dev Fund?

When it’s reasonably implementable, secure, the design is audited, it has community consensus, and it meets the above hard constraint on recipient consent.

That said, I’m not going to commit ECC to support anything sight-unseen.

This isn’t supposed to be an adversarial process. It would obviously be possible to gerrymander proposals that could be argued to meet these criteria but somehow be unreasonable in other ways. I am not trying to avoid your questions, but I don’t know why your posts are always so fraught, as if you think ECC must be trying to “pull a fast one” or something. It’s just odd.

@Dodger

If there were modifications to the slice proportions, would Bootstrap/ECC accept funding (assuming the duration of Bootstrap’s funding is no longer that one year)?

I don’t know. What’s the suggested proportion? 100% is trivially unreasonable, 1% would probably also be unreasonable because it’s not worth the hassle. There will be some value that both ECC and the community think is too high — but I’m not going to commit to a range, because I don’t have the authority to do that on behalf of ECC (and I don’t see why it is necessary).

This seems to suggests that Bootstrap/ECC’s on condition for receiving funding under a new Dev Fund is that the funding should last no longer than a year (whether or not the Dev Fund would, absent a change, continue for longer than a year). Is that correct?

No. That condition applies only to Bootstrap/ECC receiving funds via a hard-coded address (or equivalent) built in to the protocol, as I and @joshs have repeatedly said. Receiving funds via a sufficiently decentralized mechanism after (or before) that point is completely fine, and welcome. Josh’s post describes the kind of thing we mean by a decentralized mechanism (but it’s the goals that matter more than the technical detail, as long as the detail is consistent with the goals).

We’ve also argued for dev funding of other entities to be via a decentralized mechanism. For clarity, that is not a condition on our willingness to implement a proposal in zcashd, if it had community consensus and was reasonably implementable, etc.

Speaking for myself, I do think that hard-coding addresses in the protocol poses a significant regulatory risk, given recent legal decisions. (My reasoning here may be different to Josh’s, even though our conclusions are consistent.)

[GGuy]

@daira

When it’s reasonably implementable, secure, the design is audited, it has community consensus, and it meets the above hard constraint on recipient consent.

Thanks @daira. This helps.

Thanks @Dodger for asking these questions as I’m trying to avoid making assumptions .

[Dodger]

@daira

I have already been extremely clear about this. The hard constraint is that no entity receives funds from the protocol without their consent, at any point in time. Just that.

We could, in principle, support almost anything else. But how can we answer what options we will actively support without even seeing a draft of them that meets the above hard constraint? It’s a preposterous question.

The problem is that, as I pointed out above, ECC’s position has not been clear.

This:

@daira

The community has many possible choices. For example:

• It could collectively accept @joshs’ proposal either as-is, or with modifications to the slice proportions.

…is the first time that anyone from Bootstrap or ECC has suggested that they would accept funding from a new Dev Fund that was in any way different to Josh’s proposal.

@daira

This isn’t supposed to be an adversarial process. It would obviously be possible to gerrymander proposals that could be argued to meet these criteria but somehow be unreasonable in other ways. I am not trying to avoid your questions, but I don’t know why your posts are always so fraught, as if you think ECC must be trying to “pull a fast one” or something. It’s just odd.

I’m not trying to gerrymander anything. I’m simply trying to understand Bootstrap/ECC’s position to figure out where (a) Bootstrap should be included in our exploratory poll of the community (or whether there’s no point because they’ll refuse to accept funding under any new Dev Fund proposal that deviates in any way from Josh’s proposal), and (b) whether we should poll include a complex feature like @GGuy’s suggestion for a declining-schedule-with-Unissued-Reserve in the poll (or whether we shouldn’t bother because ECC would refuse to implement it in zcashd).

If all that seems odd, I expect that’s because you have a clear understanding of Bootstrap/ECC’s position (likely because it’s been discussed at length within ECC) but the rest of us don’t because it has never been clearly articulated.

The single biggest problem in communication is the illusion that it has taken place.

The impression that I (and, clearly, others) have been under is that Bootstrap/ECC would refuse funding from any new Dev Fund that differed in any way from Josh’s proposal.

For example:

@noamchom

Given the ECC/ Bootstrap’s very rigid consent statements, it appears that they’ve basically setup a binary… It’s our way or the highway.

[daira]

@Dodger

This:

@daira

The community has many possible choices. For example:

• It could collectively accept @joshs’ proposal either as-is, or with modifications to the slice proportions.

…is the first time that anyone from Bootstrap or ECC has suggested that they would accept funding from a new Dev Fund that was in any way different to Josh’s proposal.

You’ve just been misreading everything we’ve said, it seems. At no point have we ever said that Josh’s proposal is the only option in which Bootstrap or ECC would accept funding. I don’t think that was ambiguous; for example I remember there being wording changes in the blog post (relative to unpublished drafts), specifically to clarify it.

@Dodger

I’m not trying to gerrymander anything.

I wasn’t implying you were. I felt that I needed to say this, because what you were asking could be interpreted as trying to commit ECC to a fixed, immutable statement of our position, without taking into account that a proposal can always be constructed to exploit loopholes in any stated position.

@Dodger

For example:

@noamchom

Given the ECC/ Bootstrap’s very rigid consent statements, it appears that they’ve basically setup a binary… It’s our way or the highway.

Frankly, @noamchom’s post was after I’d already explained that this was not the case, and was just ignoring that explanation.

[skyl]

@Dodger

What if the community wanted to add more Dev Fund recipients?

I think we are at the point of consensus that the community does not want to add new direct recipients.

Arguably, I think the community has also rejected the continuation of direct funding for the existing recipients this November.

I think the question at hand is now, should any of the block reward be set aside for a Dev DAO and, if so, how much? If there is funding set aside for the Dev DAO, then the definition and implementation of this mechanism comes to the forefront. Who gets votes/keys? How do participants/signatories/voters get added and removed? etc.

[GGuy]

@daira

At no point have we ever said that Josh’s proposal is the only option in which Bootstrap or ECC would accept funding.

I wanted to clarify a few points. Recently, @joshs harshly criticized many of the existing dev fund proposers for not directly asking if ECC was still willing to accept dev funds from the block reward. There was no indication or statement prior to ECC’s blog post that suggested ECC wouldn’t accept these funds, so I believe @joshs was advising proposers not to make assumptions. I believe it was surprising and non-obvious to many that ECC decided not to accept dev funds directly.

Similarly, because prior to today nobody from ECC has stated otherwise, it would have also been an assumption for the community to believe there aren’t other surprising or non-obvious conditions under which ECC might refuse to implement into the “Dev Fund”. I believe many of @Dodger’s questions are simply trying to address any of these assumptions as best as possible.

Thank you for considering this perspective. It’s not about misreading, it’s about clarity .

[i2pZ7812HTZV69]

Let me say what everyone is seeing on the poll result
(even though i thought 1 year dev fund can help zcash advanced its DEX and P2P Options and ZSA)

The community is clear TIME to get Rid of Dev Fund and be a True Cypherpunk Project
Then mandatory shielded only orchard transaction at base layer
Then DEX,P2P Options & ZSA
Time for Little Bit Monero Road

WE Only Have to lose Our Chains

[AidenZ]

I have a suggestion. Considering the current situation, the funding plans for ECC, ZF, and ZCG are unclear following this year’s halving. What if we continue to provide funding at the current level for one year after the halving? However, the provided ZEC would remain locked until the transition to PoS. The received ZEC would be used for sustainable funding through PoS, and the development funds would be covered by staking reward. What do you think?

[ZcashRabbi]

This measure is unnecessary. ECC has sufficient funding to operate for the next four years, and the ZF is similarly well-funded for over two years.

While I acknowledge that Josh has recently assumed the role of CEO at ECC, Bootstrap and their board of directors and advisors have been in place for some time. Given their combined talent and experience, I would have expected them to anticipate this significant development and adopt a proactive approach at least 12 months ago. Josh could have then come in and finessed the process considering it would have been a community decision.

[earthrise]

@Dodger

From my perspective, you appear to be trying to railroad the community into committing to this vague, poorly-defined “non-direct funding model” right now, when the truth is that the only thing we must do right now is decide what happens in November 2024 (or simply not decide, in which case the Dev Fund expires without any replacement).

Deciding what the future dev fund will be used for matters just as much as deciding how much the dev fund will be and how long it will last. It’s a valid position to want a one-year renewal of the dev fund only under the condition that it’s used to implement a different mechanism that does not directly fund orgs (even if the details are vague).

That position is meaningfully different than just renewing the dev fund for one year. The code changes to zcashd/zebra before November might be exactly the same, but the language in the ZIP would be different, and there would be an expectation that the funds will be used to design and implement the new mechanism. It’s a vote of non-confidence in the current dev fund structure while recognizing that some funding is necessary to build an alternative.

[earthrise]

My personal opinion: imagine if this whole thread were filled with community members discussing how to best use development funds to make Zcash a better product, rather than debating who should get how much for how long. I’m in favor of any options that gets us closer to that goal.

[noamchom]

@earthrise

It’s a valid position to want a one-year renewal of the dev fund only under the condition that it’s used to implement a different mechanism that does not directly fund orgs (even if the details are vague).

The problem here, just as with the “gentleman’s agreement” portion of my proposal, is that it is not enforceable. There is no means for Josh/ ECC’s mandate to certainly affect anything, despite its great ambition (an Eco DAO comprised of inputs from everyone in Zcash to be designed and built in a year; presumably without negatively impacting all of the other current roadmap deliverables for the project).

This is part of the reason why I believe that this 1-year extension concept risks setting a poor precedent. It asks for a 1-year Dev Fund as-is extension, wrapped in the ambitions of accomplishing something with words, but not backed by enforcement power.

@earthrise

It’s a vote of non-confidence in the current dev fund structure while recognizing that some funding is necessary to build an alternative.

Feels a bit contradictory, where simultaneously the old way is bad, but it isn’t so bad that we can’t nicely ask for at least one more year of it.

1 more year of ZEC block subsidies only amounts to about $2-4 million dollars of income per org (generously assuming a ZEC value of $30-50 during 2025). Asking for that additional money doesn’t exactly square up, when you consider that ECC (20+ million), ZCG (+6 million), and ZF (+9 million) all have balance sheets more than triple those amounts (and they’ve also got another 5 more months ZEC coming this year, pre-halving)

[Zec_Max]

why not let it run out and than reintroduce a lets say 10% dev fund with switch to POS.
Ideally with a voting system to vote about allocation of ressourcen for different features/ projects / improvements.

[ml_sudo]

I just learned that I was named on this thread. The reason I didn’t respond to your email was because it seemed to be worded as if it was a mass mail to the ZCAP. I had no idea it was addressed to me as a board member of ECC.

[GGuy]

@Dodger

This poll is intended to gather ZCAP members’ views on What should happen in November?

Hi @Dodger, I have posted a proposal that transitions the Zcash Dev Fund to only fund grant and bounty providers starting in November. I hope your polling can also include questions to gather sentiment for moving to a grants-based model in November.

@GGuy

Proposal to Transition the Zcash Dev Fund to a Grants-Based Model

As we approach the end of the current Zcash Dev Fund allocation, it’s clear that the Zcash ecosystem is evolving. There’s growing support for transitioning the 20% Zcash Dev Fund to a grants-based model, focusing on grants and bounties that can drive innovation and community development. A straightforward way to achieve this transition by November is to specify that the Zcash Dev Fund can only be used for grant programs like ZCG and ZecHub. Additionally, this approach allows for future grant models like the Zcash Funding Bloc and Zcash Coin Weighted Voting to be funded by the Zcash Dev Fund as they develop over the next year.

Current Context

• Zcash Community Grants (ZCG) and ZecHub are currently best positioned to manage grant and bounty programs effectively.
• The Zcash Funding Bloc is an emerging concept that needs more time (up to a year) to be fully defined, implemented, and validated.

Proposal

1. Rename the Zcash Dev Fund to the Zcash Grants Fund starting in November.
2. Specify that these funds can only be used for grant programs like Zcash Community Grants (ZCG) and ZecHub.
3. Allow the community time to implement and refine other strategies like the Zcash Funding Bloc and new programs utilizing Zcash Coin Weighted Voting.

Rationale

• Zcash Community Grants (ZCG) has a track record of effectively managing and distributing funds for impactful projects.
• ZecHub has demonstrated strong community engagement and the ability to run successful bounty programs.
• The transition period will give the wider community an opportunity to explore and establish other potential models for fund allocation.

[dontpanicburns]

In it current structure; doesn’t ZCG require zf to exist to manage funds, manage grant milestones, etc?
And isn’t it a part time/underfunded role for the members?
it certainly was for me

[GGuy]

Depending on the funding levels, ZCG has many options regarding moving semi or fully independent, as well as assistance with accounting and administrative tasks to ensure smooth operations. It’s up to the community to be heard and vote on what they want .

[skyl]

I think we need to get away from thinking that the dev fund creates a fiat budget for direct recipients. The block reward is in ZEC. Grants should be requested and paid in ZEC. It’s on the recipient whether they want to sell it for their fiat bottom-line. The protocol itself should not directly fund traditional corporate entities with traditional fiat overhead.

Here’s a quick thought: 7 of 11 threshold. 3 keys to ZF, 3 keys to ECC, 5 keys to ZCG elected by ZCAP.

What are the biggest problems with this quick thought? How far are we from being able to do it technically?