[RFC] Cap all gauges at one half the previous week's wstETH/WETH gauge

Motivation

Since the beginning of Balancer’s gauge system the wstETH/WETH Balancer pool has brought in more value to Balancer than all other pools combined, any allocation of BAL rewards that sends more BAL to any other pool is relatively clear evidence of the system being gamed for individual value extraction rather than the greater good of Balancer. Recognizing this, we should limit all other gauges to have – at most – an allocation of BAL rewards commensurate with half the wstETH/ETH pool’s allocation.

We, of course, do not wish to enshrine the wstETH/WETH pool in any manner and must allow for another pool to replace wstETH/WETH as the “pace setting” pool under this policy. Thus, should any pool demonstrate that it a) can engender sufficient support to be limited by the cap placed on it by this policy for multiple consecutive weeks and, b) if uncapped could, under reasonable assumptions, bring in similar value to Balancer DAO as the wstETH/WETH pool.

Specification

If approved, the DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will, each week, set the cap for each gauge which is not otherwise capped to match that of the wstETH/WETH pool’s (0x32296969ef14eb0c6d29669c550d4a0449130230000200000000000000000080) gauge. The wstETH/WETH pool itself will be exempt from this restriction.

For instance, as of this posting, each pool not otherwise capped and not including the wstETH/WETH pool would be capped at 7.415% (=14.83%/2) of BAL rewards for the week of rewards starting on the 9th of November.

If another pool consistently reaches its cap under this policy while simultaneously bringing in similar value to the Balancer DAO as the wstETH/WETH pool pro rata per its cap, Balancer governance shall be mandated to consider an update to this policy.

2 Likes

I don’t think it’s appropriate to use wstETH/WETH pool as a reference standard, we already have a Gauge framework ([BIP-57] Introduce Gauge Framework v1) , if the current framework is not suitable, we can continue to optimize this framework.

But I agree that the Gauge’s emissions cap should be set more carefully. At present, 20WETH-80BAL - tetuBAL has 37.56% emissions, which does have a certain negative impact on the protocol revenue. The setting of the uncapped Gauge should be more conservative. I think for most Gauges the cap should not exceed 10% unless it proves to create more than 10% value.

6 Likes

I agree 100%. This has always seemed the way to a more simple framework that gives people room to move while protecting the ecosystem from a total 1 coin blackhole. It’s the simplest thing ever:

1: All new gauges shall be created with a 10% cap
2: All pools that are not capped at 10% should be moved to be so at the request of anyone who wants this to be the case for any reason
3: In a few very exceptional cases, 1 right now(wstETH), it may make sense to except pools from the 10% limit. This exception should be granted by a supermajority of veBAL HODLers

In order to ease UX and Admin burdon, uncapped and 2% gauges can be left in place for the time being, and simply migrated to a capped gauge if/when they violate the 10% rule or need room to grow.

3 Likes

Would it not be better to simply impose an x% on cap on all gauges? Why the added complexity of constantly comparing to a ‘baseline’ gauge?

2 Likes

I’m pretty against capping all gauges. It would require a bigger migration than last time and adds friction/complication to every partnership/integration discussion forever. Our most important partners like aave and lido should not have to concern themselves with a gauge cap. Limiting caps to small cap tokens solves the main issue of a particular gauge not scaling with high emissions. I don’t see what benefit there is from extending that to a global cap policy.

Yes, iterating on the gauge framework v1 may be necessary. We can work through that as appropriate.

2 Likes

Clearly highlighting a single pool is problematic as it looks like a highly biased view, regardless of intent. The current problem with trying to stop the biggest investor from voting on certain pools has now moved to an issue where votes are going to L2 where the Balancer TVL is much smaller. Surely it would be simpler if we just had a gauge cap of 10% for every gauge on Mainnet and say 5% for gauges on L2 (OP, ARB,Poly).

Such a system would prevent BAL emissions going towards pools with very low fees on L2 but would also support current investors with their positions on L1 that need higher than 2% caps on their gauges. Alternatively, a 10% cap could be applied to pools that are considered core pools and then 5% for others. (5% and 2% for L2). For full disclosure I am writing from an Aura perspective (but not officially) but I think it is fair to say that L1 generates the larger returns for the ecosystem, and will continue to do so, and should therefore receive the majority of emissions.

1 Like