MIP 31: Product Sunset Approach Source

AuthorDimitri Golecko, Nick Addison, Cesar Chavez
Discussions-Tohttps://forum.mstable.org/t/mip-31-product-sunset-approach/992
StatusApproved
Created2023-02-27

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

Technical Specifications

This section outlines the more technical adjustments of the smart contracts and transactions that will be made in order to implement a sunset.

mAssets and Save

The following changes will be made to the smart contracts in order to implement the sunset process for the mAssets and Save products.

mUSD mainnet contract changes

  • Rename the Manager library to MassetManagerV4 so the new library can be deployed and not the old library.
  • Upgrade the migrateBassets function in the MassetManagerV4 library so the new integration contract can be a zero address. This will withdraw all the bAssets from the old integrated platform and leave the bAssets in the mUSD contract.
  • Rename the MusdV3 contract to MusdV4 so the new mUSD implementation can be deployed.
  • Remove the upgrade function from the mUSD contract to simplify the deployment of the mUSD contract. The upgrade was only used for the last upgrade and is dependent on the Migrator library. It’s easier to deploy mIUSD with just a dependency on the MassetManagerV4 library rather than both MassetManagerV4 and the Migrator libraries.

mUSD upgrade process on mainnet

mBTC changes on mainnet

  • Rename the Manager library to MassetManagerBtcV2 so the new library can be deployed and not the old library.
  • Upgrade the migrateBassets function in the MassetManagerBtcV2 library so the new integration contract can be a zero address. This will withdraw all the bAssets from the old integrated platform and leave the bAssets in the mBTC contract.
  • Rename the Masset contract to MassetBtcV2 so the new mUSD implementation can be deployed.
  • Remove the initialize function from the mBTC contract to simplify the deployment of the mBTC contract.

mBTC upgrade process on mainnet

mUSD Polygon contract changes

  • Rename the MassetManager library to MassetManagerV2 so the new library can be deployed and not the old library.
  • Upgrade the migrateBassets function in the MassetManager library so the new integration contract can be a zero address. This will withdraw all the bAssets from the old integrated platform and leave the bAssets in the mUSD contract.
  • Rename the Masset contract to MassetPolygon so the new mUSD implementation can be deployed.
  • Rename references of MassetManager to MassetManagerV2.
  • Remove the initialize function from MassetPolygon.

mUSD upgrade process on Polygon

Feeder Pools

Mainnet

  • Collect interest for the BUSD, GUSD, alUSD, RAI and FEI Feeder Pools for by manually running the ETH - Collect and validate Feeder Pool interest Autotask.
  • Upgrade the Feeder Pool’s migrateBassets to support migrating bAssets from platforms back to the Feeder Pool contract.
  • ProtocolDAO collects governance fees from feeder pools by calling collectGovFees on the Feeder Pool Interest Validator.

GUSD & BUSD Feeder Pool contract changes

  • Rename the FeederManager library to FeederManagerV2 so the new library can be deployed and not the old library.
  • Upgrade the migrateBassets function in the FeederManagerV2 library so the new integration contract can be a zero address. This will withdraw all the bAssets from the old integrated platform and leave the bAssets in the Feeder Pool proxy.
  • Rename the FeederPool contract to FeederPoolV2 so the new Feeder Pool implementation can be deployed.
  • Remove the initialize function from the Feeder Pool contract.
  • Add a new cachePlatformIntegration function to the FeederPoolV2 contract that will take a bAsset address and withdraw amount. This function will withdraw bAssets from the platform integration with the recipient the integration contract, the amount as zero and the total amount as the passed in withdraw amount parameter.

GUSD Feeder Pool upgrade process

BUSD Feeder Pool upgrade process

RAI Feeder Pool contract changes

  • Rename the FeederManager library to FeederManagerV2 so the new library can be deployed and not the old library.
  • Upgrade the migrateBassets function in the FeederManagerV2 library so the new integration contract can be a zero address. This will withdraw all the bAssets from the old integrated platform and leave the bAssets in the Feeder Pool contract.
  • Rename the NonPeggedFeederPool contract to NonPeggedFeederPoolV2 so the new Feeder Pool implementation can be deployed.
  • Remove the initialize function from the Feeder Pool contract.

RAI Feeder Pool upgrade process

FEI Feeder Pool contract changes

  • Rename the FeederPool.sol file to FeiFeederPool.sol
  • Rename the FeederManager library to FeederManagerV2 so the new library can be deployed and not the old library.
  • Upgrade the migrateBassets function in the FeederManagerV2 library so the new integration contract can be a zero address. This will withdraw all the bAssets from the old integrated platform and leave the bAssets in the Feeder Pool contract.
  • Rename the FeederPool contract to FeiFeederPool so the new Fei Feeder Pool implementation can be deployed.
  • Remove the initialize function from the Feeder Pool contract.

FEI Feeder Pool upgrade process

Polygon Frax Feeder Pool

  • Collect interest for the FRAX Feeder Pool for running Hardhat task feeder-collect-interest.
  • ProtocolDAO collects governance fees from feeder pools by calling collectGovFees on the Feeder Pool Interest Validator.
  • Governance fees are transferred back to mainnet Treasury multi-sig.
  • The contract does not need upgrading as the FRAX and mUSD is not integrated to any lending platforms.
  • The Protocol DAO Safe calls setFees on FRAX proxy with zero value for the swap, redemption and governance fees.
  • The Protocol DAO Safe calls setWeightLimits on FRAX proxy with min of 5% (5e16) and max 95% (95e17).

Meta Vaults

3Pool Convex Meta Vault contract changes

Upgrade Curve3CrvAbstractMetaVault, PeriodicAllocationPerFeeMetavault and Convex3CrvAbstractVault to support withdrawing all assets from underlying vaults. Withdraw all assets for all vaults and allow withdraw proportional to user shares. Modify deposit and redeem to not do anything for all vaults (Convex, Curve and Cache Meta Vault). Modify totalAssets in SameAssetsUnderlyingVault to not include underlying assets.

The following contract change will be made:

  • Create a function liquidateUnderlyingVault in Curve3CrvAbstractMetaVault that can only be called by the ProtocolDAO. This will remove all liquidity from the 3Crv Pool and leave USDC in the contract.
  • Modify deposit and mint to not do anything for all vaults (Convex, Curve, and Cache Meta Vault).
  • Modify totalAssets in SameAssetsUnderlyingVault to not include underlying assets.
  • Modify redeem and withdraw to issue assets based on the proportion of shares

3Pool Convex Meta Vault upgrade process

Nexus

The last step after all of the above is implemented AND all changes to staking, MTA, Emissions Controller are implemented (separate Proposal).

The Protocol DAO’s Gnosis Safe calls changeGovernor on the Nexus contract with address 0x000000000000000000000000000000000000dEaD

Affected addresses Mainnet:

Affected addresses Polygon:

Copyright and related rights waived via CC0.