Liquidation of vault
In rare conditions, it would be possible for the entire vault to get liquidated, which would trigger a supplyLoss event. The scenarios in which this can happen are:
Failure of Liquidation: If the liquidation process for individual users isn’t happening, this can cause the protocol as a whole to be at risk. If users with high LTVs aren’t being liquidated then the overall vault LTV would be affected by this.
Failure of Rebalancing: The rebalancing processes doesn’t manage to keep the vault position healthy, this could be when the rebalancing process isn’t triggered on time (note: anyone can execute this and there are multiple mechanisms in place to do so)
Although this scenario is unlikely we do have capability built in to deal with it if it does occur.
What happens on a supplyLoss event?
If the vault is liquidated then the following would happen to the balances of the lenderStrategy:
Borrowed amount would reduce
Supply amount would reduce by the same amount + liquidation incentive
How we deal with supplyLoss events?
In order to deal with a this scenario correctly we need to treat impacts originating from user loans and farm loans differently.
Farm Loans: the vault has access to a farmWindfall as its loan will be partially repaid
User Loans: the user will still have access to the funds they borrowed
Key goals for the process are:
Don’t increase user LTV’s - We want to avoid a vault liquidation causing a user to become subject to liquidation. To achieve this we don’t want users with a healthy LTV see their LTV increase.
Don’t increase user accessible balances - we don’t want an individual user to benefit from the vault being liquidated. This means their accessible balance (consisting of the amount they can withdraw from the vault and the amount they originally borrowed) should not increase.
Approach
What we want to do when dealing with a supplyLoss event is breaking the impacts of supplyLoss into two separate problems; deal with impacts arising from the vault borrowing on behalf of users and deal with impacts arising from user borrowing.
SupplyLoss Event (e.g. vault liquidation)
When the supplyLoss event happens we have the following immediate impacts to our position with the lender:
liquidationIncentives: the liquidation bonus received by the liquidator. Typically expressed as a percentage of the amount repaid
Shifting balances: the balances are shifted from the supplyAsset to the borrowAsset (loan is repaid and collateral is reduced)
Step 1: Settle vault balances
To allow for clean distribution we need to deal with any positions the vault has taken on behalf of users first. Therefore if the vault had any lending position prior to the supplyLoss event occurring, we settle any outstanding balances:
Close down any positions it has taken (
withdraw & repay)Use any surplus (farmWindfall) to restore as much as possible of the supplyLoss caused by the vault position (
swap & deposit)
This leaves us with a balance that is as close as possible to what it would be if the vault had not taken out a lending position.
Settling impacts:
Increase supply: we use the unintended farmWindfall to improve the overall position of the vault with the lender.
Slippage: any slippage paid when swapping from the borrowCurrency to the supplyCurrency
DepositFees: any fees paid when depositing into the lender (these are expected to be close to 0)
The resulting position the vault has with the lender is now closer to what it would be if the vault had not taken out a position for farming on behalf of users.
Step 2: Distribute impacts
After this we end up with the following impacts that need to be distributed to users as best as possible:
Fees: we have liquidation, slippage and deposit fees that cause a real reduction in the assets we have available. As all users benefit from vault farming activities, it makes sense for these costs to be distributed to all users equally, we distribute these based on user supply positions.
Shifted positions: in addition we still have positions that have shifted. As we have already settled the changes resulting from the vault lending on behalf of users, we now only need to deal with changes in positions cause by user borrowing. To achieve this we distribute the remaining supplyLoss & borrowLoss based on user borrowing positions.
Last updated