BGD. aBPT Balancer V2 - Migration plan

Development
1

Hello another week from the Bored Ghosts side, Aave :ghost: !

As the community already knows, at the moment the Safety Module has as one of its components a Balancer liquidity pool token, a representation of providing liquidity on a Balancer AAVE (80%) / WETH (20%) pool. Currently, this pool with ~$144m TVL is one of the top 3 pools on the whole Balancer system.

This pool was created in January 2021, so it runs on the Balancer v1 system. Given the existence of Balancer v2 as an improved version of v1, together with the new BAL tokenomics, it is a clear requirement for the AAVE/WETH pool to migrate to Balancer v2.

As presented in the list of tasks of BGD, one of our objectives is to implement the technical aspects for the community to proceed with this migration. In this post, we will present the details of how we see this happening.

Context

As commented, the AAVE/WETH pool is relatively big and it has some particularities:

  • It is a smart pool, upgradeable, and controlled in a decentralized manner by the Aave governance.
  • The pool is highly linked to the AAVE Safety Module: the ABPT tokens (representing a liquidity position on the Balancer pool) can be deposited into a component of the Safety Module, participating this way in its dynamics.
  • 99.96% of the supply of ABPT tokens is deposited into the Aave Safety Module. This means that almost everybody providing liquidity is also depositing on the Aave SM, to receive the AAVE rewards for doing it.

It is important to highlight that same as with the AAVE/WETH pool, the Aave Safety Module is controlled by the Aave governance.

Because of all the previous aspects, the scenario can be summarised as a Balancer upgradeable pool with only 1 big liquidity provider which is upgradeable itself too (the Aave Safety Module itself, as almost every ABPT is deposited there).

Migration’s specification

Given the chain of ownership of upgradeability defined in the previous section, we consider the best way to do the migration is via an atomic upgrade of 2 contracts: the AAVE/WETH Balancer smart pool and the stkABPT Safety Module.

By doing this, the migration will be fully transparent to users, as they will not need to do any action. In addition, this way is possible to control any potential arbitrage due to liquidity disruptions that could happen if people would be obliged to withdraw from the AAVE/WETH Balancer v1 to deposit into a hypothetical AAVE/WETH Balancer v2.

Going into the technical details (and subject to any potential change if we feel adequate), the migration will consist of the following steps:

  1. Create a proposal on the Aave governance including an update of the AAVE/WETH Balancer v1 proxy and the stkABPT Safety Module proxy, which will sequentially execute the following actions:
    1. On the AAVE/WETH Balancer v1 update:
      1. Stop liquidity providing and trading.
      2. Create a new Balancer v2 WeightedPool, using the WeightedPool2TokensFactory contract.
      3. By interacting with the Balancer V2 Vault contract, migrate the whole AAVE and ETH liquidity on AAVE/WETH Balancer v1 to its equivalent on Balancer v2. Temporarily, the proxy of AAVE/WETH Balancer v1 will hold all the supply of the AAVE/WETH Balancer v2 tokens.
      4. Deploy a migrator contract from AAVE/WETH Balancer v1 tokens their Balancer v2 equivalents. This contract will define an exchange rate as between both.
      5. Transfer the AAVE/WETH Balancer v2 supply from the AAVE/WETH Balancer v1 proxy to the migrator contract.
    2. On the stkABPT Safety module update:
      1. Using the previously deployed migrator contract, migrate all the ABPT tokens of AAVE/WETH Balancer v1 currently deposited on the Safety Module, to their Balancer v2 equivalents.
      2. Store the exchange rate defined on the migrator on the Safety Module side. From this point onwards, stkABPT will operate its internal accounting with the reference of AAVE/WETH Balancer v1, by using the aforementioned exchange rate.

From the perspective of the users currently depositing their Balancer liquidity pool tokens into the Aave Safety Module, the only effect will be that when they will withdraw from the Safety Module, they will receive Balancer liquidity pool tokens of AAVE/WETH Balancer v2, instead of the ones they deposited of AAVE/WETH Balancer v1.

Next steps

BGD has already started working on this project, but we will proceed with the implementation, with the goal to have a PoC in the following 2 weeks.

Once the code is ready and security procedures are defined and applied to it, an on-chain proposal will be created. If approved by the community, the migration will be immediate.

In parallel to the previous, we will research implications to integrators of the Safety Module, supporting them if anything is needed for a simple transition.

Links

8 Likes
2

Hi @bgdlabs,

Great proposal :slight_smile:

I only have one question, more a clarification, as the Balancer v1 AAVE/ETH ABPT in the SM will be replaced by the Balancer v2 AAVE/ETH ABPT. Am I right thinking there will be a future upgrade somewhere to enable the SM to deposit this ABPT token into a Balancer Gauge to receive BAL rewards ?

Once the AAVE/ETH pool on Balancer v2 has been created, I would be happy to help out by doing the proposal to create a Balancer gauge which will enable the BAL rewards to be distributed to LPs. I think this step would happen after this proposal via a separate upgrade, but not fully sure.

It would be great if Users could receive BAL rewards and given the Aave DAO is planning to build a veBAL position, this voting influence could be used to direct BAL rewards to the AAVE/ETH Gauge.

3 Likes
3

Thanks @MatthewGraham .

For that model a bit more thinking is needed. It’s possible to include in the proposal the automatic staking of ABPT into a Balancer Gauge by the SM itself. But to include extra accounting for the transparent distribution of rewards has a bit more complexity, given how the SM smart contract works.

But it is something that one way or another will need to come down the line.

2 Likes
4

I believe that Notional Finance has this sort of set up with their 80/20 staking module that autodeposits into the gauge nProxy | Address 0x38de42f4ba8a35056b33a746a6b45be9b1c3b9d2 | Etherscan

More info here:

Figured it would be helpful to drop that info here!

3 Likes
5

What happened with this proposal? What’s the current status of the migration? This pool could get a gauge on Balancer v2.

6

This project has been delayed a bit, mainly for 2 reasons:

  1. The proposal to lower requirements on the Level 2 executor (executed end of October 2022) was a pre-requirement, as this migration involves the upgrade of smart contracts controlled by Level 2.
  2. We studied the status of the Safety Module holistically and realized that it is way more optimal in terms of governance procedures, development, and security audits to pack together different changes affecting both stkAAVE and the aBPT/stkABPT discussed on this thread.
  3. During the last 2 months, the audit pipeline of the community has been quite full, with projects like Aave v3 Ethereum, GHO, and others having quite high priority.

But we have being doing progress on the holistic approach referenced on 2), and currently Certora is already reviewing this Safety Module update, which includes this specific aBPT update too.

3 Likes