Automated Deleverage

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.

Deleverage in Practice

Triggering Auto-Deleverage

Should market conditions result in the KRAF indicating a (borrow or deposit) cap change is prudent for Token_A, the Risk Council can vote in a multi-sig to initiate automated deleverage.

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.

What Happens in a Deleverage?

A new, reduced cap is set for the amount ofAsset_A that 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 Deleverage

Collateral deleveraging happens when there is too much of Token_A backing loans as collateral than can be successfully liquidated. This means that liquidating loans with Token_A as collateral would result in losses. For example, the deposit caps of Token_A are lowered from $100M to $80M (thus 20% of Token_A collateral must leave the system). All users with Token_A supplied as collateral will be notified of the deleverage event. If a user were to be deleveraged, some or all of their Token_A supplied would be sold on the market, repaying the debt proportionately.

In addition to the 20% of the Token_A deleveraged, an additional deleverage penalty is paid to the liquidator (explained below).

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 Deleverage

Debt deleveraging is the reverse. If there is too much Token_B debt 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_B would 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_B are lowered from $100M to $80M (thus 20% of Token_B debt must leave the system), all users with Token_B borrowed 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_A debt 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.

Auto-Deleverage Penalty

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%.

Penalty Increase & Calculation

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)

1 Hour = 7200 Slots

(Read more about slots here)

Scenario example

If:

• minimum_liquidation_penalty = 50bps (0.5%)

• current_ltv = 80%

• days_since_deleverage_initiated: 3.4 days

Then:

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%.

Who Gets Deleveraged?

Once auto-deleveraging begins, a position will be eligible for deleverage if:

• It contains the target asset

AND

• It has a current_LTV that exceeds the liquidation_LTV of the target asset

Once deleveraging begins, the liquidation_LTV of the target asset is adopted as the deleverage_liquidation_LTV. Anddeleverage_liquidation_LTV will 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_LTV automatically decreases, thus encouraging users to reduce their LTVs to a level reasonably lower than the deleverage_liquidation_LTV.

Liquidation LTV Decrease

The deleverage_liquidation_LTV decreases by the configured rate as slots per bps - e.g. 1 bps per hour would 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)

Thus:

deleverage_liquidation_LTV = 0.8 - (0.0001 [i.e. 1bps] * (345600 / 7200) = 79.52%

Auto-Deleverage Illustration