MIP27: Debt Ceiling Instant Access Module

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


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

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.


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.


Does this mean that MIP27 can’t be deployed until a new implementation is developed to work around this problem? Where do we go from here?

1 Like

dss-auto-line griefing attack

The current implementation of the dss-auto-line contains a potential griefing vulnerability.

The essential function of the auto-line is to allow public users to increase or decrease a collateral line value by some amount gap, which results in a new line value that is the existing debt balance plus the gap. The line will not increase if the last increase happened less than ttl seconds ago. The line will decrease regardless of how many seconds have elapsed since the last change.


The motivation for adding the delay between increases is to mitigate the risk that the price of a collateral is read higher than the current market price.

In the worst case, the oracle price is higher than market price by more than the collateralization ratio buffer, which would allow one to fill a Vault and generate the maximum amount of Dai against the collateral, thus causing the Vault to be under 100% CR in the next oracle update. If the ttl is too short, anyone could increase the line multiple times before the oracle price matches the market price, which would cause the protocol to take on excess amounts of bad debt. Mitigating against this risk is the reason we have debt ceilings in the first place, and also the reason the ttl should not be too short.

Decreasing the debt ceiling carries no such risk, and is in fact desirable if the oracle price for an asset is considerably higher than the market price. For this reason, there is no ttl before decreasing the debt. It’s this lack of a ttl before decreasing the debt that creates the potential for a griefing attack.

This griefing attack would allow a user with a large vault to prevent the line from increasing after the ttl. There could be a financial incentive to perform this attack in a Dai liquidity crunch, which would allow the vaultholder to corner the Dai market and prevent supply over a critical period. While the protocol has, and will create more, Vaults that are available in a liquidity crunch, it’s still worth considering this attack vector for an asset.

Hypothetical scenario is as follows

  • auto-line is configured with a gap of 5,000,000 and a ttl of 1 hour.
  • malicious vaultholder has $10,000,000 (or more) worth of collateral in WBTC-A and 5,000,000 Dai in debt.
  • WBTC-A line is 160,000,000, WBTC-A total debt is 160,000,000
  • malicious vaultholder calls AutoLine.exec("WBTC-A") which increases line to 165,000,000
  • malicious vaultholder flash borrows 5,000,000 Dai and repays all or a portion of their debt. Total debt is now 155,000,000
  • malicious vaultholder immediately calls AutoLine.exec("WBTC-A") which decreases line to starting value of 160,000,000
  • malicious vaultholder generates 5,000,000 Dai and repays flash loan
  • WBTC-A line value remains at 160,000,000 for the next hour
  • legitimate vaultholder is unable to generate more Dai for the remaining ttl.
  • This problem is compounded if malicious vaultholder repeats the attack hourly.

Mitigation considerations

  • A shorter ttl would make this attack more operationally expensive, but it also reduces the effectiveness against oracle attacks.
  • A larger gap would require an actor with more resources, however this sort of assumption might not work in a world of flash loans.
  • Another ttl for DC decreases. This would prevent us from being able to cap the DC to gap if the market price was lower than the oracle price, and doesn’t prevent the griefing attack, it just pushes it to the end of the new ttl period.

Actions Taken

  • We’ve removed the ability for flash loans to be used to execute this attack here.


The smart contracts domain team as limited the griefing attack to actors with extremely large positions. We believe this reduces the risk of griefing the debt ceiling significantly, enough that the other benefits of this module may be realized. Nevertheless, we suggest deploying this with just ETH-B for now. This allows domain teams and governance to get used to the functionality of the module, and if the griefing attack proves to be a problem, ETH-A is always available for additional debt.

Future Notes

Some future notes about when we consider this module for other collateral types.

  • By removing the flash loan capability in conjunction with this module, it would mean an attacker would have to have the capital to fill the gap in order to execute a griefing attack. Under the mitigation section, we discussed making the gap larger in order to make this attack less available.
  • Make sure certain collateral types like USDC-B, or perhaps those managed by any future implementation of a PSM are not managed by this module.

NOTE: While we think the risk is low, it would still be helpful if the community could think about various motivations for this attack, other than those mentioned above. What would an attacker gain by griefing one, many, or all, of the collaterals that use this module?


@brianmcmichael for the initial discovery and writeup of this attack.
@Primoz et al. for discovering this independently in a risk review. Great work!
@galabasquer implementing the DC IAM, and the flash loan mitigation.


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 @brianmcmichael 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 lose 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.