🧊 [RFC] ProtocolDAO Discretionary Powers

Summary

This RFC would like to gather feedback surrounding the discretionary powers that the ProtocolDAO should be given in the future in order to be able to act in adverse conditions to protect the funds of the users, as well as the fault-free operations of the mStable protocol as a whole.

Abstract

With the conclusion of the post mortem of the Events that took place on the 12th of May in the June Governance Call, a consensus was found that a process and plan be put into place that clearly highlights the actions that the ProtocolDAO can take if such an event should occur again in the future, and also set out a contingency plan for events that go beyond this newly set out framework of discretionary power.

It is suggested to gather feedback in this RFC on the points (and ultimately levers) that the ProtocolDAO should be given discretionary powers over, as well as craft a clear protocol to follow on events that go beyond these discretionary powers.

As a starting point, the following parameters are to be included in this new framework of discretion:

  • Changing the basket weights of both mUSD and mBTC during adverse market conditions that risk overexposure to one basket asset
  • Pausing the mStable Protocol or parts of the mStable Protocol during black swan events (Hacks / Exploits / Other Malignant Behaviour from Bad Actors that Risk User Funds & Operation of the mStable Protocol)
  • Other unforeseeable events that might require the ProtocolDAO to act quickly with the uttormost core of user and fund protection and risk mitigation in mind

Motivation

With the recent collapse of the Terra ecosystem, we have learned that parts of the DeFi ecosystem are constantly at risk of causing a systemic failure of the products that build on top of them, and as we are preparing to rollout mStable V2, it is perhaps a wise decision to create a clear set of rules and an overall plan on how the mStable Protocol should behave during unforeseen circumstances ahead of time, in order to protect users and their deposits from needless loss or exposure to such risk.

Pros

  • Create an agile additional safety layer that the ProtocolDAO can act from in order to quickly enable changes if needed to protect user funds and the contracts of the protocol
  • Enable a transparent layer of steps that can be verified in case of a black swan event to confirm that the ProtocolDAO has acted on behalf of Meta Governors
  • Create a solid foundation for the safe and coordinated rollout of mStable v2

Cons

  • Sacrifice decentralization for additional safety and control over unforeseen happenings

Next Steps

It is suggested that the community comment on this RFC in the coming days, and bearing no significant opposition or change in ideation, we would move ahead with this RFC in the coming week and create a formal draft proposal on Github to be used for review.

Meta Governors are encouraged to provide as much feedback as possible until then, so we can create the best possible outcome for mStable and its users.

1 Like

Thanks for putting this proposal together @mZeroNine .

Generally I am in favour of reducing the discretionary power of the ProtocolDAO as much as possible so it would be good to hear from someone with more technical knowledge than me what powers are considered to be ‘required’ to protect the protocol and why.

If changing weights during adverse events is seen a valuable tool then I’m ok with that, but I would imagine that in the case of a significant event like and underlying asset de-pegging, this approach would be too slow to prevent loss, so taking a proactive approach to set max weights at a comfortable level seems preferable.

Similarly, allowing pausing of the contracts seems appropriate in extreme cases.

For other actions that don’t fall into these categories, perhaps defining some sort of expedited governance process would make sense?

Maybe its also worth highlighting in this proposal that there is another category of discretionary powers that are granted for convenience to minimise the burden on MTA Governors, rather than to allow urgent action. The only example that I can think of is whitelisting smart contract addresses for MTA staking. It would be good to clarify if there are other examples.

Before I can comment, can a core dev answer some questions?

Is pause functionality currently present? How does it work, and what contracts does it affect? Does it have a self-reset (things un-pause automatically after a time) or is the pause permanent until removed? Can funds be drained from the affected pool(s) during the pause in any way? This would affect how any ‘rescue’ operation would be conducted.

Thanks.

Answering the questions of @trustindistrust

Yes it exist the pause functionality as on :

  • FeederPool, NonPeggedFeederPool Contracts: it pauses mint, mintMulti, swap, redeem, redeemProportionately, redeemExactBassets and collectPlatformInterest

  • SavingsManager to collect and distribute interest to the SavingsContract.

  • mAssets: the multisig can change the the cache size, weight limits, or handle a Peg Loss, while handling the peg loss, mint, redeem and swaps actions are paused.

A multisig needs to pause them and it also needs a multisig tx to unpause them

For more details of what else the multisig can do please check here Multisig Admin Rights - Developer Docs

2 Likes