✅ [RFC] Future of mStable Treasury Assets

[0xloth]

Simple Summary

It is proposed that the mStableDAO, in the event of a shutdown option being voted on as the path forward for the mStable project, decides on what should happen to the assets (circa $2m) governed by MTA holders.

The objective of this RFC is not to discuss whether or not shutting down is the best way moving forward, but what is the fairest and most decentralised way forward for mStable Treasury Assets.

This RFC is originally ideated from the discussion here and proposes a way to handle the mStable Treasury Assets in the event of a shutdown option voted

Abstract

The MTA token is a governance token that can be utilised within the mStable ecosystem.

It has currently two major utilities: primarily, it can be staked in order to enact all governance decisions in the DAO. Secondly, it can be used to incentivize decentralisation and protocol usage through the emission controller’s dials. MTA has no rights attached to it beyond these two use cases.

mStable DAO Treasury Assets are held across the following 4 addresses: address 1, address 2, address 3 & address 4, for a face value north of $2,548m at the time of writing.

Also, as of now, none of the organisations and sub-organisations composing the mStableDAO (MTA stakers) has in their mandate the ability to take action on what could happen to the assets governed by MTA holders in the event of a shutdown or an acquisition.

This RFC is originally ideated from the discussion here and proposes a way to handle the mStable Treasury Assets in the event of a shutdown option voted

Motivation

Guiding principles

• Since its inception, mStable has been pioneering decentralised governance. MTA, an ERC-20 token, was and remains the instrument of project governance. In the event of mStable winding down, crypto-native technology and methodologies should be at the very centre of the project’s shutdown.
• Creating a self-executing framework for this important decision could enable the vote of this sunset process to be a community-made decision as well as execution.

Specifications

1. Proportional redemption of mStable Treasury Assets against MTA

   1. Overview: mStable Treasury holdings would be divided among MTA holders in proportion to their holdings, at a fixed rate using a fixed eligible supply

   2. Eligible supply for redemption: MTA Max Total Supply would be eligible excluding:
      a. Plain MTA held across address 1, address 2, address 3 & address 4
      b. Invested MTA across address 1, address 2, address 3 & address 4:
      b1. Uniswap V3 MTA/ETH pool (MTA in the pool + claimable rewards)
      b2. Ondo Finance MTA/FEI pools
      b3. MTA held in Llama Pay across address 1, address 2, address 3 & address 4
      c. MTA held in the Emission Controller contract (22,253,792 on the 6th of March)
      d. MTA returned from cancelled team streams. Calculations for this are WIP and will be part of the TDP

   3. Nature of redemption: All mStable Treasury DAO Assets would be liquidated for ETH in the coming days after the date of the vote. ETH is the most liquid path to redemption while being a trustless asset. An exhaustive list of mStable DAO Treasury holdings alongside a gas-efficient swap method will be provided as part of the TDP

   4. Method of redemption: A smart contract would be deployed for the redemption of MTA to ETH, with no expiry. This could happen on a bespoke Front-End; hosted on IPFS or straight from Etherscan. Pending research assuring feasibility, a decentralization tool like oSnap could facilitate the transfer of the ETH to the redemption contract.

   5. This redemption should start at a specific date, sufficiently in the future to allow:

      • Time for the design of the redemption back-end and front-end
      • Certainty around Treasury Assets top line (post-last funding and surplus from Builder subDAO and Ecosystem subDAO returned)

      The following TDP would specify this specific date.

Additionally, it is also proposed to:

• Halt Emissions Controller and other inflation distributions
• End Builder subDAO & Ecosystem subDAO streams on the 12th of April when full-time agreements wind up (as the remaining token amounts will be considered “unearned”)
• Leave advisors/investors’ streams running (as they have already purchased their tokens/provided services for tokens and the delivery is contractually due)
• Lift cooldown period and unstaking related fees. This would mean the de-facto end of governance, as all stkMTA will be migrated to the contract. This will be covered in detail in the TDP

We are looking forward to getting the feedback of the community, team members and MTA holders in regards to this proposal being the most efficient and decentralised way to decide on the future of mStable Treasury Assets.

Following the process outlined by MIP 29, it will be discussed in the forum, voted in a Snapshot and if MIP 30 resolves a shutdown it will be executed.

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

[trustindistrust]

Looks good to me, nothing jumps out at me as needing work.

[doncesarts]

I have the following questions regarding to the method of redemption:

Method of redemption: A smart contract would be deployed for the redemption of MTA to ETH, with no expiry.

1. How many times will treasury will deposit MTA into that contract? Only once and then seal it?

2. Related to do not have an expiry , this could lead to ETH lock forever as there could be the case that not all MTA would be redeem, from the top of my head for example, there could be holders that given the amount of MTA it would be more expensive to redeem than do nothing. Or holders that lost access to their wallets, etc etc. any feedback on this @0xloth ?

3. Could you please specify where that smart contract would be deployed ? Mainnet , Polygon ?

[dimsome]

Thanks Theo, this is a good start. I have a few suggestions or questions that i think we should address/adjust:

• For the actual MIP it would be nice to have a bit more context of what address 1, address 2, address 3. I would create a table with a wallet name (what is this wallet) and the amount of MTA. For instance, ProtocolDAO does not seem to have any MTA, so why include it in the list?

• Rather than listing all the protocols and addresses that should be excluded, why would we not just consolidate and withdraw all MTA into the Treasury and mark that as out of circulation. Maybe even better just to send to the Emissions Controller to have sort of a “burner address”

• Again, I commented this already but seems like it make it to this RFC: bespoke Front-End is a weird term, the UI to redeem would be shared with our LTS app that is being build atm.

• hosted on IPFS or straight from Etherscan. Etherscan is always an option and i don’t think we have to mention it here. The app itself will be hosted as we host our apps currently. It would be also possible to run locally.

• oSnap is really not a good choice here. 1. You would need another Vote after all governance is already disbanded. 2. It might just remove 1 tx execution from the multisig. We are still having to develop, deploy, swap all assets, potentially wrap ETH into WETH, queue in a tx to approve spending. So not really seeing the point of signaling virtue while the entire rest of the process is implemented by us.

• Time for the design of the redemption back-end and front-end What back-end? you mean the smart contracts?

• Halt Emissions Controller and other inflation distributions What are other inflation distributions?

• Leave advisors/investors’ streams running (as they have already purchased their tokens/provided services for tokens and the delivery is contractually due) I don’t think mStableDAO has juristiction over these. These agreements were made with another party, not the mStableDAO, so that other party is responsible of resolving these contractual obligations. mStableDAO has no jurisdiction to decide to continue or stop streams since it did not enter the agreements itself.

• Lift cooldown period and unstaking related fees. This would mean the de-facto end of governance, as all stkMTA will be migrated to the contract. This will be covered in detail in the TDP Yup cannot end governance if you want to use oSnap after…

• Generally: I am not super keen in allowing WETH to remain in the contract forever. What is the %-amount we can assume that will never redeem? Are we okay just burning 50% of the WETH forever? We have no estimations of how much redemption we can expect.

Happy to help if you need support.

[0xloth]

Hey @doncesarts
Thanks for your comments and questions
1 - I imagine only once, post-liquidation of all holdings into the chosen asset
2 - That’s true, the possibility of dead capital is likely assuming a contract without expiry and a relatively large eligible supply. I see a way to solve this economical question by adding a minimal amount of MTA held in the wallet to the eligibility criteria (which would aim at making claiming costs < amount claimed. Also, another way to avoid dead capital would be to have more “restrictive” eligible rules like MTA needs to be staked, not only held. If you or any community member have any suggestions to avoid dead capital, it would be very helpful
3- I imagine on mainet as everything related to governance is on Mainet. @dimsome any opinion on this?

[trustindistrust]

I don’t think avoiding ‘dead capital’ is even something to worry about. If ETH remains in the contract in perpetuity, why exactly is that an issue? If not all MTA is redeemed for its share of assets, who cares?

The point is to divest the treasury and make it available to holders. It’s incumbent upon them to gather MTA and redeem it, not upon governance to ensure that every wei is squeezed out and for nothing to linger in the contract.

[0xloth]

Hey @dimsome
Thanks for your comments and suggestions.

1. I agree with this and was thinking the MIP should include a detailed view of Treasury Assets holdings. @nesk could you help craft a table, for each of these four wallets, detailing the name, nature of asset held, type of holding (plain or invested), # of assets held, $ and value? I added the ProtocolDAO as it holds other assets like CRV or CVX
2. I think in order to consolidate we need in the first place to do this “inventory”. Then, I think using the EC as a burner address is a good one
3. I’m aligned with this LTS app strategy. I’ll let you add these app details to the MIP when it’s in crafting mode. I think it’s always good to remind people they can use Etherscan.
4. I understand oSnap is a very granular approach than can’t be used for the whole process. I still think its utilisation would be meaningful at the very start of the process for a selected tx. Which tx has the most value for which could we leverage oSnap? I think the action of sending ETH ( once the Treasury Assets are liquidated to it), to the redemption contract could be a valuable one. @cam keen to hear your thoughts about this
5. Yes sir, pardon my french
6. I meant staking originally but staking is a dial so will remove
7. I tried to address this question here. Maybe @james.simpson can add some clarity to this?
8. Clear. Imo, the use of oSnap as said in 5) would be only to initiate the first transaction to send the redeemable asset to the redemption contract.
9. I share this concern and feel it’s what @doncesarts was hinting at with the dead-capital question. More generally, having dead money is a shame but doesn’t really matter from a contract perspective, does it? However, ideas I shared to avoid dead capital:
   • Have more “restrictive” eligibility rules like MTA needing to be staked, not only held. I have no problem with this except the fact the more rules we add, the less “fair” someone might perceive the redemption rules
   • Add a minimal amount to be eligible but don’t solve the dead whale wallet question
     Keen to have your support on how to solve this

Looking forward to collaborating on the MIP draft

[cam]

Regarding oSnap, it would of course be great to see the outcome of a vote be implemented in a self-executing way but understand that it may be more practical to leave it to DAO signers to execute the will of MTA Governors given the challenges highlighted.

[james.simpson]

Hey @0xloth thanks for this.

Some points:

Vesting vs delivery of some advisor and investor tokens
A critical point to clear up here is vesting and delivery of some advisor and investor tokens. There is a lot of misinformation flying about on the discord and I want to make sure we are on the same page.

As with virtually every crypto project, there are investment rounds and advisory agreements. These agreements are about providing upfront capital to bootstrap the DAO (investment agreements) as well as services to help with that process (advisory agreements). The relevant agreements have long (3 year) delivery of tokens.

The way advisors earned tokens was to provide services for a period of time (3 year vesting)

The way investors “earned” tokens was obviously through upfront payment.

Some advisors started contributing to mStable well before token generation of MTA and the initiation of the 3 year delivery of their tokens. This means there is a mismatch with “vesting” and “delivery” of some advisor tokens.

For example, Advisor A may have started contributing in January 2020 on a three year term. The vesting or earning of these tokens would then stop in January 2023. However, because delivery from TGE was set to three years, these tokens would be delivered from approx. July 2020 (TGE) to July 2023 (three years past TGE).

In this example, there would be approximately a 6 month period where the advisor would have tokens being delivered via stream that were already earned. The advisor is owed these tokens for past work over three years; they are just being delivered to him/her over a longer period.

Regarding investors, there are some who invested in the very first round of mStable and were on a 3 year delivery from TGE. For investors, the payment was upfront capital. As these tokens have been paid for, the streams will need to continue until they are finished.

To be clear, no one is getting any tokens that haven’t been already worked for or paid for; and there is no token vesting that would be accelerated in any circumstance in a shutdown (I would be very against any proposal for this).

“Dead Capital” vs. fully redeemed treasury

In regards to the idea that is presented, as I read it, there would be no need for any acceleration of delivery for any token stream. If an investor or advisor has tokens to be delivered, they can just see that delivery out until the end. This is because the idea presented outlines a proportional withdrawal of tokens from the treasury, which could live on indefinitely in a smart contract, giving the MTA holder that comes today the same quality of, say, ETH as one that comes in 5 years. It wouldn’t matter if the investor or advisor receives tokens today or later on. I would therefore be against any form of acceleration of delivery as it makes no real difference. I also see what Trust is saying here. This one seems to be the most fair and decentralized way.

I thought I should offer an alternative suggestion however (I think this is similar to how Babylon Finance did their shutdown of treasury). There would be a time window for staking MTA in a contract (say 3 months). Anyone with MTA can stake during this window to be part of the treasury shutdown. At the end of this 3 months, the treasury would be divided up proportionally amongst those staked.

This would mean that there wouldn’t be any dead capital. The issue is that it isn’t equitable to every MTA holder and may prioritise those “in the know” rather than a silent MTA holder who wakes up in a year only to realise this has all been done. But on the other hand, given MTA doesn’t have any rights to the assets, it could be something to investigate. In terms of acceleration of delivery in this example, I actually think it wouldn’t make sesne either. The investor and advisor only need receive the tokens they are owed; there was and has never been any promise to the treasury. Their tokens could be delivered after a shutdown of treasury.

OSnap
I would like to see a feasibiliy study on this. If it isn’t possible in the timeframe, it probably isn’t worth it but I personally like the idea of direct decision and execution in general.

[nesk]

As requested, I’ve made a spreadsheet tracking most of the assets held by the multisig. In the following days I might link it with some API. For the sake of simplicity, I recommend tracking it in Zapper. In any case, feel free to give away any feedback. Besides the Treasury DAO, the protocol DAO is holding ~150 USD of CVX and CRV and there’s some MTA in Sablier streams that belong to the old funding subDAO.

[cam]

To add a couple of operational considerations here:

• It would take time for 100% of assets to be returned to the TreasuryDAO after a shutdown decision was made as there are some loans & deposits outstanding with Builder subDAO service providers that may not be returned until late April or May.
• Additionally, there will likely be value arising in the multisig in the future due to locked SAFE tokens, other airdrops, or other sources.

Any proposal here should consider what date is realistic to have all assets on hand, and also what should happen with future assets that arise.

A nice consequence of the alternative suggestion made by @james.simpson would be that there would be an additional 3 months of time for all assets to be returned to the DAO.

An option for other assets that show up later could be to have them donated to a chosen cause.

@dimsome @0xloth interested to know how you think these topics should be handled.

[0xloth]

One idea to allow for sufficient time and make sure all funds are returned to the Treasury could be to add whitelist conditions/criteria for a given period. (which could be 3 months)
We could whitelist all MTA from the Eligible Supply that is deposited by MTA holders in a whitelist smart contract deployed post resolution of MIP 30, for a period of 3 months.
MTA Holders then will be whitelisted for the mStable DAO Treasury Assets redemption
This would introduce a variable nominal redemption value but would solve the dead capital question

[dimsome]

I like this! I would not call it whitelisting though, but i think this makes sense and 3 months is plenty of time.

Maybe register claim?