MIP45: Liquidations 2.0 (LIQ-2.0) - Liquidation System Redesign

Wow. Complex. I missed this a couple weeks ago. Will dig through more carefully. Sounds like some real discussion regarding auction efficiency vs. complexity against whatever one is going to consider is the price authority (oracle) to determine how to handle clearing bad loans and recovering capital.

I will try to construct a more detailed reply when I get some time to carefully digest the OP and the discussion. Have to say a lot of work went into this.

My biggest issue here that that we basically are ignoring any way to gauge real keeper liquidity and/or trying to create say a DSR vault where people can provide DAI liquidity to buffer the auction system as well a creating mechanisms to reduce auction loads where-ever possible.

Let me say again.

  1. What is keeper status?
  2. Are there ways to mitigate liquidations - particularly during heavy stress load times we have not considered?
  3. How do we keep the system primed and tested so we can gauge keeper liquidity availability etc. I have a real issue here that the liquidation system is like a fire alarm - if you never test it - you never know what is going to happen.
  4. Have people considered what happens in high network loads? I am talking 2000-20000gwei to post tx’s?
  5. I keep coming back to spreading protocol risk over multiple networks. Beginning to think it might be prudent to think about how to fork Maker on to a number of L2s and distribute back the entire thing but this is a very complex proposition but might be worth considering - not putting all eggs into one network basket because if any part of this system effectively loses network access that could kill the system very quickly.

I think part of the problem is that there’s really no way to independently verify this. I am all ears for potential solutions.

1 Like

Edited and updated for formal submission:



I’m a big fan of the work done on Liquidations 2.0. The idea that responsibility for maintaining the collateralisation of Dai will be handed to the whole DeFi world (potentially any DEX user) rather than a limited number of Keepers is very exciting.
I’m trying to understand the scope/risks of taking a further step and having the Protocol itself liquidate undercollateralised Vaults. I know this has been discussed before but things have changed a fair bit in the last few months, including approval for the Flash Mint Module. Upon an auction being triggered, the Protocol would instantly purchase the collateral using flash-minted Dai and sell it via a supported aggregator. Assuming the market isn’t in absolute freefall, there’s a lot to be said for getting the job done quickly at a fair price rather than waiting for buyers to come in when the market is still dropping.


The biggest risk here is that it won’t get done. You want to avoid having a single point-of-failure, but you don’t necessarily want a lot of wasteful competition here, either.

There’s actually a flash-lending component built in to liquidations 2.0 already. Auction participants can borrow the collateral directly and bring it to market, as long as it is repaid in Dai. This avoids the additional step of having to borrow and repay Dai to a flash module.


Understand and agree on the points concerning the abacus and the bark incentive. On the top calculation, it makes me pretty uneasy that LIQ2.0 deteriorates even the best-case outcome in the case of an oracle attack: 100% loss of affected collateral with no chance of recovering anything (because the auction will start near 0). Using an oracle-independent top seems like a strictly more defensive design, at least w.r.t. oracle attacks. Two specific questions to consider:

  • How much can collateral ratio really overestimate the price by in realistic market conditions?
  • How harmful will it be if top price is overestimated (by e.g. 100%) given realistic choice of liquidation parameters?

I think on average 150% LR vaults get liquidated at around 145-150% CR range, so it probably wouldn’t be an issue most of the time. However I can imagine that in some severe black swan event where price drops 20%+ in 1 hour, some vaults could get potentially get liquidated at 120-130% CR range. Which means the price curve could be “too flat” for intended duration until cleared, but it’s also true that 3h largest drops of ETH have historically similar intensity as 1h drops (-28% 3h rolling vs -26% 1h rolling on BT), which means that eventually price curve would “catch the market price” if cusp (auction price drawdown reset) is -50% for instance.

I would say most of the time using LR as input for ‘top’ would be ok, but in some severe drop events it could potentially lead to worse outcomes. Especially for events where market price keeps falling and falling for few hours with similar intensity.

What about using input for ‘top’ as max of OSM price and LR implied price * 0.7 for instance?


Hello everyone,

What is the best way for me to track the progress of this MIP through the governance process? Is there an interface that people log onto like this one perhaps?

Currently I think the best we have that would be comparable is MIPs Portal. Also check out [Agenda/Discussion] Scientific Governance and Risk #131 - Thursday, March 4 17:00 UTC - #10 by Anna which has a nice timeline for MIP45.


It is certainly possible to introduce another tunable parameter that would modulate the LR implied price. Setting it correctly is still non-trivial, but at least it’s more flexible than simply using the LR price. The main downside, besides complexity, would be further adding to gas costs.

1 Like

Hello everyone,

I see that MIP45 was accepted via the MIPs Portal.

Where or how can I verify that it is published to mainnet? Great MIP by the way!

It will still need to go through another vote to actually be deployed - just watch the voting portal and you’ll see it when it comes up (or track the posts in the forums)

1 Like

Edited and updated to include audit changes here:


All audit reports are now available on security.makerdao.com:
Liquidations 2.0 - Security


Edited to include ChainSecurity audit:

1 Like

Does this mean that MIP 45 will be published on Ethereum on April 24th?

No, it has office hours so won’t go live until Monday 14:00 UTC.

By the way, if you are willing to share why you’re interested in the deployment, maybe someone can help with whatever you’re trying to do? :slight_smile:

I work for Quantstamp in the Communications department. I want to release a tweet announcing that Liquidations 2.0 is live because Quantstamp audited the MIP. I am trying to figure out the best way to know when it is finally deployed on Ethereum.