Liquidations System 1.2 Upgrade (Timeline)

I’m personally strongly in support of this idea. Auction inefficiencies with respect to lack of circulating or available Dai is a huge issue. With the size of the collateral portfolio growing as large as it has been lately, Maker is even more at risk in case there is a sudden drop.

The original circuit breaker / liquidation freeze, which is still a very viable and useful tool, was created somewhat hastily and is basically a blunt version of Liquidations 1.2. With 1.2, governance can be more granular about how they want to structure liquidations. I’d love to see this added as soon as possible.


I think if we look at what we have now. Only circuit breaker (which stops everything and has to be timed impeccably). Taking an alternative approach to liquidations by throttling them based on the litter box is probably a good step.

I am guessing we are going to have a fixed DAI sized litter box vs. one that kind of tracks a % of outstanding.

One thing I want to point out. We need a notification system when litter box is full - in the operational system status display. We also are going to need to have another parameter that tells us how much more collateral is slated to be auctioned. If we have the litter box full and like 5-10 more litter boxes of collateral coming up - governance will need to step in or we then face building system loss risk because we can’t clear collateral out effectively.

My concern is that this is another system parameter that will need to be tuned and I have no idea what scientific data we are going to use to tune it, much less come up with an initial estimate of how large the litter box needs to be and how often it will be emptied.

I agree with Jiecut that 6hrs may be too long here.

Something else but I don’t think this can be done easily is the idea if we have like 10 litter boxes of collateral to auction it would be nice to actually take 1/10th of all the collateral up for auction over all vaults with CRs below the LR and auction it. If any collateral is returned it could put a good fraction of vaults CRs above the LR removing any need to auction more collateral for that vault. I made a post illustrating this sequential vault liquidation as a mechanism to reduce the amount of collateral needing to be liquidated. IF any collateral is returned to a vault based on a partial liquidation this could raise the CR of the vault eliminating any subsequent liquidations. Honestly I think this change is much more significant and probably not a practical change but I just point it out for thought while people are working on Liquidation2.0 code. The point here is if you have 10 litter boxes of collateral and then take pieces of vaults collateral and auction them in the first litter box together one might just get enough collateral back to make it so some large fraction of all the vaults that needed to be liquidated in the previous litter box now have a CR above the LR and don’t need to liquidate any more saving keepers, system and a key point vault owners. Actually applying this sequential auctioning across entire spectrum of vaults that come up it might be that only auctioning 1/5 or 1/10 of all the vaults up for liquidation collateral and returning 1-2-3% of collateral might be sufficient not to save 1:10 but it might take 5:10 or more vaults out of the liquidation CR zone. This will be particularly true once the collateral price bottom hits and prices start to increase and we find we only need to auction only 10-20% of a vaults collateral to bring their CRs up enough so the rest of the vault collateral doesn’t need to be liquidated.

The more I think about this from the litter box perspective the more appealing this ‘sequential vault liquidation’ method seems to be in terms of staving off more collateral into liquidation than is required depending on market conditions. I hope this will be seriously considered when thinking about liquidation system 2.0 as it helps not just keepers, the system, but also vault owners tremendously.

1 Like

Hi all. Please note that the usual process for non-standard weekly polls is that there be a reasonable amount of time for discussion and visibility on the proposal before it moves to a vote.

This particular non-standard weekly poll has been expedited on the authority of the Risk and Smart Contracts domain teams (details here), who both believe that it should be implemented sooner rather than later.

Personally, I would like to see details on the code changes taking place, details of any audits that have been done (and reasoning against doing them if they haven’t.) Please bear these details (or lack of them) in mind when voting in the poll on Monday.


Hi everyone. I think Charles, Wouter and Cyrus have already expressed why this is a good change for the protocol, but let me chime in as well.

According to the largest ETH-A vault has 37m Dai debt, second largest has 30m. If any of these 2 vaults were to be liquidated (they’re pretty safe right now) we’d see an immediate liquidity crunch, as keepers try to bid on an extremely large amount of auctions. I believe the risk to the system would be high, since in case of the first vault, 290,000 ETH would be auctioned, in up to 2900 different and simultaneous auctions.

The proposed change lets Maker Governance control to some extent the amount of simultaneous auctions that can occur at once.

The proposed code is here

Changes to cat

  • box parameter, for max amount of Dai out for liquidation (as a rad)
  • lump becomes a rad (currently it’s a wad)
  • the bite function takes into account box to see if an auction can start

Changes to flip

  • Flippers now take cat as a parameter
  • On deal (when an auction is finished) and yank (use during Emergency shutdown) there’s a call to cat.scoop with the amount of dai recovered, to decrease the accumulator and let more dai be auctioned

Tests have been written and are available in flip.t.sol and vat.t.sol, including:

  • test_set_lump_multiple_ilks
  • testFail_lump_too_large
  • test_cat_set_box
  • test_partial_litterbox
  • testFail_fill_litterbox
  • test_partial_litterbox_multiple_bites

The code is public for the whole community to read and evaluate. We’re reaching out to community members who’ve reviewed code in the past. Hoping they can take a look.

Available to answer any questions. Thank you.


I’d have a few question that I hope you can clarify:

  • What does it mean that system stakeholders can access the entire Dai market?
  • How does Liquidations 2.0 help to reduce Dai price shocks?
  • Will liquidations still be based on auctions?
  • What’s the upgrade timeline for Liquidations 2.0?

I believe most of your questions would be answered if you go through following posts:

I would start with the:

It’s possible that not all relevant posts are tagged, but are likely at least referenced.


Would still be good to have those questions addressed but not going to happen, I guess.

In the above Pre-MIP link, it is written:

I don’t think it’s fair to expect forum users to address your questions, while you clearly did not demonstrate any effort.

I saw Dutch auctions being mentioned but that covers just one of my questions.

But I agree with you that I should have made more effort to find answers, I just assumed those would not be answered yet as nothing about it has been mentioned in this article which should be the most up-to-date place.

Regarding timeline…


I would say we should have a reasonable dataset at least for benchmarking the scale of this from March 13 event. That can likely be used as a test data for a stress testing model.

1 Like

Note that this was postponed for the time being so that the smart contracts team has time to write more tests before it is put to an executive vote.


Strongly in favor of this liquidation auction upgrade.
As the changes are complex, it would also be comforting to have the extra layer of security provided by an additional third party audit.

I was reviewing the code for this in dss ( and realized that this has potentially negative side effects when liquidations & keepers start to fragment and stop liquidating all collateral types. Right now the assumption is that box is an upper limit on all collateral types at auction but that is not going to hold true. There are several discussions around building specific liquidation mechanisms.

This means that current cryptocurrency (ETH, BAT, ZRX, …) keepers that mostly juts bid on these tokens and flip them on an exchange would have a given capacity to do so. If we now introduced liquidations for real world assets, or even centralized stablecoins that might attract a very different group of keepers that have a very different liquidity.

Why not implement the box & litter as a variable that can be per “family” of collateral types?

contract Loo {
    mapping (bytes32 => bytes32) public family; // ilk => family
    mapping (bytes32 => uint) public litter; // family => litter
    mapping (bytes32 => uint) public box; // family => box
    function ilkLitter(bytes32) public view {
        return litter[family[ilk]];
    // ...



If we were to turn on liquidations for fiat-backed stablecoins (USDC et al.) we’d likely already see keepers behave differently when buying these vs. other collateral types: buying up USDC at auction without being able to liquidate it immediately will still require a lot of liquidity from keepers but it won’t expose a keeper to a lot of exchange risk if they hold on to avoid slippage in the market.

1 Like

Thanks for the comment @spin. Ultimately, LIQ-1.2 is an interim patch before we release LIQ-2.0. This solves a major risk that we have today; however, if we were to imagine a liquidation model for a real-world asset, we would just simply enable a different liquidation mechanism.

Our current mechanism, and that envisioned in LIQ-2.0, is designed for tokenized assets that have healthy liquid markets. While I think we all want that for real world assets, it stands to reason the novelty of those assets and regulatory restrictions are going to necessitate alternative liquidation mechanisms.

I will say, having a collateral specific box parameter is under consideration for LIQ-2.0. Because, as you point out, one may not be able to fine 20 million of Dai liquidity for some novel asset. I am leaning towards box being the overall liquidation limit for Dai, in the same way we have Line as the overall debt ceiling, with each ilk having a more granular limit configured.

1 Like

I understand the tradeoffs and agree that having it is likely better than not having it at all even if we add other assets to the mix. However for Liquidation 2.0, this feature should probably not go into the Cat the way it is now as it would be impossible to use a custom mechanism that was not affected by this behavior.

Glad to hear you are thinking about making it per-ilk in LIQ-2. Probably you would want to group it into something that is more than one ilk though. Anything where the default liquidation path or keeper group is very similar should share the same box if we are concerned about the keeper’s liquidity. Especially given that all of the collateral we have to today has very heavy correlation it would not make sense to have separate box parameters per collateral.

1 Like

In case it is not too late, i would kindly ask that the cat would expose the tab calculation as a public function, and will be more than happy to submit a PR with tests for it, if i would get an indication that it will be considered for a merge.
EDIT: A PR was submitted

I am referring to this line in the code

A similar function exists in compound as an API (in their smart contract).

The motivation is that we are working on an opt-in liquidation system that needs to read the liquidation penalty value from makerdao’s cat.
We plan to read the cat address from the end contract, but changes like in this version, where the chop resolution changed from rad to wad will break our system (in the future, it is still not deployed).
Hence, a function that for a given art (and maybe also rate) returns the tab, would really help.


Is there a reason why support for automated “auctions” via DEXs should not be added to the Protocol itself?
I.e. in the event of relatively small liquidations, the Protocol could use spare Dai from the Surplus Buffer or a designated pool to purchase Vault collateral, then cycle the assets bought through DEXs to replenish the Dai spent, plus a bit.
Keepers and external auctions would still be relied on at times of higher demand or if the desired price cannot be met.


WBTC and ETH are very heavily correlated, but perhaps we don’t want to liquidate more than we think keepers can cycle for a collateral type. So for ETH this limit would be very high as it’s the chain’s native currency, but for WBTC keepers may only be able to cycle X amount of it before crashing the price further on ethereum, meaning they would need to use centralized exchanges or RenVM. I make this point just to show, even with more liquid tokenized assets, not all liquidity is equal and thus we probably want this level of granularity.