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

[John_TV_Locke]

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

@Llamaxyz

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.

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

@Llamaxyz

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.

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.

@Llamaxyz

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.

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.