This RFC aims to kick off a discussion on what could happen to the assets governed by MTA holders in the event of a shutdown or an acquisition option being voted on as the path forward for the mStable project. The idea is to get consensus and ultimately specification before the vote of MIP 30 happens, in two weeks.
Context
A product shutdown discussion is live since earlier last week. However, no conversation has been opened so far about what would happen to the mStableDAO Treasury Assets in the event that the mStableDAO is voted to shut down or pursue an acquisition.
Given that some MTA has been staked and governs the DAO and its Treasury, this RFC requests feedback on what should be done with the mStable Treasury Assets in case of a shutdown or an acquisition option being voted on.
Moreover, the mStableDAO (MTA stakers) is composed of sub-organisations, with different scopes:
Ecosystem subDAO (Grows awareness and understanding of mStable products, fund projects building on top of mStable)
Builder subDAO (Leads the product development of mStable)
Treasury subDAO (Execute the will of MTA holders regarding Treasury Assets)
Protocol subDAO (Execute the will of MTA holders regarding contract updates)
None of these subs. organisations have 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.
Ideas
Using crypto-native technology and methodologies, to enable fair and decentralised outcomes.
Creating a self-executing framework so that the process is a community-made decision as well as execution.
As I see it, there is no concrete proposal put forth in this RFC.
It would be more appropriate to categorize this as a discussion or ideation and move the conversation to an appropriate forum where the community can openly discuss and brainstorm potential solutions.
This is where ideas are first discussed and brought forward via post on the mStable forum.
A Request for Comment should be labelled as such with [RFC] at the beginning of the title.
It should contain the following sections: Summary, Abstract, Motivation, Pros, Cons
Seeing how this initial thread has neither an Abstract, Motivation, Pros, or Cons for that matter, I must agree and urge to rework this above post to suit the above guidelines as to be approved as an official RFC for governance.
I’d welcome more feedback surrounding the overall, based on a reworked RFC, and then we can summarize and move forward with an actual proposal in the coming days and weeks.
Looking forward to seeing the future of the treasury being shaped by the community and core contributors alike, and let’s get this moved forward quickly, seeing how this will become an integral part of any future developer efforts and will otherwise become a huge bottleneck in shutdown procedure.
Hey @0xloth thanks for this, good to open this discussion. Makes sense to discuss this given MIP 29 and the product sunset RFC and MIP.
Some general thoughts:
Since its inception , mStable has been pioneering decentralised governance. MTA, an ERC-20 token, was and remains the instrument of the project’s governance - this is one of its two utilities (the other being incentivizing liquidity and decentralization). In the event of mStable winding up, I believe any solution should be crypto first, decentralised, open, and fair. It should also be transparent. The decision obviously has to come from MTA Governors. I agree that creating a self executing framework would make sense so that decision and execution are one.
I would be interested to hear from MTA holders and the community here, but I thought some precedents could be helpful:
Babylon Finance (Snapshot wallets with at least 2.6 BABL qualify for whitelist, eligible wallet can claim their share of the proceeds. 12 days later, smart contract recovered any proceeds that have not been claimed)
Tribe DAO (TRIBE holders can redeem for pro rata share of remaining DAO controlled assets)
Also liquidity provision on a DEX are examples of relevant crypto native technologies. I think it’s important that any approach is non-custodial, decentralized, with automated execution. These traits are core-values of the mStable community since its origin and should be part of any termination of the project.
Re the acquisition path:
Traditional acquisition include any “cash” balance, and I don’t see why a crypto one wouldn’t. I also think a self executing framework would make sense so that decision and execution are one would make sense here too.
I understand the project is being advised currently by an M&A advisor, Alastor. I’d like to hear from them here.
Finally happy to see this moved or edited to fit the correct format @mZeroNine
Thanks for the feedback. I think it would go against the decentralized nature of proposing if I were to edit posts of other users and presume what their ideations and thoughts might have been when writing them in the first place.
I thus recommend @0xloth to adapt the text to the above standardization, and then continue as suggested. I don’t think we have to re-open or re-do the thread overall, as it’s probably still going to be on the same tangent as the discussion.
Looking forward to seeing what this is evolving into!
Hey, @dimsome@mZeroNine
Agreeing with both your comments regarding this post being at the discussion stage rather than formal RFC one, I edited the header and label of the topic to reflect this
I propose that, when a few ideas regarding the potential way forward for mStable Treasury Assets have been collected and assessed, I post a more formal RFC using the content ideated
I’d assume that in the case of a shutdown, MTA holders/stakers would like to see a swap of MTA against DAO assets. A way to accomplish that could be to first swap all DAO assets for ETH and deploy a contract that enables the swap from MTA to ETH.
In the case of an acquisition, the management of DAO assets would reasonably be up to the acquiring party.
I think this is the most appropriate path - allows for an automated, opt-in distribution of a decentralised asset. Should be done on the basis of only circulating coins - ie coins still in treasury etc are burnt/dont participate
Hard to give a good evaluation of feasibility without getting into any details. Potentially it’s possible.
But what would that really solve? Someone still needs to define, then develop, then deploy the smart contract. Just removing responsibility from the last step doesn’t sound like it solves much.
I like this idea @richwgalvin@im_jacksonzeng@phenrikand, so this would imply a redemption at a fixed price, with the eligible MTA supply being (MTA circulating supply) - (MTA controlled by the DAO)
It seems that circulating MTA controlled by the DAO is only the Treasury
The DAO also controls the non-circulated supply i.e tokens in the Emission Controller and Staking contracts. These should not be eligible.
It could be also proposed to halt emissions and inflation from these two contracts in the case of a product shutdown as MTA utility would be non existent
@im_jacksonzeng regarding accelerated vesting, I imagine for investors it should be fast forward as they have already purchased their tokens. For other vesting schemes (Team and Advisors), not sure. Any idea on this @Cam@james.simpson?
Hey @0xloth, in terms of the agreements made with these various parties, I would see it as follows: Investors: entitled to full MTA allocation per investment agreement Advisors: entitled to full MTA allocation as earning period has ended (but tokens are still being delivered in some cases) Team: where current contributors receive MTA via stream from the DAO, these streams should be stopped when current agreements end as these tokens are only earned on a linear basis over the full length of the agreement (there would be an exception of some small bonus streams that are fully earned).
Regarding acceleration of Sablier streams - it seems like the types of solutions proposed above would provide liquidity at any time in the future so I’m not sure if there would be a good argument to accelerate any streams.
I’m wondering how exactly these streams and agreements look like, or how the DAO will ensure that only mentioned entities described get their streams issued in this way, and nothing happens outside of this scope?
Regarding acceleration, I agree with Cam in case of such a solution be found. I don’t understand why there’s such an incentivization of investors to give them their tokens acceleratedly, when everyone else has to wait their turn.
Didn’t they too sign an agreement to get these in a vested fashion? If so, and if Cam’s statement rings true, they should get the same treatment as everyone else in my opinion.
All investor/advisor streams mentioned here are current Sablier streams from Safes secured by TreausuryDAO signers so those signers will of course just act on whatever is approved through Governance. Streams to team members are controlled by the Builder subDAO so the Builder subDAO would need to cancel those streams and return MTA to to Treasury if requested to do through governance.
An MTA<>ETH swap with no expiry is probably the best route
MTA in treasury should be burned
Naturally, halting emissions from both contracts in the event of a shutdown with a predetermined date and time of execution will be necessary as MTA will no longer have utility beyond claims to the treasury
Why are we giving Investors/Advisors preferential treatment? Either all streams should be stopped or all streams continue. In effect we are again diluting community members and team allocation with new MTA that will result in less %-share for them.
Hey, I don’t think it’s about “preference” here but more about the nature of the agreements:
Investors have purchased tokens for which the delivery is contractually due.
Advisors have already provided services against tokens for which the delivery is contractually due.
Team members earn their MTA, on a linear basis, in exchange for providing services to the mStable DAO. Should the associated services stop, in the event of a shutdown, these streams should be stopped
