Snapshot Quorum & Threshold

[Tangle]

Summary

The current Quorum Value for required SUSHIPOWAH is slightly unclear as it has been stated in the docs: For a vote to pass and become binding, it must gain a quorum of at least 5 million SUSHIPOWAH.

There is confusion on if this means 5 million in favour, or 5 mil total vote, as is a traditional quorum (also the way Snapshot calculates quorum).

Also, the threshold % in favour to pass a proposal is also not totally clear, and is assumed at 50%.

Abstract

Make clear definitions and values for both of these metrics. It would also be ideal to discover where all of the SUSHI and SUSHIPOWAH exists, to have a better understanding of how to best engage inactive voters, or ensure that vanilla SUSHI is being utilized. This would be ideal to have Flipside provide an updated list of addresses and apps holding SUSHI or SUSHIPOWAH (Compound, AAVE [deprecated], Abracadabra, Tokemak, LP’s, MEOWSHI, CEX’s, etc).


Motivation

To ensure clarity for voters, and to have this included in the docs for future votes.


Specification

It is important that the community and voter base have a clear definition for what “Reaching Quorum” means for Sushi. The options are:

• 5 Million SUSHIPOWAH voting in favour of the outcome
• 5 Million SUSHIPOWAH total votes on the proposal

In order to determine a successful vote to pass, the % threshold should also be clear. A 51% pass may not indicate clear conviction within the vote. The threshold should be clearly defined in order to be a successful vote as one of the following:

• 50%
• 66%
• 75%
  
  

Summary

Should this proposal go to Snapshot, in order for this vote to pass, we would need to see the following in order to suggest a clear outcome:

• over 5M SUSHIPOWAH in favour
• over 75% to agree on the same values

This way regardless of the current parameters, there is a clear indication of what the voting parameters should be.


For
Clarity on what quorum means, and threshold clearly determined.

Against
Quorum is already clear enough and threshold is fine at 50%.

What defines Quorum?

Quorum

• 5M in favour towards the outcome
• 5M total vote towards the proposal

What % in favour to indicate a successful vote?

Success %

• 50%
• 66%
• 75 %

[RobotTauss]

There are very few circumstances where having the amount to meet quorum be the total votes cast is desirable. The only justifiable reason for voting that way on this proposal is if you think that 5 Million to reach Quorum is too high since we’ve had votes fail simply because not enough voting occurs.

This lack of voting could be the result of active members abstaining from a vote when a vote they are not in favour of will not reach quorum without their participation. If you’re in favour of the quorum being for total votes cast, it’s more likely you would be better served by a vote that reduces how many votes are required to meet quorum.

I think this proposal would make more sense if it took that into consideration. I’m struggling hard to consider what circumstances benefit from a vote passing quorum only by having enough parties voting against and for the snapshot.

One example where it may be applicable is for when there are multiple items being wrapped into a snapshot and the voting is to show the weighting of each item and that is taken into consideration with how things will proceed after the vote. Then you would have a scenario where votes are cast for multiple outcomes and you would want to consider the total votes for the quorum.

I think this needs a bit more polishing personally. Maybe address whether 5M is the right level for quorum instead?

[SCNightshade]

The definition of a quorum is clear enough. There are things called a dictionary for those needing a refresher. The definition of a quorum means “the minimum number of members of an assembly or society that must be present at any of its meetings to make the proceedings of that meeting valid.”

In other words, a proposal need a certain amount of total votes to be a valid proposal. Changing the aspect of a quorum to “in favor” would it give more power to the big holder than they originally had. For example, when other whales are inactive or busy elsewhere the proposal will then go to the whale that does vote.

The quorum that is present now was set in place so that the power does not lie in one person. So, changing the quorum or reducing the amount needed will only give more power to the whales, and the frog nation takes over attempt to show us clearly that the whales already have too much power.

Therefore, I will be against this proposal, but I agree with the fact that the governing structure of Sushi needs to change to better function. I also agree with the part about mapping the total amount of SUSHIPOWAH available.

I would also want to see some more nuance in the proposal. In the past, many proposals 'died" while there was strong support from the community (e.g., Boring Transperacy proposal). Therefore, I want to see what will happen to proposals with strong community support and not being brushed aside.

[pocketsquare]

@Tangle

Should this proposal go to Snapshot, in order for this vote to pass, we would need to see the following in order to suggest a clear outcome:

• over 5M SUSHIPOWAH in favour
• over 75% to agree on the same values

This way regardless of the current parameters, there is a clear indication of what the voting parameters should be.

Both of these would need to be satisfied or just 1?

[mountain_goat]

We should probably try figure out the team veto while we’re at it

[Tangle]

Based on the current votes I am seeing a split between 5M in favour and 5M total. As suggested in the docs, the total to pass is different than the definition of Quorum as indicated by @SCNightshade.

To be clear, this proposal is not about the fact that one vote did not reach the 5M, as the latest vote that had 4.5M in favour would have still resulted in “No action required”. However, but seeing the split in current voters for Quorum, I do believe its important that we make it clear how Sushi identifies its quorum.

Personally I am in favour of 5M Total, and 66% Threshold. If 10M SUSHIPOWAH Voted, that would mean 6.6M would need to vote on an outcome to be considered “Passed”, so in some cases it may actually require more voters to pass.

I also think all Snapshot votes should include “Abstain” as an option, so in the event that the 5M Total vote was decided upon, voters could utilize this option to ensure votes can reach an outcome rather than failing to reach quorum.

[Tangle]

Both in this case just so there is no way to contest the voice of the DAO.

[Tangle]

Good point.

“At this time, only proposals posted to the Snapshot voting system by the CORE can be considered binding if passed with a quorum.”

[CryptoLamer]

In the first vote which had to set the “needed minimum” it was about “threshold”, not about “quorum”. From the archives:
"-Right now there is no clear voting threshold.
-There is no team for core proposals and the community has not voted upon a minimum threshold for how many votes are needed to pass.
-This vote is to establish a minimum threshold.
-We’ll establish that threshold based on a weighted average.
-Voting in favor of this vote means you believe it should be applied retroactively to the Sushi buyback proposal - but will not extend to other votes.

Explainer:
Right now, the multisigs have no clear guidance on what the community considers a fair minimum for votes and so votes that are close to a threshold can be contested.
This vote should establish the minimum number of votes that a proposal needs to pass"
https://snapshot.org/#/sushigov.eth/proposal/QmY66XwcgCSNGju7FK1E4wbVHyLy1KukBZw1Egq5nqHxdL
And this is the only legit vote about “minimum needed SUSHIPOWAH” hold by the community. The change to 5 mil is based on this one. For me it clearly states that a proposal (not a vote) should get a minimum number of votes.
As @RobotTauss said - setting a “quorum” based on total votes will just result in no voting by the people who do not support a given proposal (as they will be afraid that even by voting “against” they will help the proposal to pass. And that is not good, as thus you can not have a fair data about how people feel about that proposal… As you can not know if they do not vote because they are not interested or because they do not like it.
P.S. I fully agree with @mountain_goat that even the “veto” was handy at some moments, we should find a way make our governance work without it.

[mountain_goat]

It was useful to a point but in hindsight it did nothing to stop Dani and Sifu being let in the backdoor. Let’s not forget, that was the appropriate time to use veto and it didn’t happen.

I agree it was somewhat helpful during ondo but it’s inevitable that there are many others that don’t and the bottom line is it’s making us a centralised org ultimately controlled by a team that wish to be/will be indemnified for their misgivings.

That’s banana republic politics and until we address it we will remain a facade for a DAO.

If the veto is simply a tool to protect the team in-situ we are kidding ourselves thinking any team won’t use it to mainly protect their self interests.

The transparency vote is case in point. It was pretty emphatic and if taken as a temperature check it would be addressed. It was 100% in favour. Reality is team can ignore community.

This mechanism means that what we are discussing is irrelevant. 10m sushipowah can vote 100% in favour of removing the team and they can veto it. Say something like ‘critical threat’ to sushi if we implement.

Think Boris and Trump. Turkeys never vote for Christmas

[fig]

This is an important topic - glad we are tackling it now.

We took a stab at this and other SushiSwap voting data awhile back:

@SCNightshade

. I also agree with the part about mapping the total amount of SUSHIPOWAH available.

See our results here - SushiSwap Voting Analysis - Flipside Crypto

It illustrates SUSHIPOWAH distribution, proposal outcomes, and maps voting power buckets.

It seems there are ~19,000 potential voters, representing $92mm SUSHIPOWAH.

Out of 267 past proposals, 43 (16.10%) reached quorum.

---

---

---

I offer two perspectives on this:

1. one as a team who went through Sushi’s governance process
2. as a team who focuses on other Governance processes

As treasuries ballon in NAV and organizations realize the value of DAO-to-DAO partnerships, the importance of a clear, intuitive governance process grows.

It is imperative to allow good ideas to permeate through the DAO and limit bad ideas from becoming worse. In terms of the QUORUM, we voted in this temp check for 5M in favor

We feel this is safer representation of QUORUM, and limits one fund or whale from securing the vote

This current number is attainable by activating 5.43% of the total voting power in favor - it is a challenge of fighting voter apathy.

Sushi must encourage participation and ease the burden placed on the end voter - this can be done through new models (delegations) or predictable voting periods + a dose of healthy marketing.

I agree with this perspective @Tangle:

@Tangle

I also think all Snapshot votes should include “Abstain” as an option, so in the event that the 5M Total vote was decided upon, voters could utilize this option to ensure votes can reach an outcome

This is a strong case for 5M total and has merit.

As for the threshold, we urge Sushi to err on the side of simplicity. Why not a simple majority - 51%?

If not an option, we deter to 66% to indicate a clear winner.

Hope this is helpful and leads to a more informed discussion!

[CryptoLamer]

Hey Fig, nice analysis, but I am afraid the numbers are a bit off. The number of axSUSHI should not be added, as that number is already included in the total amount of xSUSHI.
" uint256 collective_xsushi_balance = axsushi_balance + bento_collective_balance + crxsushi_balance + meow_balance + bar.balanceOf(account); // get collective xSushi staking balances
uint256 xsushi_powah = collective_xsushi_balance * sushi.balanceOf(address(bar)) / bar.totalSupply(); // calculate xSushi weight"
The amount of tSUSHI is also off - at the moment the total supply of tSUSHI is 2,692,704
(TokemaktSUSHI (tSUSHI) Token Tracker | Etherscan)
The total supply of Sushipowah contract (SUSHIPOWAH (SUSHIPOWAH) Token Tracker | Etherscan) shows the amount of sushipowah of all the xSUSHI (no matter if they are in EOA wallets, BentoBox, AAVE, etc… it includes and xSUSHI on Polygon) and all the SUSHI/WETH SLP:
" /// @notice Returns total ‘powah’ supply.
function totalSupply() external view returns (uint256 total) {
total = sushi.balanceOf(address(bar)) + sushi.balanceOf(address(pair)) * 2;"
So to get the all available SUSHIPOWAH one just have to add the total supply of tSUSHI to the total supply of the SUSHIPOWAH contract. At the moment the result is:
76,668,848.75875+ 2,692,704.0602=79,361,552.81895 SUSHIPOWAH

P.S. From the 267 past proposals, probably more than 50% are just rubbish ones from the times, when there was no control and anybody was able to post a proposal for voting on snapshot. I mean proposals like the following:
https://snapshot.org/#/sushigov.eth/proposal/QmYMmj3WsXUSg2fs3TMCkYoPHPMpJziyddLf144JjTXD1E
https://snapshot.org/#/sushigov.eth/proposal/QmT4yzmAFN3U5ZHHeZJcti18oa8b8hR3jJ41dn81DZ98D8
https://snapshot.org/#/sushigov.eth/proposal/QmfQb4nkcimGkTeQ5cLrdpymuYUW1SuAKec8VzMvQT6AS2
https://snapshot.org/#/sushigov.eth/proposal/QmUaez8y5xRhTv2MeGKvhb7k939qkWmxgZ2R5fmgmVMEpf
Believe me, there are too many of these…

[SCNightshade]

About that, can somebody clean up the snapshot environment? Like removing all the joke proposals.
@JiroOno

[fig]

@CryptoLamer hey, thanks for your feedback.

As noted in the reply, this was current when commissioned - back in November 2021.

For the data, on tools like this (made by our community) refresh runs about ~1 week behind, hence the small difference between numbers on Etherscan.

We believe this still tells a story and visualizes where most SUSHIPOWAH lies.

For the past proposals:

@CryptoLamer

From the 267 past proposals, probably more than 50% are just rubbish ones from the times, when there was no control and anybody was able to post a proposal for voting on snapshot. I mean proposals like the following:

They may be rubbish - but it does not mean this is inaccurate. The data signals a need for better curation and processes which we are discussing here.

[JV101]

I know I’m not able to vote on proposals because I have my xsushi on KASHI. It would be nice if I were still able to vote with the unleveraged amount. Not sure if the same applies to xsushi held in bento and if its contributing to the reduction in voter participation.