βœ… [RFC] Upgrade Save Contract to comply with ERC-4626

Big shoutout to @doncesarts for leading this and working on the smart contracts.

Summary

This RFC seeks feedback for a proposed upgrade to our Savings Contract on Ethereum Mainnet and Polygon. The upgrade would adjust the contract such that it would follow the ERC-4626 standard, while still preserving the current functions to allow for backwards compatibility.

Abstract

ERC-4626 is a new standard for yield-bearing Vaults. As discussed in the previous community calls, mStable is leaning further into the Save concept and seeks to embrace this new standard.

Therefore, we would like to make the first step by upgrading our current yield-bearing contracts (Save Contract or imUSD and imBTC) to be compatible with this standard. The contract already is quite similar to the standard but requires a few changes to be 100% compliant.

Following that, the new implementation of the Save Contract needs to be deployed and the Proxy needs to be pointed to the new Implementation.

Users are not required to perform any actions. Other protocols that integrated the contracts and our front-end do not need to be updated. But new integrations can use the standard interface to interact with the upgraded smart contract.

Motivation

This follows our recent shift of focus towards the Save Concept and the embracement of the ERC-4626 standard. This step makes sense in this light as we would want to push this standard forward and be a key player with this new standard.

Additionally, following this standard could open up the door to new integrations with new protocols that adopt this standard early. One of which is Turbo Tribe, which allows any DeFi token to become productive by sharing in the yield generated from a costless FEI line of credit..

It is to be expected that more protocols will find uses cases for contracts following this standard.

Pros

  • Embrace new standards and position ourselves being a key player in the ERC-4626 arena
  • Opens up the door to more integration possibilities
  • Contract remains backwards compatible
  • User does not need to migrate

Cons

  • An upgrade to the smart contracts has some associated risks, but we are testing the contracts thoroughly to ensure a safe-upgrade

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

2 Likes

I am in support of this RFC.

2 Likes

Thanks @dimsome for this RFC , I would like to see the Save Contract (imUSD and imBTC) open to more composability under the ERC-4626 standard.

2 Likes

Definitely in favour of this, and happy this has made it’s way to the forum! :sunglasses: :+1:

A no-brainer if we are to leverage ERC-4626 more heavily in the future, and will make our tools composable across the ecosystem, LFG!

1 Like

Thanks @dimsome and @doncesarts for your work on this. I am fully supportive of this proposal. From a risk management point of view, I imagine the changes to the contract are mostly minor changes to match the standard 4626 interface? I’m sure all changes have been thoroughly reviewed within the team but might be good if someone could speak to this a little bit more given that the smart contract risk seems like the only potential β€˜con’ here.

2 Likes

I was thinking about this last weekend!
IMHO this is a MUST. Being a newly standard we might get some extra integration just by being early and vocal about it.

There is a risk on the deployment and introducing bugs, but given the history of the team, I would place my complete trust and give my full support.

@soulsby I might be missing something, but as far as I can tell, it’s basically the same functionality with different function names, types and the distinction between shares and asset amounts.

1 Like

Can we just have a contract that wraps imUSD inside of 4626-imUSD and make the 4626-imUSD conversion optional? Or would that be too much confusion?

Yeah, that would be a separate contract and less gas efficient. The way we did it now, is that it still allows the same functionality as before, but we add the functions that are ERC4626 compliant. So it is actually optional :slight_smile:

1 Like