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
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.
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.
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.
- 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
- 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
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.