To tie my proposal into this topic, I’ve already identified modifications (1, 2, 3, 4) to the original Manufacturing Consent, that account for the communicated preferences of ECC, Qedit, and Shielded Labs.
1 Like
So, if I want to give 30% to temporarily unallocated reserve for grants-only funding block and 70% to miners, I send votes for 0% to all other addresses? If someone else sent 100% to ZCG then the result would be miners 35%, reserve 15%, and ZCG 50%?
Maybe a single payload with a defined serialization would be better?
I think in this design everyone will get something and there could be some interesting floating point math …
what if 100 out of 101 voters want 0% for Foobar Inc but 1 person votes 0.1%? If the vote is followed then Foobar Inc gets 0.000990099…% of the block reward?
Still an interesting idea that might we worth trying IMO as another data point - people who actually have shielded ZEC at the ready.
You can add some rounding if you want. It is similar to how the number of seats in the House each state gets (in the US).
Fun fact: The first presidential veto was related to the rounding rule (by George Washington vs Hamilton & Jefferson).
At the risk of repeating myself…
You’re right, and we should probably make it explicitly clear that, given the time constraints, we are limited in how creative we can be w.r.t. a new Dev Fund design if we want a new Dev Fund to activate in November 2024.
You previously said:
What are those “other ways of structuring the dev fund” and can any of them be implemented in time for November 2024 activation?
The fact that there’s an infinitude of possible ways of structuring a Dev Fund is of limited relevance in this specific context if (a) nobody has yet articulated or suggested any of them, and (b) they cannot be implemented in time to activate in November 2024.
1 Like
This seems like a great idea (I’m obviously not qualified to assess whether it’s cryptographically sound and secure) but I doubt it can be implemented within the timeframe that we need to decide what happens in November 2024.
The expiration of funding has no impact on any Zcash-related IP.
The lack of a response from Josh creates a bit of a conundrum here because ECC’s position is not clear-cut.
Above, Josh states that “ECC has already communicated that we will not accept direct funding from the chain”, and ECC’s May 1st blog post says " we have decided not to accept funds directly from the protocol under a new development fund. Our wallet address will no longer be codified in the protocol."
However, the same blog post goes on to say “We are open to … extending the existing development fund for no longer than one year” and @joshs’s draft ZIP proposes a one-year Dev Fund that would allocate funds directly from the protocol, and would codify ECC/Bootstrap’s address(es) in the protocol.
So ECC is willing to accept direct funding from the chain?
From ECC’s May 24th blog post introduces another wrinkle: “We will not endorse or accept direct allocation from another four-year Zcash Dev Fund proposal that directly distributes to any formal organization, including our own” (emphasis mine).
Would a one-year proposal be acceptable? Or a two-year proposal?
In terms of this exploratory poll, what should we do - should we include Bootstrap/ECC in the list of potential recipients?
If we do, I expect we’ll be criticized for including them when they’ve already stated that they “will not accept direct funding from the chain”.
If we don’t, I expect we’ll be criticized for excluding them, and denying the community the opportunity to vote to fund ECC/Bootstrap.
This is another wrinkle.
I usually refer to “Bootstrap/ECC” in the context of the Dev Fund because the Bootstrap Project is the Dev Fund recipient (and it then funds ECC) but, in my experience, many people are unaware of that.
Neither of ECC’s blog posts mention the Bootstrap Project.
Last week, I sent the draft questions directly to two Bootstrap board members (Alan Fairless and @ml_sudo) but neither of them responded.
I’ll try reaching out to Alan again.
If we don’t get a timely response, my inclination is to include “the Bootstrap Project (the parent of the Electric Coin Company)” as a potential recipient in ZF’s poll.
If they later decide that they do not wish to be a recipient, we can always drop them at that point in the process.
3 Likes
From a practical perspective, is there any meaningful difference?
Do you know of a solution that (a) allows respondents to provide free-form text while AND (b) protects the respondents’ anonymity, AND (c) is Sybil resistant?
1 Like
Bootstrap/ECC will not receive funding directly from the chain except in the case of a one-year extension with a clear mandate to move to a non-direct funding model. That is consistent with the proposal we’ve made.
Moving to a non-direct funding model while allowing the dev fund to expire is another interesting proposal that has come up in several different forms and should be considered.
Regarding your specific survey question, your survey above does not fairly reflect the perspective of many in the community, including Bootstrap/ECC. I don’t understand your resistance, and it undermines the credibility of your survey. As such, I am not making any request regarding the questions you posed in this survey other than to completely refactor and reconsider them in light of all of the feedback you have received.
9 Likes
The ZecHub DAO recently conducted its first formal poll to assess the DAO’s sentiment on topics related to the Dev Fund. The DAO consists of 17 active members of the Zcash community who contribute to ZecHub. The DAO plans to conduct future polls that explore more specific issues as the Dev Fund discussion evolves.
You can see the results of the Helios poll here. I’ve also pasted the results below.
I’m currently working with the Brazilian, Korean, Russian, and Spanish communities to translate this poll into their respective languages in order to gather their communities’ unique perspectives on these issues.
@Dodger given some of the feedback you’ve received, would you consider incorporating some of these questions or topics into the ZCAP poll? Questions #4 and #5, for example, address the concerns @joshs and other community members have raised about a non-direct funding model.
ZecHub Dev Fund Poll (May 2024)
Question #1: Which of the following statements best reflects your opinion?
- The Dev Fund should be renewed after the next halving in late 2024. [14]
- The Dev Fund should end, and 100% of the block reward should go to miners. [3]
Question #2: If the Dev Fund is renewed, it:
- Should remain 20% of the block reward [9]
- Should be less than 20% of the block reward [8]
- Should be more than 20% of the block reward [0]
Question #3: If the Dev Fund is renewed, how long should it last for before having to be renewed again?
- 1 year [4]
- 2 years [11]
- 3 years [1]
- 4 years [1]
Question #4: Which Dev Fund model do you support most?
- A direct funding model where a portion of the block rewards goes directly to organizations (e.g. ECC, ZF, ZCG) similar to the current version of the Dev Fund. [4]
- A non-direct funding model like or similar to the Zcash Funding Bloc, where, for example, funds locked in a multi-signature wallet are allocated by trusted community participants through major and minor grants. [10]
- An alternative model or option not listed above. [2]
- The Dev Fund should not be renewed. [1]
Question #5: Do you support extending the current Dev Fund for one year to give the community more time to explore and implement a non-direct funding model, like the Zcash Funding Bloc? See link to draft ZIP below.
- Yes [11]
- No [6]
Question #6: If the current direct Dev Fund model is renewed, would you support more independent entities (in addition to the existing three) receiving a slice of the Dev Fund even if that means giving less % to the existing recipients?
- Yes [17]
- No [0]
Question #7: Which Dev Fund recipient has had the MOST positive impact on the Zcash ecosystem?
- Electric Coin Company [9]
- Zcash Foundation [2]
- Zcash Community Grants [6]
Question #8: Which Dev Fund recipient has had the LEAST positive impact on the Zcash ecosystem?
- Electric Coin Company [3]
- Zcash Foundation [7]
- Zcash Community Grants [7]
Question #9: Zcash Community Grants is a committee under the Zcash Foundation, and not a separate organization. Would you support Zcash Community Grants becoming a fully-independent entity capable of managing its own operations and organizational structure?
- Yes [17]
- No [0]
Question #10: The Zcash Trademark Agreement is a bilateral agreement between ECC and ZF that ultimately determines what is called “Zcash”. Among other things, the Agreement requires both entities to sign off on any network upgrade before it can be implemented. In addition, neither party is permitted to take actions that violate “the clear consensus of the Zcash community.” Earlier this year, ECC announced its intention to terminate the Agreement. If ECC unilaterally terminates the Agreement without concession from ZF, then ZF will gain sole ownership of the trademark. Which of the following statements best reflects your opinion on the trademark?
- The Zcash Foundation should maintain unilateral control over the trademark, including governing network upgrades, soliciting community sentiment through ZCAP and other methods. [2]
- The trademark should be limited to addressing violations of misuse and abuse only, and should not be used to govern network upgrades. [6]
- The trademark should be completely invalidated. [9]
10 Likes
This option is the default option and deserves the full force of your backing and @Dodger’s backing.
The proposed one-year extension of the Dev Fund poses significant issues and should be critically evaluated, particularly when considering the financial implications.
-
ECC would receive an additional 45,000 ZEC (approx. $1.3 million at a ZEC price of $30).
-
ZF would receive another 33,000 ZEC (approx. $1 million).
-
ZCG would receive an extra 52,000 ZEC (approx. $1.5 million).
These figures are relatively minor. ZCG could allocate those funds in just a few large grants, and ECC and ZF would deplete those amounts in less than three months of their operating budgets.
Extending the fund does little to address the fundamental issue if ZEC remains undervalued against the USD. Furthermore, an extension could alienate the market and dishearten Zcash investors.
If the extension is eliminated and perceived as a positive move by the market, ZEC’s value could more feasibly rise to $50 or $60. Remember, with an extension at $30 ZEC, the outcome is the same as having no extension but ZEC rising to $60 next year.
With the extension, the Dev Fund teams gain additional resources, but investors continue to hold ZEC valued at $30 = win-lose scenario.
Without the extension, and with the potential for ZEC to climb to $60, both the Dev teams and investors benefit = win-win scenario.
It would be naive to dismiss the “one-year extension” as a minor change or adjustment. Bitcoiners would view such a move as an attack on Bitcoin. Meanwhile, we act as if it’s a routine part of the culture, only to complain when the price of ZEC continues to suffer.
2 Likes
@joshs Upon reflection, BOSL, Zashi, and the trademark agreement should have been the least of your priorities. Focusing exclusively on this matter (deservedly so) from the outset would have afforded you 11 months, up until November 2024, to ensure its implementation.
Additionally, I am concerned that this issue was neither discussed at Zeboot nor featured in your roadmap in some shape or form. Could you please clarify why this was the case?
1 Like
I appreciate your hunch, but it doesn’t quite look like what you may envision. I can illuminate more of the decision-making timeline for the community later if helpful, but I have a packed schedule at Consensus this week and then traveling - so not much time now.
The position on the trademark is related to the dev fund, which is related to governance and decentralization. I posted my personal views on that last July as I was leaving ECC.
Since the beginning of the year, much work and discussion have gone into the trademark agreement, funding bloc design, and dev fund decision, in addition to critical and significant changes within ECC and necessary pre-work. Many of these changes and positions needed Bootstrap BoD involvement and would not have been appropriate for Zeboot or in any way related to things like BOSL or Zashi.
As you’ve stated it, that suggests that we support those as the only options, which is not correct, and does not actually resemble anything that I or @joshs or ECC have communicated.
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”.
We have not placed any constraint on what other entities can receive dev funding. Josh has said:
but this is not a constraint that ECC is imposing on the process. It is @joshs’ belief (which I happen to agree with), and clearly expressed as such.
@joshs’ proposal is just one possible proposal, which ECC is of course entitled to make just like any other participant in the Zcash ecosystem.
The community has many possible choices. For example:
- It could collectively accept @joshs’ proposal either as-is, or with modifications to the slice proportions.
- 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.
- It could collectively not accept any immediate funding renewal, so that the funding streams will expire at the 2024 halving.
- This may or may not include some future commitment to move to a grant-based model, or some specification of how to account for the funds that would have been allocated if an extension had been agreed.
- 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).
@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:
It’s not up to me to suggest specific changes that would resolve this, it’s up to @GGuy (and similarly for the other authors of proposals that currently have ECC / Bootstrap receiving direct protocol funding more than one year after the 2024 halving).
In my opinion it’s completely straightforward how to change the drafts of such proposals to meet this requirement, but there are several possibilities and I don’t want to bias the decision toward a particular alternative, because I have a conflict of interest. Each author might make a different decision, of course.
[Edit: reworded to clarify that the veto of each recipient is on how it receives funds, not on how other recipients do.]
6 Likes
Speaking for myself:
The last question here should IMHO be split into two questions:
- “No entity or corporation should receive direct funding from the block reward, effective immediately from the 2024 halving.”
- “No entity or corporation should receive direct funding from the block reward, effective from one year after the 2024 halving.”
(Existing votes for the unsplit question cannot be reinterpreted; they’re ambiguous on this point. For example, my answers would be “Disagree” to the first and “Agree” to the second.)
Also, I think that every question in future should have a “The wording of this question does not allow me to accurately state my intent.” option. (I can’t remember who originally proposed this but it is an exceptionally good idea.)
Communicating ECC’s established position:
The question “ECC should continue to receive funds from the block reward after NU6” should be changed to “ECC / Bootstrap should continue to receive funds from the block reward in the one-year period after the 2024 halving.” For ECC / Bootstrap to receive funds directly from the block reward after that point violates its stated consent and should not be on the table. (Similarly, any other proposal that violates a receiving party’s stated consent should not be on the table; ECC / Bootstrap is not exceptional here.)
2 Likes
I like your suggestions. These straw polls I created are just iterations towards what might be a good ~final survey. They can’t be edited. I hope to see eventual ZCAP/ZAC surveys that are verbose, precise, and specific. I think the specific-statement format with levels of agreement is pretty decent starting point for what could become a good survey. I’d rather see too many questions that are too verbose and too specific than too few questions that are too vague.
In concept, yes. But as a practical matter, for anything to get underway in the next month or two, the broad spectrum of ideas/ opinions needs to begin to get consolidated down into a small set of channels/ compromises.
If we had the luxury of infinite time and resources, we could continue to expand polling methods and derive another dozen proposal variants. It seems to me that we’re in the opposite situation, where time is getting tight/ the rubber needs to hit the road asap.
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.
I like what you’ve identified as a partial compromise to their consent based thinking, which is to place 20% of issuance into a reserve fund that can only be unlocked after the Ecosystem/ Dev DAO is completed/ operational. (The means of distributing those funds would be TBD for now/ depend on what the Dev DAO decides)
The path/ incentives in that scenario feel much more in-line with what appears to be the slowly forming ecosystem preference (In polling that I’ve seen so far, it looks like a majority now favor ending the old/ existing direct Dev Fund model in Nov, while also hoping for/ organizing behind a Dev DAO/ grants only model in the future)
4 Likes
I recognise that this is a lesser evil than a one year extension. However, it still sends a message that poor behaviour or decision making can be tolerated at Zcash, especially for entities like ECC (or Zcash Media). The ease with which changes can be made at Zcash is concerning and seems to be why the market is reacting negatively. Yet, we seem unwilling to learn from this.
Look at Bitcoin: its resistance to change, while not always ideal; earns market respect, which is reflected in its price. I’m not suggesting Zcash needs to be as rigid, but showing more backbone would greatly benefit the project’s credibility and stability.
I feel like it could almost be considered ~consensus already:
- end direct funding in November
- start Dev DAO accumulation
- implement disbursement mechanism
I’m biased because this is what I’ve come to favor. The key sticking point becomes the disbursement mechanism and the official constraints around it. I’d like the k of n to be large - no fewer than 6/7 of 11 but preferably much larger. I’d like the funds to be relatively hard to get at so that when people or organizations are funded, everyone can recognize that there was solid, broad agreement. There are a lot of devilish details. Maybe there could be a large grants pool with different rules from a small grants pool. Hammering out the details will likely be a lot of work and negotiation. My view on the percentage changes based on the outcome of the DAO details. If it’s a small k of n mostly controlled by ZF and ECC, maybe I only want 5 or 10%. If it’s a large k of n that functions efficiently and that everyone loves, maybe I like as high as 50%. The initial number must be called before the implementation though in an end-direct-funding-in-November proposal.
Assuming that the DAO will be sufficiently decentralized (yet efficient in an administrative sense), and that the rules for disbursement will be strict, secure, and will make the funds fairly hard to access for contributors, I would lean towards higher percentages - 20, 25, 33, even 50. I like the idea of an enormous, growing fortune that incentivizes a lot of work and competition to get at the fund. The more that is accumulated in the lockbox, the more scarce ZEC will be -miners will continue mining even with a lower percentage.
It’s a bit of a gamble but today I could vote for 20, 25% or even more.
3 Likes
Can you define what you mean by “a one-year extension”?
Would a one-year Dev Fund consisting of 23% of coin issuance, a declining schedule, and additional Dev Fund recipients (and, therefore, a different split to the current Dev Fund) fall within your definition of a “one-year extension”?
What happens if you don’t get a clear mandate to do what you want? Will you still accept a slice of a one-year Dev Fund?
And how can there be “a clear mandate” when we have no clarity as to the details of how a “non-direct funding model” would be implemented, who or which organisations would have control of the funds, what the regulatory implications and consequences might be, and what legal exposure those individuals or organisations would be subject to?
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).
Anybody can propose, advocate for, develop, and collaborate on different ideas for the future.
Today, we don’t need to commit to anything beyond what happens in November 2024.
3 Likes