[Signal Request] Rolling out the Debt Ceiling Instant Access Module (DC-IAM)


At the end of November, we saw MIP27 (The Debt Ceiling Instant Access Module) pass successfully through the monthly governance cycle. Since then it has been implemented and activated for the ETH-B vault-type, and has worked as expected as part of the Maker Protocol.

This signal request seeks to gain a mandate for rolling out the DC-IAM to new and existing collateral types where the mandated actors feel that it makes sense to do so. Smart Contracts feel that the benefits outweigh the risks, and this opinion is shared by Risk and the other mandated actors. While the previously mentioned griefing exploit is possible, we feel that it is low liklihood, low severity, and easily mitigated should it occur.


Details on the benefits of the DC-IAM can be found in MIP27, but briefly, it allows:

  • Automatic management of Debt Ceilings such that governance can spend less time manually adjusting ceilings to keep the available debt low.
  • Protection outside of the GSM-Delay in the event of a severe market downturn.

Important Note

@Risk wishes to make it clear that more widely using the DC-IAM does not mean that we should just ‘yolo’ all the debt ceilings up by very large amounts given the new functionality.

Risk still needs to be managed actively, and in general increases as the amount of collateral locked in the Maker Protocol increases. This may lead to @Risk proposing higher Stability Fee values for vault-types that balloon in size.

Next Steps

Should this signal request be successful, an on-chain poll will be had to confirm that MKR Token Holders support the wider roll-out. From that point, risk evaluations will also include risk parameters for the ttl and gap parameters within the DC-IAM.

Implementations for the existing collateral types will be added over the next few months, according to the Risk team’s availability, with on-chain polls to confirm the new risk parameters on a per-collateral basis. An initial set of parameters was provided here, but these may change before implementation.

The MakerDAO Mandated Actors

Should we roll out DC-IAM Implementation to current and future vault-types?
  • Yes
  • No
  • Abstain

0 voters

This poll will be open for at least 5 days, until Friday 15th January. It may be extended until Thursday 21st January if I don’t feel there has been enough participation or if the outcome is contentious after 5 days.


I really wish there was an option here for a rolled out approach… (with ETH-A being last)

1 Like

The signal is proposing a rolled out approach.


gotcha… any clarity RE the sequence?

in my eyes, starting at the smallest amount of debt outstanding and working our way larger and larger each week makes sense.

Ain’t that :point_up: the truth. Lately it feels as we all think ETH & MKR will go straight up to 10,000 without any downside risk. Stay focus Y’all.

1 Like

Thanks for the writeup. I have a few questions before voting.

(1) Do you know if it’s possible for a borrower, assuming the DC is at maximum and ttl is met, to raise the DC and borrow Dai in the same transaction? Wouldn’t this mitigate the griefing attack?

(2) This is more of a general question, but does the DC-IAM offer us significant protection against OSM delay attacks? Is it safe to say that if ttl is at least 1hr, it would offer total protection against OSM delay attacks?

(3) Would it make sense to avoid deploying this feature on short-term stablecoin facilities like USDC-B in order to mitigate the potential impact of a griefing exploit?

EDIT: I believe that the ability to decrease the debt ceiling with no ttl offers some protection against OSM delay attacks, but I could use an explanation to understand if it offers total or partial protection (or none at all).


I think @cmooney and / or @Primoz are probably better suited to answering these than me, but I’ll have a go:

  1. I don’t think there is anything stopping a flashloan in which someone raises and mints in the same transaction.
  2. I think it offers us some (in that the severity is limited.) But I don’t think it’s anywhere near total. The DC-IAM only changes the ceiling to the defined gap. So you’re exposed up to a maximum of gap in terms of the OSM delay attack.
  3. Not sure.
1 Like

I’d like to get some more participation here before wrapping this up. Please consider voting if you haven’t already, otherwise I’ll extend this to end on the 21st.

Given the outcome so heavily favouring ‘Yes’ I’m happy to end this today and put it up for vote on-chain on Monday.