Debt Ceiling Instant Access Module: Pre-MIP Discussion

Hi all,

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.

DC-IAM Variables

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 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. 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 calculation is 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.
  • 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.

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.


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.

Future Considerations

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.


Do we actually need this? It seems like these modules could just be replaced as needed when a new version is implemented. Isn’t it just a matter of giving permissions to the IAM contract and revoking them when we want to replace it with a new contract?

Yes, exactly, modules could be replaced as needed with an executive vote. I’ll remove that statement as it is incorrect.

(My reason for including it was a bit beyond the scope of this post, so being more specific, the thinking here was that ideally anyone should be able to call for a DC increase/decrease, but in the instance that the community thinks that’s too liberal, and that users should instead put up a bond/stake, we’d need to manage any sort of stake/slash function in the event of malicious/spammy/disruptive activity. If this is beyond the IAM, then such a module could also be whitelisted to shutdown the DC-IAM with a minimum amount of MKR - although if our upper/lower boundaries are correctly set this would be unnecessary).

Anyway, for now we should probably focus on the IAM rules for raising/decreasing the DC…and then work on the authority piece - perhaps as a v2. So, the values we will need to come up with for each collateral type will be the following, starting with ETH-A and BAT-A:

Collateral line(Max DC) ttl (Wait Time) top (Adjustment Value)

I find the naming conventions for top and lineNew to be confusing. since lineNew is not actually a change in the line variable can we consider changing the names of these variables? Perhaps top could be room or delta or something, as this represents the difference between the current dai supply and possible target debt ceiling after IAM adjustment. Perhaps lineNew could be changed then to top or roof or something, so that it is clear that it is semantically distinct from line.

It is also a little unclear to me how the currently named top variable is used when lowering the debt ceiling. Does this now represent the lowest value the new debt ceiling can be set to? This seems reasonable since there would be an upper and lower bound on how much the debt ceiling can change during a single IAM adjustment.

1 Like

Hi @befitsandpiper , I like your naming conventions, in particular ‘roof’. Let me get with the smart contracts team and review, thanks!

Correct, if the supply were to reduce, then the top would be used to lower the new upper boundary (your roof). (I should include these naming conventions against my examples)

1 Like

How is this IAM different than what we already have with voting for DC increases since you have to vote for a max anyways? What are the benefits of this implementation over the current system? Thanks in advance.

lineNew is actually an internal calculation variable. So not part of the storage layout, then nor something that governance will set up. I think it would be better to take it away from the description to avoid confusion.

1 Like

It should allow to set the max ceilings higher than the current debt ceilings.
One of the functions of the debt ceilings is to protect against the osm delay attack, which can happen if there is a hard crash of a collateral market price. Someone could full-fill the debt ceiling at that moment generating DAI below the 100% ratio (against the actual market price).
With this module, that specific problem would be mitigated at certain extent, as the debt ceiling would be always tight to the total supply.


Are we talking since the last increase or the last ttl? In the later case you can be stuck at the line if you miss a ttl.

Meaning disable it? Or something else?

MIP17 was more specific on top being an absolute value at the beginning and a percentage at some point. I liked the idea, not sure if that can be done here.

Anyway, good job.

Completely accurate.

I also want to add for aaron. The whole point of this is we already have a decent idea of how the DCs should be managed what we don’t have is an automated mechanic to do that management. A clear goal here is to make it so that governance only needs to change the DC maximum and DC minimum as well as DC rate of change say once every few months vs. every bloody week.

Frankly once we have the above MIP DC_IAM I’d also like to see an EPC take on the role of being the one to manage coming up with proposed DC changes, or DC IAM changes and pushing them through governance.

So one of the things I am back to is revisiting onboarding EPCs defining responsibilities and authorities. Let’s put some of this governance micromanagement stuff into EPC hands so we can have people who have vested interests in making their work ‘more efficient’ work toward making ‘all of our work’ in governance ‘more efficient’.

Hi SebVentures, I was referring to there being a minimum interval required to pass before setting a new increase i.e. for example if the ttl is a duration of 12 hours, then a subsequent debt ceiling increase would not be possible until this period of time has elapsed.

Similarly, yes, an executive vote could always be submitted through Governance to disable anything introduced by the IAM.


This is the piece I was missing. It wasn’t clear where the delay was to stop someone from hitting the current DC, raising it, and then hitting it again etc, essentially doing the OSM attack with a few more steps. If there is an algorithmic delay thats perfect.