backstop-syndicate / dai-backstop-syndicate Goto Github PK

View Code? Open in Web Editor NEW

This project forked from dharma-eng/dai-backstop-syndicate

29.0 3.0 10.0 489 KB

A pooled liquidity contract for participating in the upcoming MKR auction at a "backstop" price of 1 MKR per 100 Dai.

License: Creative Commons Zero v1.0 Universal

Solidity 23.56% JavaScript 0.45% TypeScript 75.99%

dai-backstop-syndicate's Introduction

Backstop Syndicate for MakerDAO

Abstract

A Community Effort to Ensure a Successful Auction of MKR

Context

On Thursday, 12 March, the price of ETH fell precipitously. The price decline caused many vaults in the Multi-Collateral Dai system to become undercollateralized. Many of these undercollateralized loans were liquidated as expected. However, due to a combination of market panic, network congestion, an issue with the price oracle, and attention deficits, some of the vaults were liquidated in exchange for zero DAI. As a result, the Multi-Collateral Dai system currently has a negative surplus. To eliminate this negative surplus, MakerDAO plans to sell MKR tokens in exchange for DAI in a real-time auction to begin on Thursday 19 March.

Proposal

We have established a pooled auction contract that gives syndicate participants a way to participate in the auction process should the price of MKR (denominated in Dai) fall to 100 DAI / MKR. Anyone can trigger an auction using pooled funds at the given price once the auctions begin, and all participants in the pool will then be able to redeem the tokens they minted by supplying Dai for the equivalent Dai / MKR blend held by the pool.

This contract is not designed to provide liquidity for liquidations during flaps (exchanging MKR for DAI the other direction) or flips (exchanging DAI for a vault's collateral). This contract is designed to signal community support for MKR and act as a buyer of last resort during the upcoming MKR auction.

Technical Implementation

The DaiBackstopSyndicate smart contract allows anyone to indicate support for the backstop by depositing Dai with the enlist function. This mints an ERC20 token called "DBSv1-100" to represent the share of pooled funds owned by the depositor. Anyone is free to enlist to the syndicate until the pool performs the first bid. This first bid is triggered automatically once MKR auctions reach a price point below 100 DAI/MKR. The syndicate will participate in all auctions until the Dai pool is exhausted. A holder of the ERC20 "DBSv1-100" pool token can call defect at anytime to withdraw a proportional amount of the pool's remaining Dai and MKR. There is also a single function, controlled by an owner, called ceaseFire that halts all new auctions and deposits (withdrawals are of course never "halted", though you may not be able to withdraw if the Dai is currently being used for an auction).

Deployed Contract

backstopsyndicate.eth => 0x00000000357646e36Fe575885Bb3e1A0772E64Cc (Dai Backstop Syndicate v3-100)

Group Chat

Acknowledgements

Thank you to the following community members for contributions to this tool.

dai-backstop-syndicate's People

Contributors

Stargazers

Watchers

Forkers

sambacha phabc defiboy brianmcmichael cgewecke metacartel 8001800 herman-rogers metatrust-benchmark-repo-org

dai-backstop-syndicate's Issues

Consider adding an upper limit to number of active auction sets.

The OpenZeppelin EnumerableSet is used here for maintaining the list of auctionsets and includes a warning against using enumerate() on large data sets.

I haven't benchmarked the gas usage of this contract yet but enumerate() is called in getActiveAuctions() but critically in _getActiveAuctionVatDaiTotal() which is relied upon in many locations, including defect(), getDefectAmount(), getDaiBalance(), and getDaiBalanceForAuctions()

The _getActiveAuctionVatDaiTotal() function calls enumerate() on the set at line 350 and then makes another complete loop across the set at 354.
This function will end up being quite expensive due to the consecutive loops, mloads, and safemath operations.

Starting 3/19 there will be approximately 50 auctions starting in quick succession, followed by another 50 or so in the following days. I'm concerned that adding too many auctions to this set will cause the _getActiveAuctionVatDaiTotal() function to begin failing due to gas limitations and start preventing other functionality.

At this point the safest solution might be to add a check in the EnumerableSet's add() function that sets a maximum number of auctions that can safely be maintained at one time. I have not benchmarked the gas usage of this function yet, however, and so I do not yet know what the safe number of auctions might be.