[Urgent Executive] ETH-A, USDC-A and PSM-USDC-A DC increase

This is not a signal request. It goes straight to executive using @LongForWisdom governance facilitator prerogatives.


Is there any desire to include a decrease of the TUSD Debt Ceiling, given your second point?

1 Like

It seems to be the community wish according to the recent poll. Nevertheless, this issue is there for some time now and there is no reason to address that directly. The USDC DC increase will put us in the same situation as before the ETH price rise. For TUSD-A, the usual process will take place.

1 Like

If this is true why are we increasing both?


Ok but why 30M if Governance agreed with 500M ?
What about something in between like 100/150M?
I feel like 30M will be consumed very quickly.

1 Like

Two reasons:

  • @Primoz is the only risk mandated actor currently and he decided to propose only 3M. While we have a bit of evidence that the PSM work, it’s still new and started to be used a few days ago (yesterday?). After discussion with @hexonaut we decided to propose 30M to find a balance between the benefits of the PSM and any PSM risk.
  • What really matters for an urgent executive is to pass (quickly). A failed executive is useless at solving the underlying issues. We don’t have evidence that the PSM executive was easy to pass (it has barely the hat currently).

This is from MIP24 regarding the Urgent Response Procedure though there may be something newer.


It will probably be consumed quickly but there’s a feeling that a vote for going immediately too 500M would be less likely to pass. It also makes sense from a risk perspective to only gradually increase the bounty associated with a possible security flaw in the PSM (highly unlikely but we’re trying to straddle the line between moving fast and being safe).

So MIP24 represents the path that the community can take to propose an urgent response to something. Additionally, we’ve empowered the mandated actors to also push urgent proposals in the event that they believe there is a clear need for them (such as us hitting the ceilings today.)

Yes this is fair. 30M was chosen as a compromise between those that want to see it increased rapidly, and those that are still concerned about the new code.

I appreciate that some people are unhappy about the proposal, or the process it went through. The best answer I can really give to that is that if we’d done otherwise, or delayed for 24 hours to have a poll then a different set of people would be unhappy about a different set of parameters or that we weren’t reacting quickly to the market environment.

I really think this sort of process represents the best of both worlds. We have mandated actors that are empowered to create proposals quickly in the event that an urgent change is deemed to be of interest to governance. Additionally, governance can trigger an urgent response through the process laid out in MIP24. In times where there is no urgency, governance is able to fine-tune the contents of executives via off-chain and on-chain polls and the mandated actors don’t propose things unilaterally.

In this case the PSM complicates matters because the Maker Foundation can’t touch it. Primoz and Wil being unavailable also complicated things. However in the absence of those people, Sam and Seb are the closest we have to Smart Contracts and Risk domain actors.


I see, raising ceilings does make sense.

All three measures seem reasonable given the circumstances. I think lifting USDC-PSM DC to 30MM is also reasonable in light of the discussions of the past few weeks. Even though this amount won’t play a key role in helping supply, it allows us to further battle test the PSM as we prepare to increase its DC further.


The executive vote is now live.


I really hope to use IAM to solve the problem of DC increase, it will be more efficient.

1 Like

What a joke! Look at ETH-B pls!

exec got scheduled, will be executed tomorrow. thanks @SebVentures and @hexonaut and everybody else involved :rocket:


Hi all, wondering why the GSM delay is still 48 hours? I understand that the recent upgrade to v1.2 solved the flash loan voting problem, is it possible then that the GSM delay was further decreased to like 24/12 hours just like in the past? This will be useful to execute urgent proposals like DC increase to generate more DAI

1 Like

So the current timing is that it gets executed in the next 12ish hours and then will take another 48 hours after that before it is applied… correct?

ETH-B is at cap too, when can we raise the debt ceiling there?


Good job handling this @SebVentures and @hexonaut. I agree with proposed changes but I do want to note that we need to increase PSM-USDC-A DC as soon as possible to a higher level since increasing USDC-A DC is not ideal. The issue is that USDC-A SF is set to 0% and speculators have zero cost of capital to perform 100x leverage trade on the DAI price even before the $1.01 price is reached. This literally happened in the past few days. And this means USDC-A DC can get utilized very fast and can not be used right when needed mostly.

As soon as we feel confident about PSM we should increase PSM DC more drastically and set DC for old stablecoin vaults to 0. This also prevents increased exposure to TUSD.

As for ETH-A exposure I think nobody wants to miss on new DAI minting demand, but we should be aware that ETH exposure is increasing heavily and current rates are probably not applicable anymore at these risk levels. We have been undercompensating risk for ETH-A already in the past but now it is becoming more obvious. Good news is that competitive rates in DeFi increased heavily.

If we are going to be aggressive with growing debt exposure increasing SFs won’t be enough to protect though. Community also needs to think about 1) limiting further DC growth of certain collateral types such as ETH-B 2) Increasing box parameter 3) Increasing Surplus Buffer.

Imagine we have a big crash soon after this bull run and we get ETH-B liquidations queued due to the 15m box parameter and the price keeps tanking. Not sure though how we can argue higher box value apart from hoping the keeper ecosystem improved in past months. There was also discussion about increasing Surplus Buffer and it seems the community is divided between increase to 10m and leaving it at 4m. I think a solution with a Surplus Buffer increase and the ‘lerp’ module might be a good compromise.