MIP 29 - Adjustment of Builder SubDAO Mandate

Posted on behalf of the operational core contributor team of the Builder subDAO

Simple Summary

It is proposed that the mStable project and its Builder subDAO refocus its mandate to find a clear direction forward for the DAO. This comes after suggestions given by core contributors, community and Meta Governors in the forum in this RFC.


Several mStable community members, stakeholders and core contributors have voiced concerns that the mStable project is facing major structural challenges, stemming from the MTA token price and an unsustainable burn rate. From these concerns, the options of a shutdown and acquisition have been proposed.

Conversely, several mStable community members, stakeholders and core contributors have written comments in this recent RFC differing potential future paths for mStable.

It is proposed that a four-week period is opened at resolution of this MIP in which:

  • Those who wish to reform and bring mStable forward can create and publish a formal proposal outlining their plan;
  • The Builder subDAO shifts its focus to facilitating merger or acquisition talks as well as assessing the requirements to shutdown the project.

The purpose of this four week period would be to have all proposals (continuation, acquisition, shutdown) published for consideration and voting in a follow-up MIP.


Several mStable contributors, community members and stakeholders have agreed that the project is facing major structural challenges, which can be summarised as:

  • the project will find it very difficult raise with the current token given its value;
  • the protocol isn’t earning enough from its products to self-sustain;
  • the DAO’s runway is continuing to decrease each month and will be depleted at current burn within 12 or so months.

From these concerns, the options of a shutdown and of an acquisition were proposed.

Conversely, several mStable community members, stakeholders and core contributors have written comments in this recent RFC outlying differing potential future paths for mStable, such as continuing with a slim team made up of existing core contributors, hiring a new, smaller team, or reforming the project’s product line.

In light of these various opinions, it is proposed that MTA voters allows a period of four weeks to get more clarity and certainty on each of these paths.

Again, those who want to reform and bring mStable forward would be invited to create and publish a formal proposal about how this would be done.

In the meantime, the Builder subDAO is proposing to shift its focus on:

  • Facilitating merger or acquisition talks
  • Work with other parties to discuss potential strategies to allow the project to continue
  • Assist with governance proposals
  • Assess requirements to shutdown

The primary purpose of this vote is for MTA governors to decide if it is worth allowing a period of time for proposals to be presented which could allow the acquisition or continuation of the mStableDAO, as well as to understand what a shutdown would look like.
Additionally, this vote will guide the current Builder subDAO and Ecosystem subDAO in how resources should be allocated immediately following its resolution.


Voting options:

  1. Shift Builder subDAO focus, for a limited period of seven weeks starting upon resolution of the proposal - The mandate would be: search for acquisition options from other DeFi projects as well as assessing requirements to shutdown. During the first four weeks, any proposal can be made by any party which would allow the mStableDAO to continue to operate in some way.
    After the initial four week period has elapsed, a new MIP would be created so that governors can vote on all available options.
  2. Pursue a shutdown as soon as possible - The mandate would be: create a proposal that outlines a plan to shutdown the mStable DAO and its product/protocol as soon as practicable. There would be no attempt at seeking acquisition or fielding proposals to continue the project.
  3. Reject this MIP

Notes about option 1

  • If a project or entity is interested in acquiring mStable, they must submit a proposal to do so within this four week period. If there are no submissions within this timeframe, the DAO will assume there are no interested parties.
  • If there is somebody or a group of people who would like to propose a way to continue mStable, they must submit a proposal to do so within this four week period. If there are no submissions within this timeframe, the DAO will assume there is not a path to continue building mStable.
  • At the end of this four week period, all submissions for acquisitions and continuing mStable will be put together in a vote, along with a choice to fully shutdown the project. Each choice will have an accompanying specification, including the estimated costs associated with a shutdown option. There will also be options to abstain from voting or to reject all options.
  • If there are no submissions for acquisitions or continuing mStable within this period, a shutdown will be proposed. The specification for this shutdown will have been written during the four week period to give the mStable community time to consider it and provide feedback.

Builder subDAO Funding

  • If first voting option is passed, the Builder subDAO proposes to carry out its new mandate using the currently approved funding until a clear path forward is established.
  • If the second voting option is passed, the Builder subDAO proposes to use currently approved funding for a short period until a new shutdown funding budget is presented as part the full shutdown proposal.

For the first voting option, it is proposed to set prerequisites in order to avoid any malicious governance behavior during this period:

  1. Proposers of a reform or acquisition strategy will need to lead the governance process around this proposal and takes ownership of its execution. This is done to avoid trolling or suggestions without any follow-up skin in the game.
  2. The Builder subDAO will update the mStable community via forum after two weeks on an update on current acquisition progress. It is expected a formal proposal be made in the following, final 2 weeks, by any party interested in acquiring mStable.
  3. It is strongly suggested interested parties (to continue mStable or to acquire it) indicate interest in submission as soon as possible to allow for feedback.

In order to facilitate the next steps for Governance, the following clauses are also proposed to be added to the vote to ease complexity and ensure integrity of previously agreed-upon processes:

  1. All regular governance processes be halted that coincide and would disrupt this process of a higher priority - In detail, this means that new signer elections & upcoming monthly Governance Calls onwards will be halted until the resolution and carrying out of both MIP 29 and MIP 30 have concluded. This will ensure the integrity of the multisig is retained and the remaining runway and priorities maximized towards resolving this challenge.

Next Steps

Pending no significant changes to its content, this proposal will be taken to a Snapshot vote on Monday, the 6th of February 2023.

Voting will be open for a 5 days window to give adequate time for a concurrent discussion. Governors can change their vote at any time should the discussion sway their decision. We look forward to hearing what MTA token holders have to say and seeing how they cast their votes.

1 Like

Hey @mZeroNine
Thanks for posting these specifications. I’m aligned with the two options forward proposed.
I think allowing a specific time window to find an acquirer and/or leave the floor open for reform proposals makes a lot of sense without compromising long-term value
I also really like this 2-week update idea to have the mStable community looped in early enough. In the case of rapid developments worth sharing, I even think an update could be shared earlier


Hey everyone,
This is Georges from Athena Consulting. I would like to give my opinion on the situation and also propose a solution that the community may find fit.
First of all, I do not think that a shutdown is any good for the community, investors and ecosystem as a whole. If shutting down is the end goal both ways, then it would be preferable to try to extend it until a new bull market comes around.
Second of all, the runway to build is ~12 months, and I am 100% sure that the runway could be increased by 50-100% just by reducing costs aggressively, and working with third-party subcontractors.
After the runway is increased, the main goal of the project would be to increase the value of the token and increase its intellectual property so that it is possible to raise in the next bull market at an acceptable valuation. From there, mStable could look for either a listing on a CEX or an exit strategy that the community sees fit. But with the whole project in shambles right now, there is a lot of work to be done.
When a team can take over, a strong detailed proposal of every step should be taken into consideration and a lot of meetings will take place for:

  1. Understanding the reason of the failure, to be able to reform and create a sustainable protocol.
  2. Implement the new strategies to raise the IP and valuation of mStable and get the project back on track.

We believe that the community, if they decide to do so, deserves a real chance for the project to succeed rather than just shutting down

This is considered a crisis situation, and the longer the wait the harder it is to get out of it.

At Athena Consulting, we do not have a problem to try and reform or manage the DAO and build forward to a clear road during the bull market. We will also use our connections at exchanges, protocols and VCs to be able to find suitable funding for the project. This will need a lot of reform and a lot of work and trust from the community. Our firm has partnerships with trusted and cheap subcontractors, and our team has experience in the space.

AGAIN, this does not mean that we SHOULD take over the reform, but just an explanation that there is a chance and it is possible if the right strategies are implemented.

We are open to move this discussion further if the community is interested.


I would personally be interested to see your/Athena Consulting’s way to proceed moving forward given the current circumstance.

I feel we could amplify and significantly reduce overhead if a proposed RFC that details the planned takeover would be made public either in this thread or a dedicated thread on the forum (depending on size of proposal) moving forward, prior to any resolution. I think it’s clear to say at this stage that any time saved for the DAO is a serious consideration for all Governors. Our burn rate is incredible, and doing a due diligence check now, in line with the proposed acquisition strategy the Builder subDAO put forward, I think there’s a real space here to discuss opportunities in the public.

The biggest challenge, as far as I understand it, was related to the MTA token, the MTA token price, related legal challenges, and overall runway on the side of the Builder subDAO - if you’re happy to discuss either one of these in public together with the team and get core contributors on the operational side involved in these discussions, I think it be a fair proposal to make for governors to chose upon in the aftermath of this MIP, and in an expedited way so.

I see a dwindling chance to make it work the longer we wait, so let’s get some discussions going in the open for proposed mergers or takeovers as soon as humanly possible.


Thank you for the reply.
To be able to actually understand how to solve the burn rate and increase the runway as much as possible, then we would need a deeper internal look into how cash is being spent in the DAO. We also would like to propose hiring our subcontractors, which we believe are much cheaper than developers from US/EU with the same quality of work.
This is the first step. Then, we work on increasing the runway to 24-36 months minimum. This could impact rate of production and delivery, but from our experience this comes second as to survival, since opportunity only comes for those that exist.
With a long runway, we can start focusing on what we can build in the short term and what we can improve on to create value that investors, protocols and new users would be interested in.
From there, we would focus on working closely on any reform that would benefit the protocol as a whole.
One point we would like to discuss is for example how important is the MTA token as a whole following our productivity and utility theorems. In our opinion, this token is theoretically made to go down to 0 in value over time, which reduces the value of the protocol as a whole. We could expand on a way to move the MTA holders to other tokens in the ecosystem that are yield bearing and increase in value over time OR add utility to the MTA token so it is mathematically feasible for the token to become a value accruing token.
Again, there is a lot of research and work that needs to be taken into consideration, but there is definitely a solution that lies in reforming and restructuring.
As a team, we have no problem being hired by the DAO for the reform or even handling the project to reach a sustainable phase before retreating to a DAO voted team when the market as a whole has recovered, especially mStable.

1 Like

Thanks a lot for your exhaustive reply, and it is much appreciated!

I think many things will need to be discussed from the operational side of the current Builder subDAO. I think that I’m not in a position to fully discuss this, as I don’t really know what exactly has led to the current circumstance fully.

I’d in all honesty suggest to create a RFC as per MIP-20 to get a discussion kicked off with the key stakeholders of said entities and then discuss potential avenues and opportunities to offboard into Athena, even if this is prior to any governance discussion resolved here, as it will pave a clear pathway for potential voting participants to see alternatives and ways to this alternative outside of the current Builder subDAO narrative proposed.

In this way, we can also seclude separate avenues, while still pertaining to this MIP in essence, and we can post updates here if they are deemed necessary to expedite or otherwise influence the voting to take place for MIP 29.

Thanks again for proposing this, and I’m looking forward to seeing a healthy and fruitsome discussion take place on potential avenues the DAO can take for a good resolution for the highest good of all MTA holders :innocent:


No problem @mZeroNine !
We just created an RFC for comments.
Let us move the conversation there and hopefully discuss what is best for the community.


Hey guys,
It is obvious that the existing team is in favor of shutting down the project. Is there anyone who can shed light on the reasons behind the consensus to shut down the project without even trying? I urge you to reconsider your stance and work towards finding a solution that will keep the project alive, or is there a member already silently willing to take on a leadership role and drive the necessary reforms? I encourage anyone who feels uncertain about their ability to lead or lacks a complete plan, but is still willing to try, to come forward and express their readiness to do their best.

Thanks for the proposal, glad we are making progress and try to find some certainty in the whole process. I am welcoming that the entirety of MTA holders are able to have a say in the future of mStable and that we are having an open discussion on these points.

A few remarks:

I would remove this kind of rhetoric from the proposal. Let’s be more facts based with proposals, rather than assuming intentions of each Builder subDAO member. In reality it’s more complicated than stated.

And secondly, the whole point of this proposal is to gather proposals for a given time period, so the time after the vote is resolved would be in our open governance process the first instance of proposing anything officially.

Same here, the word desire is really misplaced.

Curious why we have to repeat this so many times?

What is the criteria there for success? I assume just governance for any proposal would take minimum of 3 weeks. So in totality there is one 1 weeks to work on a path?

Is this not already the case? Anyone writing a proposal has ownership over the process.

Last words

In the end, this proposal is a bit unnecessary.

  • The only option is really shutdown, because that will be the default in each option. Is there a third option?

  • The path forward or acquisition proposals would have been already something that could be proposed via normal governance route.
    We don’t need really to explicitly vote for the possibility to start a proposal or the discussion. That is already something that the governance process can facilitate and how decentralised governance should work.

  • The intention of this proposal should be really to ask for permissions adjust the mandate for the funding request and alter all regular governance processes. This is really what will be changed in affect.

  • The title “Decide on the Future for mStable” does not reflect the true nature of this proposal. There is no real decision being made here. Each option defaults to shutdown. And as mentioned earlier, this is just changing in affect the mandate and regular governance processes.

1 Like
  • @hedgeh0g I think there is more nuance to your first sentence. I (and the rest of the existing team I assume ) are very open to any of the options proposed. Personally, I think the M&A route makes the most sense as we could not find so far a realistic way to reform internally knowing the current structural challenges. I’m sure that current team members would use the forum should this change, but that’s the current status.
    I don’t think anyone in the core team nor in the broader community wants to see mStable shutdown without trying out the few options outlined in this proposal: - opening up the floor to any reform proposals - finding a buyer, both in a specific time-window
    These two options have the highest chance of maximizing value for MTA holders which is the greatest concern of the current team.

  • @dimsome to your point, the way I see the shutdown presented in the first option is a “last resort” in case of lack of success of our attempts. What this option gives is a mandate to allocate dedicated time and effort for this purpose. A simple “shutdown” option would not illustrate this shift in focus. Maybe we could make it more obvious I agree

  • I also agree with you that should the M&A route be voted on, we would need metrics to assess its success and should present them during the 2-week review.
    Some ideas for this success metrics: expression of a desire to write a buyer proposal and status of the draft, number of meetings had with the target, acquisition price ranges, premium contemplated, operations contemplated with the target (partial/full merger/acquisition, etc)

  • @dimsome regarding a third option, what would you like to see offered? I think the first option leaves the door open to any structured proposition while capping “status quo” costs to a month

I agree with @dimsome comments, I don’t think that there was a lack of intention of many members of the builder subDAO to continue building within mStable.

Moreover, on the RFC everyone was talking about three options. Why are there only two here? While we couldn’t find consensus on the details of the third option (slim team), this is something that could be discussed further down the line if that option were to win. Furthermore, one of the main stakeholders proposed that the fallback option to not achieving an M&A should be to continue with a slim team. Considering the consensus found that probably the best option was to seek an M&A, in my opinion the three options should be:

  • Seek an acquisition, and if it is not possible, shut down the project.
  • Seek an acquisition, and if it is not possible, continue with a slim team.
  • Continue with a slim team
1 Like

@nesk I think any slim team proposal is welcome and included in the first option. The point of this first option is to allow/open any form of continuation. I feel it needs to be expressed more clearly as it creates confusion.
Imo because it involves a reform of the Builder DAO in its current form (i.e slimming down the team), it should be a new proposal with a dedicated plan

Just from how proposals work. There can be no change until a proposal is voted in. So the proposal proposes a change. A change is then voted in and executed.

If the proposal is going to get voted on as is, then there would be a change regardless of choice. You see how this is not really a proposal anymore.

The proposal should clearly state on how things are proposed to change. This can be rejected by MTA governance.

1 Like

If I understand correctly, then option 1 would give 4 weeks for different proposals, and then there would need to be another vote to implement such proposal?
I think the best way forward is to enable a period of 4 weeks in which we would listen to all different proposals and then there would be a vote, in which all of them would be options, along with shutdown and “No changes” as Dimitri just said

1 Like

What would a shutdown look like?

  • Are contract upgrades made impossible?
  • Will V1 be segmented from V2?
  • Will there be an MTA buyback with remaining funds?

I am not opposed to a shutdown, however my proposal would be to cut all funding into V2. All remaining work is on a V1 redesign so that makes the code have no expenses from the protocol side – no mBasket asset management gas costs and no server hosting costs and no multi-sig for contract upgradeability. That the V1 protocol revenue go to a monthly claim for MTA holders. V2 gets a forked token and developers can continue to working on that project with a large potential upside in their spare time for equity only.


Along this line, we could enlist Rook to have their arb network maintain the ratio on the AMM. I think this was on the table last year, but then went no where for some reason.

Of course, I’m fully on board with the contracts being fixed, as this is one of my asks for any outcome, shutdown or no.

For completeness, from Discord from yourself:

My dream would be that if V1 forked from the project and became lean and profitable that it could introduce Frax to the mBasket and redesign its save strategies. Then mUSD:FraxBP on CVX would be 10%+25% Frax and could be bribed with MTA and FXS. I would only enable gauges for Votium, Frax/mUSD on Polygon, and ETH:MTA on Balancer. I would target the MTA be RFV investment in other protocols – namely FXS, CVX, and CRV. That every MTA represents control over x% of those tokens and promote the flywheel ponzinomics everyone was hype about one and a half years ago. I wouldn’t let users vote on how to use the FXS, CVX, CRV that their MTA controls. MTA would just always vote for its own mUSD:FraxBP.

I’m pretty down with all of that.


I think there is an important distinction between a desire to “continuing to build within mStable” and being willing to propose and lead a major restructure and manage a team going forward. From my point of view, I haven’t seen anyone in the current team express a desire to take on the latter role, which would be critical to continuing with a slimmed down team. In saying that, I think it is fair to give others on the team a chance to put forward a proposal over the next few weeks, and I would be very happy to see this.

I had input in drafting the proposal shared above and the motivation for reducing to two options was that either a continuation with a slim team or a M/A would each require a separate proposal to be put forward by a third party and therefore would not have a major impact on the immediate next steps.

I agree with much of the feedback provided in this thread, and think it makes sense to focus this proposal on determining the mandate/next steps for the Builder subDAO in the short term, while clarifying clear timeframes to allow proposals from any party.

I don’t think a simple vote for ‘continue with a slim team’ makes sense as I don’t see a path to get there without a proposal from someone clearly outlining what this would look like.

Regarding having the option of ‘no change’ as a choice, I generally agree that there should always be an option to reject a proposal (I expressed this view myself in the original RFC), so happy to have this included as an option.

Regarding comments from @Jeshli and @trustindistrust, I think this sort of options can be put forward as proposals over the next four weeks and I am sure the current team could help to determine viability and cost.


gm everyone :sunglasses:

Thank you so very much for all the insights and feedback provided to the original MIP draft. The operational core contributors of the Builder subDAO have now altered the text and included all the suggestions and criticisms voiced here, and I have taken the liberty to edit and update the first post accordingly.

You can see the exact changes made by clicking on the pencil on the right side of the post.

It would be GREAT if all of you who voiced concerns could quickly align and signal consensus on the updated MIP, so we can push these changes to GitHub ASAP and not miss our deadline for the Monday Snapshot.

If there are still major concerns or vetoes, please voice them as soon as humanly possible, as otherwise we’ll lose the opportunity to move this to a Snapshot next Monday (albeit of course, we should still use due diligence and care to not rush this process).

Thanks, and have a great day ahead!


This is a lot better, thanks a lot for taking all the feedback. I support this MIP


Thanks for the adjustments and thanks for taking our feedback and incorporating this into the proposal.

I would also like to signal my support for Option 1: Shift Builder subDAO focus, for a limited period of seven weeks starting upon resolution of the proposal.

I think it’s important for the builderSubDAO to have this shift in focus and to have it formally verified by governance. This would allow us to make any preparation if we need to but also allow us to seek a solution that would be more beneficial for MTA holders.