[GIP-125] Enabling partial liquidations through bots

Author

van0k, 0xmikko, apeir99n

Summary

Note: this proposal is in an optimistic format. This means that transactions to deploy and connect partial liquidation bots will be queued before voting ends. If the vote succeeds, transactions will be executed immediately after; if it fails, pending transactions will be canceled.

This proposal aims to deploy the PartialLiquidationBotV3 contract and connect it as a special permissions bot for all current Credit Managers, which will enable partial liquidations. We also propose to gradually ramp ezETH’s LT to a lower value more aligned with the asset’s actual risk as well as changing debt limits on Arbitrum.

Overview

The recent ezETH depeg has demonstrated the need to minimize the selling pressure when liquidating accounts. Due to the current core contracts only allowing liquidations of CA’s entire debt, significantly more ezETH were sold off than required to bring the affected accounts back into health. This caused undue losses for users who were basically forced to sell their entire positions at low price / with high slippage, and also contributed to the imbalancing of on-chain ezETH pools.

After the depeg, on-chain liquidity remains limited, which can complicate or even outright prevent successful liquidations of remaining ezETH accounts.

To improve this going further, we propose to deploy the PartialLiqudiationBotV3 contract (audited by Mixbytes) and assign it a special permissions bot status in all existing Credit Managers. This will enable liquidators to partially liquidate unhealthy accounts by purchasing just enough collateral at a discount to bring an account back to health - thus significantly reducing selling pressure from liquidations and allowing to keep CAs healthy even with current limited liquidity, while also minimizing losses for users.

PLB technical details

To better understand this section, basic knowledge of Gearbots is recommended. You can find a detailed explanation here.

Partial liquidation bot logic

PartialLiquidationBotV3 is a Gearbot contract that enables partial liquidations of accounts below a specified `minHealthFactor`. A partial liquidation is essentially a swap of some collateral asset on an unhealthy Credit Account for the liquidator’s underlying at the price equal to `oracle_price * (1 - liquidationPremium)`. The underlying received by the account is immediately used to partially repay CA’s debt.

To be precise, PLB performs the following sequence of actions:

1. Applies price feed updates required to compute account’s health (this is only relevant for accounts that possess assets with Redstone pull oracles);
2. Checks that the account is actually unhealthy (by comparing the account’s current HF against a `minHealthFactor` parameter);
3. Computes the paid underlying amount given the requested collateral amount, or seized collateral amount given the underlying amount (this is the only difference between functions `liquidateExactDebt` and `liquidateExactCollateral`);
4. Transfers underlying to the Credit Account;
5. Calls the CreditFacadeV3’s botMulticall with following operations:
   1. Decrease debt by the amount of underlying transferred minus the DAO’s liquidation fee;
   2. Withdraw the liquidation fee to the treasury;
   3. Withdraw the passed / computed amount of collateral to the `to` address specified by the liquidator;
6. Ensures that the resulting health factor is above `minHealthFactor` and below `maxHealthFactor` (if this parameter is set).

The liquidator then disposes of received collateral at their discretion.

Note: The minimal debt requirements for Credit Accounts apply post partial liquidations. This means that a partial liquidation can only reduce an account’s debt to `minDebt`. If that is insufficient to restore an account to health, a full liquidation needs to be performed.

Deployed PLB configurations

The following configurations of PLB will be deployed:

1. AP_PARTIAL_LIQUIDATION_BOT,

minHealthFactor: 10_000,

maxHealthFactor: 65_535,

premiumScaleFactor: 10_000,

feeScaleFactor: 10_000,

special: true,

1. AP_DELEVERAGE_BOT_PEGGED,

minHealthFactor: 10_100,

maxHealthFactor: 10_250,

premiumScaleFactor: 5_000,

feeScaleFactor: 5_000,

special: false,

1. AP_DELEVERAGE_BOT_LV,

minHealthFactor: 10_400,

maxHealthFactor: 10_600,

premiumScaleFactor: 5_000,

feeScaleFactor: 5_000,

special: false,

1. AP_DELEVERAGE_BOT_HV,

minHealthFactor: 10_600,

maxHealthFactor: 11_000,

premiumScaleFactor: 5_000,

feeScaleFactor: 5_000,

special: false,

Where minHealthFactor means below what value the bot can start de-leveraging a position (10_000 is equal to Health Factor 1), maxHealthFactor means up to what value the bot can do de-leveraging of position, special=true means bot will be compulsory for all Credit Accounts in the CM (if false, bot should be enabled by user manually). The compulsory bot charges the same premium and fee as full liquidations in respective Credit Managers, hence premiumScaleFactor and feeScaleFactor are set to 10_000 (i.e., 100%). For de-leveraging, there’s no need for such incentivization, so both premium and fee are reduced by 50%.

Change debt limits on Arbitrum

Based on the results of the analysis of liquidations on Arbitrum, it was decided to change the size of credit accounts:

	Min debt	Max debt
ETH Tier 1	2 WETH	45 WETH
ETH Tier 2	2 WETH	15 WETH
USDC Tier 1	5k USDC	100k USDC
USDC Tier 2	5k USDC	25k USDC

The logic behind changes in the lower bound is associated with increasing profitability for the liquidator, and the upper bound is associated with reducing price impact.

Voting

Simple Approve / Reject