Risk Parameter Updates for Aave v2 Ethereum Liquidity Pool (2022.11.25)

Risk General
1

Title: Risk Parameter Updates for Aave v2 Ethereum Liquidity Pool
Author: @Llamaxyz & Chaos Labs (@defijesus , @MatthewGraham , @omergoldberg )
Dated: 2022.11.25

Simple Summary

In response to recent market events and resulting discussion on the governance forum, Llama and Chaos Labs propose to make a series of parameter changes to the Ethereum Aave v2 Liquidity Pool.

Abstract

This proposal presents an alternative pathway forward to AIP-121. The community can elect to Disable Borrowing whilst retaining the ability to Deposits assets across the majority of Reserves rather than Freezing as outlined in AIP-121.

This proposal is a collaborative effort between Llama and Chaos Labs and reflects the communities governance forum discussion.

Motivation

In response to recent market events and the continued contraction of liquidity across markets, this proposal seeks to reduce the risk profile across many higher volatile assets. AIP-121 presents an opportunity to Freeze many Reserves, whereas this proposal intends to Disable Borrowing whilst retaining the ability to deposit assets.

AIP-121 is a more conservative response relative to this proposal. It is likely, LTV and LT thresholds for highly liqudity assets will also require amending in the near future. This will be managed via a separate submission.

Specification

The following risk parameter proposal are presented below:

Implementation

This proposal will reconfigure the following asset Reserves:

  • YFI
  • CRV
  • ZRX
  • MANA
  • 1INCH
  • BAT
  • sUSD
  • ENJ
  • GUSD
  • AMPL
  • RAI
  • USDP
  • LUSD
  • xSUSHI
  • DPI
  • renFIL
  • MKR
  • ENS
  • LINK
  • UNI
  • SNX

This proposal is written in an atomic manner that will unfreeze reserves in case AIP-121 gets executed before.

To achieve this, freezeReserve(address asset), unfreezeReserve(address asset) and disableBorrowingOnReserve(address asset) will be performed via the PoolConfigurator for each asset respectively to ensure a predictable final state.

POOL_CONFIGURATOR.freezeReserve(address asset)
POOL_CONFIGURATOR.unfreezeReserve(address asset)
POOL_CONFIGURATOR.disableBorrowingOnReserve(address asset)

Copyright

Copyright and related rights waived via CC0.

9 Likes
2

The AIP has been reviewed and published for voting: Aave - Open Source Liquidity Protocol

3 Likes
3

Hi Everyone :wave:

We have published this AIP for community members to vote on:

Thank you in advance for your participation in the vote.

1 Like
4

I write to suggest this is a short sighted proposal and AAVE should continue with AIP-121. Many of the comments in this forum seem to misunderstand the AAVE vulnerability displayed by the CRV attack. Many seem to think it has to do with stablecoin LT, or that it was a psyop to get an induced short squeeze, allowing the attacker to profit from longs on other venues. Both are incorrect - the core issue was the ability to corner a massive amount of token float, take on a short, and then due to limitations of price oracles (not reporting trade volume or liquidity; https://twitter.com/mayazi/status/1592623187552260096), drastically suppress token price to withdraw the collateral pledged, leaving AAVE with bad debt. Contrary to popular CT belief, the short squeeze led by Andrew Kang and propped up by the CRV team’s release of its stablecoin proposal actually thwarted the CRV attack. Given the OI of CRV at the time of the attack, it was not possible for the CRV attacker to have profited from the short squeeze/forced liquidation. The only path to profitability was through suppressing the price to withdraw collateral, but it was spotted too early and counteracted by the short squeeze against the attacker. These two threads explain the attack well: https://twitter.com/layerzerointern/status/1595226023884460034
https://twitter.com/0xmev/status/1595222132589350914. What this means is the roughly $1.5m in bad debt AAVE sustained was the absolute lowest bound of what was vulnerable. Had the attacker succeeded, AAVE likely would’ve been left with $20-40m of bad debt. The CRV attacker only failed because they did not have enough collateral to buy up the entire float prior to Andrew Kang’s short squeeze. I actually submitted the presence of this vulnerability through the AAVE bug bounty program well before the attack was attempted and my concerns were brushed off. Had the AAVE team implemented my suggestions, it would have avoided the $1.5m of bad debt it actually incurred, as well as the $20-40m actually vulnerable to exploitation. When I followed up with the team after the CRV attack, they continued to brush off my bug bounty report and seemed to misunderstand the attack as a short squeeze/due to CRV liquidity. I presented the exact attack done by the CRV attacker to the AAVE team well before it occurred, was not listened to, was not paid a bug bounty for it, and the security team continues to misunderstand the nature of the CRV attack and the vulnerability in AAVE.

3 Likes
6

So if this proposal passes, what happens to existing borrows of disabled assets?

ex. If I am borrowing 10k CRV and CRV borrowing is disabled:
-Does my 10k borrow still hold and I cannot borrow more?
-Can I repay the debt?
-What happens to the interest rate?

Would this scenario change if AIP-121 instead goes into affect and CRV is frozen?

1 Like
7

Hi @0xTJ,

With Borrowing disabled, users are not able to borrow any more CRV from the Reserve. Users can repay CRV debt at any time. However, once repaid, it then can not be borrowed. Essentially, only existing CRV debt can be repaid and no user can take out anymore CRV debt.

As the interest rate curve remains unchanged, the borrowing rate remains a function of CRV deposited into the Reserve and CRV borrowed from the Reserve. Based upon what percentage of the CRV deposited is borrowed, ie: utilisation, will determine the interest rate paid by borrowers. In short the interest rate still functions the same way, just over time debt goes down as the CRV is repaid. Just keep in mind if people redeem there aCRV holding, the utilisation on the Reserve could increase and rates go up, as utilisation goes up.

If AIP-125 passes, AIP-121 essentially becomes obsolete. Meaning AIP-125 will make the proposed changes to reflect AIP-125 parameters.

3 Likes
8

What the reasoning for freezing assets like GUSD? It is a stable that cannot be used as collateral. How can it be exploited? What is the risk for current suppliers of GUSD?

1 Like
9

Did you ever get a response from the team about this? They seem to be acting rather late on all this.

1 Like
10

No I didn’t. My bug bounty was refused and the team/community seem to misunderstand the underlying vulnerability.

1 Like
11

Why don’t you tweet about it. Or ask some very well know on tweeter to tweet about it.

1 Like
12

Well doing so would bring attention to this vulnerability and someone with more collateral could successfully pull it off once the temporary freezes on use of these illiquid coins as collateral/borrowing is disabled. I’d much prefer the team take the bug bounty steps under advisement and implement a fix before the vulnerability can be exploited.