Snapshot proposal config change to support aggregated voters

With the potential addition of tokenised veBAL holders to the Balancer ecosystem, I would like to propose some changes to the snapshot voting config to support protocols like Aura, whose voting power is directed by a second layer of voters.

To highlight the need for this, we could look at the current timeline of a yes/no vote. It is a binary vote that lasts for 3 days. If a protocol like Aura were to vote in this, it would need to create a proposal as soon as the vote was created, conduct it’s own voting, then forward the result of this on to Balancer. This makes the timelines really tight and could potentially create voter/dao fatigue and missing votes. Also, if the vote is only binary option and not weighted, it would use ALL of the voting power of this protocol on one option, rather than split as the voters had directed. If the vote could be split (so voters could vote for 83% yes and 17% no) it would allow less of an all or nothing.

Seperately, I think that the quorum could be increased to ensure that only proposals that are fully supported by the community could be passed. Maybe 20-30% of the total veBAL supply at the time of posting.

Proposal:

  • increase minimum snapshot voting window to 1 week
  • post all proposals using the weighted voting type
  • consider only posting proposals at X specific times in the week (say, on Monday and Thursday)
  • consider increasing min quorum
3 Likes

I don’t have a problem with any of this as long as it happens after Aura launches successfully. This would be pretty crippling if we did it before then

Does Aura voting power have to be directed by a second layer of governance? Isn’t it possible to implement a snapshot strategy that combines veBAL + veBAL-in-Aura and use that in the Balancer snapshot?

1 Like

then Aura token has no value proposition tho :sweat_smile:

I don’t understand. Don’t Aura token holders control the voting power of veBAL-in-Aura? I’m not a snapshot expert, but seems like just a matter of rescaling Aura balances.

I think all the veBAL deposited into aura is controlled by AURA holders. AURA holders need to hold a vote to determine how the veBAL under their control will be voted.

the people holding veBAL-in-Aura have zero governance power (these are probably LP’s in the stable pool).

We’re saying the same thing :smile:
And because Maha is saying Aura intends to act as a passthrough to the votes of Aura holders (as opposed to voting with 100% of its voting power on the option picked by the majority of AURA voters), I think this can be implemented in a single snapshot strategy.

1 Like

@markus combining tokens (i.e. strategies) would be an interesting way to solve the problem so there isn’t two separate votes. Balancer DAO initiates the vote and both parties can vote. However would it ever be possible to acquire more voting power at a cheaper price if purchasing auraBAL directly? or will that not be possible, also maybe that is what you meant by scaling.

in terms of the quorum, it is probably okay to up the % once voting power is in more people’s hands. additionally we don’t currently have a very large delegate population so some of the early votes just barely passed and that was at around 15%

1 Like

Hi @0xMaha,

This is a great proposal. As someone who has experience with Index Coop’s metagovernance votes, I know first hand the challenges it creates for Communities voting on another Communities proposal via Snapshot.

A bot can be created which automatically posts all veBAL votes on the Aura Snapshot for voting. This is what Index Coop currently uses for AAVE, COMP, UNI, YFI and BAL proposals before veBAL came along.

Voter apathy is a huge issue, Index Coop’s metagovernance votes hardly ever reach quorum and voter attendance is incredibly low until recently when we started more actively coordinating voter delegation.

The bot solves the getting the votes listed for AURA or vlAURA holders to vote. The voter apathy issue can be fixed in a couple ways. Either an internal team at Aura steps in when votes don’t reach AURA/vlAURA quorum or Aura encourages participants to delegate there AURA/vlAURA voting rights. The later is to ensure there routed to active voter participants.

What ENS did with the airdrop is a potential solution. When participants deposits into the vlAURA contract they have to delegate. Participants can either set themselves up as a delegate or delegate out. If there is not appetite to create a delegate for themselves, then they are not likely to be active voters.

Streamlining when veBAL votes go live and extending the duration of the voting period are both great ideas. This is an enabler for the Aura community to be more active in voting. 5 day votes starting on a Monday is a simple fix for me.

Aura has the BAL distribution votes which will always get good turn out because there is money involved. But the non BAL distribution votes, these ones are a high risk of lower voter turnout. Regarding quorum, I am in favour of increasing this but I would need to review the veBAL distribution before thinking about a percentage number. Ideally we don’t want any one entity dictating the vote.

Why does Aura want voter weighted voting for veBAL votes that are not related to BAL distribution ?

I do think Aura needs to give further consideration to some of the points mentioned above regarding voter apathy. But this is more an Aura community than Balancer community discussion.

3 Likes