# \[BIP-750\] 2025 Gauge Management Proposal **URL:** \ **Category:** General Proposal\ **Created:** [January 7, 2025, 9:31pm UTC](https://forum.balancer.fi/t/bip-750-2025-gauge-management-proposal/6248 "2025-01-07T21:31:42Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![ZenDragon](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/zendragon/32/1542_2.png) [@ZenDragon](https://forum.balancer.fi/u/ZenDragon)\ **Post date:** [January 7, 2025, 9:31pm UTC](https://forum.balancer.fi/t/bip-750-2025-gauge-management-proposal/6248/1 "2025-01-07T21:31:42Z")
PR With Payloads > > > Three parts to gauge management in Q1 2025. > > Define rules going forward for qu…arterly kills. \>60 days without veBAL votes, and \<100k USD TVL for \>60 days. > > Kills initial batch of 102 gauges based on this \[table\](https://docs.google.com/spreadsheets/d/12yhvFmXKZMwuyb0dUrPB-2WMKiQnHw9L3puDNe6Svjo/edit?usp=sharing). > > Increase weight cap to 100% of ACX/wstETH after incredible core pool round and Binance listing. > > Add Balancer v3 Launch Gauges to veBAL system. ### Summary and Motivation: As we enter Q1 of 2025 the veBAL gauge system is expected to see aninflux of new gauges due to Balancer v3’s launch. This proposal will act to disable a large sum of Balancer v2 gauges which have been inactive for several voting epochs, and hold insignificant TVL, less than 100k USD. If executed this will set a framework for the Balancer Maxis to review the inactivity of gauges meeting this specific criteria quarterly, and put forward a kill proposal. The benefit is reducing operational spend on the gauge checkpointing operations done every voting round. The criteria is straightforward, but can later be adjusted and is subject to exceptions if a gauge is vouched for on the forum. - The gauge is flagged as worth killing if it has not received veBAL votes for \>60 days, and the TVL has been under 100k USD equivalent for \>60 days. - Gauges can still be killed at any time due to externalities, the rules above are simply meant to keep the system lean and efficient. This proposal will also enable several new gauges for pools on Balancer v3. Lists of both will be outlined below in the attached payloads, and can be cross checked against this [spreadsheet](https://docs.google.com/spreadsheets/d/12yhvFmXKZMwuyb0dUrPB-2WMKiQnHw9L3puDNe6Svjo/edit?usp=sharing). Balancer v3 has successfully onboarded 30M TVL with minimal incentivization and diversity of assets thus far. In order for continued bootstrapping and veBAL voters to allocate their votes on v3 pools this will make the interface much more streamlined for everyone involved. This will also simplify the Aura, Hidden Hand, and Paladin markets in terms of voting and partner interactions. Based on the tokenomic updates coming to Balancer v3 pools related to yield fees and recycling of revenue. The core pool cycle will go live at the earliest convenience of the Balancer Maxis, with the expectation for the automation to be fully functional by the last week of January. All of each v3 pools revenue up until that point will be utilized in the first active incentive round. In the scope of this proposal the ACX/wstETH pool on Balancer v2 will have it’s gauge weight changed to 100%, as opposed to 2% as it has proven to earn more than enough fees to deserve this increase. ## Specifications: #### Gauge Kills Due to the sheer size of the gauge kill list, the table will be left out of the proposal but can be referenced via this google [sheet](https://docs.google.com/spreadsheets/d/12yhvFmXKZMwuyb0dUrPB-2WMKiQnHw9L3puDNe6Svjo/edit?usp=sharing). The DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will interact with the `AuthorizerAdaptorEntrypoint` at `0xf5dECDB1f3d1ee384908Fbe16D2F0348AE43a9eA` and call performAction using `0xab8f0945` for the data(bytes) argument and the “Root Gauge Address” list for each pool below will be used for the target(address) argument. #### Increase of ACX/wstETH Gauge weight cap: The Balancer DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will interact with the Authorizer `0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6` calling `grantRole` with the following arguments: role: `0xae60dce27f51ce5815357b9f6b40f200557867f8222262a1646c005d09b7dfba` This role corresponds to `setRelativeWeightCap(uint256)` on mainnet gauges and can be confirmed [here](https://github.com/balancer/balancer-deployments/blob/de8c3a52cb62185469dbbc90589afa83e5490760/action-ids/mainnet/action-ids.json#L726) in the Balancer deployments repo. account: `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` The Balancer DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will interact with the `AuthorizerAdaptorEntryPoint` at `0xf5dECDB1f3d1ee384908Fbe16D2F0348AE43a9eA` and call `performAction` with target: `0xf7b0751fea697cf1a541a5f57d11058a8fb794ee` being the ACX/wstETH root gauge and data `0x10d3eb040000000000000000000000000000000000000000000000000de0b6b3a7640000` to set the cap to 100% The Balancer DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will interact with the Authorizer `0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6` calling `revokeRole` with the following arguments: role: `0xae60dce27f51ce5815357b9f6b40f200557867f8222262a1646c005d09b7dfba` account: `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` to revoke the previously assigned role to change gauge weights. ### Gauge Adds for Balancer v3 | Network | Pair | Pool Address | Root Gauge Address | | --- | --- | --- | --- | | Ethereum | Lido wETH/wstETH | 0xc4ce391d82d164c166df9c8336ddf84206b2f812 | 0x4b891340b51889f438a03dc0e8aaafb0bc89e7a6 | | Ethereum | Aave wETH/ETHx | 0x4ab7ab316d43345009b2140e0580b072eec7df16 | 0x1f3a4c8115629c33a28bf2f97f22d31d256317f6 | | Ethereum | Aave wETH/osETH | 0x57c23c58b1d8c3292c15becf07c62c5c52457a42 | 0x70a1c01902dab7a45dca1098ca76a8314dd8adba | | Ethereum | Aave USDC/USDT | 0x89bb794097234e5e930446c0cec0ea66b35d7570 | 0xeec405b834c90b59122bcc2357f27110b2adb4b7 | | Ethereum | Aave USDe/USDT | 0xc1d48bb722a22cc6abf19facbe27470f08b3db8c | 0x95d260ac86b58d458187c819f87aad2c7c4203ef | | Ethereum | rsETH/hgETH | 0x6649a010cbcf5742e7a13a657df358556b3e55cf | 0xcbc0a61E99fE3adba90BEAD3738446952bCb8002 | | Ethereum | shezUSD/sDAI | 0xac035537edf62beef0c7208181379f89def22119 | 0xf6A9bbB5D9733fa6F77120683636061bc26E7E85 | | Gnosis | Aave wstETH/GNO | 0x272d6be442e30d7c87390edeb9b96f1e84cecd8d | 0x40B04058fF35fD3164E6cc66C4E6398c1E5E68c8 | | Gnosis | Aave wETH/wstETH | 0x6e6bb18449fcf15b79efa2cfa70acf7593088029 | 0xfD151734ffC9A4A55C50fed4b66c15B06Bbb390B | | Gnosis | Aave GNO/sDAI | 0xd1d7fa8871d84d0e77020fc28b7cd5718c446522 | 0x5C36197A631649441649028110fa503a3be00162 | | Gnosis | sDAI/BRLA | 0xa91c3c043051e7e680b61d79b3a733d3e2c0fb5e | 0x7632c11C49E6091504Bb0395c0C81C8BE48f4a8C | The Balancer Maxi LM Multisig `0xc38c5f97B34E175FFd35407fc91a937300E33860` will interact with the `GaugeAdderv4` at `0x5DbAd78818D4c8958EfF2d5b95b28385A22113Cd` and call the `addGauge` function with the following arguments based on the table above: gauge(address): `Root Gauge Address` gaugeType(string): `Network` ---
**Author:** ![zekraken](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/zekraken/32/823_2.png) [@zekraken](https://forum.balancer.fi/u/zekraken)\ **Post date:** [January 8, 2025, 4:13am UTC](https://forum.balancer.fi/t/bip-750-2025-gauge-management-proposal/6248/2 "2025-01-08T04:13:04Z")
I think it is important to keep the list of voting gauges up to date, otherwise it can be difficult to navigate. I think one important piece about the in-scope criteria is that the gauge/pool is merely flagged for now and not automatically removed. There could be, in some cases, reasons why a gauge/pool has dipped below the thresholds for an “extended” period of time and should not be killed. If I understand it correctly, any project that shows up on the list going forward will have time to challenge before their gauge is moved to killed status. Another positive is that this status isn’t permanent, it can also be undone if necessary. ---
**Author:** ![Xeonus](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/xeonus/32/3621_2.png) [@Xeonus](https://forum.balancer.fi/u/Xeonus)\ **Post date:** [January 8, 2025, 7:55am UTC](https://forum.balancer.fi/t/bip-750-2025-gauge-management-proposal/6248/3 "2025-01-08T07:55:31Z")
For transparency: we performed 2 internal reviews/audits of this kill list and used the following [dune query](https://dune.com/queries/4517325) for cross-checks. We will further improve the monitoring logic once internal optimizations for the corresponding dune labels have been performed. It is worth noting that a fully automated solution is not yet feasible and human review / intervention is still needed. A quarterly gauge review cadence seems like a reasonable time-frame. ---
**Author:** ![Xeonus](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/xeonus/32/3621_2.png) [@Xeonus](https://forum.balancer.fi/u/Xeonus)\ **Post date:** [January 9, 2025, 6:51am UTC](https://forum.balancer.fi/t/bip-750-2025-gauge-management-proposal/6248/4 "2025-01-09T06:51:57Z")
[https://snapshot.box/#/s:balancer.eth/proposal/0x86f4d00790410ea0d6d1c777258b95cd4a8b12550fc583a155af282605ec39ee](https://snapshot.box/#/s:balancer.eth/proposal/0x86f4d00790410ea0d6d1c777258b95cd4a8b12550fc583a155af282605ec39ee)