That’s correct. Historically (since the beginning of 2021), average engagement in ZCAP polls is 74%.
Note that some of those who didn’t vote are set to be dropped from ZCAP due to repeated non-participation. However, any who would be dropped but who would be immediately eligible for being re-added (e.g. because they are a core developer) will remain on ZCAP.
That’s correct - I’m assuming that someone who voted in, for example, both the ZCAP and ZAC polls, voted the same way in both.
They could have voted differently in each poll but it seems unlikely to me.
Edited to add: Incidentally, for me this is a strong motivation for avoiding overlap across multiple polling groups. It appears that sub-communities (e.g. ZecHub, Zcash Espanol and Zcash Brazil) prefer to vote as a bloc, instead of as part of a “Super ZCAP”.
If we can establish a common set of eligibility criteria (and appropriate standards for Sybil-resistance), we could have distinct groups (i.e. groups with no overlap between them) who could vote in separate polls, and the results could be added together to produce an overall result.
I’m guessing the outcome doesn’t change, but we are still waiting for ZAC and ZURE results.
The right thing is to wait for the survey owners to release and acknowledge sentiment before making a claim.
Isn’t that what Josh suggested we move to?
Now that all of the results are in, we can call it.
ZAC Runoff Poll results:
ZURE Runoff Poll results:
Well, my understanding of what Josh is proposing is one where signing keys are allocated to different organisations or groups. In the diagram below, I assume that (hypothetically) the five members of the Zcash Community Grants committee would collectively decide whether they wanted to sign off on a grant application.
Presumably, it would be up to the ZCG committee members to agree how they would decide whether they collectively approve a grant application (and sign the corresponding transaction to send the funds to the applicant). They could adopt a policy of only approving grant applications where all five ZCG committee members are in favour, or a simple majority…
In any case, my interpretation of this diagram is that ZCG only gets a single “vote” in this Zcash Funding Bloc process (as opposed to five votes), and the same goes for the other organisations listed.
(I’m more than happy to have my understanding/assumptions corrected, by the way.)
By contrast, the process we use for the Minor Grants program gives everyone on ZCAP a single vote.
Multiple different approaches are possible: “one person, one vote”, “one organisation/group, one vote”, weighted polling of different groups (e.g. core developers’ votes get weighted higher than another type of voter) but there are common issues across them all:
My proposal is a little different. Overlap of individuals isn’t as much an issue because protocol decisions aren’t made by a couple hundred filtered people, they are made by clear consensus of various constituents who may choose to gather sentiment within their community differently. It allows us to get better signal and allow for coin holder participation.
Each constituency has different mechanism for assessing their collective sentiment and then a formal mechanism for expressing their voice.
For example, core developers are a constituency that also might be part of coin holders. The weight of their voice may be different in each. Coin holders may want to express their opinion by signaling based on the number of coins they hold. The core developers may want to express sentiment based on a committee decision. A DAO like ZecHub might want to use a different mechanism for their members, etc.
If core developers signal something that differs from ZCAP survey results, for example, that is useful information to consider and bake into the process.
Each constituency signs their key but change only occurs if a certain threshold is met (the k/n multisig). This includes the addition and removal of constituency groups over time, allowing for greater decentralization and robustness.
Happy to listen to why you believe my proposal is not anti fragile.
I’m concerned about plutocracy, where a few whales control governance and decisions are made by the highest bidders. I think that the person that really needs ZEC to survive but can only afford one token at a time, should at least have as much a say as the billionaire that holds millions of dollars of ZEC but where it only represents a small fraction of their wealth and they have no real need for the token’s utility.
There are other issues such as renting tokens, etc, that can be mitigated, but that is my primary concern with 100% of the direction being determined by token voting.
An idea that I had a couple of weeks ago, that appeals to me, is to potentially privilege coinholder sentiment via a “coinholder veto” mechanism.
The market is ultimately the entity that can “veto” any consensus protocol change, by sending the price of ZEC to zero. However, this is likely to be a lagging signal - if a proposed change is strongly disliked by the market, we might not all find out until after the change has been made.
The idea of a coinholder veto is that the market could signal, via a coinholder vote, disapproval of a proposed protocol change, before that change is active in the consensus rules - and thereby perhaps avoid the problems related to the market’s preferences being received via a lagging signal.
The risk of veto power is of course that it can stall progress. But IMO coinholders are likely to be aware that stagnation presents just as much a risk to their holdings as change does, so my hope at least would be that in a rational market, progress would continue to be allowed. After all, even Bitcoin gradually makes progress despite being highly conservative with respect to consensus rule changes.
How do you suggest we achieve this?
In a coin voting scheme there could be a minimum weight/ maximum weight per vote constraint.
I don’t think it is a simple design, but that would be the start for a discussion. Sybil resistance protection jumps up as an immediate concern because an inspired attacker could create a means to split their hundreds of thousands of ZEC across many wallets, to exploit the min weight configuration…
In my opinion, there don’t seem to be any easy solutions to the challenge of coin voting nuance.
I think it’s worth exploring quadratic voting.
The bloc proposal diversifies decision making where coin holders form 1/n constituencies.
Quadratic voting really only makes sense when you have strong sybil resistance, and that’s extremely nontrivial; gitcoin has spent years trying to get it right and TBH I don’t think their approach is applicable to the Zcash community.
Wasn’t their approach specific to fundraising? Are there other DAOs experimenting with it?
They were using it for grant matching; the grant pool was raised off-chain from donors interested in the betterment of the ecosystem, and then the QF rounds are used to determine how to distribute those grant funds. In that sense, it’s a little different than using it for an up-or-down vote on a specific proposal, but I think that irrespective of the application, without sybil resistance you have a situation where someone willing to split up their funds to make many small voting positions can readily influence the outcome.
If the coin holder vote is done via QF, without sybil resistance the most likely outcome is that it fails either to provide good information about market sentiment or the views of small coin holders.
To make coinholder voting more useful, I would actually take an approach where registration windows are announced only for periods where the window is already closed, in order to bias the results of coinholder polls toward those who consistently maintain a balance in the shielded pools. We really need good tools like shielded hardware wallets for this to make sense. Of course, to some degree this introduces other risks; if someone can predict when a proposal will be put to a vote, they can speculatively and in advance try to time the registration window. Still, that’s a bigger hurdle to overcome.
a non linear formula in amount of coins does not work when users can split their notes.
if V(a+b) < V(a)+V(b), there is an incentive to split
if V(a+b) > V(a)+V(b), there is an incentive to merge.
Making V depend on other parameters such as coin age can help.
Can you give an example of an environment that isn’t Sybil prone? If you cant, are you suggesting democracy doesnt work? Quite bold. 
For now, I think a balanced approach is where we should reach. We can debate the percents.
I believe that worrying about the influence of wealthy individuals in the governance of a privacy-focused cryptocurrency is not productive.
The coins have equal value for all holders, and anyone can write a ZIP, regardless of their financial situation. This makes the system inherently balanced.
If necessary, it would be more practical to tweak the ZIP process itself rather than trying to manage external influences, I think.
I believe “length in the shielded pool” should be the primary voting power for ZEC holders. Yes, I think we should ignore the opinions of transparent pool users who never interacts with shielded pools. They should use BTC instead.
I’m seeing a bit of a disturbing theme here!
All ZEC are equal (fungible, weighted the same) but some ZEC are moreso than others (?)
Opinions aside, it seems obvious that the forum could use a “Coin voting” theory/ design thread of its own, to prevent these discussions from derailing the current Dev Fund topics.
