Consider liquidation price on take #219
Conversation
| @@ -248,7 +251,7 @@ contract Clipper { | |||
| sales[id].tic = uint96(block.timestamp); | |||
|
|
|||
| uint256 top; | |||
| top = rmul(getPrice(), buf); | |||
| top = max(rmul(getPrice(), buf), tab / lot); | |||
There was a problem hiding this comment.
Using tab / lot isn't optimal because it neglects mat. See Lucas's reply to me here:
From discussions w/Primoz, having some multiplier (i.e. a second buf) is the most flexible option. See e.g.:
https://forum.makerdao.com/t/mip45-liquidations-2-0-liq-2-0-liquidation-system-redesign/6352/25
There was a problem hiding this comment.
Still thinking through this. I can see Lucas's point, but I see this as an emergency fallback, the oracle price will still be primarily used as the starting point unless there's a hugely dramatic drop.
Primoz has a point, too, but rather than reducing it by a multiplier I'd argue for Lucas' point that this is just a starting point for the auction and that at least gives the vaultholder a fair shot at recapitalizing in the market. If indeed it is too low, it should still be repriced in the redo()
Takes the max of
getPrice()*bufortab/lotontakeonly.This sets a price floor on initial
takes to ward against an OSM attack.This formula does not apply to
redo()because the initial auction will take time. In a real oracle attack we'd resolve the oracle issue, but in a catastrophic market decline theredo()would rely entirely on the OSM price to set the price on the second try.