[TEMP CHECK] Safety Module Update Part I - Migrate AAVE/wETH Balancer v1 Pool to Balancer v2

Governance
1

title: [TEMP CHECK] Safety Module Update Part I - Migrate AAVE/wETH Balancer v1 Pool to Balancer v2
author: @Llamaxyz - @dydymoon & @TokenLogic
created: 2023-04-13

Summary

The publication proposes creating a new AAVE liquidity pool on Balancer v2 and including the BPT in Aave’s Safety Module (SM).

Abstract

The SM currently accepts two deposit tokens, AAVE and ABPT. The ABPT is a 80/20 AAVE/wETH Balancer v1 liquidity pool receipt token. Balancer v1 is now obsolete and the main AAVE liquidity pool requires migrating. This publication presents several pool options to consider when migration of the main decentralized exchange (DEX) AAVE liquidity pool and if the receipt token (ABPT) should be included in Aave’s SM.

Given Balancer DAO has adopted a veTokenomics model, if the new AAVE liquidity pool was to receive a gauge and incentives then this would represent an alternative yield source that does not incur any risk of shortfall. This is an important consideration when estimating the cost of renting users backstop liquidity within the SM.

This publication seeks to determine what liquidity pools should be created on Balancer v2 and if those ABPTs are to be included within Aave’s SM.

Motivation

By depositing AAVE and ABPT into the SM, depositors receive stkAAVE and stkBPT respectively, along with yield nominated in AAVE. 550 AAVE are distributed daily to users who stake AAVE and another 550 AAVE is distributed daily to depositors who stake ABPT. In return for the AAVE yield, depositors are risking up to 30% of their capital by providing a backstop for the Aave liquidity pools.

Currently, the ABPT accepted in the SM is representative of a liquidity position on Balancer v1, 80/20 AAVE/wETH. The initial portion of this proposal is to focus on if the AAVE liquidity is to be migrated to Balancer v2 and if so, what pool composition should be considered. For the remainder of this publication, it is assumed Aave seeks to continue having the primary AAVE liquidity pool on Balancer protocol and other DEX providers are not considered,

This publication excludes BPTs featuring Balancer Linear boosted Pools which deposit funds into Aave v3 deployments from inclusion in the Aave SM due to the systemic risk of using deposits in Aave as backstop for Aave. This pool type is still worthy of consideration for being the main AAVE liquidity pool, or for the StakedATokens but without being accepted into the SM.

Non-Aave Boosted pool pairs were also excluded from this proposal during the initial review due to the increased risk surface area spanning beyond Balancer and Aave Protocols, but could still be considered if the community decides it, as long as the underlying strategy is fully unrelated to Aave. There are alternative means of improving the capital efficiency for liquidity providers with better risk reward trade-offs. An example is established and battle tested Liquid Staking Tokens (LST).

Considering the SM is over exposed to the AAVE token, the following options will focus on reducing the AAVE weights and explaining the pros & cons for each option. This publication presents the following four Balancer v2 liquidity pools options for discussion:

1. 80/20 AAVE/wETH
Like for like pool migrating v1 to v2
2. 80/20 AAVE/wstETH
Like for like migration with improved capital efficiency
3. 50/50 AAVE/wETH
Reduces AAVE concentration within SM, increases wETH
4. 50/50 AAVE/wstETH
Reduces AAVE concentration, increases capital efficiency by including most dominant ETH LST

In the future, an AAVE/GHO pool could be created and introduced for consideration in the SM.

Option 1 - 80/20 AAVE/wETH

This option only requires to recreate the same pool on v2 and for users to migrate.

Option 2 - 80/20 AAVE/wstETH

Option 2 is the same as Option 1 whilst replacing the unproductive wETH with wstETH. There is additional risk to consider with the inclusion of an LST relative to wETH and the additional yield it offers Liquidity Providers.

Option 3 - 50/50 AAVE/wETH

This option involves pivoting the 80/20 pool weight on the existing pool to 50/50 when deploying the new pool. Inclusion of this pool in the SM will increase the portion of wETH within the stkABPT deposits. However, it is expected the pool would experience greater impermanent loss due to the equal split composition of the pool and this could lead to higher reward expectations.

Users who migrate directly, will need to add wETH to their liquidity withdrawn from the Balancer v1 pool when depositing into the new 50/50 pool to avoid triggering a swap upon depositing.

Option 4 - 50/50 AAVE/wstETH

The Option 4 pool could be converted into a Balancer Core Pool by replacing wETH with wstETH, as the Core Pools require at least 50% in a Interest Bearing Token (IBT).

For context, 50% of the yield generated from the IBT is collected with 65% directed towards bribes via Hidden Hand for voting incentives and the remaining 35% are kept by the Balancer DAO. The Balancer team is responsible for claiming the portion of yield and distributing it to attract veBAL votes.

Considering the Shanghai upgrade date is confirmed, the risks on LST de-peg and liquidity will be reduced over time, which would make it a good asset in the SM.

Discussion

Llama suggests keeping the 80/20 composition of the v1 Balancer pool and replacing wETH with wstETH when deploying the new Balancer v2 pool. This publication favors Option 2 due to the additional capital efficiency of including an LST relative to wETH and noting the majority of the ETH correlated liquidity on Balancer v2 is nominated in wstETH. There is also the potential upside of BAL rewards which is significant given the current Aave roadmap considerations.

If the Aave community is to pursue this pool, Llama will proceed to seek support within the Balancer, Aura and other communities to determine if Aave would be eligible to participate in the 80/20 incentive program. The wstETH component, plus swap fees, would help reach the revenue contribution requirement of the pool. Whilst the time-lock on the Safety Module is only 3 weeks, it will contribute towards the 16 week time lock requirement mentioned in the proposal, linked here.

Given the AAVE/wETH pool currently holds $117M of liquidity, migrating 100% of the pool would nearly meet the top tier TVL requirement ($140M with $7/BAL). With 20% of the pool held in wstETH, yielding 4.5%, this is equivalent to $1.05M in wstETH nominated yield. If Balancer was to receive 50% of this wstETH yield as revenue, then Aave could receive the maximum 250K BAL, provided other conditions are met over the lifetime of the program. For full details do read this forum post and an amendment to the original proposal.

The migration will require users to activate the cooldown, unstake the BPT v1, withdraw the liquidity, deposit on the new pool and restake.

This can be implemented independently from the following parts. In this case, a “classic” gauge will be required. Alternatively, the gauge design will be discussed in Part III.

Technical Specifications:

  • Migrate the SM Infrastructure to Balancer V2 (BGD)
  • Create the new pool depending on vote results (Balancer / Llama)
  • Add support of the new pool in the SM (BGD)

Next Steps

Continue the discussion in the comments. The following options are to be presented for voting after a suitable period of time has passed.

Voting options

  1. YAE - 80/20 AAVE/wETH
  2. YAE - 80/20 AAVE/wstETH
  3. YAE - 50/50 AAVE/wETH
  4. YAE - 50/50AAVE/wstETH
  5. NAE - Rework Proposal
  6. ABSTAIN

Reference

@bgdlabs is currently progressing an upgrade the SM architecture to support the launch of GHO. The details can be found here.

Links to the the Llama publications are shown below:

  1. [TEMP CHECK] Safety Module Update Part I - Migrate AAVE/wETH Balancer v1 Pool to Balancer v2
  2. [TEMP CHECK] Safety Module Upgrade Part II - Asset Diversity, SM Categories & Slashing Updates
  3. [TEMP CHECK] Safety Module Upgrade Part III - Enable gauges on BPT in Safety Module (smBPT)
  4. [TEMP CHECK] Safety Module Upgrade Part IV - Incentives Management Upgrade
  5. [TEMP CHECK] Safety Module Upgrade Part V - veToken Holding Management Framework
  6. [TEMP CHECK] Safety Module Upgrade Part VI - Future considerations

Disclaimer

The Llama is not compensated by any of the mentioned communities outside of Aave.

Llama is an unpaid delegate within the Balancer ecosystem.

Members who contributed to this proposal are not angel investors or advisors to any of the mentioned communities but some do hold small holdings in those communities tokens.

Copyright

Copyright and related rights waived via CC0.

5 Likes
2

6-parts! big one, thank you for taking the time and organizing the discussion for the Safety Module Update.

For this conversation, we believe the main goals should be:

  1. efficacy of the SM to protect Aave depositors

  2. sustainable cost for AAVE holders

using metagovernance and Aave’s partnership with Balancer could be an optimal avenue to reduce the cost of funding the SM for AAVE holders.

Agree here on the concern around the SM over-exposed to the AAVE token. We doubt the efficacy of AAVE as a solution for the SM, given the dependency of AAVE value on revenues from protocol usage, any loss would likely have a negative effect. A sample can be taken from the EUL >50% fall following their hack, with obvious understanding that EUL was much less liquid than AAVE and it was a pretty extreme attack in terms of size relative to total.

Further, the only signal we have received from risk teams/research is that the ability to liquidate BPTs is not good. As we discussed in our initial response to the SM update, before allocating the resources to update the SM to accept Balancer v2 BPTs we should assess the efficacy of these assets for their desired purpose - to be there when Aave depositors need them.

We recognize one of the original purposes for the SM, according to the SM technical update from @BGDlabs, was to increase utility for the AAVE token. We doubt the impact of this added efficacy to adding value to the AAVE token, compared to its primary utility of managing protocol parameters and allocating DAO resources. However, a staking module can be discussed (separate from the Safety Module) for AAVE holders to both participate in governance and potentially earn a revenue share, if there are utility concerns. The main takeaway being separating AAVE utility and Safety Module design, as the combined solution is suboptimal for both utility and depositor safety.

As part of that, we think the focus for SM assets should be on liquidity and correlation to Aave success. Ideally, BPTs with liquid assets (stables/ETH/wETH) will be very effective for the need. But until we have confidence in the availability of that liquidity, we do not think the DAO should allocate the resources (in AAVE cost or Service Provider time/cost). Lastly, we would push back on the systemic risk of ABPTs (Aave boosted pools) concern if AAVE is an acceptable asset for the SM. Based on the framework of liquidity and correl to Aave success, if ABPTs are not suitable for the SM then neither should AAVE.

At worst, we would suggest options 3 or 4, which have a lower AAVE allocation.

2 Likes
3

4 seems to be the most appealing to me as a user. This said the SM would be exposed to LIDO. If LIDO has a problem, we would. It’s preferable at least to wait for the unstacking feature of LIDO is actually available before doing this.

As well, it would be a good option to accept other liquid ETH so we mitigate the risk.

4

Thank you for this update!

Very thorough and we believe that the best option would be Option 3 as it reduces counterparty risk with LSTs even after a very successful Shangai Upgrade. The liquidity to unlock such amounts of staked ETH could cause slight de-pegs in extreme stress scenarios.

Totally in agreement here with @John_TV_Locke.

1 Like
5

For some extra context from the technical side, one of our tasks pending execution is the aforementioned migration of 80/20 AAVE/WETH aBPT from Balancer v1 to Balancer v2 (last update here)

Given the permissions involved to execute this in practice (Level 2 governance), pre-requirements (update of Level 2 requirements, Safety Module 1.5) and availability of security resources of the community, this will be finished only now, after the Safety Module 1.5 upgrade.

Regarding the options proposed and how they would fit into the project:

  • It is possible (we have it almost ready) and important to migrate the current users from v1 to v2, via a governance proposal, but this applies only with 80/20 weight distribution. We don’t recommend changing the weight of the current ABPT to 50/50, as it will create important friction for users, together with important operational overhead.
  • Following on the previous point, the reason for an 80/20 distribution was that participants in the Aave Safety Module are in practice AAVE holders, who want to keep more AAVE exposure in all senses. A change for a 50/50 could encourage existing participants to acquire WETH/wstETH from their AAVE, which is a clearly bad dynamic.
  • It needs more technical evaluation, but we are fairly confident that we can include in our planned upgrade/migration Balancer v1->v2 the “swap” from AAVE/WETH to AAVE/wstETH. Of course, if maintaining the 80/20.
4 Likes
6

gmgm, jbeezy here, a contributor at Lido. I am biased, of course.

The reasoning by @bgdlabs makes a lot of sense IMO and it would probably be ‘easier’ to migrate, keeping the 80/20 current split and then opening additional conversations on a future rebalancing at that time.

I voice support for AAVE/wstETH due to the capital efficiency and further alignment between the protocols. @coinsu brings up a potentially valid case of waiting until withdrawals, depending on the risk tolerance of the DAO. That said, that will no longer be an issue in a few more weeks.

In terms of diversity of risk, I pose the question. Is it trivial to upgrade the SM each time with a new asset or a linear amount of work? If minimal adjustments are the optimal outcome, I argue that no other liquid protocol can match the depth of liquidity across ETH and its L2s where AAVE is deployed/deploying.

1 Like
7

Looking forward to seeing the safety module migrate to Balancer v2! Been a long time coming.

For my two cents on weth vs wstETH, I think the future is wstETH. Over many years that free extra yield adds up. Lido and Aave are already very close partners and including wstETH in the safety module feels like a reasonable next step to take in this relationship. Balancer v2 has very deep wstETH<>weth liquidity so adding that additional hop for some traders (weth → wstETH → AAVE) will not materially increase gas costs or price impact.

We’re moving towards a world where most people will likely be trading wstETH → AAVE rather than starting with weth anyway so Aave is simply getting a head start if you decide to go this route :slight_smile:

3 Likes
8

KyberSwap and other aggregators already use wstEth and stEth as hop tokens so an AAVE/WETH → AAVE/wstETH migration should also result in higher total APR for pool holders, without sacrificing volume.

9

This actually quite an important aspect that deserves some clarification.
In technical terms, the Safety Module doesn’t exist by itself as a smart contract, it is just the architecture of staking, slashing, and incentives applied to independent “types”: stkAAVE and stkABPT at the current moment.
What this means is:

  • An “upgrade” of the Safety Module means updating separately the different components, for example, the emission rate of incentives, slashing parameters, or the codebase itself (as in our v1.5 proposal).
  • Adding a new component to the Safety Module is quite frictionless. Let’s assume that apart from stkAAVE and stkABPT, the community would like to add an additional stkABPT2 (e.g. composed of AAVE/DAI). In practice, this will mean deploying the same contract of the existing stkABPT and configuring it with the right underlying asset (the BPT) and params.
    The complexity is more on the security side, for example evaluating the underlying asset introduced in the new “stk type”.
  • Doing a “hot upgrade” of an existing “stk type” has more complexity, such as having the current stkABPT and replacing the underlying AAVE/ETH BPT with an AAVE/DAI. It is possible, as that is what we are working on the migration of stkABPT from Balancer v1 to v2, but not really doable if the underlying of the underlying (AAVE and ETH) diverge too much from the targeted ones: a migration of AAVE/ETH BPT to an AAVE/DAI is as complex as to consider it simply not doable.
4 Likes
10

Hi everyone,

Based upon the feedback from @bgdlabs, the following options are to be presented for voting on:

  1. YAE - 80/20 AAVE/wETH
  2. YAE - 80/20 AAVE/wstETH
  3. NAE - Rework Proposal
  4. ABSTAIN

@Llamaxyz’s recommendation is Option 2. Balancer is very much so becoming the home of LSTs DEX liquidity pools and Lido’s wstETH product is the proven market leader with over 31% of all staked ETH supply. We also like the additional capital efficiency of having IBTs within the liquidity pool.

The Snapshot vote can be found here.

1 Like
11

Hi Everyone :wave:

With the Snapshot vote coming to an end, we will now be focussing on Part 2 and 3 of the Safety Module upgrade.

Aave DAO has elected to proceed with an 80/20 pool comprised of AAVE and wstETH respectively.

Screenshot 2023-05-22 at 17.39.07

3 Likes
12

Hi everyone
What happened with this idea/proposal? @MarcZeller before Llama ends as a SP, do you think they can push for this implementation?

@Llamaxyz any comments?

13

We would highly appreciate it if someone could chime-in here and explain the status of this proposal.

@TokenLogic @Llamaxyz

1 Like
14

Gm @ApuMallku, sorry for the late reply !

The SM update is a complex & important topic which didn’t receive much feedback so wanted to make sure everyone had the time to read, understand or ask questions if needed

In addition, there are two reasons about why SM Update ARFCs are not live yet:

  • SM strategy rework needed - Part 4: Consequence of AIP-42 (More details below)
  • GHO depeg issue making stableswap liquidity counter effective right now.

Note that the proposal is still being worked to adapt to the current market metrics. From Llama’s side, the code supporting veBAL position is already implemented via the StrategicAssetManager contract and can be deployed pending community feedback.

There is a discussion currently on vlAURA support; if it makes sense technically and the community approves the vote, Llama can add vlAURA to the StrategicAssetManager.

SM Proposal Updates:

This proposal is split between 6 sub-parts with a breakdown & updates explained below:

  • Part I: Migrate AAVE/WETH v1 to AAVE/wstETH v2:

This migration could be implemented anytime, no blocker on this proposal if shipped alone.

  • Part II: Assets diversity, SM Categories & Slashing updates:

The categories & slashing parameters proposed should remain unchanged in the ARFC, however the assets list proposed will be updated to focus on stable LPs & adapt to the liquidity strategies voted.

  • Part III: Enable smBPT gauges

The concept of smBPT gauges has been approved by both Aave & Balancer DAOs. In practice, this will require a wrapper contract in the SM, minting smBPTs for BPTs, and specific proposal on Balancer for each gauge but this part is dependent on the next parts.

  • Part IV: Incentives Management Upgrade:

This part is currently being reworked to adapt to recent ecosystem changes caused by AIP-42 early August on Aura governance which impacted the SM estimations. I posted a TEMP CHECK explaining AIP-42 potential impacts & open the discussion about the next steps in this proposal to update Balancer Ecosystem holdings which is being voted on.

Basically after AIP-42, the emission power changed depending on if holdings are veBAL or vlAURA, however some projects didn’t understood the impacts, leading them to overpay for bribes. It also impacts veBAL holders (less attractive than vlAURA), which explain the proposal above to update the strategy before locking.

If approved, @TokenLogic will propose options to handle the B-80BAL-20WETH unlocked in the treasury, look for options to acquire AURA OTC (TokenLogic & ACI already closed a time sensitive deal), and @Llamaxyz will submit an ARFC to add vlAURA support to the StrategicAssetManager.

The other part complex to predict is the proportion of vlAURA votes / total votes bribed. Until AIP-42, the emissions were equivalent, but now, whether the split is 20% veBAL 80% vlAURA or the opposite really changes the results.

The bribe market irrationality & the new split below complexifies accurate estimations, especially for a project of Aave size, but solutions are being explored so part 4 will be updated in the ARFC for sure.

  • Part 5: veTokens Management framework

This post proposes to elect a committee & define a framework to manage operations related to strategic assets. Considering that this part was highly needed, and most likely before SM implementation, Llama built the StrategicAssetManager contract v1 including veBAL support, and will update to v2 with vlAURA support if approved.

TokenLogic recently submitted a proposal to create & fund a liquidity committee for a different purpose initially, but it can be assumed that the committee scope will increase over time, and could include the SM.

So part 5 is kinda already in work, SAM contract & committee scopes will only require updates once needed.

  • Part 6: Future considerations

This is the only part not voted yet on TEMP CHECK as it’s better to have everything else above live for considerations to:

  • Include protocol owned liquidity in the SM which partially self insure
  • Define a framework for new assets (which could increase the max budget)
  • Allocate a portion of GHO earnings to replace AAVE emissions

GHO situation

The GHO depeg is another consideration for the SM upgrade implementation atm, which wasn’t assumed when the proposal was created as GHO wasn’t live yet.

One of the goals of the SM proposals is to incentivize GHO liquidity & protocol cover with the SM current budget, which means a lot of incentives so a lot of stableswap liquidity, which is the counter effective to get GHO back at peg as it will just cost more to do it.

That’s why I mostly focused over the past weeks on the GHO Liquidity Strategy Update & Liquidity Committee that we recently published with TokenLogic.

The recent issue with boosted pools also impacted the liquidity, which is bad for GHO long term but helpful short term, as it will enable it to restore the peg with less buying pressure, which can initially be started with the DAO expenses (for example, TokenLogic SP proposal requested 100% of the funding in GHO and others might follow).

Buying pressure coordinated with liquidity strategy should help improve the peg situation and enable to rebalance the pools on Balancer with arbitrages, to then follow up with the SM ARFCs and implementation if approved.

Hope this update is helpful. Lmk if you have any additional questions !

1 Like