# \[BIP-262\] L2 Gauge Migration

**URL:** <https://forum.balancer.fi/t/bip-262-l2-gauge-migration/4661>\
**Category:** General Proposal\
**Created:** [April 15, 2023, 2:48pm UTC](https://forum.balancer.fi/t/bip-262-l2-gauge-migration/4661 "2023-04-15T14:48:41Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![solarcurve](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/solarcurve/32/1487_2.png) [@solarcurve](https://forum.balancer.fi/u/solarcurve)\
**Post date:** [April 15, 2023, 2:48pm UTC](https://forum.balancer.fi/t/bip-262-l2-gauge-migration/4661/1 "2023-04-15T14:48:41Z")

</div>

### [BIP-262-L2-Gauge-Migraiton by solarcurvey · Pull Request #141 · BalancerMaxis/multisig-ops · GitHub](https://github.com/BalancerMaxis/multisig-ops/pull/141)

### Motivation

Development of cross chain gauge boosts in collaboration with Layer Zero has progressed significantly and the new L2 gauges are ready to be used. Every existing gauge on a network other than Ethereum will either be migrated to a new gauge that supports cross chain boosts or killed. Balancer’s UI will feature the ability for veBAL lockers to sync their veBAL balance to non-ethereum networks to take advantage of boosted BAL emissions - this is expected over the next one or two months.

There will be four groups of transactions - group A will add the new gauges to Gnosis chain and be executed immediately. Group B will kill the old gauges on Gnosis chain and be executed approximately on May 9th. Group C will add all new gauges on all other L2 networks, to be executed approximately on May 9th. Group D will kill all old gauges on other L2 networks approximately on May, 23rd. This is to allow time for the respective Aura voting cycle to complete to ensure any protocols providing voting incentives get the full value of those incentives. For those new gauges which get veBAL votes before May 4th the first emissions through the new gauges would start on May 11th. The one week emission delay for voting would be true for gauges voted on in the later cycle.

Also on May 11th Balancer’s UI will display informational warning messages on all L2 pools which are getting a new gauge - this will provide a one click “gauge migration” for LP’s, meaning unstaking from the old gauge and re-staking in the new one. These will be applied as pools are migrating over the next several weeks.

> **These L2 root gauges are being killed rather than migrated due to a lack of usage, 12 total.**
>
> o-stg/bb-rf-aUSDC → `0xC02b1b15888277B54Fb4903ef3Dedf4881a8c73A`
> 
> o-IB/rETH → `0x78F50cF01a2Fd78f04da1D9ACF14a51487eC0347`
> 
> o-wstETH/LDO → `0xeC6BA3d9D9045997552155599E6Cc89aA08Ffd76`
> 
> o-bbrfaUSD → `0x8B815a11D0D9eeeE6861D1C5510d6FAA2C6e3fEb`
> 
> o-rETH/bbrfaUSD/bbrfOP → `0x97a92eDcDD4176B1495bF5DA6D9547537A53ED72`
> 
> o-bbrfaUSD/beets/rETH/bbrfBAL → `0xb8F91FF8Cd5005f6274B6c2292CF3CCCdBCF32b7`
> 
> o-wstETH/bbrfaUSD/bbrfaWBTC → `0xa26B3523227e300Ff8eCA69CD3b0bdcbd2Db0313`
> 
> o-wstETH/bbrfaWETH → `0x74CE2247eC3f0b87BA0737497e3Db8873c184267`
> 
> a-BAL/WETH → `0x6823DcA6D70061F2AE2AAA21661795A2294812bF`
> 
> a-vst/dai/usdt/usdc → `0x709E5d6258aa97F12f3167844CB858696c16F39A`
> 
> a-weth/vsta → `0xd863DA50435D9FCf75008f00e49fFd0722291d94`
> 
> p-rbw/weth → `0xa3E3B2C9C7A04894067F106938cA81e279bC3831`

We will be coordinating with the various voting incentive marketplaces to ensure all future voting incentives only go towards the new gauges.

> **List of L2 root gauges to be migrated, 33 total**
>
> g-bbagUSD → `0x25D6F29429bccCc129d1A3e2a5642C8B929BCC07`
> 
> g-bbag USD/WETH/WBTC → `0x56A65cC666bfe538c5a031942369F6F63eb42240`
> 
> g-bbag USD/GNO → `0xd27671f057e9e72751106fBfbBBB33827D986546`
> 
> g-bbag WETH/GNO → `0x3FB2975E00B3dbB97E8315a5ACbFF6B38026FDf3`
> 
> o-weth/rETH → `0xfb0265841C49A6b19D70055E596b212B0dA3f606`
> 
> a-RDNT/WETH → `0x19ff30f9B2d32bfb0F21f2DB6c6A3A8604Eb8C2B`
> 
> a-wstETH/weth → `0x519cCe718FCD11AC09194CFf4517F12D263BE067`
> 
> a-bbrfgUSD → `0x5b0C1b84566708Dd391Ae0FecE1a32e33682EE3d`
> 
> a-wbtc/weth/usdc → `0x359EA8618c405023Fc4B98dAb1B01F373792a126`
> 
> a-bb-DAI+/bb-USD+ → `0x5A7f39435fD9c381e4932fa2047C9a5136A5E3E7`
> 
> a-MAGIC/USDC → `0x68EBB057645258Cc62488fD198A0f0fa3FD6e8fb`
> 
> a-bbaweth/rETH → `0xad2632513bFd805A63aD3e38D24EE10835877d41`
> 
> a-bbaweth/wstETH → `0x74d3aa5F9A2863DC22f6cF9c5faaca4E1fc86F75`
> 
> a-bbaUSD → `0xb2102335Ea09E0476F886Ef7a4e77170235c408E`
> 
> p-bbawmatic/maticX → `0x87F678f4F84e5665e1A85A22392fF5A84adC22cD`
> 
> p-bbawmatic/stMATIC → `0xBD734b38F2dc864fe00DF51fc4F17d310eD7dA4D`
> 
> p-tetu/usdc → `0x1E0C21296bF29EE2d56e0abBDfbBEdF2530A7c9A`
> 
> p-sphere/wmatic → `0x90437a1D2F6C0935Dd6056f07f05C068f2A507F9`
> 
> p-usdc/wusdr → `0x21a3De9292569F599e4cf83c741862705bf4f108`
> 
> p-bbtUSD → `0x28D4FE67c68d340fe66CfbCBe8e2cd279d8AA6dD`
> 
> p-wbtc/usdc/weth → `0x88D07558470484c03d3bb44c3ECc36CAfCF43253`
> 
> p-jEUR/PAR → `0x0DB3F34d07682B7C61B0B72D02a26CD3cBDBBdd0`
> 
> p-20weth-80bal/tetuBAL → `0xcF5938cA6d9F19C73010c7493e19c02AcFA8d24D`
> 
> p-wmatic/usdc/weth/bal → `0xA5A0B6598B90d214eAf4d7a6b72d5a89C3b9A72c`
> 
> p-tetuQI/QI → `0xD762F3C30A17222C0b8d25aFE1F1dCEC9816F15B`
> 
> p-thx/stMATIC → `0xEd510769CCf53eA14388Fc9d6E98EDa5b1a5BAC8`
> 
> p-xSGD/USDC → `0xe42382D005A620FaaA1B82543C9c04ED79Db03bA`
> 
> p-wmatic/ankrMATIC → `0x6a08FD22bd3B10a8EB322938FCaa0A1B025BF3b3`
> 
> p-tngbl/usdc → `0x43E4bE3A89985c4f1fCB4c2D3bd7e6E0C5df42D3`
> 
> p-jEUR/agEUR → `0x3bEEB803124bf0553B1d54301BA18368c74483c6`
> 
> p-sd/maticX → `0x9649d14f2b3300Edf690C96fbCb25eDC4B52Ea05`
> 
> p-wstETH/bbaweth → `0x304a75f78C96767a814c36Aaa74d622ECf875d36`
> 
> p-bbaUSD → `0x8D7d227746eE06D2532903D6EF1F69D80647C0E7`

### Specification

> **Group A**
>
> #1  
> The DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will initiate a transaction to the Authorizer `0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6` calling grantRole with the following arguments:
> 
> role: `0xf49d7ffb5922642adc9f29cfb52b2214e81e0b0e54e9cd1e9f70439f0011f368`
> 
> This corresponds with the role for calling add\_gauge on the gaugeController.
> 
> account: `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f`
> 
> This allows the DAO Multisig to directly add gauges to the controller.
> 
> #2  
> The DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will interact with the AuthorizerAdaptor at `0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75` and call performAction with the GaugeController at `0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD` for the target(address) argument and using `0x3a04f900` followed by the gauge addresses listed below and the corresponding gauge type for the data(bytes) argument.
> 
> > **List of gauge addresses**
> >
> > g-bbagUSD → `0x3B6A85B5e1e6205ebF4d4eabf147D10e8e4bf0A5`
> > 
> > g-bbag USD/WETH/WBTC → `0x21b2Ef3DC22B7bd4634205081c667e39742075E2`
> > 
> > g-bbag USD/GNO → `0xcB2c2AF6c3E88b4a89aa2aae1D7C8120EEe9Ad0e`
> > 
> > g-bbag WETH/GNO → `0xE41736b4e78be41Bd03EbAf8F86EA493C6e9EA96`
> 
> #3
> 
> The DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will initiate a transaction to the Authorizer `0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6` calling renounceRole with the following arguments:
> 
> role: `0xf49d7ffb5922642adc9f29cfb52b2214e81e0b0e54e9cd1e9f70439f0011f368`
> 
> This corresponds with the role for calling add\_gauge on the gaugeController as seen here .
> 
> account: `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f`
> 
> This removes the ability for the DAO Multisig to directly add gauges to the controller.

> **Group B**
>
> 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 gauges for the target(address) argument.
> 
> > **List of gauges to be killed**
> >
> > g-bbagUSD → `0x25D6F29429bccCc129d1A3e2a5642C8B929BCC07`
> > 
> > g-bbag USD/WETH/WBTC → `0x56A65cC666bfe538c5a031942369F6F63eb42240`
> > 
> > g-bbag USD/GNO → `0xd27671f057e9e72751106fBfbBBB33827D986546`
> > 
> > g-bbag WETH/GNO → `0x3FB2975E00B3dbB97E8315a5ACbFF6B38026FDf3`

> **Group C**
>
> #1  
> The DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will initiate a transaction to the Authorizer `0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6` calling grantRole with the following arguments:
> 
> role: `0xf49d7ffb5922642adc9f29cfb52b2214e81e0b0e54e9cd1e9f70439f0011f368`
> 
> This corresponds with the role for calling add\_gauge on the gaugeController.
> 
> account: `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f`
> 
> This allows the DAO Multisig to directly add gauges to the controller.
> 
> #2  
> The DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will interact with the AuthorizerAdaptor at `0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75` and call performAction with the GaugeController at `0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD` for the target(address) argument and using `0x3a04f900` followed by the gauge addresses listed below and the corresponding gauge type for the data(bytes) argument.
> 
> > **List of gauge addresses**
> >
> > o-weth/rETH → `0xDaCD99029b4B94CD04fE364aAc370829621C1C64`
> > 
> > a-RDNT/WETH 10% cap → `0x8135d6AbFd42707A87A7b94c5CFA3529f9b432AD`
> > 
> > a-wstETH/weth → `0xDf464348c4EC2Bf0e5D6926b9f707c8e02301adf`
> > 
> > a-bbrfgUSD → `0x09D1036B04ef49BC155D258D7360FA7aE8F5B84d`
> > 
> > a-wbtc/weth/usdc → `0xf460C9A5D00ef665F12Ee9634983A2b799dA5317`
> > 
> > a-bb-DAI+/bb-USD+ → `0x260779495dA7Ce3A76b44F5C994cD18EBDa8177f`
> > 
> > a-MAGIC/USDC → `0x0EDF6cDd81BC3471C053341B7D8Dfd1Cb367AD93`
> > 
> > a-bbaweth/rETH → `0x4944b07977A42C15c6a06CF4e204e24c60564104`
> > 
> > a-bbaweth/wstETH → `0xB5044FD339A7b858095324cC3F239C212956C179`
> > 
> > a-bbaUSD → `0x54BeFB03BB58687cDE09cd082Bd78410e309D8C7`
> > 
> > p-bbawmatic/maticX → `0x082AACfaf4db8AC0642CBED50df732D3C309E679`
> > 
> > p-bbawmatic/stMATIC → `0xDd3b4161D2a4c609884E20Ed71b4e85BE44572E6`
> > 
> > p-tetu/usdc 2% cap-\> `0x1f5Cb5b832f27E24A3b0ad4b837d3Ed26FF7aC6E`
> > 
> > p-sphere/wmatic 2% cap-\> `0xA4c104AB9116a84714C081e0Ed6d750221e4c756`
> > 
> > p-usdc/wusdr 2% cap-\> `0xc534C30749b6C198D35a7836E26076E7745D8936`
> > 
> > p-bbtUSD → `0x39cEEbb561a65216A4B776ea752d3137e9d6C0F0`
> > 
> > p-wbtc/usdc/weth → `0x1604b7E80975555e0aCEaca9C81807FbB4D65Cf1`
> > 
> > p-jEUR/PAR 2% cap → `0x16289F675Ca54312a8fCF99341e7439982888077`
> > 
> > p-20weth-80bal/tetuBAL → `0xd1177e2157a7fD6A0484B79f8E50e8A9305F8063`
> > 
> > p-wmatic/usdc/weth/bal → `0xF5C7F74103d4E9D1fF8FBa3420c6319723e3473A`
> > 
> > p-tetuQI/QI 2%cap → `0x31F99c542CbE456FcbBe99D4bf849Af4D7fB5405`
> > 
> > p-thx/stMATIC 2% cap-\> `0xe603cc3f7Ec38cC6ab1Eef7FdA9Bb599493e9a24`
> > 
> > p-xSGD/USDC 2% cap → `0x145011e0C04805E11BEf23c1EEd848Faf49bB779`
> > 
> > p-wmatic/ankrMATIC → `0x21483F79a1aE94536Dc1d5dDfC6f591fB3B430Df`
> > 
> > p-tngbl/usdc 2% cap → `0x2cc5BebcFdAAD20f2a608EC153d1C7BED66EeEC3`
> > 
> > p-jEUR/agEUR 2% cap → `0x790DE8ABE859f399023BCe73B5FE5C4870cD816A`
> > 
> > p-sd/maticX 2% cap-\> `0x0a650F4E0C416c24C8713c322d5AAA531a5A0112`
> > 
> > p-wstETH/bbaweth → `0x47D7269829Ba9571D98Eb6DDc34e9C8f1A4C327f`
> > 
> > p-bbaUSD → `0x6b641e334f63f0D882538Fe189efC0702d961696`
> 
> #3
> 
> The DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will initiate a transaction to the Authorizer `0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6` calling renounceRole with the following arguments:
> 
> role: `0xf49d7ffb5922642adc9f29cfb52b2214e81e0b0e54e9cd1e9f70439f0011f368`
> 
> This corresponds with the role for calling add\_gauge on the gaugeController as seen here .
> 
> account: `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f`
> 
> This removes the ability for the DAO Multisig to directly add gauges to the controller.

> **Group D**
>
> 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 gauges for the target(address) argument.
> 
> > **List of gauges to be killed**
> >
> > o-stg/bb-rf-aUSDC → `0xC02b1b15888277B54Fb4903ef3Dedf4881a8c73A`
> > 
> > o-IB/rETH → `0x78F50cF01a2Fd78f04da1D9ACF14a51487eC0347`
> > 
> > o-wstETH/LDO → `0xeC6BA3d9D9045997552155599E6Cc89aA08Ffd76`
> > 
> > o-bbrfaUSD → `0x8B815a11D0D9eeeE6861D1C5510d6FAA2C6e3fEb`
> > 
> > o-rETH/bbrfaUSD/bbrfOP → `0x97a92eDcDD4176B1495bF5DA6D9547537A53ED72`
> > 
> > o-bbrfaUSD/beets/rETH/bbrfBAL → `0xb8F91FF8Cd5005f6274B6c2292CF3CCCdBCF32b7`
> > 
> > o-wstETH/bbrfaUSD/bbrfaWBTC → `0xa26B3523227e300Ff8eCA69CD3b0bdcbd2Db0313`
> > 
> > o-wstETH/bbrfaWETH → `0x74CE2247eC3f0b87BA0737497e3Db8873c184267`
> > 
> > a-BAL/WETH → `0x6823DcA6D70061F2AE2AAA21661795A2294812bF`
> > 
> > a-vst/dai/usdt/usdc → `0x709E5d6258aa97F12f3167844CB858696c16F39A`
> > 
> > a-weth/vsta → `0xd863DA50435D9FCf75008f00e49fFd0722291d94`
> > 
> > p-rbw/weth → `0xa3E3B2C9C7A04894067F106938cA81e279bC3831`
> > 
> > ——
> > 
> > o-weth/rETH → `0xfb0265841C49A6b19D70055E596b212B0dA3f606`
> > 
> > a-RDNT/WETH → `0x19ff30f9B2d32bfb0F21f2DB6c6A3A8604Eb8C2B`
> > 
> > a-wstETH/weth → `0x519cCe718FCD11AC09194CFf4517F12D263BE067`
> > 
> > a-bbrfgUSD → `0x5b0C1b84566708Dd391Ae0FecE1a32e33682EE3d`
> > 
> > a-wbtc/weth/usdc → `0x359EA8618c405023Fc4B98dAb1B01F373792a126`
> > 
> > a-bb-DAI+/bb-USD+ → `0x5A7f39435fD9c381e4932fa2047C9a5136A5E3E7`
> > 
> > a-MAGIC/USDC → `0x68EBB057645258Cc62488fD198A0f0fa3FD6e8fb`
> > 
> > a-bbaweth/rETH → `0xad2632513bFd805A63aD3e38D24EE10835877d41`
> > 
> > a-bbaweth/wstETH → `0x74d3aa5F9A2863DC22f6cF9c5faaca4E1fc86F75`
> > 
> > a-bbaUSD → `0xb2102335Ea09E0476F886Ef7a4e77170235c408E`
> > 
> > p-bbawmatic/maticX → `0x87F678f4F84e5665e1A85A22392fF5A84adC22cD`
> > 
> > p-bbawmatic/stMATIC → `0xBD734b38F2dc864fe00DF51fc4F17d310eD7dA4D`
> > 
> > p-tetu/usdc → `0x1E0C21296bF29EE2d56e0abBDfbBEdF2530A7c9A`
> > 
> > p-sphere/wmatic → `0x90437a1D2F6C0935Dd6056f07f05C068f2A507F9`
> > 
> > p-usdc/wusdr → `0x21a3De9292569F599e4cf83c741862705bf4f108`
> > 
> > p-bbtUSD → `0x28D4FE67c68d340fe66CfbCBe8e2cd279d8AA6dD`
> > 
> > p-wbtc/usdc/weth → `0x88D07558470484c03d3bb44c3ECc36CAfCF43253`
> > 
> > p-jEUR/PAR → `0x0DB3F34d07682B7C61B0B72D02a26CD3cBDBBdd0`
> > 
> > p-20weth-80bal/tetuBAL → `0xcF5938cA6d9F19C73010c7493e19c02AcFA8d24D`
> > 
> > p-wmatic/usdc/weth/bal → `0xA5A0B6598B90d214eAf4d7a6b72d5a89C3b9A72c`
> > 
> > p-tetuQI/QI → `0xD762F3C30A17222C0b8d25aFE1F1dCEC9816F15B`
> > 
> > p-thx/stMATIC → `0xEd510769CCf53eA14388Fc9d6E98EDa5b1a5BAC8`
> > 
> > p-xSGD/USDC → `0xe42382D005A620FaaA1B82543C9c04ED79Db03bA`
> > 
> > p-wmatic/ankrMATIC → `0x6a08FD22bd3B10a8EB322938FCaa0A1B025BF3b3`
> > 
> > p-tngbl/usdc → `0x43E4bE3A89985c4f1fCB4c2D3bd7e6E0C5df42D3`
> > 
> > p-jEUR/agEUR → `0x3bEEB803124bf0553B1d54301BA18368c74483c6`
> > 
> > p-sd/maticX → `0x9649d14f2b3300Edf690C96fbCb25eDC4B52Ea05`
> > 
> > p-wstETH/bbaweth → `0x304a75f78C96767a814c36Aaa74d622ECf875d36`
> > 
> > p-bbaUSD → `0x8D7d227746eE06D2532903D6EF1F69D80647C0E7`

---

<div class="post-metadata">

**Author:** ![phijifry](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/phijifry/32/1867_2.png) [@phijifry](https://forum.balancer.fi/u/phijifry)\
**Post date:** [April 18, 2023, 10:58am UTC](https://forum.balancer.fi/t/bip-262-l2-gauge-migration/4661/2 "2023-04-18T10:58:08Z")

</div>

Fantastic proposal, and it’s great to see that it’s making progress. The move to go cross-chain with gauges and boosting is a significant step towards enabling users on layer 2s and sidechains to access the full range of benefits that the Balancer ecosystem has to offer, including Aura.

I have a suggestion that could help reduce the risks associated with the migration process. In my opinion, it would be more beneficial to deploy the migration in two phases. Firstly, we could migrate a smaller chain, such as Gnosis. Then following a successful migration there push forward with the rest.

A cautious and thoughtful approach to the initial deployment could benefit everyone involved and give us all an even higher level of confidence in the new gauges, layer zero contracts, and relayers before proceeding with the migration to other chains. This approach might push the timelines back by an epoch or two, but I believe that the benefits of a reduced risk and the avoidance of potential future migrations outweigh any minor delay.

I look forward to hearing others’ thoughts on this suggestion and any additional ideas they might have.

---

<div class="post-metadata">

**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:** [April 18, 2023, 3:46pm UTC](https://forum.balancer.fi/t/bip-262-l2-gauge-migration/4661/3 "2023-04-18T15:46:00Z")

</div>

[https://snapshot.org/#/balancer.eth/proposal/0x80330ddb48c3d0aef169d2deb8af8792e78be76438a2ddc1c01677e5054ae2eb](https://snapshot.org/#/balancer.eth/proposal/0x80330ddb48c3d0aef169d2deb8af8792e78be76438a2ddc1c01677e5054ae2eb)