The purpose of this forum post is to revisit the discussion on how a Debt Ceiling Instant Access Module could work. This work builds upon the thoughts generated in MIP17 and the subsequent community discussions such as the Working Group Call and the 30th July G&R Call, which describes MIP17 as laying the groundwork for a future Instant Access Module (IAM) to help automate such functions.
This post, therefore, illustrates exploratory work done by the Smart Contracts Team for how an IAM could work in the space of debt ceiling adjustments, with particular credit to @galabasquer . To manage community expectations, please be aware that the development of a DC-IAM is secondary in priority to Liquidations new Chief contract work, despite this I think we can generate some good discussion that will help inform the implementation of MIP17 and how it can be developed going forward.
Instant Access Module Introduction
An Instant Access Module contains components to create direct, bounded changes to the Maker Protocol without consensus in the DS-Chief. In the context of this forum post, the idea is to introduce a Debt Ceiling Instant Access Module that permits anyone* to adjust the debt ceiling within constraints that are voted in by Governance. This flexibility introduces concepts such as the minimum time required to wait before it is possible to increase the debt ceiling, as well as the maximum amount that the ceiling can be adjusted via the module, which will be discussed below.
Although not the scope of this post, one can see how direct changes to the Maker protocol could be used to make changes to a whole host of system variables such as the Dai Savings Rate or the Stability Fee, thereby reducing the weekly governance burden that we currently experience - of course for this to be efficient we need to better understand the effect of changes on the overall ecosystem, including edge cases and security risks.
*anyone could literally be any individual signing an Ethereum transaction which would be executed only if the defined rules are met. If we feel this is too liberal, we could explore a solution that while bypassing Chief requires a minimum amount of MKR to act as a bond for a set time period while the system changes are introduced. Refer to the ‘Authority’ section below for more info.
Debt Ceiling Instant Access Module Summary
The Debt Ceiling Instant Access Module decentralises debt ceiling control to the broader community by allowing all stakeholders to control this important risk variable. It helps solve the somewhat frequent problem where the community finds itself having reached the debt ceiling and now needs to wait for an executive vote to pass in order to make further adjustments. The same occurs in reverse when it becomes necessary to lower the debt ceiling in the event there is a reduction in Dai supply.
This capability will be available once the community has a good idea of the logic defined in MIP17 and then once the DC-IAM has been voted in by Governance, after which point, executive votes would not be necessary to adjust the debt ceiling within a predefined upper boundary. An executive vote can however always be used to overrule the behavior of an IAM.
Below outlines the system variables that allow this module to function, and then we look at how these variables are applied to adjust the debt ceiling. In the interest of simplicity, target risk premiums have been omitted from this design, however, once we better understand the relationship between debt ceilings and stability fees, these could also be explored as was initially proposed in MIP17.
The following checks and variables define the parameters of the DC-IAM and can be set and amended by Governance through an executive vote.
on- A check to see that the
ilkis enabled and part of the
line- The maximum debt ceiling possible. This variable is determined by Governance and can only be updated through a governance vote as it prevents the DC-IAM from exceeding an upper limit.
top- The amount that it is possible to adjust the ceiling over the existing
ilkdebt. This can be a percentage or an absolute value, which will be determined by Governance.
lineNew- The new target debt ceiling once the new variable
topis introduced. This calculation is based on the actual collateral debt plus the
topas long as the final value falls within the maximum debt ceiling allowed (
line). If it falls beyond the maximum allowed debt ceiling, then the
lineitself will be the highest possible value for the new debt ceiling.
ttl- The minimum time required to wait before it is possible to increase the debt ceiling. Note, the
ttlis not required when lowering the debt ceiling.
last- The reference point in time that
ttluses to determine the last time the ceiling was increased.
Adjusting the Debt Ceiling
- The Debt Ceiling Module is independent for each collateral type and will work for any
- There will be a minimum time interval required to pass before setting a new increase. This is determined by the
ttlwill consider the OSM upgrade schedule so it takes into consideration the new OSM price before allowing an increase in the debt ceiling.
- Anyone can trigger a transaction to adjust the debt ceiling if supply conditions are met and the required amount of time since the last debt ceiling increase has also been met.
- The debt ceiling can only be increased if the underlying supply is also increasing. The amount of increase possible will always be a single value, known as the
top. This can be defined as an absolute value or a percentage relative to the existing
- If the supply is equal to or lower than the current debt ceiling and trending down, then it will be possible to reduce the debt ceiling - again, using top relative to the supply.
- Note that the reduction of the debt ceiling does not need to check the
ttlwhich is what sets the interval for how often the debt ceiling raise can be implemented. This means that there is no waiting period required for reducing the debt ceiling.
After enabling this module through an executive vote, anyone is able to adjust the debt ceiling. Let’s use the below example values:
- The current supply is 100M for a particular collateral type,
- Max limit is 150M
- % increase is set to 10%
- Once the ttl passes, let’s say the supply has since gone from 100M to 108M, anyone can increase the debt ceiling 10% higher, to 118.8M. [10% * 108M = 10.8M. 10.8M + 108 = 118.8M]
- Once again, after the next ttl, let’s say the supply has gone up to 115M, meaning anyone can at that point increase the debt ceiling to 126.5M. [10% * 115M = 11.5M. 11.5M + 115M = 126.5M]
This process can be repeated until the limit value of 150M is reached, which has been determined by governance. It would then be up to governance to make changes to the hard limit (via an executive vote) if there was a desire to increase this limit.
- If Governance wanted to decrease the debt ceiling due to a reduction in supply, it is possible to do so without waiting on the ttl time. This ensures that the ability to draw be kept tight against supply.
- Let’s say supply is at 115M and the debt ceiling is at 126.5M. If the supply were to decrease to 112M, then the debt ceiling could immediately be reduced to 123.2M in order to retain the 10% buffer that Governance has deemed safe.
- Calculation for the above: when the dai supply is reduced to 112M, the module takes 10% of that value (11.2M) and adds it to the Dai Supply amount (112 +11.2 = 123.2), therefore, the new debt ceiling will be 123.2M. The DC-IAM is always based off of the Dai Supply and either moves up or down 10% (or another value as determined by governance).
- Should we think of this module in the same way as we think about e.g. calling drip when updating the DSR? It could be called by anyone as long as it falls within the time and boundary parameters determined by Governance. Could this be an altruistic bot or an incentivised action? All good topics for debate.
- If for any reason the DC-IAM module is misbehaving (e.g. our ttl time period or upper boundary is too inflexible), it will be possible to bypass it through an executive vote where governance can also vote to skip the delay in the GSM.
- In the event of a contracting market, the community should ensure that the debt ceiling defensively tracks the contracting Dai supply. This value should be informed by Risk. Currently there is no incentivisation for such altruistic/defensive behaviour. It may therefore be relevant to introduce a Defensive Debt Ceiling (DDC), which would be a lower boundary voted in by governance, similar in effect to the upper boundary, whereby the IAM would not be able to lower the debt ceiling below this point.
This pre MIP discussion has restricted its focus on the Debt Ceiling mechanics of an IAM. It is reasonable to assume, as was explored in MIP17 that a future design will build on this to include a risk premium element. Initial thinking is that the greater the concentration of an asset in the governance portfolio, the higher the risk premium should be to take into account exposure and inherent risk. This will require further analysis to better understand the relationship between the debt ceiling and the risk premium and their respective growth rates.
This forum post details initial thoughts behind a debt ceiling instant access module that I hope will give the audience an understanding of what could be possible while also helping to inform the previously discussed, unratified MIP17. Following community discussion, I am hopeful we can revisit documenting a formal MIP and a followup executive vote.