Comment on page
Lenders are the most important participants in the K-Lend protocol and all of the engineering behind the risk engine is aimed at protecting their funds. Bankruptcies (bad debt) situations should be avoided at all costs. Therefore, once identified, risky borrowers and risky assets should be evicted from the system to ensure lenders get their tokens back. Auto-deleveraging is a novel mechanism introduced by the KLend contributors that can facilitate a protocol-wide deleverage of any asset if the current supply and/or borrow amount is deemed as too risky according to the risk framework (KRAF).
For example, if there is an outsized borrow position on an asset whose market liquidity vanished abruptly, the protocol would suffer a loss when liquidating this asset (this loss would be socialized between the lenders). Instead, auto-deleverage is designed to prevent the protocol from falling into this scenario, facilitating an orderly unwinding of the asset, after which the protocol continues normal operations.
Auto-deleveraging can be triggered by the Risk Council, but can also be automated in the future by taking into account various signals within the protocol. Should a situation similar to that of the Aave CRV, or Solend Whale case happen, the Risk Council can trigger the deleveraging module to perform the unwinding of the toxic collateral.
Deleveraging can be applied to toxic collateral (unwinding longs) but also to toxic debt (unwinding shorts) or both.
If the multi-sig vote passes, all affected users will be notified of the deleverage event, and will be given a 72-hour margin call period to take action. If enough borrowers took action and unwound their positions bringing the current levels below the new caps, then the process ends here.
A new, reduced cap is set for the amount of
Asset_Athat is supplied/borrowed. The difference between the current amount and the new cap is the amount that will be auto-deleveraged.
Users subject to deleveraging will see a proportional reduction in the target asset, along with the corresponding tokens in their position. Deleveraging will generally result in a more healthy LTV ratio.
Lenders are never affected by auto-deleveraging, only borrowers.
Deleveraging works slightly different depending on whether the caps are adjusted on the Supply or Borrow side:
Collateral deleveraging happens when there is too much of
Token_Abacking loans as collateral than can be successfully liquidated. This means that liquidating loans with
Token_Aas collateral would result in losses. For example, the deposit caps of
Token_Aare lowered from $100M to $80M (thus 20% of
Token_Acollateral must leave the system). All users with
Token_Asupplied as collateral will be notified of the deleverage event. If a user were to be deleveraged, some or all of their
Token_Asupplied would be sold on the market, repaying the debt proportionately.
Note that supply deleverage for a certain asset will often coincide with a borrow deleverage on that same asset, depending on its current utilization, and maximum utilization. Most likely the triggers for deleveraging are the abrupt loss of market liquidity for that asset, making both supplies and borrows hard to cover.
Debt deleveraging is the reverse. If there is too much
Token_Bdebt in the system and prices were to rise, liquidators would not be able to liquidate without a loss to the protocol. When liquidating a debt asset,
Token_Bwould have to be bought off the market and repaid into the protocol. However, if such a market buy would incur a slippage higher than the actual debt amount, it's an indicator that a deleverage is needed. For example, if borrow caps for
Token_Bare lowered from $100M to $80M (thus 20% of
Token_Bdebt must leave the system), all users with
Token_Bborrowed will be notified of the deleverage event.
When a user is deleveraged, the liquidator sells a portion of their collateral and covers the debt in
Token_A. This continues until 20% of the total
Token_Adebt in the protocol is closed. Users affected by deleverating will have their debt repaid by their collateral, but also suffer a deleverage penalty.
The penalty is designed to incentivize the borrowers to take early action, hopefully during the margin call period when no penalty is applied.
Deleveraged loans incur a minimum liquidation penalty of
50bps. The penalty is calculated as a % of the deleverage amount. Thus, if the penalty =
0.5%and the deleverage amount =
20%, the user will be subject to a:
0.2 * 0.005 = 0.001 = 0.1%penalty. Thus, instead of losing eg. 20% of their collateral, they lose 20.1%.
The liquidation penalty continually increases until either:
- Maximum penalty threshold is reached
- Target asset deleverage cap is achieved
The rate of increase of the liquidation penalty is a function of the user's LTV and the time elapsed since deleveraging was initiated. The liquidation penalty is expressed as follows:
liquidation_penalty = minimum_liquidation_penalty + (current_ltv * days_since_deleverage_initiated)
minimum_liquidation_penalty = 50bps (0.5%)
current_ltv = 80%
days_since_deleverage_initiated: 3.4 days
liquidation_penalty % = 0.005 + (0.80 * 3.4) = 2.725%
The maximum penalty that a deleverage can incur is capped at the lowest liquidation penalty of the assets in a user's position.
eg. If a position contains SOL, USDC and WETH, and liquidation penalties are 6%, 8% and 10% respectively for those assets, the deleverage penalty for the position will be capped at 6%.
Once auto-deleveraging begins, a position will be eligible for deleverage if:
- It contains the target asset
- It has a
current_LTVthat exceeds the
liquidation_LTVof the target asset
Once deleveraging begins, the
liquidation_LTVof the target asset is adopted as the
deleverage_liquidation_LTVwill then decrease over time, as outlined below.
If no positions exceed the
liquidation_LTV, deleveraging will begin starting from the loans with the highest LTV, and continue down until the target reserve cap is reached. As time goes by, the
deleverage_liquidation_LTVautomatically decreases, thus encouraging users to reduce their LTVs to a level reasonably lower than the
deleverage_liquidation_LTVdecreases by the configured rate as slots per bps - e.g.
1 bps per hourwould be
7200 slots per bps(assuming 2 slots per second)
The calculation for the decrease rates is as follows:
deleverage_liquidation_LTV = liquidation_ltv (e.g. 0.8) - (0.01 * (slots_since_auto_deleverage_initiated / slots_per_bps)
deleverage_liquidation_LTV = 0.8 - (0.0001 [i.e. 1bps] * (345600 / 7200) = 79.52%