MIP27: Debt Ceiling Instant Access Module

If I understand correctly,
At the end of the day, once the flash loan risk is removed, we currently have a same risk. If I recall it has already happen with USDC or ETH when we had 0%. someone filled up the vault to push governance to increase then remove the loan.
Except that with the MIP27 it is 5h instead of one week.

The other option, but I guess you have already thought about it and there is an issue somewhere that I can’t see.

We save the previous line and allow people to go back to it with out ttl. If it is with in the previous ttl.

Good stuff Mooney! Took me a bit to fully understand it–I have read about griefing on Minecraft and insufficient gas griefing, but never about a main dish of collateral shortfall/DC disruption/griefing with a side dish of Flash Loans haha

Thank you to @BrianMcMakerDAO for having the eye of the Tiger and for Primoz for always having our best interest at heart–and of course to @galabasquer for his hard work and dedication.

Hey @yaronvel wanted to circle you into this thread and ask if you can help the community think of any other attacks that would motivate a malicious vaultholder to increase line with other collateral types outside of ETH, such as WBTC-A and perhaps the proposed/talked about WBTC-B collateral type? Your thoughts would be helpful!

1 Like

I am not sure i fully understand, but wouldn’t an attacker without extra capital would be able to perform same attack simply by temporarily decreasing his position?

E.g., I withdraw the DAI to supply liquidity to uniswap, and now I use the ETH/DAI LP as a collateral to borrow more dai, and then i repay some of my DAI debt.
Or I withdraw DAI to supply liquidity to curvfi, and now i use it as a collateral at cream to borrow DAI.
Or even simpler, just take my current ETH collateral to a minimum, put it in another vault, and mint DAI.

But more generally why only capital-less (aka flash-loan) attack is the issue?
It seems only whales could apply it anw, so assuming they have few millions on the side, on alternatively that they could decrease their debt by few millions using their extra collateral, is not unlikely.

In WBTC-A (and other mintable coins, like USDC), one motivation to increase line is when the admin key is being compromised (in WBTC it is technically more than just admin key, but same idea), and infinite minting occur. The more DAI one could mint wrt the now 0 value WBTC, the more profitable your attack was.

Even in the absence malicious intents, i think it is always the interest of WBTC (but also YFI etc) whales to increase the line, so their coins would have more usage, and they could e.g., mint DAI to get some yield on it in curvfi or pickle.

For the proposed WBTC-B, the backstop has an incentive to have biggest line as possible, as over time it will bring more users. But this is solvable by setting the absolute cap to a reasonable value.

1 Like

4 posts were split to a new topic: ETH-B DC-IAM: Initial Parameters

Oh, if it wasn’t clear from my original post, a whale can still grief the DC. This is why I wanted the community to think of strong reasons to do so, and if it’s obvious this would become a problem from whales.

Removing the ability for anyone to grief the DC, we believe, lowers the risk of this happening to a point where the protocol can benefit from a more automated DC. That is, the risks outweigh the benefits. To test this out, we suggested just putting it on ETH-B to start, as the automated increases would prove useful, and if a whale did grief the DC, ETH-A still exists as an escape hatch.

1 Like

Also it states that the fix only mitigates a flash loan. but it seems that you have to be a whale to begin with ($5m net position) to execute the attack. So it is not really about flash loan right?

That said, personally I don’t see a way where one can directly profit from it.


It’s possible that in a Dai squeeze a whale could attempt to corner the market on Dai, driving up the price the price of Dai and profiting from that while retaining the exclusive ability to create it. That said, with the initial proposal to use this only on ETH-B I’m not entirely sure that this is undesirable from a system security perspective. Since ETH-B has the lowest collateralization ratio this “attack” could protect the system by encouraging the use of other vault types with higher collateralization ratios and fees (like USDC-B), increasing the overall system collateralization in a market downturn.

1 Like

Is this fixable just by adding a cooldown for any changes? Adding the flash-loan guard gives one block for others to interrupt the cycle. What if you just have a 1 hour delay that triggers after any change (up or down) in addition to the 12 hour ttl on increases?

That way you can reduce the debt ceiling rapidly during downturns, but you wouldn’t be able to decrease the ceiling until 1 hour after you increased it.

yeah, so reducing the supply or just an attack by a competitor that want more people to borrow DAI on his platform.
But hard to put $ value to it.
That said, other than simplicity, what other advantages are there in making the line going down quickly, as opposed to the line increasing which is more gradual?

Is it to always to put a tight upper bound on the profits from an oracle attack?

We’d discussed this, but the shorter delay provides mitigation against oracle attacks in a rapid market downturn or against an oracle attack, by quickly lowering the collateral line we put an upper limit the ability of users to print unbacked Dai before the OSM update.

1 Like

I think we want to limit DC exposure to rapid price crashes where the delta of market price is much lower than the oracle price. This can happen with an oracle attack or otherwise (BT). Having no ttl on lowering is a huge advantage in this case. It remains to be seen if this advantage outweighs the possibility a whale griefs the DC-IAM.

1 Like

This was one of the backup plans. It still means the grief can happen after that cooldown period, but would create a window where the DC could not be lowered. This window, however, needs to be shorter than OSM updates to limit DC exposure in a crash. If we see this grief attack being a problem in the future, this is the lowest hanging fruit for a solution, but we loose some of the security functionality of capping the ceiling.

1 Like

Human-managed updates of the collateral line could be regarded as having a large gap of often 10-50% of the previous line and ttl on the order of weeks. A sufficiently well financed “attacker” could perform a similar griefing attack on the current non-automated, human-managed system. As soon as the line is set through an executive, the attacker could mint sufficient DAI to reach the line, blocking other vaults from minting. The attacker could even continue to mint more DAI to compensate for other vaults paying down their DAI debt to keep the total DAI minted at line. This situation could be maintained until a few days before the community is to decide to raise the line, at which point the attacker would pay back the DAI and disappear. Suddenly, the community will note DAI generation is far below the debt ceiling and may keep the line unchanged or maybe even lower it.
So maybe the dss-auto-line griefing attack is not so severe given that the current-human managed line is also theoretically vulnerable to a similar attack.


I am bringing up this MIP, to check if anyone has an idea about a fix to mitigate this issue?

1 Like

Hi there,

I can’t see where the git repo is for this MIPs.
Any idea where I can clone the repo?

Edit : Ok found it.

@alexis In view of my reply above (MIP27: Debt Ceiling Instant Access Module), why do you think we need to defend against this attack?

It is actually different as the line can’t go down. Or at least an external user can increase and decrease the line, only governance can do it.

@alexis Yeah, but my point is that manually adjusting the debt ceiling is subject to the same vulnerability. Whether we use MIP27 or manual adjustment, it doesn’t matter.

Sorry, my comments are actually not relevant.
I removed them as they can make people confused.

Just realized that there is a governance vote on it.

My point was to make the governance vote happen as we reach again the ceiling, well too late it is already there.

To be honest I don’t believe this issue is significant and can be mitigated by setting back the line to 0 and let the governance taking back control on it.

The code is on makerdao GitHub.