Simple Summary
This proposal outlines a sunset process and smart contract changes to products as specified in MIP 29.
It is important to note that this proposal is not indented to propose or discuss whether to sunset the products or not but rather in the case that the subsequent proposals to sunset are voted upon there is a set of clear guides and requirements specified to follow.
Abstract
Important comment upfront:
- This MIP 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 MIP outlines HOW to sunset the products and to offer transparency around the guiding principles, methodology and smart contract changes/upgrades.
- 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 Proposal and the formal proposal resulting from it will be superseded by the winning proposal
This document serves to discuss the guiding principles and methodology for sunsetting the products and their smart contracts in accordance with MIP 29.
The first guiding principle for sunsetting the products and their 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 front end for a period of at least 6 months starting after the vote of the sunset in the subsequent proposal has been conducted. 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 MIP 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 on behalf of MTA Governors / mStable DAO.
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.
Specification
Outlined here is the high-level approach to the sunset of each product. Staking contracts are excluded here and will be further specified in another proposal outlining MTA procedure.
mAssets and Save
- Upgrade the mAssets’s
migrateBassets
to support migrating bAssets from platforms back to the mAsset contract - Remove platform integration
- Set swap and redeem fee to 0
- Set new min-max weights (5% and 95%)
- This applies to mUSD and mBTC on Ethereum mainnet and to mUSD on Polygon
Feeder Pools
- Upgrade the Feeder Pool’s
migrateBassets
to support migrating bAssets from platforms back to the Feeder Pool contract - Remove integration contracts if present
- Set swap and redeem fee to 0
- This applies to mUSD and mBTC on Ethereum mainnet and to mUSD on Polygon
- Exception: GUSD is still integrated with Iron Bank, a full withdrawal from the integration contract to cache as specified in MIP 23 was not possible without further changes. The GUSD contract will be adjusted to allow partial migration of assets back to the cache.
Meta Vault
- Upgrade contracts to add functionality to withdraw from underlying
- Withdraw all assets back to the contract
- Modify deposit and redeem functions to not do anything for all vaults (Convex, Curve, and Cache Meta Vault)
Automated Tasks
- All automated tasks will be disabled
- This applies to mAssets, Feeder Pools, Emissions Controller, and Meta Vault
Front-ends
- In all front-ends and the landing page, a banner will be added to notify everyone of the sunsetting of the product and to encourage withdrawals.
- The front-end will be kept alive for at least 6 months after the vote of the sunset in the subsequent proposal has been conducted.
- The possibility to access the contracts afterward is still possible via a locally run front-end or directly with the smart contracts (i.e. Etherscan).
Nexus
- Set new governor to address dead:
0x000000000000000000000000000000000000dEaD
- Once the governor’s ownership has been renounced, the following is locked into place so this would be the very last on-chain transaction by the protocol governor
- all modules in the Nexus. eg Liquidator and SavingManager addresses
- All proxy contracts can no longer be upgraded
- This should be the very last step and requires that the staking contracts upgrades/changes are resolved as well