Liquidation design & testing

[devsquaaa]

At the moment, our liquidation function just repays the debt (including interest) to the stablecoin (e.g. MAI or GHO).

I assume this is not the final system we want to implement. Here are some alternatives :

1. Fixed "profit" for the liquidator : the liquidator pays an amount of stablecoin such that the LP position he receives is worth x% (to be determined, can be an actual constant, or a function of the minimum collateral ratio) more valuable than what he paid (i.e. selling it at the current market price would yield x%). Obviously, if the position's CR is below 1+x%, the protocol will just require that the liquidator sends enough stablecoin to cover the debt of the position (since the liquidator's profit will be below x% anyway). This is how we would compute the amount the liquidator is supposed to pay : amountToPay = max(positionDebt, positionValue * (1+x%)), with these values quoted in the stablecoin (so, in USD for MAI or GHO). This system is reasonnable because it incentivizes liquidators, while allowing the protocol to build up nice reserves, and potentially gives us a revenue stream.
2. Liquity-like stability pool mechanism, I think we all know how it would work.

So, any idea what we should implement for the v1? @Lolshh @userdarius @GustaveCharles @NilsDelage

[gaspardthrl]

I agree with the first point.

About the second, I don't know if a stability pool mechanism would be relevant for the v1 as it would expose us to much more vulnerabilities imo. I'm totally cool if we implement it and will be happy to it (or at least part of it) but it will be a lot of work and will require some serious thinking and risk analysis prior to its implementation. Again it all comes down to the questions: What do we want the v1 to be (i.e. should it be similar to the MVP) and when do we want to have it finished?

[userdarius]

Agreed I don't even think a stability pool in itself is relevant anymore for now anyway. We should focus on capital efficient liquidations that incentivise the liquidator while keeping the process enjoyable for the borrower. Liquidations should also be capped to a maximum of 50% initially to avoid liquidity pools to be tampered with on Uniswap.

[gaspardthrl]

What do you mean exactly by "Liquidations should also be capped to a maximum of 50%" @userdarius ?

[userdarius]

We shouldn't allow a liquidator to liquidate more than 50% of the position

[userdarius]

@devsquaaa how long will this take to implement?

[devsquaaa]

Liquidations should also be capped to a maximum of 50% initially to avoid liquidity pools to be tampered with on Uniswap.

This is a good idea for most cases, but I think a liquidator should be able to liquidate a position if we're about to go into bad debt (i.e. position value is "barely" greater than debt value, because it would be impossible to liquidate 50% of the position and get a position above the minimum CR). Here is the design I propose :

• everything about option 1 in my first message
• the proportion p of the position being given to the liquidator is given by min(<the proportion the liquidator wants to liquidate>, max(50%, <the proportion that would make the position's CR greater than minCR>))

This basically gives us the following guarantees :

• We never liquidate more than 50% of a position unless it's necessary to avoid bad debt.
• A liquidator can liquidate less than the maximal amount if they want to.

Any thoughts ? @Lolshh @userdarius

@devsquaaa how long will this take to implement?

The design I described could most probably be ready for Sunday, and tested next week.

[userdarius]

All good for me!

[userdarius]

Let's try to finish this function and tests before the deadline

[devsquaaa]

The liquidate function is ready. I just pushed 2 tests (e1f0740b99035151c6f28fc7cc8511240803ba08) of the liquidate function that cover the 2 important cases of a liquidation (case where the position's health can't be improved, and one where it is). Would be nice if someone else with another point of view could add some new tests for potential edge cases.