✅ [RFC] Product Sunset Approach

Request for Comments
#1

Important comment upfront:

  • This RFC is NOT to discuss whether to sunset or not, this will be part of a future proposal. But in light of MIP 29, we need to prepare for the eventuality of the shutdown of the products and how it’s going to be handled on a smart contract level.
  • This RFC is to discuss HOW to sunset and to offer transparency around the guiding principles and methodology.
  • The actual decision to execute this will be done in a future proposal. A future proposal will be made that is referenced in MIP 29 that will offer options for proposed continuation as well as to pursue the shutdown.
  • In the case that a proposal for Merge/Acquisition/Continuation is successful, this RFC and the formal proposal resulting from it will be superseded by the winning proposal

Summary

This RFC is to discuss how to handle the shutdown of the products as specified in MIP 29. Smart contract changes need to be made and tested for any mandate specifying a sunset of the products.

It is important to note that this document and any associated formal proposal that may result from it are not to discuss whether to sunset the products or not.

Abstract

This document serves to discuss the guiding principles and methodology for sunsetting the products and smart contracts in accordance with MIP 29.

The first guiding principle for sunsetting the products and smart contracts is to allow user withdrawals at any time in the future and to never lock user funds. This means that any user will be able to access their funds at any point in the future, with no restrictions. It also means that users can be sure that their funds are safe, as they are not kept locked away in the contract.

The second principle is to remove all integration contracts such as Aave and Compound, meaning that all of the benefits associated with keeping funds within the contracts will be eliminated. This includes the ability to earn interest on deposits and any rewards. Furthermore, all fees will be set to zero to allow natural arbitrage to flow freely, without the user being able to earn, while also allowing for easier withdrawals with fewer fees in any basket asset.

The third principle is to remove all ownership from contracts held by the ProtocolDAO. This means removing the ability to change parameters, upgrading contracts, and finally renouncing all ownership of the nexus contract and the delayed upgradable proxy.

The fourth principle of open-source projects is to make any remaining repositories that have not yet been made publicly available to the community. This is an important step towards allowing other developers to benefit from the work of the project, as it allows them to access the code and build upon it.

The fifth principle is to communicate the sunset of deployed apps, landing pages, and social channels. This will allow for withdrawals on the hosted frontend for a period of 6 months. After this, withdrawals can still be made using locally hosted front-ends or through direct smart contract interaction, such as Etherscan.

Motivation

The motivation behind this RFC is to ensure a swift and secure transition for the sunset of the products while allowing users to remain in control of their funds and access them at any time in the future, removing ownership from contracts held by the ProtocolDAO.

Data on Ethereum and Polygon don’t have an expiration date and our smart contracts should reflect this fact. Any user, no matter when they chose to withdraw, should get their assets back.

It’s important to keep in mind that any changes made to a system may require a significant amount of time to implement properly. Once the changes are in place, it’s also essential to test them thoroughly to ensure that they function as intended. Only after thorough testing should the changes be deployed into the live environment to minimize the risk of any potential issues arising. All of these steps are critical to ensuring that changes are made safely and effectively.

Pros

  • Allows user withdrawals at any time in the future and never locks user funds
  • Ownerless contracts remain functional for withdrawals
  • Public repos can be used for the benefit of the ecosystem
  • Supports locally hosted front-ends or direct smart contract interaction for as long as the blockchains remain or state pruning is enabled

Cons

  • Takes time to test and deploy changes
  • No ownership over the smart contracts anymore and possible bugs will remain
  • Hosted front-end cannot remain indefinitely and users would need to use more complex methods to access funds after the support period ended

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 weeks and create a formal draft proposal on GitHub to be used for review. The formal proposal would contain all the details and how smart contracts would be changed/upgraded or its parameter adjusted.

2 Likes
#2

Thanks for posting this @dimsome :sunglasses:

Really well thought out, and in the case of the shutdown winning, some great guiding principles how to sink the mStable ship with dignity and remain on-board and committed to seeing it decommissioned successfully until the bitter end.

Not much to add here otherwise, and happy to see this formalized in the coming weeks!

1 Like
#3

I would add :

  • To avoid new mints or deposits so not even by mistake user would add more liquidity to the metavaults.
3 Likes
[Discussion] Future of mStable Treasury Assets
#4

Thanks @dimsome really thoughtful approach that puts users first and ensures the non-custodial nature of the protocol remains indefinitely.

#5

The Cons, although undesirable, are a part of the Decentralized Ledger landscape. It is laudable to take the time required to test and safely deploy changes which accomplish ownerless mStable contracts. While I wish it hadn’t come about in this manner, ownerless contracts was always the end goal.

1 Like
#6

Thanks @dimsome. Supportive of this approach if a vote goes towards sunsetting the mStable products. Good to see the guiding principles laid out.

From an operational point of view, it would be good to define an exact date for the end of the 6 month period for the hosted frontend, such as the 30th of September 2023.

#7

We could define a hard date, but we have no certainty as of yet when the entire process will be completed. Hence the 6 months after.

Wdyt about that or would you rather estimate a date with some buffer so we leave in worst case at least 6 months?

1 Like
#8

You’re right, the important thing would only be to have an exact date once a vote was passed to execute a product shutdown. Could state “a minimum of 6 months from the date that a vote is passed”.

#9

Hard to attach it to the outcome of this proposal. It cannot be fully implemented until it is proposed, voted upon, and implemented to what happens with MTA.

Would it make sense to attach it to the full implementation of the sunset? I.e. after the removal of ownership in the nexus contract we do 6 months minimum?

#10

Sorry, I meant 6 months from when a vote was passed to shut down the mStable product line (as opposed to a vote on this proposal). In this scenario, from funding and operational point of view it would be good to have a clear date set before the end of April if possible but understand that there are a number of considerations.

#11

Yeah I think it makes sense, will add this to the MIP. Also let’s keep a buffer, so we can provide for AT LEAST 6 months.