@GGuy’s, @Noamchom’s and @JGx7’s proposals were all published here on the forums more than two months ago.
You’ve had plenty of opportunity to respond to their proposals (like @aquietinvestor did).
2 Likes
An easy thing to implement would be the Dev Fund block reward going into an address (or other unallocated reserve) that is held in a trust until the decentralized dispersement mechanism is implemented. A basic implementation could be to put the ZEC in an address that one of the 501c3 orgs holds in anticipation of the implementation.
1 Like
The approach I’m advocating for is what we’re discussing here - poll the community in as open and unrestricted a way as we can (within the practical constraints that we face) to see if a consensus approach emerges, and then turn that into a draft ZIP for the community to evaluate alongside the other options that have been put forward.
Imagine you’ve just sat down in a restaurant, and the waiter comes up but instead of handing you a menu, he tells you “We are serving cheeseburger and fries tonight. If you don’t want to eat that, get out.”
Now imagine a different restaurant, where, instead of handing you a menu, the waiter asks “What would you like to eat? We’ll prepare whatever you want, however you want it cooked.”
The elephant in the room here is that any current or potential Dev Fund recipient is conflicted, and to be perfectly frank, I don’t think it’s appropriate or ethical for someone (or an organisation) to use resources paid for from the Dev Fund to try to influence the outcome of a process like this in their own favour.
That’s why I’m not putting forward a proposal. I feel that, as ZF ED, I have a duty to ensure that the community has a voice, and the freedom to choose between as wide a range of options as possible, instead of being force-fed something that they don’t want but don’t have a choice.
It would be very easy for me to throw my (and ZF’s) weight behind the proposal to extend the current Dev Fund allocation and split - it means that ZF continues to receive Dev Funding for another year, pushes our runway out a bit longer, no drama, everyone’s happy.
But it’s not the right thing to do. I’d rather sleep peacefully at night knowing that I’ve done the right thing and fulfilled my duty to the Zcash community, even if it means that ZF gets defunded.
3 Likes
Yes, as I’ve previously said…
The question is not necessarily whether sufficient people are “happy”. In a situation and with a diverse community like this, and especially with what’s at stake in terms of the power dynamics within the Zcash ecosystem, there will absolutely 100% be people who raise a myriad of objections, loudly and at length, to try to stymie the emergence of consensus.
So the question can’t be “Is everybody happy” but whether there is sufficient support within the community a specific approach.
This is effectively an adaptation of the Delphi method but applied to decision-making rather than forecasting.
Firstly, I honestly and genuinely applaud you for actually putting some effort into coming up with a constructive solution instead of simply criticising without proposing any meaningful alternative.
With that said, the way you’ve phrased the “questions” (e.g. “The Dev Fund should be allowed to expire in November 2024”, “The current Dev Fund allocation should be extended beyond November 2024”) introduces bias through anchoring.
That’s why we try to phrase questions to ZCAP as neutrally as possible.
We also try to ensure that questions don’t conflict or overlap. For example, a person who strongly agrees with the statement “The Dev Fund should be allowed to expire in November 2024” is almost certain to strongly disagree with the statement “X should receive ZEC directly from the protocol after November 2024” if those questions are presented to them at the same time.
However, if were already consensus is that there should be a new Dev Fund in November 2024, that person is likely to respond very differently to questions about which organisations or programs should receive ZEC directly from the protocol.
You’ve also mixed questions about what should happen in November 2024 with questions about what should happen in November 2025, which risks causing confusion. I know that “The entire Dev Fund should transition to a “grants-only” model.”, and “The Dev Fund should be managed by a DAO-like structure with “k of n” voting.” both refer to November 2025 onwards but many ZCAP members may not.
That’s why we’re limiting our polling to the November 2024 timeframe.
1 Like
No, I do not believe that your vote “Yes” in response to the question “In principle, would you support the introduction of a new funding mechanism to replace the current Dev Fund when it expires in November 2024” can be interpreted as a vote to extend the current funding.
Agreed 100%. That’s why we’re now polling with more specific questions to see if there is broad community support for a specific approach.
Yes. However, doing that would stop the progress we’ve made towards decentralization dead in its tracks because there could be no new Dev Fund recipients (e.g. ZecHub, QEDIT), and both ZF and ZCG would face severe financial constraints.
However, as we’ve stated, ZF will support whatever the community decides.
God, yes! 
I have seen tax forms harder to fill than this server 
IMO, the first question should be “Do you support the continuation of the devfund?” and then N/A options for the rest if you reply “no”.
2 Likes
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.
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.
Helios supports approval voting but not STAR.
I concerned you’ve misunderstood the purpose of this poll. The purpose of this poll is to try to construct a proposal based on the community’s response to this (and subsequent) polls.
By “continuation of the devfund”, do you mean continuing the Dev Fund in its current form, as proposed by ECC?
Because that’s what a lot of people will interpret the word “continuation” to mean.
FYI, to my mind, the current Dev Fund will end in November 2024. If there is a Dev Fund after that date, it will be a new Dev Fund.
1 Like
I disagree that sending 100% of the devfund to a temporarily unissued reserve would stop progress “dead in its tracks.” It would require focus, prioritization, execution, an adjustment of the treasury, and perhaps some austerity. I think all of the developers and community involved could still be well remunerated over time. It would be a drastic shift in outlook, one that I think the market and contributors would ultimately love.
2 Likes
If the answer is yes, there should be a series of questions to describe what the pollee wants.
1 Like
You mean like these?
Progress towards decentralization.
Maybe we restructure to something like this:
- Should there be a new Dev Fund?
- If there is a new Dev Fund, should there be a declining schedule?
- If there is a new Dev Fund with a declining schedule, what percentage of issuance should be allocated to the Dev Fund?
- If there is a new Dev Fund WITHOUT a declining schedule, what percentage of issuance should be allocated to the Dev Fund?
@Dodger, by asking for community feedback and then trying to argue it away, you are undermining the legitimacy of this survey and trust within the community.
As for the timing, since joining this late December, I have been diligently working through legal and financial questions, along with a series of conversations with Bootstrap board members. As you can imagine, this level of potential substantive change required much thought and a lot of conversations. I first posted the idea of a grants-based model in March. There seems to be some support for this model or something like it.
In addition to not surfacing my ZIP proposal, you chose not to include a single question about my grants-based proposal. I’m trying to not take it personally.
A perfectly acceptable framing would be to provide the community an option that includes letting the dev fund expire while we implement such a solution, in addition to the proposed ZIP. Those are 2024 decisions, with a plans to evolve in 2025. Without providing these as options, you are not adequately informing the ZCAP or allowing the community its voice.
Your assertion in this thread about decentralization because of financial hardship is, in my opinion, incorrect. Implementation of distributed decision-making involving greater community through a non-direct funding model would categorically increase decentralization and outcomes-based spending. Compare this with a few orgs receiving preferential treatment through guaranteed funding without accountability. Without surfacing that there may be alternatives, these statements appear to be scare tactics and a reflect bias, intentionally or not, that the project will somehow implode if ZF (and others) are not funded directly.
Given ZF’s role in the community, I request that you restructure the survey based on all this feedback, and get community consensus that it’s well structured and unbiased before asking anyone to vote. I would like to see ZF inform the ZF ZCAP members of our proposals and decisions, point them to our blogs with the rationale.
Given the importance of this decision and its complexity, you might also consider bringing in an independent and unbiased third-party to construct the surveys and polling. We shouldn’t rush this process.
3 Likes
That’s because the goal of this poll is not to seek feedback on your ZIP proposal.
The goal of this poll is to solicit the community’s input in as open and unrestricted a way as we can (within the practical constraints that we face) to see if a consensus approach emerges, and then turn that into a draft ZIP for the community to evaluate alongside the other options that have been put forward.
You have chosen to draft a ZIP proposal.
ZF is choosing to draft a ZIP proposal based on the community’s input and we’re soliciting that input by polling ZCAP.
Our proposal won’t automatically supercede yours, @GGuy’s, @noamchom’s or @Jgx7’s.
The difference is that y’all chose to write a proposal yourselves, while we’re takin the opportunity to give the community the freedom to express what they would like to see happen, without artificially constraining the options.
What’s the largest n that might be technically feasible in 6-12 months?
The problem is that the choices are not fungible: It is not clear how one is supposed to combine the answers to the questions.
There is one thing that is fungible: ZEC!
I suggest polling the distribution from 0-1 year, 1-2 year, 2-3 year and 3-4 year (or simply 0-4 year).
Protocol
The ZF creates a shielded address for each potential recipient of the block reward (including the miners).
For example, with the ECC, ZF and ZCG we would have 4 addresses: zECC, zZF, zZCG and zMINER.
Every voter casts a vote by sending a transaction for exactly a total of 0.01 ZEC to these addresses (they can split the amount as they want). Any transaction that sends less or more is disqualified
[1].
At the end of the voting period, the ZF reveals the full viewing keys so that anyone can check the transactions.
The final amount in these addresses determines the reward allocation[2].
How does the ZF prevent double and unauthorized voting?
With Zero Knowledge Proofs…
Setup
The ZF generates a random voting key v_i for each authorized voter. Then they build a merkle tree. This tree has root r and each voting key v_i has a position \rho_i and a merkle path \pi_i. The ZF sends to each voter i their key information: (v_i, \rho_i, \pi_i).
Vote
The voter i calculates their vote id as V_i = \text{PRF}(v_i) and adds a memo containing V_i to their vote transaction.
Also, they generate a ZKP of the statement:
Given the primary input of
- r
- V_i
there is an auxiliary input:
- \rho_i
- \pi_i
- v_i
such as:
- Merkle Path Validity: (\pi_i, \rho_i) is a valid Merkle Path from v_i to r;
- Vote Id integrity: V_i = \text{PRF}(v_i)
The ZF
- rejects invalid votes when the ZKP does not validate;
- rejects double voting when V_i is used twice.
4 Likes
A problem here is that if someone wanted to express support for something like ECC’s modified ZIP-1014, their answers would be identical to the answers of someone who wants the dev fund to continue as-is but be reconsidered yearly instead of every four years.
And as @nuttycom pointed out, dependencies between answers are lost. If someone’s second choice to ECC-ZIP-1014 or a short-duration dev fund was a 0% dev fund, their answer of 20% would contribute to the tally for Q1 and actually support the opposite of their intent if the majority selected a duration of 4 years.
If the intent here is just to collect community feedback to turn into a ZIP, I think it would be best to present a list of existing proposals and provide a free-form text field for ZCAP members who aren’t active on the forum to offer arbitrarily-complex feedback. Ideas that get repeated often in the free-form text can be pulled out and presented as options in a future poll.
The poll text itself should also be very clear about whether it is intended for governance, i.e. seeking a final decision from ZCAP members about their recommended course of action, or if it is only exploratory, i.e. collecting ideas and testing their popularity in support of writing a ZIP.
I think some of the tension here is coming from the fact that ZCAP polling is basically what will decide what happens to the dev fund (barring any strong signals otherwise from different sources). When it’s used as an exploratory tool, that needs to be made really clear, so that there is zero risk of the results being interpreted later as being in support of a final decision.
6 Likes