PSM-USDC-A Starting Debt Ceiling 19th Dec 2020

Hey all,

If we don’t get any of the Smart Contracts Mandated Actors to be able to comment on the severity of smart contract risks of the new PSM implementation before deployment, I personally don’t feel comfortable starting with 500m DC from day one. We want to be close to 100% sure this is safe from technical standpoint. Otherwise I would prefer to start with a Debt Ceiling of 3m for PSM-USDC-A and if everything runs smoothly, governance can increase the Debt Ceiling at the next possible executive vote. The level of 3m would be proposed because the surplus buffer can still protect Maker against any potential losses.

The financial risks are high here, but I can evaluate them only in relation to SC risks where I can only rely on external opinion. @hexonaut thoughts?


Why did we have a signal request and on-chain vote?

1 Like

For context, I will add that @equivrel pointed out that starting with a lower DC would be wiser. I think we should welcome any idea no matter how late they come. We usually start small for new stuff and here no one had this idea earlier.

It doesn’t change much to the idea that we are targeting 500M DC.

It’s really an implementation detail that is above my paygrade. I fully support @Primoz, @hexonaut, and SC domain facilitators whatever their decision is.

We need to start trusting people we have put in charge.


So in terms of smart contract risk we’ve done everything we can to prepare for this launch. Because the psm is built on existing Maker code it is fairly safe imo as we are protected by the already tested code. We have the audit in place to give that extra level of safety which should be considered a stronger guarantee than the smart contracts team looking things over. I get that there is a (well deserved) level of trust people put into the Foundation SC team, but they are human and there are no guarantees about any new piece of code. Personally I think we are good to go at a 500M debt ceiling, but I’ll defer to risk if they want to start with a test ceiling. I will aim to push the spell out tomorrow so we have a day to think on this.


I think the results of those votes will still be used to determine the target debt ceiling, so I do think they were useful. Hopefully we can increase the ceiling to that level in future executives.

I’ve prepared the executive copy for a version of this proposal with a 3M ceiling and no changes to the existing debt ceilings of the other stablecoin vault types.

Unless we hear otherwise from @Risk at some point tomorrow, I believe @hexonaut is happy to deploy this more limited initial version of the PSM.


Sorry all, but I analyzed risks versus benefits once again today and under current circumstances and unfortunately I decided as I did. Delaying a 500m DC for PSM for a minimum period of testing is still my preferred position. If we can signal that increasing PSM DC to fix the peg is still the main plan, but only got delayed slightly because Maker tests in prod wisely, it should be fine.

Of course I should have proposed this earlier, but I think I also got a bit influenced by this peg obsession in the community lately, where everybody wanted to solve it as soon as possible. So we rushed through this December to make it happen and forgot about what Maker represents.

How ever you may interpret this, I proposed what is best for Maker from my standpoint. That said, I don’t want to be in the role of a blocker as no individual that cares about DAO wants to be.


No worries Primoz–you’re doing the right thing. I fully support this delay/lower DC–we will get there when we get there. I polled for 500M and 250M DC–but I’m not disappointed. All good.


So we’re gonna have 0 DC on all stablecoins (except USDC-B) and a 3M PSM for several weeks?

I support this plan to implement PSM safely and steadily.


I guess we will not touch the DCs of the existing stablecoin vaults. Setting them to zero makes sense only as soon as PSM is able to replace them

No, Debt Ceiling for low LR stablecoin vaults would remain as it is for now. We always need a buffer remaining if it comes to potential DAI demand shocks. The question is whether we should limit TUSD DC to 0 because of that other issue, but I am personally not afraid of Maker getting blacklisted in two weeks. And it is also unlikely exposure to TUSD increases.

But I also don’t mind if TUSD DC goes to 0 if SC team has capabilities to write a spell for it, although I think they are out for this year (as they should be), unless something really urgent.


Let’s not mix in things like TUSD uncertainties into this topic


After giving this some more thought, I completely agree with @Primoz’s decision to switch to a 3M test DC. I’ll try to go into my personal logic:

The reason I wanted to start with a non-test DC is because my understanding from previous conversations is that we wanted to maximize fee collection - hence why I built the lerp module. This in conjunction with uncertainty with whether MKR holders wanted to lower the stablecoin SFs to 0% gave me a sense of urgency with getting this done and getting vault holders to voluntarily switch over to the PSM. I believe this was the same sense of urgency that Primoz was feeling as well. This is not even to mention the urgency of fixing the peg in the first place which has no longer become relevant due to people front-running the PSM. All in all it was blinding us a bit to the risk here, and we were taking an excessive leap when a small one would work just fine.

As the lead smart contracts person on this project it was my mistake to not recommend starting with a test DC. This is clear to me now, and I apologize to @Primoz for the position I put him in making that call alone on Saturday.


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.