Liquidations System 1.2 Upgrade (Timeline)

Liquidations System 1.2 Upgrade

The main goal of this forum post is to introduce and explain the need for a Liquidation System 1.2 upgrade and provide a timeline for the implementation.


The Liquidations 2.0 redesign will allow the system stakeholders to access the entire Dai market, which should have the dual benefit of helping to reduce Dai price shocks. However, given the Liquidations 2.0 upgrade timeline, we believe that there should be a minor upgrade to the current liquidations system to further secure it until the release of the full 2.0 Liquidations system. The highlighted points below explain why a Liquidations system 1.2 upgrade is the best interim step prior to the full release.

Liquidations 1.2 Upgrade Considerations

Based on our ongoing analysis of the market, the Maker Foundation teams have determined several opportunities to improve the Maker Protocol’s collateral auction mechanism. For example, we saw earlier this year; the Maker Foundation is working on a Liquidations 2.0 redesign that is currently in-progress and is aimed to be delivered in Q4 of this year. Additionally, last month we saw the Liquidations system 1.1 upgrade become officially ratified through the MIPs process. This upgrade contained improvements to the Maker Protocol’s auction contracts to avoid the need for extra funds when a bidder modifies a bid they have already made (“double liquidity” issue) as well as to fix the “stuck debt auctions” bug.

  • With the present market paired with the current operating liquidation system, it has become increasingly inefficient to run Keepers and participate in the Protocol’s auctions. Additionally, with the current level of DAI debt in the system and the ~$1.3 billion value of collateral locked up, the liquidity provided by the Keepers is becoming increasingly insignificant. Therefore, if the market were to crash unexpectedly, Keepers may not be able to access the capital necessary to handle a rapidly increasing quantity of liquidations.
  • The Liquidation Upgrade 1.2 contains one of the longer-term planned Liquidation 2.0 upgrade design components, which has been thoroughly examined and discussed in the community. Given the current market conditions and the related risk, we believe we need this functionality added to the Protocol sooner.
  • Additionally, this upgrade also adds a practical oracle security method. This method would be used to prevent an oracle attack affecting liquidations. For example, if there were an oracle attack on the system that resulted in the collateral spot price reaching a low level and Maker Governance failed to act or respond in the time required, this could leave all collateral assets in the Protocol vulnerable to liquidation. This upgrade seeks to decrease risks associated with Keeper liquidity by instilling governance parameters that set the maximum DAI amount that may be in line for auction at any given time.

Why upgrade the Maker Protocol’s Liquidations System instead of using the Circuit Breaker?

Maker Governance recently introduced a mechanism to perform Collateral Liquidation Freezes. The addition was called the circuit breaker, which serves as an issue-response tool. The Circuit breaker works by creating a mechanism for Governance to temporarily disable Vaults from being sent to the auction liquidation module and operates outside of the Governance Security Module (GSM) and is therefore not subject to any delay. In order to re-enable liquidations, MKR Holders would have to pass a subsequent executive vote.

In summary, the circuit breaker’s primary purpose is to be used in situations where a sudden Eth-price drop occurs and possibly triggering a series of auctions. Without the circuit breaker as an option, the Maker Protocol remains more vulnerable to certain price movements. This is not an issue of how much collateral the exchanges can absorb, but how much Dai liquidity keepers can generate and utilize. The circuit breaker helps by processing liquidations in a more orderly manner.

Despite the circuit breaker being a useful issue-response tool, there are a few drawbacks to using it if the crypto market experiences a rapid, massive, and widespread price decline. The following are several notable risks, though this list is not exhaustive and there may be more risks that we have not identified (individuals are encouraged to do their own research):

  • The Circuit Breaker requires impeccable timing.
    • For instance, using the circuit breaker requires getting the right execution time and relying on the Maker governance community (MKR holders) to respond quickly.
      • Triggering the circuit breaker requires X amount of MKR to execute - which may not get fulfilled in time.
      • If the timing is not right, there is a substantial risk that Keepers are unable to handle an overwhelming number of liquidations.
    • As another point, having a 1 hour time period to rally enough MKR to activate the breaker is challenging to coordinate unless everyone is already paying attention.
    • To re-enable liquidations, another executive action would be required.
  • Using the circuit breaker requires subsequent action after it has been executed. More specifically, once the oracle price has been frozen, it cannot be un-frozen without re-deploying the Oracle Security Module (OSM) and updating the Maker Protocol smart contracts to point at the new deployment.
  • Relying on the circuit breaker, at this moment, seems best reserved for future exogenous events.

Given the above-listed points and the potential for further unseen risks, we believe a better solution is to intermittently upgrade the liquidations system to address potential issues and improve the system’s efficiency and usability before the Liquidations 2.0 system is finalized for implementation.

Liquidations 1.2 Upgrade Details

Overview: With the amount of Dai outstanding in the Maker Protocol, if there were a price crash, there would not be enough liquidity available to manage a large amount of auctions properly. In this case, the circuit breaker is not the right solution as it is subject to the system delay in addition to other complications. The Liquidations 1.2 Upgrade will allow Maker Governance to control the total amount of Dai that can be in auction at any one time.

Technical Details:

  • From a technical point of view, the plan is to deploy new flipper contracts and the cat contract. Additionally, there will be a new risk parameter defining the maximum Dai amount collected through the auctions at any time.
  • The governance parameter box will be used to determine the maximum DAI amount that can be out for auction at any given time.
  • As more auctions occur, an accumulator variable named the litter will be incremented.
  • Each time a bite is called on a given Vault, a check to ensure litter < box will occur.
  • Whenever an auction is concluded, the DAI amount of that auction is decremented from the litter.
  • Update the DEFCON spell with the new contract addresses.
  • Deploy DEFCON spell and add to the dschief (executive voting contract) slate.

Next Steps (Timeline for the Liquidations 1.2 Upgrade)

This upgrade will follow the newly ratified Weekly Governance Cycle (MIP16) 's schedule:

  • Monday, August 10: Governance Poll goes live
  • Thursday, August 13: Governance & Risk call to discuss the results
  • Date TBD: Executive Vote is published

Overview of Maker Governance Cycle’s



Nice! A throttle upgrade for 1.2 to add security before Liquidation System 2.0. Big improvement over the current circuit breaker.

So no idea how big the box would be, one thing is that amount of DAI being auctioned in the same 6h period, isn’t the biggest problem, but having a lot of DAI in auctions ending close together. So with the current system it might take 6 hours to empty the litter box, that might’ve gotten filled in 10 minutes. It might help to have boxes that are 1-2 hours big (or shorter than an hour), instead of putting all 6 hours into 1 box.

Basically what I’m saying is that some more finer tuned throttle control might be even better.

Multiple smaller boxes

  • In the extreme case, less DAI auctions bunched together and ending at the same time
  • Governance will be able to set a bigger combined box. More DAI being auctioned every 6 hours.

So the technical difference, have the litter box empty itself over time, and not from auctions ending.

Anyways, a circuit breaker sounds great. Not sure if you can make any technical changes before the Aug 14 executive. Or if the added complexity is needed instead of focusing on Liquidations System 2.0.

This is the main point I think. Doing the simplest possible change now that doesn’t distract us from the 2.0 work.


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