This forum post aims to serve as a “pre-MIP” discussion, where the Maker Community and the Smart Contracts Domain Team can discuss and provide input on the proposed solution for a redesign of the liquidation system of the Maker Protocol.
The main goal of this “pre-MIP” forum post is to introduce a proposed solution for a liquidation system redesign and gather feedback in preparation for the creation of a formal Maker Improvement Proposal (MIP), which will contain more implementation details. The MIP itself will be proposed as a MIP2 proposal, which means that the Feedback Period and Frozen Period defined in MIP0 are ignored for both MIPs and Subproposals and are instead determined by the MIP Author(s). In general, in order for proposals to qualify as a MIP2 proposal, it must address one of the issues listed in MIP1.
Initial Research and Findings
The process behind the proposed solution design initially began with looking at many different options to determine which may be optimal for the Maker Protocol. More specifically, we considered the following classical auction solutions:
- English Auctions
- Reverse English Auctions
- Sealed/Batched Bid Auctions
- Multiphase Auctions
- Dutch Auctions
- Reverse Dutch Auctions
After research and design consideration, the Smart Contracts Domain Team believes the Dutch auction system, based on its merits (further described below), is likely the most suitable solution for a redesign of the liquidations system. The Dutch auction system has been validated in the market and has proven to work for massive liquidation events, such as Set Protocol’s use of Dutch auctions for rebalancing. Set Protocol’s implementation can be found here and is also described on page 24 of their whitepaper.
In terms of this proposed solution design, the sections below address the motivation behind the system redesign, the design considerations, and the details regarding the requirements of the solution:
Our ongoing analysis, further focused by the events of March 12th, 2020 (“Black Thursday”), developed several opportunities to improve the Maker Protocol’s collateral auction mechanism. Specifically, the following list covers the areas of improvement that can be considered when designing a new liquidation system for the Maker Protocol:
Reducing the reliance on DAI liquidity
- Today, Keepers require sufficient DAI before making a bid, and that DAI is locked until that Keeper is outbid; if the Keeper’s bid wins, it must then find a way to recycle that purchased collateral back into DAI in an efficient manner.
- Since multiple Keepers are necessary to ensure competitive (and thus, efficient) auctions, there is a multiplier effect on the DAI required. For every 1 DAI of debt sought by auction, there needs to be at least 2 DAI of liquidity.
- The need to lock DAI for multiple blocks after a bid is submitted means that flash loans cannot be used to ease liquidity requirements.
Reducing the likelihood of auctions settling far from the market price
- Currently, an arbitrarily low bid can be made immediately after an auction starts. If other participants are not able to outbid the initial bid, due to liquidity constraints (above) or network congestion, the auction is won at the initial low bid price.
Reducing the barriers to entry
- Participating in auctions: (1) is capital intensive; (2) involves significant time exposure to collateral and DAI price; and (3) requires substantial technical sophistication.
- As MCD scales with more collateral types, the infrastructure cost and liquidity requirements of running Keepers for all collateral types increases. Therefore, the Maker Community should seek to hold constant or reduce both liquidity requirements and infrastructure costs as MCD scales.
Design Considerations for a New Liquidation System
With the above in mind, the Smart Contracts Domain Team put together a list of desirable features for the new liquidation system of the Maker Protocol.
Single Block Composability
- Decentralized Exchange (DEX) Compatibility - This would allow Keepers to use their liquidity to purchase collateral and instantly cycle it back into DAI through a DEX or DEX aggregator. This method would lower the friction of recycling capital for Keepers and also mitigate the risk inherent with Keepers committing to a bid for some period of time.
- Automatic auction Bidding with DEX Aggregators - It should be possible for open auctions to show up in DEX aggregators, allowing regular users to buy directly from active auctions (if they have the best price available on the market). This function expands the pool of auction participants beyond just Keepers, likely increasing liquidity and resilience for the system.
- Flash Loan Compatibility - Flash loans can be used to augment liquidity by performing atomic arbitrage. Ideally, this means that, for some set of bidding strategies, Keepers would need only provide the gas costs to execute a flash loan. However, this should not exclude Keepers from providing liquidity if they choose to do so. This function could provide a significant advantage as it may alleviate the capital requirements for auction participation and permit Keepers to employ such strategies to mitigate the operational security risk of holding funds in hot wallets.
- Allowing Partial Bids - A Keeper could buy a portion of the collateral in an ongoing auction, even if they lack the capital to purchase the full amount. This functionality would open the door to smaller players to participate in auctions more readily. It also likely simplifies the liquidator contract (Cat), which would no longer need to perform partial liquidations.
- Protection From Low Bids - The new liquidation system should contain logic that prevents Keepers from making bids that are unreasonably far from prevailing market prices.
- Relying Only On Prices From the Oracle Security Module (OSM) - The new liquidation system, like the existing one, should be oracle risk-minimized.
Proposed Solution Design
The Smart Contracts Domain Team believes, given the design considerations above, that Dutch auctions are likely the optimal design solution. Dutch auctions, in which a high starting price is set, and then decreases deterministically over time, can address most of the design considerations discussed above and likely make the Maker Protocol more robust.
Single Block Composability
- Decentralized Exchange (DEX) Compatibility - Since Dutch auctions settle instantly, Keepers could use their liquidity to purchase collateral and instantly cycle it back into DAI through a DEX or DEX aggregator.
- Automatic auction Bidding with DEX Aggregators - Again, since Dutch auctions settle instantly, open auctions can show up in DEX aggregators allowing regular users to buy directly from active auctions.
- Flash Loan Compatibility - The instant settlement of dutch auctions also enables the use of flash loans.
- Allowing Partial Bids - A Dutch auction would permit Keepers to buy a portion of the collateral in an ongoing auction, even if they lack the capital to purchase the full amount.
- Protection From Low Bids - Since Dutch auction prices start high and decrease deterministically, extremely low bids are not generally possible unless sufficient time passes (and auctions could be configured to reset before reaching arbitrarily low prices).
- Relying Only On Prices From the Oracle Security Module (OSM) - A Dutch auction would rely on the OSM to liquidate undercollateralized Vaults and establish an initial price of the auctions.