All gauge votes each week will be rolled into an Optimistic Veto Snapshot, and added if 200k veBAL does not signal more consideration is needed.
All gauges will be announced in the same place as always with the same format as always for at least 4 days before they are added.
Gauges may still be added by the old snapshot process if they are vetoed in the optimistic veto round.
Background
Each week veBAL voters are asked to vote on around 5-15 governance topics. Some of these governance topics are important, and foundational to the DAO. Others are approvals for gauges, that are often later killed with more governance, for various different reasons. In the end, our governance is flooded with gauge requests, making it very hard for voters to engage in governance without spending an unreasonable amount of time on it. This BIP seeks to change that.
Core Ideas
This BIP ratifies the following basic ideas about how Balancer Voters thinks about gauges and applies a new governance model to them. Note that in all cases we refers to Balancer Governance/veBAL voters.
Gauges are not sacred at Balancer.
a. We migrate pools and gauges often.
b. We retire gauges that are not being used.
c. We have conversations and eventually kill gauges that are deemed toxic or bad for the ecosystem.
d. We further control caps on gauges based on some mix of economic frameworks and politics.
What voters really want is the ability to kill problematic gauges and or block them before they go live.
a. Misconfigured pools
b. Toxic Tokens.
c. Emissions blackholes (owning most of a pool and voting a lot for it)
The Optimistic Approve/Veto system
This new method for deciding on gauges is meant to give the community a chance to veto, without requiring any action for gauge adds to move forward.
Each Thursday, the Maxis will consider all properly formatted/posted gauge requests labeled with [BGR-XXX] in the subject. After doing sanity checks, the gauge i’ll be assigned a BGR number and added to the weekly veto snapshot.
All gauges that do not receive at least 200k veBAL in veto signalling will be added the following Monday, enabling them to be voted on the same week.
After a gauge has been vetoed, it or gauges similar to it can not use this Optimistic process until a snapshot has been conducted to vote on the gauge in question.
All gauges must first go through the Optimistic process before a direct snapshot. Gauges that seek more than a 10% cap should get attempt Optimistic approval for 10% and then apply to governance for a cap increase with a BIP.
This means that there will be 1 gauge veto snapshot a week, with voters able to signal veto desire with their full vote weight on some, none or all of the listed gauges:
As before, posting a snapshot is pending someone with 200k veBAL (as specified in BIP-163) to setup the snapshot. The Maxis can support this.
A bot will be setup to post automated messages about gauge adds and removes in a fresh channel in the Balancer Discord as soon as time allows and investigations will be made into automatically posting said changes to the Forum.
Specification
While no on-chain changes are required, this BIP grants the Balancer Maxis(LM Multisig on Mainnet) the authority to run veto votes as specified and add gauges that are not contested.
I support the spirit of this, my only concern is the amount of new rules this introduces and the amount of discretion it gives the Maxis. I think we can implement an optimistic approval system with one simple change compared to today - run a single snapshot vote per week where voters only vote if they want to stop a gauge from being added to the system.
i.e. call it “Optimistic Gauge Approval” and each choice is “NO - Gauge X”, “NO - Gauge Y”, etc.
if a choice reaches quorum the gauge is not added to the system, otherwise it is added.
nothing else changes compared to how we operate today. I’m not fond of forcing people to show up in the forum to oppose a gauge and really not fond of the Maxis having to be the arbitrator of deciding how much veBAL someone should have to oppose it and verifying that.
I think I like Solar’s Snapshot approach a little better than the forum approach, but perhaps the wording for that vote can be changed from “No” to “Hold” or “Needs More Discussion,” just to be more diplomatic. I also think the quorum for No/Hold should be much lower than usual, not 1.5, perhaps 200K. That’s how much you need to go direct to Snapshot, so it seems congruent to keep that number to “remove” something from Snapshot–allows smaller fish to chime in as well. I’d be okay with an even lower number for objection as well.
You guys know how this discussion was born, basically we worked backward from this. I think we need to tie everything together, bring it full circle. Essentially, if we are getting looser on entry, we need to simultaneously get stricter on the exit, so we should clarify the details here.
don’t think an optimistic process fits with killing gauges. we’ve periodically put forth a BIP that kills a group of gauges which I think has worked well. likely best to stick to improving the process for adding gauges which is obviously cumbersome atm
I am interacting with partners and preparing gauge votes together with @ZenDragon on a regular basis and I see a huge benefit in this approach. Not only is the “gauge noise” reduced on snapshot, it would also improve on “voter fatigue” significantly while managing weekly gauge modifications in one spot.
The only concern I have is that we make sure the proposals are uniquely identifiable and can be tracked with our GitHub - BalancerMaxis/multisig-ops in an efficient manner. Preparing and validating payloads is important and should be continued as it was - except assigning unique BIP-numbers to the payloads.
So in general I am in strong support of this change.
Speaking with various people in private we came up with the follow idea.
The veto snapshot should include a link to the forum posts for each gauge in it.
You’re right that more uniqueness would still be good. What about a different number OGR(Optimistic Gauge Request), or BGR (Balancer Gauge request). So we start with OGR-1 and move up with each gauge. When the gauge is added to snapshot we modify the PR/payload to have this tag, and then also mention it in the veto text.
Does that seem to solve you concerns without creating too much additional overhead?
It wasn’t super easy to put together/write. It will be somewhat time consuming for the Maxis to do it like this until we get some automation in place, but we should be able to figure that out within a few weeks. Maybe we hold of on implementation until we have a way to manage the process wel?
Agreed. If we change the current process it should be an improvement for all parties involved. It might be a good timing given @ZenDragon and I want to build some tools around gov automation as well like an easy to use front-end to create gauges and payloads. Let’s use synergies and switch the process when we have everything in place!
If I got it right, the idea is to have people actively voting in the gauges they want more discussion. If there are not enough votes, it passes. If people took the time to vote and block the automatic approval, we would discuss more.
I like the idea for the reasons already mentioned. We need to have the wording extra clear to avoid confusion.
You got it. Was going to plan to take this week to get the wording perfect, get an example snapshot together and maybe run this next week. If you have any feedback as to the wording of the Optimistic Veto Snapshot, feel free to drop it here or message me on TG me with suggestions.
This is an excellent proposal that we can only support as it will heavily streamline the process.
I still think gauge creators should create the forum post as it creates sufficient context to understand intentions / structure of the protocol and token receiving emissions. This post can also be used as a fallback if the gauge is vetoed.
We’re good on this–timetable is up to you guys. My only comment for now is instead of using words like “Veto” or “No,” we change it to something like “Needs more discussion” or “Hold” so someone rejecting a gauge can be a bit more diplomatic and projects know that they have a chance to re-format/re-submit if they get held up here.
Cool. Will do. Been a bit tied up, and waiting to see if we can get some automation in place. Will wrap this up and bring to a BIP in the next week or 2.
Agreed. Some engineers from Bleu have been working on automation in the background to enable this. I think we’re quite close to being able to do this well.
@Xeonus think you could circle back around and look at that work/consider implementation in the next week or 2 and let’s do this
As per the recent update posted here by @Xeonus, it was decided not to persue optimistic gauge approvals at this time, and instead to continue to rely on veBAL voters to ratify final decisions around gauge caps, adds and removes.
I tend to agree with you that these problems would be better handled by building a system to do so, but it is quite a feat of engineering, planning, politics and eventual ongoing management to get it right and the Maxi’s simply do not have the resources to execute well on it as well as everything else we are trying to do.
