[ARC] Risk Parameter Recommendations for Aave V2 ETH (2022-11-22)

Looking at the extensive community discussion over the last few days in light of the CRV mango squeeze attack, we appreciate that there are two paths forward for the Aave community:

  • As proposed by Gauntlet in this proposal, freeze tail assets in Aave V2 and encourage migration to V3, where borrow and supply caps enable granular management of risk.
  • Continue supporting tail markets in V2 and change risk parameters on an asset-by-asset basis, i.e., do not be as conservative as in Option #1 above.

Having considered all the arguments in favour of and against this proposal, we have decided to vote YES in favour of this proposal for the following reasons:

  • Market conditions have evolved; liquidity has reduced across the board, causing these long-tail assets to have greater risk than they would have had even weeks ago. Therefore, in today’s market conditions, freezing tail assets that represent only 5% of Aave’s TVL and pose much higher risk is prudent.
  • Freezing assets does not meaningfully impact existing user positions and does not lead to liquidations of healthy positions as reducing the LT for major assets like USDC/DAI would do.
  • The risk profile of attackers has changed. Attacks are not only being done where the expected value is profitable; rather, as in the case of the CRV attack, traders are willing to risk substantial amounts of their own capital even if it is not profitable for them, which can cause insolvency on Aave. This fundamentally changes the security threshold for each asset.
  • The proposal is not one that has arbitrarily decided to freeze all V2 assets, as can be demonstrated by UNI and LINK not being initially included in the list of assets. It aims to protect Aave against numerous market risks, as highlighted by @Pauljlei - insolvency risk from liquidation cascades, price manipulation, traders borrowing stables against volatile assets to avoid slippage, and high utilisation impacting atomic liquidations. Over the past few weeks, we have seen examples of how all of these attacks can potentially be implemented on Aave, and therefore out of an abundance of caution, agree with the proposal to broadly de-risk V2.
  • Freezing the Aave V2 pools will provide additional incentive to migrate to the V3 contracts once those launch. V3 has additional features around supply caps, borrow caps, isolation mode, e-mode, etc. that can help defend against future attacks.

With regards to the proposals to change the LT of USDC and DAI, as outlined by Chaos Labs, we are in broad agreement to incrementally reduce the LT and attempt to protect healthy users from liquidations.

Lastly, with regards to the points made against this proposal, we agree that there must be more granular decision-making in V3, where supply and borrow caps and other features allow for more bespoke decisions. However, continuing to maintain long tail assets on V2 exposes Aave even more to bad debt and to reduce the probability of insolvencies, will require the LT of major assets like USDC, DAI, ETH, wBTC, and stETH to be reduced, which will lead to liquidations for many users across Aave.

5 Likes

Given that the community does not have a parallel proposal for granular risk mitigation and given the recent support for more conservative approach and that time is essence, I will vote YAE for proposals 121, 122, 123 and 124.

3 Likes

Hi Everyone :wave:

@Llamaxyz and Chaos are actively preparing a proposal in line with the conversation above. We hope to have the proposal up for voting shortly.

For those favouring Disable Borrowing over Freezing Reserves, this option will be coming to governance shortly. Thank you for your patience, we will be doing peer reviews (@bgdlabs & Chaos) and ensuring the payload is double checked prior to submitting to an on-chain vote.

Voting YAE or NAE on AIP-121, AIP-122 and AIP-123 will not affect this proposal. The earlier comment from bgdlabs clarifies this.

The AIP will propose the following amendments:

8 Likes

Is that borrowing BAT proposed Enabled a mistake? The current status is actually borrowing Disabled

Correct. Typo has been corrected. Nice work picking that up.

1 Like

Hi all,

We’ve recalibrated our model to additionally relax the attacker rationality factor. The final result and ARC can be found here.

3 Likes

After thinking a bit about both sides - disable borrowing vs freezing, it’s clear the latter isn’t optimal from a UX perspective. However, this proposal despite being conservative makes sense and is justified given the level of activity of these assets and the risk they pose to Aave.

We will be voting in favour of this proposal as 1) it’s a needed and important safety measure under current time constraints and 2) assuming a second alternative proposal does not pass, this proposal will serve as the base case.

Regarding 2), we will also be voting in favour of the proposal by @Llamaxyz & Chaos Labs which reverses the freezing of assets and instead disables borrowing.

Both alternatives are critical to mitigating short-term risks spurred by insufficient liquidity and vulnerable parameters. While we have no strong opinion on which is better as there are solid arguments for both, we do acknowledge that disabling collateral provides a more lenient yet risk-aware solution.

5 Likes

Hey all,

The AIP for disabling borrows on select assets is live here.

1 Like