Here are some thoughts on how we came up with the system launch parameters. Keep in mind, a few of these parameters are set a certain way specifically for migration, and others can be optimized based on further research. For now, these are based on what we believe are logical and sensible starting defaults.
Global Stability Fee
This parameter applies a base stability fee to all collateral types. It’s intended to easily pass on the cost of the DSR to all collateral types without regard to the unique risks of individual collateral types. At launch, however, this parameter needs to be set to 0 in order for the migration contract to avoid accruing stability fees. After migration, where Sai is no longer a special collateral type, governance can begin to use this parameter as needed.
Global Debt Ceiling
The global debt ceiling is the total amount of Dai that can be generated, regardless of individual debt ceilings. For example, three collateral assets may be assigned a debt ceiling of 50 million each, but a global debt ceiling may only be set to 100 million. This would restrict all three collateral assets from being simultaneously at their maximum debt ceiling. This feature might be useful in certain scenarios going forward. For now, however, we suggest a global debt ceiling equal to the sum of the individual collateral types.
The surplus buffer is a Dai reserve pool, which is the minimum amount of excess Dai accrued from stability fees above the Dai minted for DSR accruals. Surplus auctions won’t be triggered until the lot size above this threshold has been reached. In general, this buffer might become a critical piece of risk management, as Dai reserves can be very important for covering undercollateralized Vaults. Additionally, future funding for oracles or risk teams may be paid out of this reserve. However, there are certain game theoretic concerns with regard to emergency shutdown that limit the effectiveness of this buffer. For now, we suggest a buffer of 500,000 Dai to protect against some moderate losses.
Debt Auction Delay
When a Vault is bitten, its debt immediately goes to the bad debt accounting line, and can only be erased with the proceeds of the collateral auction. Therefore, in order to avoid triggering an unnecessary debt auction whereby MKR is printed and sold to recover a net deficit of Dai in the Maker Protocol, there should reasonably be a delay that allows the collateral auction to complete. Large Vaults may take hours to finish, some potentially more than 1 day. Therefore, we have selected a two day delay for the debt auctions to begin after a Vault has been bitten.
Governance Security Module Delay
The Governance Security Module (GSM) is a delay on any governance changes. This allows the community to intervene in case of a governance attack. While the GSM is good for governance attacks in a mature system, it potentially worsens technical problems, as the community would be less able to quickly deploy bug fixes should there by a required delay in the GSM. As a result, we are recommending the GSM start with a value of 0, to be increased post migration.
Emergency Shutdown Module Delay
The Emergency Shutdown Module (ESM) Delay is the amount of time after which users may claim collateral with their Dai. It is logical to allow any outstanding auctions to finish first, and so therefore we have selected 73 hours (3 days plus 1 hour) for the ESM delay.
Emergency Shutdown Threshold
This is the minimum amount of MKR needed to trigger emergency shutdown. 50,000 has been selected as a number that is attainable in a short period of time. However, as the distribution of MKR changes over time, this number may change. In general, we leave the game theoretic discussions surrounding this threshold for another discussion.
Oracle Security Module Delay
The Oracle Security Module (OSM) Delay represents the time interval between a price being pushed to the OSM and that price being used in the Maker Protocol. It serves as a layer of defense to prevent Oracle attacks from affecting the system. If an erroneous or malicious price is pushed to the OSM, then Emergency Oracles have the delay period to freeze the OSM to protect the system.
The OSM Delay is set to one hour. This value was chosen as an equilibrium between giving the Emergency Oracles sufficient time to freeze the OSM and enabling the Maker Protocol to react to changes in collateral prices to minimize potential losses.
Oracle Feed Quorum
The quorum is the minimum number of Feeds needed to submit a new price to the Medianizer. Due to gas optimizations in the Medianizer, the Oracle Feed Quorum must be an odd integer. The quorum can be derived by evaluating two possible Oracle attack vectors. The first attack is classified as the Oracle Price Manipulation Attack, in which a set of malicious Feeds submit any price for any collateral asset to the Medianizer. This attack requires a floor ((quorum / 2 + 1)) of malicious Feeds to be successful. The second attack is called the Oracle Censorship Attack. In this attack, enough Feeds are either malicious or offline and cease submitting prices such that achieving quorum is impossible. The Oracle Censorship Attack requires (totalFeeds - quorum - 1) to be successful.
Out of a total of twenty Feeds, a quorum of thirteen was derived by contrasting the number of Feeds needed to executive each attack. This quorum requires seven malicious Feeds to execute an Oracle Price Manipulation Attack and eight malicious or offline Feeds to execute an Oracle Censorship Attack. A quorum of fifteen was also considered which would make the Oracle Manipulation Attack require eight Feeds and an Oracle Censorship Attack require six Feeds. Ultimately a quorum of thirteen is preferred due to the likelihood of one or more Feeds being offline at any given time drastically reducing the threshold required to successfully mount an Oracle Censorship Attack.
The dust limit is the minimum amount of Dai that can be drawn from a Vault. Due to a potential spam attack, this number should be set relatively high at first, although this can be safely lowered soon after launch. Essentially, if a large number of Vaults are all opened with a tiny amount of Dai drawn, then these Vaults become too low-value for them to be bitten by keepers. As a result, the system may start to become effectively undercollateralized. We suggest a starting parameter of 20, to be reduced in the weeks following launch.