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)
To determine initial borrow caps, we’re looking at several factors:
- The optimal utilization rate (
- The current supply of the asset (
- The supply cap of the asset (
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.
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.