Liquidations 2.0 and Oracle Price Drop Faults

The information below was presented and discussed on the March 18th, 2021 Governance and Risk call, and is being posted here for broader awareness and discussion.

Oracle Price Drop Fault Risk: Greater Concern in Liq 2.0 than 1.2

  • A significant concern with Liquidations 2.0 relative to 1.2 has been identified in pre-launch risk discussions regarding the exposure of the system in case of an oracle fault.
  • The severity of the consequences for the system is much greater for Liquidations 2.0 as opposed to Liquidations 1.2 (the current system), although the security of the oracles is unchanged.
  • The specific scenario is a drastic drop in oracle prices that diverges from the true market value (oracle attack or malfunction, “flash crash” with a quick recovery, or market manipulation).
  • In Liquidations 1.2, auction settlement price is not related to the oracle price. Further, the DAI target buffer (“box” parameter), combined with an enforced minimum time-to-settlement, limits the rate at which Vaults are put on-auction.
  • Thus, in an oracle price drop anomaly, Liquidations 1.2 has a relatively robust ability to minimize losses to the system, avoiding bad debt accrual.
  • Liquidations 2.0, on the other hand, will offer liquidated collateral for sale very near the oracle-reported price at the start of the auction. In the envisioned scenario, this starting price is well below the market price, so the auction will quickly be bought out, locking in a systemic loss. Further, this purchase clears 2.0’s DAI target buffer (“hole”), allowing more liquidations to occur immediately.
  • Thus, if the oracle price for a collateral suddenly goes to near-zero, or even just significantly below the true market price, the entirety of Vaults for that collateral can be liquidated very swiftly and for very little DAI, causing massive losses to both the system and Vault holders.
  • The system is not defenseless–the 1-hour delay applied to oracle prices gives MKR holders time to prevent catastrophe via use of an instant access module–the greatly increased severity of such an oracle fault is deemed a serious issue for Liquidations 2.0.
  • Further, the incentive to cause such a fault for a malicious actor grows proportionally to the collateral in the system. This is not sustainable and puts a lot of pressure on the oracle security model as we scale.
  • This is not a new problem and we have been aware of it since the original design of the system. In fact, the OSM’s 1 hour delay along with the oracles freeze functionality was put in place to offer protection, and is considered sufficient in the case of Liquidations 1.2. However, the additional severity in the case of Liquidations 2.0 calls for additional measures to further contain this risk.

Smart Contracts Team Recommendation

  • The system currently faces significant risk from real market downturns and DAI liquidity crunches–there is no free lunch. Thus the ideal solution allows us to launch Liquidations 2.0 as planned, without invalidating the extensive scrutiny applied the the code to this point.
  • We can decrease the false price drop risk in the short term with a special permissionless circuit breaker. It allows anyone to disable liquidations instantaneously any time the next price for a collateral is lower by a configurable percentage than the current price. It is similar in principle to the debt ceiling IAM. This is an extremely simple module that can be safely deployed within a couple of weeks without affecting the core auction code. More details on its design will be forthcoming.
  • In the longer term, we believe more robust mitigations should be implemented. However, researching, implementing, testing, verifying, simulating, and auditing them will take significant time–on the order of a few months from research to rollout. A number of promising options are under discussion, but need more rigorous study.
  • This plan allows the phased rollout of liquidations 2.0 to proceed according to plan (with the addition of the permissionless circuit breaker); that is, there should be no further delay, pending completion of final checks.
  • Integration partners should be clearly informed in advance about the planned upgrade, and given guidance on how to prepare for it as early as possible.
  • In summary, the Smart Contract team recommends continuing the phased rollout of Liq 2.0 as has been communicated previously, with an additional permissionless circuit breaker and a commitment to making a future upgrade to further mitigate oracle price drop fault risk.


I hear and value your concerns, but at some point you have checked and doublechecked everything twice or thrice. You have done what you could and all involved knows there is nothing absolutely certain in life and most certainly not in crypto.

You are concerned about liquidations 2.0, well I am concerned about not having liquidations 2.0.

Here is the scenario: once the USD 1.9 trillion stim package hits the US economy all bets are off with regards to the crypto markets. The boom-bust cycle we are alreay in the middle of could become intense. And accordingly - when the next crash eventually happens, it could be an epic disaster. I feel it is much much better to have even a gimped version of Liq 2.0 in place compared to any Liq 1.2 or version of should this happen.

At some point you just got to take a deep breath and hit Play.


I actually agree with @Kurt_Barry,
The main concern in general is that we change the type of auction. In your scenario, I would be more worry with a v2 during a crash than with v1.

We know exactly how the current auction works/ reacts with the pros and cons. It is also the “normal life” type of auction.

With v2, we dump massively during a crash which will push the instant oracle price even further. By doing that we sort of manipulate our market oracle price. It will probably react like kraken last month with a 70% drop. Interestingly I am less concern by an oracle price deviation than by the lack of buyer from the market at the t time.

With v1, we deliver the asset after a certain delay so it is outside the market. And the auction duration is a long period ( probably too long to be honest).

1 Like

I’m surprised at the tradeoff chosen. It seems to buy extreme tail risk for more efficient liquidations overall.

I hope that future additional dev bandwidth will allow for fulfilling that “commitment to making a future upgrade” in time.

1 Like

Can’t this be mitigated by looking at a smoothed oracle price (24hr avg) against the current and acting appropriately. I mean the attack is that an actor has to affect the instantaneous oracle price and there is still the 1hr delay before action can be taken.

I think the real point here is that it is going to be much harder to affect the 24hr average than a rather instantaneous number. Use the 24hr price average as the auction starting point vs. the instantaneous oracle price?

I am completely not up to how the oracle prices are determined but wondered if multiple input sources that one could create a oracle input pricing disparity measure that is a measure of the oracle price distribution. If there is a large disparity in oracle price feeds flag this as well.

The point here isn’t just that the oracle can be manipulated but that at the same time network access could be hampered to do/change anything allowing an attacker to get collateral as below market prices.

Now what settings, and what to do in these cases becomes the issue here. But if we are just talking about what the starting price of a liquidation auction should be to be effective I would think the safe bet is to use a 24hr rolling average and/or look at consistency between different oracle prices before determining an auction price.

I also come back to Maker using some of it’s surplus to purchase pieces of collateral at auction prices so it can use this collateral to probe the market price - before launching assets under management. I think the idea of losing say $1K on using 10ETH to determine the current state of the auction market before dumping 10M might be a good use of funds. The point here is that if the oracle is telling us the price is 2K/ETH and we only fetch 1K/ETH on 10ETH in liq2.0 the system needs to flag someone in operations telling them that the auction system price is massively disjointed relative to oracle and some manual intervention might be required.

I believe it would be better to periodically buy assets at market or in periodic auctions to then put then on the liquidation block periodically to measure auction response and to use the measure of these liquidation prices in conjunction with oracles to determine what actions to take when seeking to liquidate system collateral.

I believe doing the above would provide a general measure of liquidation system response both in good market times and bad and the price disparity between collateral liquidation price and oracle to be a key measure to determine how efficient the keeper system is at liquidating collateral (at least from a price perspective).


Please note that the recommendation is to stick with the timeline of the rollout. I.e. not postpone LIQ2.0 launch.

This plan allows the phased rollout of liquidations 2.0 to proceed according to plan (with the addition of the permissionless circuit breaker); that is, there should be no further delay, pending completion of final checks.

1 Like

Why don’t you just offer the collateral at the higher of the OSM and whatever satisfies the system’s outstanding debt for like 10 minutes? Then increment it downwards by a fixed % every 10 minutes thereon? Maybe I’m missing something but I don’t see how things can go wrong so long as the system has the opportunity to recover the bad debt.


An alternative suggestion is to offer it at the higher of a TWAP of the past ~10 OSM prices or the current one

1 Like

I would assume the main problem is when we get to the point where we pass the CF and Maker starts to lose money.

Don’t we want to stop at this point and start the classic auction ( same style at V1) with a longer period.

I ve also noticed that the implementation doesn’t allow an easy auction type change ( the dog is relatively specific). I haven’t been too much into detail but wouldn’t it be possible to have it a bit more modular with the clipper holding/responsible-for the auction implementation. For example currently it is not possible to have the flipper plug-in even if you try to adapt it.

Doesn’t my suggestion solve this?

Let’s say the OSM reads $100, previous price was $200 and the Vault was 200% collateralized, and the Vault liquidation ratio was 150%. Offer the asset at $150 (we know this covers the debt) and increment your way down to $100 over a fixed period of time.


I am not too sure, for me it is already more or less what it is implemented. Instead of having a 10 min waiting time and x% drop you have it but continuously. I don’t remember exactly how it works to be fair.

If you start higher than the oracle you fall into the issue that you don’t decrease quickly enough against the market. Don’t forget, everyone is liquidating a lot in general when we are trying to liquidate, so your oracle will probably be already higher than the actual buyer market. I actually think it is not too bad to start lower, until a certain point.

What I proposed is different as the solution actually stop the direct liquidation into the market when we hit the lowest acceptable point for us. When we hit this point, the losing point, that mainly means the market can’t absorb any more asset or we have an oracle issue. By switching to a v1 auction type we use a longer time period, so it should be less market time driven and more risk driven. It will also give us time and counter balance an eventual oracle failure.

Note, the lowest acceptable point is actually not necessarily the losing point, it can be lower or higher.

This is one (actually a combination of 2) of the mechanisms that was considered, but it would require a more complicated change in the code base which would invalidate the security audits and add several weeks to the launch timeline for LIQ 2.0.

The suggested solution put forward by the team may be less optimal than the kind of mechanism you’re describing, but it should add sufficient protection and allow us to stick to the timeline without delaying the launch any further.

Given the fact that LIQ 2.0 will remove a lot of risk once it’s in place, that delaying extends that risk, and that there will always be a next, better, version, the team opted to not postpone the launch any further in order to build the more optimized solution.


I’m curious about the feasibility of taking the MAX(token_oracle_price, cdp_debt_value) instead of completely depending on the oracle price. Obviously we can still lose money if the oracle price is very low, but at the very least we avoid the potential of bad debt.

This would allow Maker to effectively ignore a bad oracle token price, but still be able to use them for gains effectively if they’re higher than the debt value.

Edit: After completely reading through the thread it sounds like g_dip is saying the exact same thing so I’m glad it’s already been proposed :slight_smile:

1 Like

Yeah that and variations on the theme have been discussed a lot. It’s on the list of mitigations to consider in future upgrades.