Gauntlet Aave V3 Isolation Mode Methodology

Simple Summary

On Aave V3, isolation mode requires multiple considerations, including mitigating tail risks to protocols, optimizing user experience, and allowing on-chain liquidity to remain robust. Here we describe the main factors we consider in calculating isolation mode recommendations.

We may deviate from these methodologies in certain edge cases and in the event of very idiosyncratic or compelling developments.

Methodology

We aim to isolate assets that are susceptible to infinite mint attacks, possess non-standard token functionality, or may otherwise have inherent and unpredictable risks. The debt ceiling is designed to restrict protocol exposure to price swings and potential resulting insolvencies.

To mitigate insolvencies, we prioritize having adequate on-chain liquidity to ensure an effective liquidation process. Thus, we recommend setting the initial debt ceiling for an asset at a maximum of 15% of its existing circulating market cap for a conservative approach and 25% for an aggressive approach. Furthermore, to avoid overexposure to isolated assets, we cap the debt ceiling at 20% of the available liquidity of assets that can be borrowed in isolation mode on the protocol.

If the community believes that the primary purpose of debt ceilings is to protect against unpredictable asset behavior and market risk, a natural progression would be to remove an asset from isolation mode when it has demonstrated “safety” rather than increase the debt ceiling over time. On the other hand, if an asset is demonstrated as being risky, we should aim to delist it from the protocol rather than reduce the debt ceiling. However, since the debt ceiling is denominated in USD, we may consider revisiting the debt ceiling if:

  • Available liquidity on protocol drops and the existing debt ceilings represent a substantial percentage of the remaining liquidity

Moreover, we may consider removing an asset from isolation mode if:

  • Users express a preference to borrow from a more diverse set of assets
  • The increase in revenue generated for the protocol would be significant
  • The asset has demonstrated some level of safety (e.g., gone through security audits, is not experiencing market fear and doubt, etc.)

It is important to note that this methodology aims to help safeguard against unpredictable attacks but does not protect against a specific type of attack.

Application of Methodology to Aave V3 Avalanche, Polygon, and Arbitrum

We recommend the following changes to the isolated debt ceiling across the Aave v3 deployments:

Chain Asset Current Borrowed Against Asset Current Debt Ceiling Conservative Recommendation Aggressive Recommendation
Avalanche FRAX $0 $2M $600K $1M
Polygon EURS $1.43M $5M $405K $675K
Arbitrum USDT $773.21K $5M $2.5M $2.5M
Arbitrum EURS $0 $5M $15K $25K

Notice that these recs would cease borrowing against EURS on Polygon but would not affect current user positions. 85% ($2.31M) of EURS on Polygon is currently supplied on Aave v3 Polygon, with one whale account 0x8da35b920fe236a757a0fad93d3a3ab8ea0a24cc supplying 62% ($1.7M). While this user is currently at a relatively safe health factor on Aave v3 Polygon, there would not be enough liquidity on Polygon to liquidate the user in a worst-case scenario.

Next Steps:

  • Welcome feedback from the community.
1 Like

Some questions from our side:

  • What do you mean by ‘non-standard functionality’? Might be helpful to explain what these terms, including infinite mint attacks, mean.
  • What do you think we should do about the whale user for EURS on Polygon?
  • Why are the conservative and aggressive recommendations for USDT on Arbitrum the same?
1 Like

As a heads up, given that these parameter changes aim to de-risk these isolated assets without impacting existing positions, we plan on publishing a Snapshot vote on 3/22/2023 with the Conservative and Aggressive options.

We have published the Snapshot vote below. Voting begins tomorrow:

https://snapshot.org/#/aave.eth/proposal/0xb1f8b1814d9c09760daa4d7e9fa90d906b2c9ff5fbd20c8d0f5793c4f5cc4999

Non-standard functionality refers to custom token behavior defined outside of the ERC-20 standard. One example of non-standard functionality is rebasing, which allows for updates to a token’s balances and circulating supply based on certain external factors, such as target price or yield accrued. Integrating such tokens often requires custom implementation and can introduce unexpected behavior, so we recommended starting from the isolation mode if the community strongly desires to enable these tokens as collateral.

An infinite mint attack occurs when a hacker exploits contracts and mints a large amount of tokens. The hacker can then deposit these erroneously minted tokens as collateral and drain the protocol by borrowing other assets. Therefore, we also recommend isolating assets that are susceptible to this type of attack.

Given that the EURS whale account is supplying $1.7M EURS and borrowing $700k USDC, which suggests a relatively low risk from this account. In the event of liquidations, it’s likely that liquidators would redeem the liquidated EURS for EUR through Stasis rather than swapping EURS for other assets through DEXs. As a first step, we still recommend reducing the debt ceiling to limit further borrowing against EURS. We will continue to monitor the market and propose additional actions when needed.

For USDT on Arbitrum, the available liquidity of assets that can be borrowed is the limiting factor for both conservative and aggressive recommendations, rather than the circulating market cap. Therefore, the conservative and aggressive recommendations are the same.

1 Like

The Snapshot vote has shown a preference towards the Aggressive option. Gauntlet will prepare an AIP for these debt ceiling changes targeting next week. We thank the community for its participation on structuring Aave’s isolation mode.

1 Like

As an update, we will publish AIP on Tuesday, 4/4/2023.

AIP has been published below. We thank the community for their feedback and participation.

The AIP has passed and been executed. We are preparing the Guardian Steward for the Avalanche V3 changes, and thank the community for their participation.

1 Like

The Avalanche V3 changes have been implemented. All the changes in this proposal have been implemented now, and we thank the community for their participation to mitigate risk in Isolation Mode.

1 Like