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.