AAVE V3 Borrow Caps Methodology

Risk
1

Summary

Supply and borrow caps are new risk parameters introduced in AAVE V3. For many of the assets already listed, neither cap has been set. For those that have been implemented, there wasn’t always a consistent methodology. Moreover, with the recent changes in market sentiment and volatility, there is a need to set forward a new, transparent methodology and process.

In the short term, we expect to iterate more frequently on setting supply and borrow caps while setting optimal thresholds. It will allow us to better identify and analyze market behavior following such changes, as we have already witnessed increased deposits in response to setting the supply cap on LINK.

Borrow Cap References (from Aave docs and forum posts)

  • Borrow caps can be used to prevent traditional and flash borrowing of an asset that may experience a price exploit and lead to protocol insolvency (link)

  • Tokens that are mainly used as collateral and have no obvious borrowing use cases usually should start off with a conservative borrow cap slightly above optimal utilization. With this, the asset can still be borrowed while limiting the exposure of the protocol (link)

Methodology

To determine initial borrow caps, we’re looking at several factors:

  1. The optimal utilization rate (UOptimal)
  2. The current supply of the asset (CurrentSupply)
  3. The supply cap of the asset (SupplyCap)

Note: UOptimal is a static 0.45 based on the interest rate curves currently approved. There are already several reviews underway to modify and enhance these curves, which will require further research and likely amended Borrow Cap proposals.

The rationale behind setting the caps

We want to accommodate all cases, including when the maximum amount is supplied (the supply cap). The ideal utilization in the case of maximum supply will be achieved at the optimal utilization ratio meaning SupplyCap * UOptimal. For instance, if the supply cap is set at 1,000 for token AAA and UOptimal is 0.45, a borrowing cap of 450 AAA tokens will suffice. This is because even if 1,000 AAA tokens are supplied, we can reach the optimal utilization point. Of course, most of the time, the supply will be lower. In this case, Slope 2 of the interest rate curve is supposed to help limit borrowing at CurrentSupply * UOptimal. However, as it takes time to adjust supply caps when nearing the cap, we also allow another 10% of the supply to be borrowed in case of high demand until the supply cap is raised.

A temporary exception to this rule is when the amount of tokens already supplied to the protocol is already high. In this case, we understand that supply pressure pushes to increase the supply cap, so we allow for a somewhat higher borrow cap for the asset to accumulate demand ahead of the supply. This cap is at 70% of the current supply. Using the example above, where the cap on token AAA is 1,000, and there is already a supply of 900 AAA tokens, we’ll set the cap to 0.7 * 900 = 630 AAA tokens. This is because we understand that under the current supply pressure nearing the cap, we’re likely to review an increase in the supply cap (depending on risk concerns), and following also the borrowing cap.

Level 1 Borrow Cap = SupplyCap * (UOptimal+0.1)

This theoretical limit still allows optimal asset utilization at the point of maximum supply. The additional buffer of 10% of the supply leaves room for more borrowing in case of high demand until the supply cap is raised.

Level 2 Borrow Cap = 0.7 * CurrentSupply

In cases where the current supply is nearing the existing supply cap, we want to allow for a higher borrow cap, as it is a signal of high supply that may likely result in increasing the supply cap. Higher borrow caps will leave space to identify increased demand to support such a decision. The borrowing cap is complementary to the interest rate curve, and the latter is the main mechanism to ensure sufficient liquidity on the supply side to allow aToken redemption both for suppliers to withdraw liquidity and to ensure efficient liquidations. At the same time, we seek to ensure sufficient liquidity for suppliers in case of surging demand from borrowers, so the lower bound is set at 0.7.

The recommended borrow cap should be the larger value between Level 1 and Level 2.

This is an initial iteration of the borrow cap methodology. We’d love any community feedback or ideas on how to improve the methodology.

10 Likes
2

Thank you, @ChaosLabs for sharing this methodology. Borrow caps on V3 market assets are a key risk management tool and I am looking forward to their widespread use.

This methodology seems reasonable as a first step. I imagine in the future we will also be able to incorporate the liquidity of the asset and its trading pairs when determining borrow (and supply) caps as the V3 markets grow in both maturity and value.

1 Like
3

Thank you @ChaosLabs for the proposal! This is Guangye from Blockchain at Michigan. We like the overall intuition of the borrow cap methodology. We are wondering how the parameters 0.7 and 0.1 were determined? Were they based on simulations?

4

Thanks @GCao for the question. The parameters were not determined by simulations but chosen as initial buffers for the following purposes:

  1. The 0.1 parameter is utilized in the Level 1 cap, where the current supply is relatively low, as a buffer to allow for room for additional borrowing beyond the UOptimal point, in case of high demand and until the supply cap is raised.
  2. The 0.7 parameter is utilized in the Level 2 cap, where the current supply (at the time of amending the cap) is close to the supply cap. The buffer is in place to ensure sufficient liquidity for suppliers to withdraw their positions in case of surging demand from borrowers.

We intend to continuously iterate and refine the methodology based on market research, protocol usage, and community feedback.

1 Like
5

Thanks for sharing! I believe the community needs to agree on a framework or methodology to set supply and borrow caps asap, so I would love to get input from other contributors!

Two questions that came to my mind:

  1. Is a good idea to adjust the borrow cap primarily based on the UOptimal value? It’s the IR’s purpose to drive liquidity of the pool, not the borrow cap imo.
  2. Borrow cap should be based primarily on market liquidity, contracts risks, asset maturity, bridges risk, etc.
1 Like
6

Great to see this published for the community to see! Should we expect follow up proposals to adjust current markets?

1 Like
7

Absolutely. Our first proposals for supply and borrow caps were mainly for uncapped assets. We are constantly monitoring the markets and the utilization on Aave and will propose amendments to the caps accordingly.

1 Like
8

Great topic! Thanks for bringing this up.
Currently the inconsistent use of borrow cap prevents us from easily integrating AAVE to our solution (https://www.mangrove.exchange/).

Our use case is the following: Mangrove is an order book in which liquidity providers can have offers that pull their funds from an arbitrary source, for instance AAVE, whenever matched by a market order. The absence of borrow cap makes it possible for an attacker to make an AAVE based offer fail by drying up the pool using a flashloan (external to aave) + supply + borrow of the whole asset supply. So a borrow cap preventing AAVE insolvency within the block would prevent this.

The suggested simple formula above would do the trick in the most realistic cases I believe.