2021 August 20 Exec Update: PAX PSM at 50m this week

MKR holders,

The Protocol Engineering Core Unit is preparing a new PAX PSM deployment for this week’s executive. This deployment has required the modification of some code from the existing USDC PSM deployment.

Due to the new code and recency of the changes, we will be proposing the initial debt ceiling be set to 50 million Dai during the initial deployment period. These changes are fairly low impact and we can be reasonably assured that we’ll be able to raise the debt ceiling to the full 500 million requested in the next executive after a short burn-in period. For safety we would prefer that new code have some time to settle in at a value within the surplus buffer limit.

These changes have been discussed and agreed to by GovAlpha and BizDev facilitators.

Thank you,

Your Friendly Neighborhood Protocol Engineering Core Unit


Very prudent! Should we make this a standard rule for all new structural deployments like this? Or is this a special case?


I was thinking we should consider a kind of vault burn in period. Start with lowish DC wait a bit to see if anything crops up before running a DC past 100M. idk really.

1 Like

@brianmcmichael Would it be possible to publish a light-weight assessment somewhere to summarize which considerations lead to these debt ceiling recommendations? For example, I would imagine the team considered elements such as:

  • Business logic complexity
  • New business logic compared to the USDC module
  • Lines of code
  • New lines of code compared to the USDC module
  • External dependencies
  • Formal verification
  • Internal audits
  • External audits

Having metrics like this with qualitative scores, not just for this change but future changes as well, would help the community to better understand the technical risk trade-offs. Later this can be formalized and adopted as part of a more comprehensive risk framework.


Hi Wouter,

I’m not sure I can give so tight a heuristic, it’s not really about lines of code. Generally we need to be careful adding any code to the system, whether we’ve seen it or not. To date, we have not added any new collateral or modules in excess of the debt ceiling, and it’s historically been considered the most effective defense for limiting collateral risk. With the new code involved and lack of a clear emergency this didn’t feel like the right time to start swinging outside of that, so we have stuck with a longstanding precedent.

This system is fragile and there are many moving parts. The team makes every effort to fulfill our mandate of safety and security of the system, but in many cases we don’t know what we don’t know. In addition to the risk of new code, errors can get introduced in the spellcrafting process or in the interaction between the PAX code and the PSM module code. PAX itself is a proxy implementation with no way for us to tell on-chain whether the implementation has changed, so we will likely need to do additional research to mitigate this risk. While we have prepared and simulated tests, there are no takebacks in smart contracts, and a failure here can create irreversible loss, so somewhat absurd levels of caution are advised.

A more detailed risk framework is something we can certainly discuss among the team, and that will take additional time and effort to produce. In this case, reasonable measures within historical precedent and the team mandate were taken to mitigate inherent risks in system modification.