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

7 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.

2 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
7

ABPT Balancer v1 → v2 Migration update


Since the snapshot on the AAVE/wstETH migration was submitted in may 2023, the Safety Module has undergone multiple upgrades, from slashing over emission change to the most recent Aave Governance v3 upgrade which lead to significant gas savings for stk tokens (before, after).

In parallel to this development an effort was started to create a manipulation resistant oracle to price the balance v2 AAVE/wstETH LP which was deployed ~two months ago. Important to highlight that is for off-chain usage, not on the smart contracts layer.


While the original plan was to upgrade the stkABPT token contract on the fly (from Balancer v1 to Balancer v2 with same token composition), the change of plans decided on the Snapshot vote forced us to adjust the migration plan.
Therefore a new migration contract was developed allowing users to migrate their positions via one single transaction.

As the pending upgrades were blocking the release and a new safety module deployment (to be used with stkGHO) was already on the horizon, we spend some extra time reworking the stake-token contract to have a more maintainable code-base in the future.

On the original contract there were a lot of minor issues like:

  • Spec deviations (because some of the EIPs the stake-token implements were not finalized at the time of original deployment).
  • Deprecated open-zeppelin dependencies.
  • Presence of deprecated storage slots for legacy reasons.
  • Immutables for aspects that should be variable (distribution end, cooldown period).
  • Complex nested inheritance chains.

All of them have been resolved now, and all changes have been audited by Certora, which means we are finally ready to create a proposal for the community to approve stkABPTv2.



The governance proposal will do the following:

  1. Upgrades the existing stkABPT(v1) to allow immediate withdrawal without cooldown and disable slashing.
  2. Stops emission on stkABPT(v1).
  3. Starts emission on the new stkABPT(v2).

The stkABPT(v2) will be configured analog to stkABPT(v1)

  • 20 days of cooldown
  • 2 days to unstake
  • 30% max slashing

The now variable distributionEnd will be set to 1 year after the safety module activation. This can be changed by the community at any time, but seems like the correct approach, not being too long or too short.

3 Likes
8

Following the timeline, an on-chain AIP has been created for the migration of stkABPT v1 to stkABPT v2.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=21



If the community approves it, a migration tool will be available for stkABPT v1 positions on https://app.aave.com/staking/

1 Like