Increasing the amount of votes necessary for the proposal threshold and quorum

Increasing the amount of votes necessary for the proposal threshold and quorum

  • Title: Increasing the amount of votes necessary for the proposal threshold and quorum
  • Author(s): Ralsambek (delegate)
  • Submission Date: 13.08.2022

Increasing the amount of votes necessary for the proposal threshold and quorum

Simple Summary

This proposal offers to increase efficiency of the Governance process by increasing proposal threshold and quorum to 10 k EUL.

Motivation

The motivation behind the proposal is to lower the risk of manipulation of the Euler governance via Snaphot.

As of now, the number of votes sufficient for Quorum is 1k.

  1. However, based on the data provided in the EulerFinance Documentation (https://docs.euler.finance/governance/eul), it is assumed that the current number of EUL tokens in circulation is approximately 8 millions. That means that Quorum equals just 0,0125% of the current circulation.

  2. At the same time, it is clear that not all the token holders take part in the voting on a regular basis. Analysis of the data available for the previous voting (Snapshot) shows that the average number of votes participated in the polls amounts to 35,5k and the average number of voters is 434.

  1. It was registered during the voting, that some wallets possess (or act as a delegate) an amount of EUL that is several times greater than the Quorum. For example,
  • 0xf69EA6646cf682262E84cd7c67133eac59cef07b = 3k EUL
  • 0xeD95cbd2185924807e3B893B7E7Ac5dFE2efe33F = 5k EUL
  • 0xf69EA6646cf682262E84cd7c67133eac59cef07b = 5,4 k EUL
  • 0xD178F2d93B92Ac47cf51a899463Eca8acC37A8D5 = 20 k EUL
  • etc.
    It means that a small group of people or even one person could pass a quorum and accept/reject a proposal in their own interest disregarding the possible outcome and consequences of a decision for the Protocol in general.

Based on the assumptions mentioned above, I suggest:

  1. Increasing the number of votes necessary to proposal threshold on the Snaphot to 10 k (0,125% of the current circulation).

  2. Increasing the number of votes necessary to reach Quorum for the Snaphot voting to 10 k, (0,125% of the current circulation).

Benefits

  • Increase legitimacy of votes
  • Prevent low cost governance attacks.

Downside

  • Makes it “harder” for a proposal to be put to a vote and passed.

Voting

“Yes” -

  1. Increasing the number of votes necessary to proposal threshold on the Snaphot to 10 k (0,125% of the current circulation).

  2. Increasing the number of votes necessary to reach Quorum for the Snaphot voting to 10 k, (0,125% of the current circulation).

“No” - Do nothing

2 Likes

Thanks for this well-crafted proposal.

I’m in agreement here, broadly. The system as it stands here was loosely based on the Aave snapshot (which also uses just 50 AAVE) requirement for a proposal.

On each of the points:

  1. I support quadratic voting if it’s possible to implement in Snapshot (I believe it is?)
  2. I support. The quorum number looks much more sensible to me.
  3. I support increasing the number of votes, but I’m not sure if this is technically possible in Snapshot. I guess it could be done through social consensus, since off-chain voting is not enforced anyway.

I think that in the long-run off-chain voting should probably only really be used for DAO decisions that don’t involve code upgrades. All code upgrades will eventually have to be done through on-chain votes, so it might be worth the DAO getting used to those mechanisms through WithTally in the near future.

There are some projects using quadratic voting via Snapshot, so I thinks it’s possible to implement (however, not sure how easy/difficult it is)

I agree with points 1 and 2. Snapshot does support Quadratic Voting which they have documented with its pros and cons and it can be enabled easily.

However, one downside of quadratic voting is we need a mechanism to also ensure whales to do not spread tokens across multiple wallets. I will say let’s analyse this a bit more.

Regarding the quorum, the value seems fine as well.

While 1 and 2 can be enforced on Snapshot, the third point cannot technically be automatically supported. Moving code based proposals to on-chain governance in the long run will be great too. Will be nice to start migrating towards that.

Another point is the proposal threshold on Snapshot at the moment, which is quite low at 50 EUL. This will need increasing to avoid spam proposals. For our on-chain setup, the proposal threshold is currently 75,000 EUL. We can also have this value set to 10,000 EUL.

Agree with the proposal threshold increase!

As for the third point, since it is not possible to make it automatically, maybe as an alternative Euler Foundation could be entrusted with this task?

I don’t understand how this can be implemented in practice.

This will simply force the big holders to split their votes across multiple addresses or create different delegates to gain an advantage, and make their votes even bigger than they were before, as the interest of the small holders is also likely to remain small due to small “skin in the game” and they will not will bother and scatter EUL to different addresses.

Happy to move this to eIP stage and onto Snapshot to allow the community to vote for the proposal threshold and quorum increase both to 10k EUL.
For the quadratic voting, this will be based on a proposal-by-proposal basis for flexibility. So this option (voting strategy) can be opened up on Snapshot too.

We can begin with a simple proposal to first of all increase proposal threshold and quorum and followed by making the voting strategy flexible (to support the quadratic voting).

Please update the proposal accordingly so it can then be moved to eIP stage. Thanks!
Otherwise, happy to link it.

Done, sir! Let me know if any other amendments might be required.