Should SAVE be made composable?

It is proposed that mStable's SAVE functionality be amended to make it more composable. These improvements are detailed in MIP-5, and grouped across three broad categories:

1. Tokenising the “Savings Credit”, creating an imUSD token that represents the yield accruing mUSD and can be transferred and used as collateral in DeFi platforms
   • Core behaviour will be optimised in terms of gas usage
2. Enhancing capital efficiency by depositing X% of SAVE deposits elsewhere in the DeFi ecosystem (initially a yEarn mUSD vault)
3. Providing an imUSD deposit box, a place where long term savers can store their imUSD and earn MTA
   • This is aimed at supporting the migration of funds, and ensuring that recipients of system yield have a say in how it is distributed
   • To ensure long term alignment, earnings will be boosted for MTA stakers, and lockups will apply

Arguments in favour of making it composable include enhancing its functionality, improving capital efficiency for depositors and increasing SAVE’s potential to be integrated across the DeFi and CeFi ecosystems.

All other functionality of the existing platform would remain the same – savers would be required to deposit mUSD into SAVE to mint the composable token and mUSD and the composable SAVE would remain separate tokens/assets.

Note the implementation of this change would require the existing SAVE contract to be closed and, over time, existing savers would migrate their deposits to the new, composable SAVE contract.

MIP-5 can be accessed here - https://mips.mstable.org/MIPS/mip-5

Should mStable's SAVE functionality be amended as outlined in MIP-5?