I dont think any governance proposal should involve to maintain the status quo. I dont think it is a sincere proposal to save the project. It is just another way of saying “let it die”. Because status quo will not solve any of the issues of mstable. There will still be no use case for MTA and there will still be no demand for mUSD. So the fair purposal should be;
1- Continue the project WITH RADICAL EVEN EXPERIMENTAL CHANGES
2- Try to sell it, If not possible continue with radical changes
3- Try to sell it, if not possible kill it
I’m not suggesting that option one would mean that things continue as normal for the next year; I just think specific action plans should be discussed separately once there is consensus on the basic decision to continuing investing in the project or not.
In terms of governance proposals having an option of maintaining the status quo in general, I think this should be the case to avoid forcing voters to choose between multiple options where they may not support any of those options.
This proposal seems to have more of a signal effect rather than being definite as I see it. So we are answering the question of which path should be explored further to adjust the mandate that is given to the BuilderSubDAO.
As of this moment, the Product & Engineering Team is a bit in a limbo. We have to continue to work what is required by the mandate that was given with the last funding request, while being not certain about the future of such work. The Team continues to work on Meta Vaults, albeit for learning purposes and for the public good if those are not ultimately used to deploy the contracts.
So it would be good to have more certainty about what paths are to be investigated.
I really like the suggestion of having a option as a fallback. From my perspective only these combination make sense though:
A. Pursue Acquisition or Merger, default to shutdown if not successful. B. Pursue a continuation and open up for proposals, default to shutdown if not successful. C. Pursue a shutdown.
I think a combination of “Sell but continue if not successful” does not make sense.
I also want to highlight that these are just indications. For instance, any Acquisition or Merger deal needs to be proposed to governance after, if such a deal is not proposed within a certain timeframe, the fallback option is the way to go.
Similarly with the continuation. We need a proper proposal with the details on how to continue in order to be implemented. If such a proposal is not made or voted in within a given timeframe, again fallback is shutdown.
I think this vote would be very helpful to see which direction is preferred and give the product and engineering team more certainty on what to focus. i.e. a shutdown needs to be prepared and spec’d out, smart contracts need to be coded, implemented, proposal for the shutdown procedure needs to be passed etc.
Its sad to see you go but I know the incredible effort, through both good and tough times, you have put into mstable all the way from the initial concept. I think your approach now is mature and transparent and thank you for it - and wish you the best in your future roles.
Re the options before us all now, our preference, for the sake of the project/team, is to rapidly pursue option 1 whilst at the same time defining a granular plan for Option 3. I think Henrik’s approach mentioned above (~3 FT team members with goal to povide long runway and leverage community for ideas/growth/implementation) is the best alternative should Option 1 come to nothing/take too long.
DACM is here to help in any way we can with the path(s) chosen.
I have to say that while I love the idea of continuing with a smaller team, a 3FT team (as @phenrikand and @richwgalvin are proposing) is not going to cut it. The way I see it, if we want the project to maintain some chances of success it will need to have at least 6 FTE:
3 smart contract devs (this could be reduced, but it will have a significant impact in the output)
1 front end
1 product manager
1 growth and marketing
Some additional money would still need to be spent in audits and probably marketing too.
Considering everything, in my opinion the options are:
Try to seek a merger/acquisition, if fails, shut-down
Try to seek a merger/acquisition, if fails, continue with smaller team (here we have two options, the one described above, and the one described by @trustindistrust, in which there would only be a part-time dev that would operate the Meta Vaults/Save)
Continue with smaller team (again, the same two options as above).
For the sake of simplicity, the options should only be three, and in case a “continue with smaller team” option wins, another vote to discuss what “smaller team” means (using concrete numbers of how much it would cost, how much runway it would imply and what would be the TVL requirements to achieve sustainability in each case).
I just wanted to say I think you’ve put in a huge amount of effort in the face of what turned out to be an impossible situation as you’ve outlined. Burnout in our field is real, particularly with such a long tenure as a founder from back when most people didn’t know what DeFi was.
I haven’t been a contributor for about a year, but I’ve been impressed seeing the launch of Meta Vaults. If the launch timing had been ideal, it’s not hard to imagine it capturing a lot more TVL and expanding beyond Convex.
The trouble is, as you have said, is reconciling the work needed to grow that platform with a limited runway and a much-reduced token value. High quality, original DeFi products take a lot of work. Compromising on the most expensive costs (Solidity devs, auditing) seems highly counterproductive for a yield-focused protocol.
The comments from Henrik and others about option 3 are completely unrealistic.
Wishing the current contributors the best of luck moving forward with their preferred option.
First, I want to express our gratitude and appreciation to James for your work during your time here. It is a hard time, and this transparent approach to communicating and collaborating on such a difficult decision has positively impacted us all.
As everyone else already said, it’s a complicated situation, and it goes without saying that I’m also sad about it. I had many ideas for the future of mStable and possibly new products, and I’m still processing the idea of a complete shutdown.
Here is my opinion on the options:
An acquisition from a DeFi project: would be the best and easiest path.
A full shutdown of the project: This should be the default fallback from any option and may be necessary if it doesn’t work out. We still have some cash in the treasury that would allow us to continue for some time, but more is needed to survive the bear market and achieve product-market fit with Meta Vaults.
Continuing on with a very slim team to extend the runway: I feel like this is the worst idea because the team is the most valuable thing we currently have. Making a very slim team will slow the development process to almost a maintenance mode, and we won’t be competitive enough in the market.
many thanks for all the diverse feedback, and it is much appreciated as always.
The core contributors from the operational side of the Builder subDAO with some governance-related advise from myself have begun crafting and consolidating a formal proposal on all the comments and feedback provided, and I’ll be uploading this proposal later to GitHub.
Please continue all relevant discussion in the upcoming MIP for further feedback and ideation around the best way forward for mStable and ensuring all relevant feedback was captured there.
A quick footnote to the letter: I have spoken to core contributors and March 31st will be my last day as a core contributor. I will stop any signer duties that I’ve been elected for before this date.
I’ve decided that I will be abstaining from voting on votes regarding the future direction of mStable (that is MIP 29 and 30). I brought up the discussion here and it doesn’t feel right to me to influence the outcome, especially given I’m leaving in whichever scenario. I’d prefer to leave it to the broader community and stakeholder groups. I’ll help implement whatever decision is made in my final weeks at the project.
Looking forward to seeing where the community decide mStable should go next.
