The Aave protocol has some specific risk management characteristics. Compared to other competing technologies, it features:
- Custom liquidation penalty per asset
- Custom Loan To Value (aka borrowing power) per asset
- Custom Liquidation threshold (aka Maintenance Margin) per asset
These risk parameters greatly help in mitigating liquidity risk. A higher liquidation penalty for less liquid assets means higher chance for liquidations to be profitable, which greatly increases protocol safety. A lower LTV than the maintenance margin ensures that no borrowers can be liquidated right off the bat, and provides a soft protection against market volatility (soft because there isn’t any constraint for borrowers to withdraw some of the assets and have a riskier position if they wish to do so).
One thing that the Aave protocol is missing is an adequate strategy for debt ceiling.The Debt ceiling concept was initially introduced by Maker and is a powerful way of handling protocol exposure to a certain asset.
The debt ceiling specifically helps protecting against the following:
Economic attacks: Pump and dumps, even potentially in one transaction using flashloan/flashminting, might temporarily increase the price of an asset even by orders of magnitude, allowing attackers to borrow more than they are allowed to. The immediate drop of the price after the attack is completed leaves the protocol insolvent.
Supply attacks (aka infinite minting): Some permissioned/upgradeable tokens might be attacked in a way where a malicious actor might be able to mint an infinite amount of tokens. Bugs might cause that too (see the recent $COVER infinite minting attack).
Concentration risk: The protocol might become overexposed to a certain asset that might fail for reasons not strictly related to attacks.
In Maker each asset can mint up to a certain amount of DAI. Once the ceiling is reached borrowers will need to wait until the governance increases it. This introduces some UX friction:
Users that deposited the asset and didn’t immediately borrow might not be able to do so at a later time depending on the state of the debt ceiling
Users can’t borrow more once the ceiling is reached
Users can always, anyway, introduce more of the asset in the system as a way to protect from liquidations. These frictions are relatively minimal compared to the safety that the debt ceiling provides to the whole system.
Achieving the same result in liquidity markets like Aave is extremely complex, and impossible to do completely onchain. Since all the deposits of a user are aggregated to calculate the total borrowing power and a user can borrow both stable and volatile assets, there is no way of having onchain at any point in time the exact amount each user has borrowed with a specific asset. Even calculating that offchain can be rather complex due to the nature of the cryptomarket and the way the protocol works (at the very least there would be multiple ways of doing that, each with certain drawbacks).
Some projects already attempted/are in the process of implementing an equivalent or similar approach to the debt ceiling:
BentoBox is moving away from the liquidity market/aggregated borrowing power idea to introduce lending pairs. Although this would technically allow for an exact debt ceiling like Maker does, the individual lending pair approach comes with a whole host of different UX problems (eg liquidity segregation, need for multiple transactions to deposit/borrow the same asset, need two pairs for the same asset for the ability to long/short, and so on) that makes the solution not particularly attractive.
Cream.Finance introduced a supply cap to their forked implementation of the compound protocol, by adding a check on the mintAllowed() function once a certain amount of tokens have been deposited. This solution also comes with some drawbacks: Legit holders of a certain asset won’t be allowed to add more of it to protect against liquidation (something that Maker always allows) and they would be forced to deposit a different asset to increase their maintenance margin. This is a big problem especially for certain entities/institutions for which keeping exposure to a specific asset (eg WBTC) is mandatory. Also due to the nature of how cTokens work, the supply cap does not completely cover infinite minting risk (an attacker might still airdrop minted underlying to the cToken contract artificially inflating the cToken:underlying exchange rate). Moreover, this doesn’t work well with stablecoins (you never want a supply cap with stablecoins as their most relevant utility is not to be used as collateral but to be borrowed).
Although the Aave protocol, compared to the Compound protocol, is technically capable of a true supply cap (since the accrual of the interest in the aTokens is separated from the actual amount of underlying available in the token) i personally believe it’s not the best solution, as i think the possibility of adding more collateral to prevent liquidation is something that should always be allowed.
What I am proposing is a different way of approaching the problem that i call “Exposure Ceiling”. The exposure ceiling uses the LTV (borrowing power) risk parameter to drop the borrowing power of a certain asset when it’s time to reduce exposure.
The implementation would introduce a depositCeiling configuration parameter. Given a token X, The deposit cap would specify a certain amount of the total supply of X deposited after which the LTV of X would automatically drop to 0. By doing so, a user would still be allowed to:
Borrow using X as collateral when the total aToken supply is below the deposit ceiling (being 1:1, the aToken supply closely tracks the amount of underlying in the system)
Always refill the system when needed to prevent liquidation using X, since X maintains its liquidation threshold
Not allowed to borrow more when the aX total supply is past the deposit ceiling.
This solution would cover most of the needs, although it is bypassable: Supposing X is past the deposit ceiling and is being attacked with infinite minting, an attacker might use a legit currency Y (where Y has still borrowing power), borrow from the system, deposit X and then withdraw Y - the attacker factually used Y to initiate the loan, then replaced Y with X to keep the maintenance margin.
This requires that one limitation is introduced. Specifically, users who deposit multiple assets will be required to first withdraw assets that are past the deposit ceiling, if they are borrowing. If they aren’t borrowing, there won’t be limitations. See how this prevents the scenario above:
User deposits Y, borrows Z
User deposits X, his maintenance margin increases but not his borrowing power.
User tries to withdraw Y, he’s not allowed to. The system will require that he withdraws X first.
Debt is still covered by Y
This potentially leaves open a window for abuses if users that are close to liquidation increase their maintenance margin using an infinite minted asset. I believe this is a remote possibility:
Assets that get infinite minted quickly drop to 0. Therefore the most important protection that is needed is immediately after the infinite minting takes place. After that is passed, the governance and the emergency admins have the capability to act accordingly (for example by freezing the reserve so that X can’t be deposited anymore).
It does not increase, anyway, the total debt of the system.
So what do we get compared to the most precise implementation of debt ceiling:
Protection against infinite minting attacks
Limited protection against economic attacks (although the concept can be extended to also consider the exposure in USD, see final paragraph).
Limited protection against concentration risk: Since there isn’t a direct correlation between the total supply and the price of an asset, even by reducing the exposure cap, the protocol might still become overexposed if the asset’s price increases significantly (in this case too, the exposure in USD can improve this).
In terms of additional UX friction:
- Users that deposited when the deposit cap was not hit will not be allowed to borrow if the deposit cap is passed
- Users will not be allowed to borrow with an asset that is past the deposit cap
- Users that are borrowing using multiple assets and want to withdraw (lowering their maintenance margin) will be required to withdraw first the assets that are past the deposit cap.
- Users are always allowed to refill their position with the asset
- Users are always allowed to deposit for lending
1 and 2 are in common with the most exact debt ceiling implementation. The 3 I believe is due to the nature of the system and I don’t feel like it is a dealbreaker, when we factor in the additional safety this feature provides to the whole system.
4, in my opinion the most important one, is preserved. 5 is a great side effect, that is especially important with permissioned stablecoins.
Potential extensions of the idea:
Implement also an exposure cap in USD: when the supply*price is past a certain threshold, the LTV drops to 0
Hard supply cap: We can have a soft exposure cap and a hard one: users that deposit when the soft cap is reached are still allowed to deposit for lending and/or increase the maintenance margin; once the hard cap is hit, no more deposits are allowed.
This (long) thread is meant not to be a guideline for implementation. The goal is to bootstrap a discussion on this much needed feature and a brainstorming session with the community and especially the users.