[BIP-51] Gauge Migration to Composable Stable Pools

Motivation:

As of May 17th 2022 a benevolent hacker disclosed a potential vulnerability to stable and managed pools as shared by Fernando’s Vulnerability Disclosure. No funds were ever at risk. As a result, however, all phantom stable and managed pools need to be upgraded by deploying new contracts to fix the vulnerability.

The affected Contracts are the following:
The vulnerability was present in contracts deployed by the following factories:
• StablePoolFactory
• MetaStablePoolFactory
• StablePhantomPoolFactory
• InvestmentPoolFactory

The fix for the disclosed vulnerability has been facilitated by the Balancer Labs team and the implementation has been approved by governance as highlighted by [BIP-31] Authorize the Batch Relayer v3. The proposed way forward is to allow all new contracts to be approved for liquidity gauge incentives, assuming they are replacing one of the current gauges that were compromised due to the vulnerability.

Allowing this proposal will reduce friction by decreasing the amount of repetitive governance votes for pools which are currently in good standing with the protocol. Furthermore, the transition for liquidity providers to migrate from the soon to be deprecated pools to the newly launched contracts will be less confusing in this streamlined format, as opposed to fragmenting the process.

Specification

The following pools listed by network are meant to be replaced by the newly deployed contracts and will automatically be approved for a liquidity gauge; the underlying assets and attributes are identical to the originals. The deprecated pools will no longer receive core pools bribes as they will be redirected to the updated addresses.

Ethereum (1) bb-a-USD –

Current Pool Address: 0x7B50775383d3D6f0215A8F290f2C9e2eEBBEceb2
Current Gauge Address: 0x68d019f64A7aa97e2D4e7363AEE42251D08124Fb

New Pool Address: 0x9B532AB955417AFD0D012EB9F7389457CD0EA712
New Gauge Address: 0x66122C9030030155fB2BBE2E1E9A72588065C4f5

Polygon (137) B-stMATIC-STABLE (WMATIC/stMATIC)

Current Pool Address: 0xaF5E0B5425dE1F5a630A8cB5AA9D97B8141C908D
Current Gauge Address:0xc3bB46B8196C3F188c6A373a6C4Fde792CA78653

New Pool Address: 0x0b8319061732b34cab22445fa83b81f950e4b7ed
New Gauge Address: 0xBF01d2b482381881592579802b423bA894c0Df84
Mainnet Root Gauge: 0xfe78625545d64f6D8D8b8d5c9725A951cC02f904
Polygon Streamer: 0x8D3A5d94DF2cBda23FF6e6014D7Ac1121c3622D0

Polygon (137) B-MaticX-STABLE

Current Pool Address: 0xC17636e36398602dd37Bb5d1B3a9008c7629005f
Current Gauge Address:0xf01541837CF3A64BC957F53678b0AB113e92911b

New Pool Address: 0x7947df380f4ef1da1e7083c174d6a7ed8edeed95
New Gauge Address: 0xc06aD80598d846Ea7E94c051D346b3f73FeaE86A
Mainnet Root Gauge: 0xce1Bd9772B3dB5e138726436bBf7e9B5BC844B77
Polygon Streamer: 0x93cd981ee6f44ebd3f57b6850fbfaefa186d8049

Killing Gauges

If approved, the DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the AuthorizerAdaptor at 0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75 and call performAction using 0xab8f0945 for the data(bytes) argument and the following list of contracts for the target(address) argument. Each contract will be its own transaction, thus there will be a total of 3 transactions.

Ethereum (1) bb-a-USD – 0x68d019f64A7aa97e2D4e7363AEE42251D08124Fb

Polygon (137) B-stMATIC-STABLE (WMATIC/stMATIC) - 0xc3bB46B8196C3F188c6A373a6C4Fde792CA78653

Polygon (137) B-MaticX-STABLE - 0xf01541837CF3A64BC957F53678b0AB113e92911b

Activation of New Gauges

All pools in the scope of this proposal will be incentivized as core pools outlined here by BIP-19.

The following pool’s owner are set to the DAO Address: 0xba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1b

The transactions to complete this process will be executed by the LM Multisig via the gaugeAdder V2.
Address: 0xc38c5f97B34E175FFd35407fc91a937300E33860

Execution Plan:

  • The current gauges corresponding to the pools listed above will be killed by the DAO multisig 3 voting epochs from the approval of this proposal.
  • The new gauges will go into effect as soon as reasonably possible, allowing adequate time for liquidity to migrate to the new pools.
  • The next round of BIP-19 core pool incentives will apply to the new pool addresses.
  • All transactions will be executed by the LM Multisig to approve the new gauges.
  • All transactions to kill the obsolete gauges will be executed by the DAO Multisig.

Risks:

  • The new contracts for the respective pools are currently under audit. There is a potential for this migration to take place and need to be repeated upon any potential vulnerabilities in the new versions.
  • Liquidity is not moved from the current pools to the new pools in a time effective way. Too quickly or too slowly, decreasing the overall revenue of the Protocol.

Conclusion:

Migration to the new contracts is a safe step forward for Balancer. This provides more flexibility for users with less risk due to the vulnerability disclosed prior. The process will last several weeks to permit liquidity migration to happen in a progressive fashion and not shock LPs in any way. The incomplete audit of these new contracts is inherently a risk, however the complexity of the updates are relatively low to a point where migration at this time is worthwhile. Ideally this will showcase Balancer as a safe place to facilitate liquidity provision and swapping on yield bearing assets moving forward.

**Edit to Specification section to properly kill gauges using the AuthorizerAdaptor. As done in [BIP-30] Purge Unused Gauges.

5 Likes

https://snapshot.org/#/balancer.eth/proposal/0x4d4b23994bcc53e01144fe6ebd76806de80ea570911401ec6af63f357cc59804