eIP 32: Delegate Optimisations in Governance

Simple Summary

I propose, with the approval of the DAO, to automatically segregate delegates based on participation. This will increase participation in governance by rewarding the most active delegates and mean greater representation in decisions reached.

The criteria agreed on are:

  • 60% participation
  • 600 EUL delegated
  • Comments next to each and every vote

Abstract

Disclaimer: I am a senior researcher at Euler Labs. However, the following comments and views are my own and do not represent the positions of any affiliated organisations.

Nevertheless, there is a growing problem among some delegates. Many have a sizable EUL delegation, and yet contribute very little, if anything, to the governance of the protocol. By my estimates (taken from app.euler.finance/delegates), some 30K EUL is currently delegated to delegates that do not vote / contribute.

Motivation

This is problematic because contentious votes like EIP24 do not have the full weight of the community behind them: voices remain unheard. So long as delegations continue to inactive delegates, some voting power remains unused.

I propose the splitting of delegates into two groups: Active Delegates and Public Delegates. This is the first step in my DOG (Delegate Optimization in Governance) plan, which ultimately aims to codify the lifecycle of a proposal, though more on this later.

Specification

My proposed solution is to classify delegates into two tiers (for now):

  • Public delegates (no change required)
  • Active delegates (details mostly worked out, implementation is purely on the front end)

Public delegates will remain as they are. They will remain on the front end for EUL holders to potentially delegate to them under app.euler.finance/delegates.

Active delegates are delegates that meet the following criteria (provisional, please give your thoughts):

  • The delegate votes on at least 60% of Snapshot votes in any given month
  • The delegate must give a comment on Snapshot as to why they have voted this way. See the following image for context.
  • The delegates must have no fewer than 600 EUL delegated to them. This is to prevent people with 1 EUL spamming the status. This number has been agreed on by the DAO and can be revised later (alongside all numbers)

See the following for a mockup as to how this might look. Please note the proposed delegate profiles are merely suggestions and not representative of the end result.

As for enforcement, it can be verified automatically by scraping on-chain data. There are no changes required to the existing governance system: this proposition is merely cosmetic.

Further considerations

Implementation might take a short while. I suggest we wait 1 month from the point of the vote passing in order to provide everyone an equal chance to become an Active Delegate.

A pardon system could be implemented for Active Delegates who are temporarily AFK but do wish to remain an Active Delegate. My suggestion is an Active Delegate can be placed into this “Pardon Zone” for the number of months they’ve been active as a delegate but in weeks (e.g. 6 months = 6 weeks) to a maximum of 8 weeks.

Voting

Yes: engage the Euler Foundation to implement this front end change

No: do not implement this change

Snapshot

https://snapshot.org/#/eulerdao.eth/proposal/0x9da517e2a16214570748cc1e91adc4c9387bf25993c565e54376bc96e56559dd

6 Likes

Voting on this proposal will commence tomorrow.

1 Like

I agree that delegates need to communicate their reasoning for voting the way they did. That said, requiring on Snapshot means we don’t have a great way to aggregate that and track it in one place.

Instead, and maybe this is a future iteration, we have a delegate section of the forum where each AD has their page they update after they vote (very similar to what Maker and a few others do). I am seeing some of our delegates start to do this already, which is great.

Overall, and regardless of that (although I think it makes a ton more sense to do it the way I’m proposing), I am supportive.

1 Like

Thanks for this! We will review the process in Q1 next year and evaluate how we feel about it all. I will note this down and please ping me if you have any suggestions / observations as the program proceeds. Your support is much appreciated!

1 Like

hmmmm

so i had less than 600EUL token in wallet I might fail to vote even i have been authrised more than 600 voting pwoer?

Hey DM me on discord and I explain the proposal a little more clearly to you !

This may be possible using Snapshot’s API. Here’s one way you can get the reason for votes in a given proposal.

I agree that delegates need to communicate their reasoning for voting the way they did. That said, requiring on Snapshot means we don’t have a great way to aggregate that and track it in one place.

Instead, and maybe this is a future iteration, we have a delegate section of the forum where each AD has their page they update after they vote (very similar to what Maker and a few others do). I am seeing some of our delegates start to do this already, which is great.