Revamp governance voting rules - 7 days Max, Low Quorum

Proposals
1

Summary:

Current Quorum rules are outdated and need a revamp to enable a more Agile approach to change

Abstract:

The time taken to get a good idea through the voting mechanism is excessively long. There are already many days and rules in place to get an idea from ideation to an official vote on the governance platform where holders can vote. With the safety and consensus mechanisms in place to get to the governance portal, the actual voting process needs to be streamlined so that good change, with majority in favor, can happen quickly.

Motivation:

Zilliqa isn’t quite where it needs to be and change is the path that can lead us to be more competitive. If change has impediments to speed of implementation, they should be removed.

Specification:

  1. No change to the process involved in getting from a poll on the forum to the governance portal.
  2. Once up for voting by gZIL holders, the voting should remain open for a maximum of 7 days
  3. Quorum should be set very low. Exact percentage to be determined but a level that can easily be met within a day or two
  1. This will allow proposals with overwhelming support to pass quickly. It will also provide urgent incentive for voters to vote; If you’re not an active voter in the ecosystem, the train shouldn’t be held up because of you. Also, if the quorum clears at a low percentage level and it isn’t what many holders prefer, it is their responsibility to vote if they want to reflect a different outcome.

Crypto is a fast paced environment and having proposals which are overwhelmingly backed and have already gone through the forum polls be delayed longer than 7 days, is a disadvantage in a highly competitive space.

  • For
  • Against
0 voters
1 Like
2

Hi @Gandalf,

Please add references that describe the current state, e.g. ZIP-12, and outline the current state so that it becomes clear what you would like to change.

I can read from ZIP-12: “A minimum of 168 hours (7 days) for snapshot voting…”. Your proposal states a maximum voting duration of 7 days. Does it mean voting duration shall be fixed to 7 days, because minimum equals maximum? If not, please clarify. Do you propose a new minimum duration?

With respect to the quroum number, I do agree, 20% is too high. I suggest reducing the quorum to 1%. Very famous ENSDAO also has 1% quorum!

Cheers,
Julian

3

Agree to reduce or limit the voting requirements to allow active voters to shape the ecosystem. If not endless participation and proposals ending with low voting quorum exhaust the innovative ideas to push the protocol forward.

This is also due to lack of know-how with no direct information on how to properly set up a proposal, where & how to vote etc.

4

Honestly, I think 5 days is enough. However, 7 days seems a little more fair. If examined, I think one would struggle to find valid reasons for extending the voting period beyond 7 days. I’ve not specified it above but now that I think about it, I would suggest fixing it at 7 days across the board. No more, no less. 7 days is more than sufficient for any criticism that a vote was passed too quickly or stealthily, to be silenced. I also decided not to update the above, in order to not alter the content and possibly affect the integrity of those who’ve already voted FOR. To summarize, we know that a shockingly low number of gZIL holders actually vote, and those that intend to vote, will vote quickly. Let’s use this information to tune up our voting mechanism so that everything can improve sooner.

2 Likes
5

Well said @Gandalf ! 100% Agreed!

6

I had to vote against, please do not solve problem this way.
What are you suggesting would compromise decentralization of the network further.
I thank you for your time to read my detailed reasoning and suggestions bellow:

There are 2 problems with $gZil voting:
Problem1: Difficult to pass a suggestion, mainly due to holders lacking either initiative or information to participate
Problem2: For a single interested party/organization it is quite easy to buy enough $gZil to pass the votes on their own. Currently, attacker would need to own 56k $gZil, which is ONLY ~3.5mil of USD, and that will allow to make changes without anyone else agreeing. Someone moderately rich could own the governance right now…

When solving Problem1 we must not worsen Problem2. Thus suggestion to “Quorum should be set very low” is dangerous and should not come though on its own, as even less money would allow centralized control of Zilliqa’s governance. Furthermore, reducing voting time would not allow community enough time to unite and resist the attack with remaining $gZil

Also, reducing max duration would only result in less holders having chance to participate, probably resulting in quorum not met in time anyway, forcing to start over. Finally, if we allow many changes to be voted in in short periods of time, Zilliqa team would still not be able to implement them right away, so rushing decisions brings no benefits as I see it.
We should discuss and make improved suggestion that solves both problems. My ideas:

Solving Problem1:

1.1 Voting shall remain open for 30 days. BUT as soon as quorum is met, the remaining time would be reduced to 7 days at once. So if quorum is met quickly, e.g 2 days, then voting would close after 9 days, after allowing less active (or away) users to see the proposal too.
1.2 Holders would have to “check-in” their address for voting on vote.zilliqa website (before the snapshot is made), this way declaring activity and interest in participating in governance at all. Check-in shall stay valid for 1 year.
1.3 Quorum shall be increased to 50%, but only check-in $gZil would be counted as “100%” of votes.
1.4 Voting can only happen once at least 10% of circulating supply has been check in. (Otherwise, token is not being used for its purpose on a massive scale, and other measures needs to be taken to solve this)

This would solve problem with exchanges, speculators or ignorant holders not using their $gZil for voting, which currenly prevents quorum from being reached

Example: Total of 65k $gZil has been checked-in by the holders, which is 100%. Snapshot is made. Then, 41k $gZil have been used for actual voting, so quorum is met, as it is ~67% of checked-in voters.

Solving Problem2:

It is not fair and decentralized, when optinion of single rich person holding 5000 $gZil, means more than opinions of thousand (1000!) holders who holds average of 4.9 $gZil. Money should not have such drastic effect, as it demotivates and eliminates majority of interested developers who are not currently rich. Thus, I suggest to not use linear function when determining of number of votes per $gZil. Instead:

2.1 Use square root (v= sqrt(c) where c - count of $gZil held, v - number of votes) when determing number of votes.
Examples:
1 $gZil - 1 vote
50 $gZil - ~7 votes
200 $gZil - ~14.1 votes
5000 $gZil - ~ 70.7 votes
This would still give motivation to hold more, but would make opinions of moderate amount holders more significant

2.2 Mind this problem: suggested change 2.1 could be “rigged” by splitting ones’ holding to multiple wallets. As wallet with 5000 $gZil = 70.1 votes, holder would create a hundred of wallets with 50 $gZil, totaling in 100 * 7 = 700 votes.
But I believe this can be ultimately solved with KYC person verification much later. For now, it is still improvement, as cheating like this would require much effort from attacker (i.e. voting hundred of times, managing and switching wallets), and would not worsen current situation.

Thank you for reading this. I ask you to always consider security of Zilliqa network when proposing changes and voting for them. :blush:

2 Likes
7

Hi @Chainvalrous,

thank you for your extremely diligent thoughts on the governance process. That’s definitely some food for thought!

I tend to agree with the points and solutions you have provided to Problem 1.

Problem 2 is much harder, because you have to solve the identity issue first. KYC at “GZIL check in” would solve this, but would of course come at the cost of ZilFam privacy. Privacy is also an important good we have to protect.

BR,
Julian

8

@Gandalf

Can we put this on snapshot now?

Do you want to update the proposal according to @Chainvalrous suggestions? I think the solutions to Problem 1 are quite meaningful!

Cheers,
Julian

9

I’m happy to put it up for Snapshot and I do like both the proposed solutions put up by @Chainvalrous. Granted, the solution to problem 1 is milder than what I had originally proposed, it still represents an improvement and I am happy to make incremental progress if anything.

For consistency’s sake, perhaps the check-in date can be fixed yearly. For example, it happens from every 18th June each year (Zilliqa’s Anniversary). People can check in any time during the year, but it only stays valid till 18 June, whereafter they need to renew for the next year to continue to be able to vote. If a holder has remained inactive for a long time and suddenly on an October, realises there will be things they’d like to vote on in November/December, they can check in (valid till 18th June the next year) and be ready for any upcoming Snapshots. This would allow Zilliqa to market on Telegram/Twitter/etc to remind holders that they need to renew this every year.

Cheers

10

Appreciate the time to identify the issues. Problem 1 is definitely a pain point for active proposers ATM.

For problem 2. Active participants can easily override the 1% who purchased over the market so I am not too worried about it. In any case, we may revert the vote with another proposal.

The solutions look feasible as well and we could look into that.

The simple method is to keep quorum around 1% with a number of days to vote. Along with an cool off allowance for anyone with a better proposal to revote the process.

11

Yup, many possibilities, all sound better than the existing process. Let’s just get something up for voting please so that things can get approved quicker. Thanks

12

Gandalf,

  • I am having second thoughts about quorum needing 50% of checked in votes. It might still be a challenge to get half, especially in the second half of the year. Thus i suggest 42% for quorum, since 42 is the answer to the universe anyway :slight_smile:
  • Just to clarify: I am suggesting to check in wallet address, and not a specific amount of $gZil
13

I suggest 20% Quorum. 1) Lower than 0.236 (fib). 2) Round number. 3) Complies with Pareto’s principle - 80% of gZIL holders, even if they checked in that year, probably won’t care to vote that often (this is assuming worst case) on most proposals. 4) Low Quorum gives a real chance for your suggested scenario to play out - “if quorum is met quickly, e.g 2 days, then voting would close after 9 days”. That 7 extra days is enough time to get previously non-interested voters to actually vote, IF, it’s not going the way they prefer.

14

Hello!

I’m going to vote yes for 7 days Max!

I’m your average Investor, and just saw this link on tweeter.

I mean it’s just overwhelming for the average Joe to stay up to date in crypto hence, possibility of participating in voting.

Zilliqa will always need guardians! GZil whales to vote for what’s required to stay up to speed in crypto.

Having a quorum as this one only forces its guardians to have enough gZil available on hand to protect the ecosystem.

This means less gZil is invested in Defi options, and more will be just staked (gZil staking finally begins where you still can vote while staking ), and that’s when gZil price will rise too!

If gZil is what it is, meaning used for governance of Zilliqa, the futures most scalable, but secure while decentralized environmental friendly integration into Metaverse and Web3, then it should be guarded as such.

7 days Max let’s get serious, this has to force zilliqa guardians to take it more seriously otherwise things can change against them very fast.