Total protocol utilization rate above 100% in some dates?

Hi there!

I’m looking some hisotrical data of loans vs deposits. Some days in july, I’m seeing a rate that is above 100%. How is this possible? Anything I’m missing here?

Thank you!

Sounds like those few days when we couldn’t mint any more DAI because we were over total utilization. Basically because we set a few vaults to 0 Debt Ceiling to prevent more minting from them (USDC-A being the main culprit), the sum of the total debt ceilings was less than the total DAI following some big mints and a decrease in some other DC’s through our Debt Ceiling Instant Access Module (a module that allows anyone to call a function that will return the overall DC to it’s Target Available Debt amount).

So basically due to the artificially low total debt ceiling, combined with stability fees being generated and automatic decreases in some debt ceilings we ended up with more DAI than our total debt ceiling for a few days.

Hey Payton, thanks for this! Appreciate it.

I’m not 100% familiarized with the Maker mechanics (doing some further reading there at the moment), but if I understand correctly:

-Protocol was close or at total utilization (in theory it should never be above, no? As that would cause a liquidation event that avoids it?)
-Why did you have to set vaults to 0 debt ceiling? Shouldn’t this mechanism happen automatically?
-So, you artificially set it lower, resulting in a ratio that shows that there is less collateral than there is, but at the same time DAI was still being minted. My question here again: How? Shouldn’t there have been liquidation events to prevent this?

Is this common? Seeing it only happened in july last year

appreciate it!

I’m not actually 100% sure this event is what you’re referring to. It might help if you could share the data you’re looking at. That might make it easier to explain what’s going on. Only realized that after I’d written the below though, so here it is anyway

I think we’re confusing a few different mechanics of the Maker Protocol here.

The Global Debt Ceiling is the parameter that caused the issue in July, this has nothing to do with the collateralization ratio, liquidation, or anything to do with DAI backing. This parameter just limits the maximum amount of DAI that can be minted by users of the protocol - it can be set to any value. Under normal circumstances, it is always higher than the current amount of DAI minted.

What we did previously was to set the Global Debt Ceiling to the sum of all the individual debt ceilings of each vault-type. So ETH-A + ETH-B + WBTC-A, etc. However, this caused a problem when we set some of the vault type’s debt ceilings to zero when they still had outstanding debt - bit of an oversight on our part, but largely harmless. Basically some of the inputs to the SUMOF function were negative, which meant that the total was not as high as it should have been. This in turn led us to hit the Global Debt Ceiling, and prevented DAI being minted from any vaults until we’d fixed the problem.

The total DAI outstanding can still increase when a debt ceiling (global or vault-type specific) is hit, because the accumulation of fees continues, and these fees are gathered via adding to the debt of the vault.

Yes, in theory we should never hit the Global Debt Ceiling (but only because it’s a horrible UX because no one can borrow DAI, not because it makes DAI unbacked.) But no, this doesn’t cause liquidation events, as described above, these are separate mechanisms.

Maker Goverance does this when we want to retire a vault-type. For example USDC-A which was superceded by PSM-USDC-A. It can’t be automatic because it’s an intentional action.

Yeah, this question reflects a misunderstanding of the system. Setting debt ceilings has no bearing on the collateral ratio or backing of DAI. If stability fees push a vault over the line into liquidation, then it is just liquidated. If the price of a collateral asset decreases, it might push a vault into liquidation. But yeah, not the debt ceiling.

Nope, it was an oversight that was obvious in retrospect. Very unlikely to reoccur now that it’s on everyone’s radar.

Hey there! Thanks for the thorough explanations; allow me to let them sink in before further inquiring.

For reference, the data is coming from here: Dune Analytics

Maybe it could also be an issue that its outdated and not capturing all the deposit contracts in the platform?