MIP27: Debt Ceiling Instant Access Module

cmooney · October 7, 2020, 5:03pm

MIP27: Debt Ceiling Instant Access Module

Introduction

Following the Pre-MIP Discussion, this MIP formalises the Maker Improvement Proposal request for a Debt Ceiling Instant Access Module. Since further work has also been done on MIP17 it is worth noting that this MIP does not render MIP17 redundant. It will be for the community to decide at which point they wish to move towards using an Instant Access Module for controling debt ceilings.

Preamble

MIP#: 27
Title: Debt Ceiling Instant Access Module
Author(s):  Smart Contracts Domain Team
Type: Technical
Status: conception
Date Proposed: 2020-10-07
Dependencies: 
Replaces: Weekly governance executive debt ceiling adjustments

Sentence Summary

MIP27 defines the Debt Ceiling Instant Access Module (DC-IAM) allowing any user to adjust the debt ceiling within constraints that are voted on by Governance.

Paragraph Summary

An Instant Access Module contains components to create direct, bounded changes to the Maker Protocol without consensus in DSChief (or DssGov). This MIP introduces 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 to, which will be discussed below.

The parameters and boundaries included herein should be considered examples and will be voted in at the time of implementation. There is an expectation that MIP17 and ongoing community governance experience will help inform the correct risk boundaries and governance parameters.

Motivation

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 explores 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.

Specification

The following checks and variables define the parameters of the DC-IAM and can be set and amended by Governance through an executive vote.

MIP27c1 Definitions

on - A check to see that the ilk is enabled and part of the vat
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 ilk debt ceiling. 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 top is introduced. This value is a calculation based on the actual collateral debt plus the top as long as the final value falls within the maximum debt ceiling allowed (line). If it falls beyond the maximum allowed debt ceiling, then the line itself will be the highest possible value for the new debt ceiling.
DDC - the defensive debt ceiling acts as a minimum floor preventing the debt ceiling from being reduced any lower.
ttl - The minimum time required to wait before it is possible to increase the debt ceiling. Note, the ttl is not required when lowering the debt ceiling.
last - The reference point in time that ttl uses to determine the last time the ceiling was increased.

MIP27c2 Adjusting the Debt Ceiling

The Debt Ceiling Module is independent for each collateral type and will work for any ilk in the vat.
There will be a minimum time interval required to pass before setting a new increase. This is determined by the ttl.
ttl will 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 ilk debt.
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 ttl which 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.

MIP27c3 Example

After enabling this module through an executive vote, any individual with a web3 browser will be able to adjust the debt ceiling per accepted collateral type. 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 will be determined by governance. It would then be up to governance to make changes to the hard limit (via an executive vote) if there was appetite 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.

New DDC

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).

MIP27c4 Defensive Debt Ceiling

In the event of a contracting market as in the above example, the community should ensure that the debt ceiling defensively tracks the contracting Dai supply to minimise excessive exposure. There is a level, called the Defensive Debt Ceiling (DDC) that prevents the Debt Ceiling from being reduced any further. This will be a fixed absolute number per collateral type, determined by Governance and Risk.

MIP27c5 Authority

Any individual with a web3 browser will be able to change the Debt Ceiling as long as the intended changes meet the parameters as voted in by Governance.

MIP27c6 Security

The ttl acts as a pause that prevents any individual from hitting the debt ceiling, increasing it, hitting the debt ceiling and repeating all the way up to the line limit. This function will allow governance to control the velocity at which the actual debt ceiling is able to increase.

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.

MIP27c7 DC-IAM Onboarding of Collateral Types

The onboarding of collateral types into the DC-IAM will require independent executive votes whereby the values described above (MIP27c1 Definitions) will need to be confirmed by Governance. It is expected that the community will want collateral types to have a track record before we hand DC control to the IAM.

MIP27c8 Licensing

AGPL3+

ElProgreso · October 7, 2020, 6:16pm

Holy Batman! Do you ever take a day off @cmooney

Chris, you are a Magician

Planet_X · October 7, 2020, 6:20pm

This is really great!
Instant Access Modules is a sort of do-it-yourself-governance, I can’t wait to try it.

Could you maybe detail this one? I am sure there is a bit more too it.

Derek · October 7, 2020, 7:19pm

Hi Planet_X the thinking here was that anyone with e.g. a MetaMask wallet would be able to connect and if the conditions for a change are allowed (e.g. Dai supply is coming close to hitting the debt ceiling) then they will be able to create a transaction making the DC changes. This would even be possible through etherscan by writing to the contract.

Planet_X · October 7, 2020, 7:27pm

So no MKR or DAI deposit? Fee?

Derek · October 7, 2020, 7:44pm

Ahh, gotcha, it would just be a simple ethereum contract call - very minimal gas fee. No Dai or MKR required.

LongForWisdom · October 12, 2020, 1:11pm

Going to just read through and leave feedback. Super excited about this one! Thanks for taking the time to write up the proposal.

So I’m going to go out on a limb and say that it maybe should. It appears to be a more autonomous version of the same thing. Setting up polls and executives each week takes a reasonable chunk of my time each week, and I know it takes up the smart contracts team’s time as well. If we can minimize the time-cost of governing debt ceilings, that leaves us able to focus on other, more valuable items of work.

From a governance perspective reducing the number of repetitive votes is also a clear win for voters in my eyes.

Can we be more specific here? Technically in the future we may have multiple teams, I can see a path where this becomes confusing down the line.

This field is supposed to MIPs that are being replaced, not just random things. I would just change this to N/A.

If we need a MIP that defines the process to control this/these modules, I suggest we write a MIP specifically with that aim, rather than trying to make MIP17 that MIP. Although it’s related, it wasn’t quite written with MIP27 in mind.

I would actually reverse this as I’ve suggested above. Let’s sign-off the use of DC-IAM’s in principle (in the form of this MIP), then we can craft a MIP that fits the functionality we have available.

Incredibly minor formatting thing. In almost all the other MIPs these are written as MIP27c1: Definitions. (Added colon.)

When you say this is determined by governance, do you mean that the IAM supports both and we can use either interchangably, or that we need to decide once in advance whether we want absolute or relative values for all DC-IAM’s, or that we can decide per ilk?

To clarify, is there one module that controls all ilks or one module per ilk?

Did you mean ‘update’ rather than ‘upgrade’?

Is there planned to be a UI for this module? Or is it thought that this interaction will take place using direct contract interaction on Etherscan?

How do these changes affect the global protocol line value?

I’m not sure I understand the utility of the defensive debt ceiling. Can you maybe elaborate as to why this exists in the MIP?

Does the individual enter new values manually? Or does the system just have an ‘update’ method which calculates everything and requires no parametrized input?

Pretty sure I understand this, but assuming the DC-IAM is proved out, is it possible to activate it in the same executive as a new collateral is onboarded?

Derek · November 4, 2020, 5:11pm

Apologies, I realise the above questions didn’t get answered. In advance of the Smart Contract Team formalising this MIP, I have provided some quick responses below;

Agree, it feels like this MIP will render MIP17 redundant. Note that the additional UI frontend work will however take more time to implement.
Re: author specificity - yes, the Smart Contract Mandated Actors are proposing this enhancement.
Re: percentages or absolute values. This should be updated to an absolute value only. Debt ceiling parameters will be set per ilk. Depending on the frontend design it may be possible to batch DC changes in a single transaction for efficiency through a proxy contract (TBD).
Agree, that the process for changing parameters will need to be a new sub-MIP dependent on the UI frontend designed for this purpose.
There is one module that controls all ilks based on what exists in the vat.
The intention is to build a UI specifically for this module in order to reduce the weekly voting burden. The UI should self calculate the possible change for the user to then action a transaction. Note, no frontend work has been defined yet so this may change.
Individual ilk DC raises will also increase the global line value.
It will be possible to use the DC-IAM for an ilk in the same executive that it is onboarded (because that collateral will then exist in the vat).

mrabino1 · November 4, 2020, 5:21pm

What are the implications of MIP27 with MIP21? I understand why this is needed when we have an unknown number of users that might cause DAI minting. However, it is not clear to me if this is truly needed for Real World Assets or actually how it would impact operational off-chain lending.

thoughts?

Derek · November 4, 2020, 5:56pm

Good question! So, the DC-IAM needs to be authorised per collateral type, therefore, Governance would need to approve it’s use for RWA (for example). Due to the different risk/collateral parameters being proposed in MIP21 I do not think we would want to activate this module for real world assets - at least not initially.

cmooney · November 4, 2020, 7:37pm

I’ve officially moved this MIP from RFC to Formal Submission for the November governance cycle. @charlesstlouis

ElProgreso · November 4, 2020, 7:58pm

Hello Derek–you mention that Anybody can increase/decrease the DC via the IAM without the need of holding/owning MKR/DAI–I would imaging the Team has discussed how an actor could use the DC IAM to trigger a Flash Loan? Was there consideration that perhaps only MKR holders that lock their MKR in the DSChief (or DssGov) should be allow to use/trigger the DC IAM? Just thinking out loud…

cmooney · November 4, 2020, 9:00pm

This is correct. For RWA, governance would leave this module off.

Derek · November 5, 2020, 12:33pm

Hi @ElProgreso , correct, the idea is that anyone can make a transaction as long as the rules for a debt ceiling change are met - namely that the current Dai supply for a collateral type is within a defined range of the debt ceiling but still below the upper limit, and that the time (ttl) to make a change has elaspsed.

Initial discussion did consider limiting the IAM only to those that hold MKR (e.g. using an IOU token to control such functionality), however because of the rules that are in place, such as; time limits preventing immediate subsequent DC increases as well as limits to how much the DC can be increased or decreased, meant that authorising the DC-IAM to operate within these bounds becomes possible without restricting it to MKR holders. It also helps democratise the IAM capability to those that may be vault holders but not necessarily MKR holders - although it is always MKR holders that determine, through Governance the risk parameters that define the system.

With regards to flashloans…hmm, I don’t think they would be relevant here…but let’s keep the idea alive for a bit…so, a standard ethereum transaction is all that is needed to implement a DC change. So let’s say a DC is raised - in the same way as it is today when we raise the DC, there’s nothing stopping any vault from maxing out the limit - for example this is what we saw earlier this year with the Nexo vault that I think maxxed out WBTC. In such a scenario, all we can do is monitor and make sure that the parameters we have in place - amount of the increase, the time to new increase and relevant SF’s and Liq ratios, are sufficient enough for the risk that the protocol is taking on. But I’d be keen to hear if anyone has any thoughts around how flashloans could be of influence here.

Derek · November 30, 2020, 10:11am

Hi everyone, thank you for the positive DC-IAM feedback on the G&R calls, R/C and forum. The overall function of this module remains as initially outlined in the above MIP, however the Smart Contracts Team have renamed one of the contract functions, specifically:

top has been renamed to gap and is defined as an absolute value. It is worth noting that the gap will also function as a minimum debt ceiling. As a result, it is high time for the community to work with the risk team (@Primoz) to determine the following four values;

Which collateral types (ilks) will the DC-IAM support?
What is the maximum debt ceiling (line) allowed per collateral type?
What distance (gap) do we want between existing debt (Dai supply) and the debt ceiling?
What amount of time (ttl) do we want to enforce between debt ceiling changes?

Let’s dive into each of these in a little more detail to provide a reference point from which to begin:

ilk : Which collateral types will be authorised to use the DC-IAM and what will be their initial debt ceilings?

The Smart Contracts Team is comfortable for all collateral types to be authorised to use this module. This statement is made with the awareness that the module is limited to controlling only the debt ceiling within parameters defined by governance. Therefore is the rest of the community comfortable with all collateral types having this capability or do we want to trial-run this with a limited number of ILK’s?

line : What is the maximum debt ceiling allowed per collateral type?

The maximum debt ceiling limit can always be increased or decreased through a governance action. The maximum debt ceiling is a hard limit that prevents any further incremental debt ceiling increases through the module. As an example, this value should be sufficiently high enough to not require adjustment for the following 3-4 months (otherwise it defeats the purpose of having an IAM).

gap : What absolute number should be the distance between the current debt (Dai supply) and the debt ceiling?

The Smart Contracts Team recommends looking at existing Dai mint amounts to ensure that these can be supported within the proposed gap. Governance often observes the creation of large Dai generating vaults which ideally should not be hindered.
It is worth noting that the maximum borrow amount of Dai may be slightly higher in the event that there is an immediate supply decrease which hasn’t yet triggered a debt ceiling decrease.

ttl : What amount of time is required to pass before a new adjustment to the debt ceiling can be made?

The value chosen should require at least one OSM update so the module reflects an accurate market price. For example, a ttl of 2 hours, with a maximum 10m increase, would allow users to increase the debt ceiling by +100m in a single day, which is similar to what we have today when passing an executive vote. Note, the ttl is not required when reducing the debt ceiling.

These values should be agreed upon in the following format for the Smart Contract Mandated Actors to code and implement:

ILK (Collateral Type)	Participate in the DC-IAM (Yes/No)	LINE (Max Debt Ceiling)	GAP(Distance between Debt and Ceiling)	TTL (Time between DC changes)
ETH-A
ETH-B
Etc…

User Interaction:

Initially this contract can be called through etherscan by any user familiar with the contract write capability . In time the expectation is to provide a user interface that visually illustrates the debt ceiling per ILK with the ability to call the contract through the UI.

Timeline:

The intention is to agree upon the above values with the community and mandated Risk Team in time to launch the DC-IAM as part of the December 11th executive.

Aaron_Bartsch · November 30, 2020, 1:39pm

Thanks Derek,

Are you expecting the community to post signal requests to determine these parameters or is the risk team going to propose starting parameters?

Thanks

Primoz · November 30, 2020, 1:52pm

Thanks @Derek. Since we have only this week to discuss this topic and have parameters proposed I would personally prefer trial-run implementation for vault types that will see most benefits using this, especially during the holidays when executive voting will be limited.

Therefore I suggest we implement DC IAM for ETH-A, ETH-B and WBTC-A. Potentially also for YFI-A where DC is maxed out, but we need to agree on higher SF, which as I mentioned in the other forum thread, could go to double digit numbers. Plus, we almost had a single YFI-A vault liquidated last week with 9m debt exposure.

I personally think DC IAM is mostly beneficial for ETH-B vaults, because it helps us protect against OSM attacks.

Also, I think DC IAM can not be very efficient until we decrease GSM delay, currently set to 3 days. The idea is to have a line (max DC) set higher than what current debt ceiling is, but at the same time we need to be able to lower it if something goes wrong. If GSM delay is set to 3 days, maximum debt ceiling could be already reached, unless we have a very low gap or high ttl. But this can become very limiting and efficiency of IAM DC becomes questionable.

Nevertheless, we can still implement it for all collateral types if the community prefers. We spent some time already to calculate max DC figures for each collateral type, which are based on certain estimates of risk tolerance (mostly based on CEX+DEX volumes).

Aaron_Bartsch · November 30, 2020, 2:05pm

Sounds good. Are you planning to present on this in the next G&R call or here? What are the next steps?

Primoz · December 1, 2020, 11:28am

We are planning to post some suggested parameters for these three vault types here very soon. I was only waiting for community if someone thinks we should implement it for all vault types next week.

Primoz · December 2, 2020, 5:58pm

After analyzing parameters needed for IAM DC and right before proposing them here we did another analysis of user behaviour under IAM DC. Unfortunately we found a bug that makes IAM DC very ineffective and limiting if particular actors were to be performing certain actions.

Below is a scenario where an actor could perform a larger repay and consecutive equal amount of mint and in between lower actual DC. Since lowering DC is not limited by ttl it means DC could in theory be maxed out all the time if such actions were to be performed in a timely manner by certain actors.

| ttl = 6 | gap = 25 |             |     |              |      |                                                                  |
|---------|----------|-------------|-----|--------------|------|------------------------------------------------------------------|
|         | activity | actual debt | gap | debt ceiling | line |                                                                  |
| t - 1   | /        |          40 |  25 |           65 |  100 |                                                                  |
| t       | 10 mint  |          50 |  25 |           75 |  100 | debt ceiling is increased, 6 hour ttl time clock starts          |
| t + 1   | 25 repay |          25 |  25 |           50 |  100 | debt ceiling is reduced, no timelock                             |
| t + 1   | 25 mint  |          50 |  25 |           50 |  100 | debt ceiling fully utilized and can not be increased for 5 hours |

I hope @Protocol-Engineering an find a solution to this issue. I was thinking we could have ttl applied also for DC decreases, but I think the same attack could be performed, the only difference is that it can be performed only once ttl time lock is reset.

We can post our analysis on parameters proposed, but I think it doesn’t make much sense until current implementation is fixed. I was also thinking such attack doesn’t really make any economic benefits to anyone so maybe we could still try it out for ETH-B vault type, where benefits of IAM DC are highest due to potential OSM attacks. Note however that in the worst case someone can make ETH-B DC constantly fully utilized. Preferably of course different solution needs to be found.

Feedback welcome, particularly from @Protocol-Engineering as we may have also missed something here.