[Discussion] Improve mStable Accessibility and Increase MTA Utility & Value Accrual


Building upon the low-hanging fruit addressed by PDP 22, the logical next step for mStable is to focus on attracting more liquidity.

Given mStable’s greater capital efficiency than Curve (and thus higher base yield–roughly 10x), logically it wouldn’t make sense for an LP to choose Curve over mStable. So why does Curve have over 160x more liquidity than mStable?

Much of this liquidity discrepancy can be attributed to Curve’s accessibility to yield aggregators, whereas mStable, by putting a lock on MTA rewards and requiring users to purchase and stake MTA in order to earn boosted rewards, is not accessible to yield aggregators.

Three proposed components would help resolve this discrepancy and attract more liquidity, while also enabling greater value accrual and utility for MTA:

  1. Develop a pooled boosting layer in which users can stake MTA and pool their boost for yield aggregators and other depositors to use. Those who stake and pool their MTA will earn a cut of the boost, earning cash flow on their MTA.
  2. Remove the time lock on MTA rewards for liquidity providers.
  3. Increase buy & make allocation to 30% of fees generated.


mStable’s current competitive advantages reside in the capital efficiency and reflexivity inherent to its design. As a result, the recent base yield (without gov token rewards) of Save hovers around 10%, whereas Curve’s 3Pool has consistently hovered under 1%.

Despite this massive edge, mStable’s time lock on MTA rewards and requirement to purchase & stake MTA to receive boosted rewards do not allow yield aggregators and other large depositors to take advantage of mStable’s higher base yield. Yield aggregators require instant liquidity (cannot have capital locked up) and cannot take any principal risk (i.e. buying MTA puts them at risk of underperforming USD stablecoins).

Becoming yield-aggregator compatible is the last missing piece for mStable. If we resolve this compatibility issue and level the playing field with Curve, we would become the preferred place to LP (lend out idle bAssets → higher base APY).

If mStable draws liquidity from yield aggs, it will improve its swap execution and drive swap volume, generating swap fees & Save APY and attracting even more liquidity (i.e. the reflexivity story everyone loves about mStable).


When thinking about the process to integrate yield aggregators, the #1 consideration/concern is to ensure sell pressure on MTA is mitigated and value accrues to MTA. If no value accrues, what is the point of drawing more liquidity?

Convex-style pooling layer enters the chat

The basic mechanics of this feature would be to allow users to stake, lock, and pool their MTA to allow yield aggregators and other depositors to deposit through their pooled boost. These depositors could earn the boost without having to go through the prohibitive process of buying and staking MTA with their own capital. The MTA poolers earn a cut of the boosted yield (currently staked CRV poolers on Convex take 10% rake). Everyone wins.

In addition to the pooled boost, mStable should also remove the lockup on rewards to resolve the instant liquidity problem and further level the playing field against Curve.

Lastly, as mStable will attract more liquidity, drive more swap volume, and generate more fees if it implements this solution, we should increase the buy & make allocation to 30% of overall fees. If we’re drastically improving the experience for LPs, we should be compensated accordingly and improve value accrual to MTA. 30% still offers a competitive advantage over Curve who takes a 50% cut of fees from LPs.

At a high level, why is this a good idea?

  • Convex’s pooled boost on top of Curve launched ~2 months ago and already has $3.9 billion TVL, which eventually flows to Curve, improving their liquidity. This rapid traction conveys the benefit this feature provides to LPs and the subsequent benefit provided to the underlying protocol.

  • Value Accrual: By earning a cut of the boost, MTA stakers now have a way to generate cash flow from their MTA, generating more token utility. mStable now can also provide a staking yield that isn’t fully based upon emissions to directly to stakers (thinking longer term here). Increasing buyback & make allocation to 30% still offers an advantage over our competition, but also accrues more value to MTA, benefiting holders and our treasury (~90% MTA).

  • Pooled staked MTA will be locked, leading to greater scarcity and more MTA supply removed from the market, reducing pressure on the token. You have seen CRV continue to hold its value in recent months using this implementation even in the face of an extremely aggressive emission schedule.

Incentives for staked MTA poolers:

  • Earn cash flow from a large pool of capital (yield agg capital, etc.) .

  • Retain upside in MTA without needing to commit capital to Save/Pools in order to take advantage of staking. Currently, users need stablecoins or btc in addition to MTA to take advantage of their boost. Not everyone has that much capital available or desires to hold those assets, reducing their incentive to buy and stake MTA. This solution provides a direct source of cash flow for buying and staking MTA → again, utility + value accrual.

Benefits/how this addresses challenges mStable currently faces

  1. Improves liquidity/TVL. Yield aggregators would no longer have to take principal risk to access MTA boost and would retain instant liquidity on all yield owed to them, which is necessary since any of their users can withdraw at any time. Removing these prohibitive barriers allows us to better compete for liquidity with Curve, which has Convex pooling & no lockups. As mentioned at the outset we should actually outcompete Curve because our base APY is higher.

  2. Better swap execution. Ceteris paribus, swap execution is determined by (1) swap fee (2) liquidity. We have already addressed (1), now we need to address the other (more important) part of the equation (2) liquidity. Better swap execution unlocks more potential for value accrual/greater fee revenue.

  3. Added utility and value accrual to MTA without needing to use recollateralization as a means to generate utility, which as we discussed in Discord, causes the Protocol to have to dump its own token at the worst time (saw that recently with SNX).

  4. Helps resolve treasury concentration in MTA/project funding needs. mStable could bootstrap the Convex-style MTA boost pool with some of our treasury’s MTA to get that feature off the ground and then gradually sell off the MTA we receive as cash flow. This implementation offers value back to the protocol and is preferred rather than selling our existing asset base of MTA for funding, which hurts our longevity. Greater swap volume & fees from improved liquidity + expanded buy & make allocation also help support MTA and the value of our treasury.

  5. Aligns with the existing effort to redesign/revamp MTA staking later this year.

I welcome thoughts and technical/implementation considerations before potentially moving to a formal proposal.

TL,DR: mStable’s capital efficient, innovative design is superior to Curve. Curve has more market share currently because they have more liquidity as the the “go-to” for yield aggregators. Trust me, I work for a yield agg, and we couldn’t integrate mStable right now if we tried. Yet we LP on Curve. Let’s level the playing field, iterate on our current design, leverage our strengths, and go become the next DeFi blue chip.


I’ve read through this a few times now, and I’m still noodling on all the details, but my first impression is this idea is total aces.

I know our efforts are directed in a few different places right now (more integrations, new fpools, new mAssets [mstketh ftw!], further improving and decentralizing governance, standing up a recollateralisation system… ok maybe more than a few!), all of which are immensely valuable to expanding mStable’s usage, visibility, and role in the ecosystem – however, I believe that overhauling MTA’s purpose and value, which really is the core token of the protocol, will put us on a path to further unlocking mStable’s full potential.

I think right now newcomers to mStable may feel as though MTA is a bit on the backburner. The mStable product suite is excellent, and only getting better, but the MTA token on the other hand is facing a few issues. It’s been handed a tough emissions schedule, it’s sitting at a somewhat awkward time for staking benefits (given max lockup is only a few months at this point), and it doesn’t have many partnership integrations that give it a ton of use (though I know more are coming!). On top of this its gone through some fairly harsh price action this year, which can be concerning to outsiders given 90+% of the mStable treasury is made up of MTA.

All that being said though, I think moving forward with an idea like this, though perhaps bold and comes with some heavy lifting, brings MTA’s value and thus the exciting prospect of owning MTA to the forefront along with the amazing suite of products that mStable offers. I think this is a great step towards creating a cohesive protocol, product, and investment experience, which is really what you find with the best of the best in this space.

I think @Cold_Summer has done an excellent job outlining all the specifics in this post, so I won’t touch on them any further, but I fully support this idea and hope we can implement something along these lines.


I also think it’s worth mStable boldly throwing its hat in the ring here. I asked a rhetorical question a few weeks ago that @Cold_Summer didn’t take as rhetorical: “Save yields are so much better than 3pool…so why is anyone LPing in 3pool?” And the writeup above is the fleshed-out version of his answer, and it really resonates with me. There are many factors here, and so much that we simply can’t discover without trying the experiment… But this seems like an experiment worth trying. My dream is something like this generating some positive buzz, and then that getting amplified by the very factor that may make mStable seem quiet today – its longevity and pedigree! Imagine if Convex had happened, but instead of atop a new protocol, within an existing protocol with a few years of Lindy, cheap Nexus Mutual cover on offer, etc. I don’t know how big it would be, but I would love to find out. :slight_smile:


This is well thought out and well-written post. I don’t have anything else to add. For me, the highlight is the ability for Yield aggregators to delegate their risk onto the poolers without putting in more capital and then making the risk more attractive to MTA stakers / poolers by earning a cut on the boost. Treasury being 90% made of the native asset i.e. MTA, needs mechanics like this to retain any value long-term as we have already seen in the face of volatile market conditions.

I fully support this proposal and would love to see something like this out in production.


Thanks Cold Summer. Fantastic proposal.

  • your question is pretty much who is our customer when it comes to LPing and increasing liquidity. You are correct that DeFi is moving very much the way of aggregators and we should ensure that our protocol is composable with those important customers. The main impact that we need to think about is ensuring that any changes do not lead to a wholesale dump of MTA given that’s what those strategies usually are based on.
  • I think the Convex MTA solution is a no-brainer. @alsco77 rightly points out that the vast majority of our 3x boosted stakers are early investors and/or close collaborators meaning that normal investors either can’t or don’t want to have the price exposure to MTA in order to get the boost. This gives more utility to MTA and an additional income stream. I have no objections to this.

In terms of 30% buy back this is something we will look at as we spec out staking v2. The protocol could also implement a direct fee collection like Curve, but denominated in mAssets (or a Balancer LP token that represents a pool of these tokens). Lessons can be learned from Sushibar and xSushi here too. Whatever the case, there needs to be a strong reason for MTA holders to support this as they won’t want to “pay” for growth if it means significant dilution of MTA value without the protection of vesting. 30% buy back seems like a smart solution. Interested if there’s anything more that could be done or other approaches.

My main question is for the protocol developers. How hard is it to make a convex style product? @naddison @alsco77


Appreciate the comments, James! To your first point about ensuring MTA is protected, that was my #1 goal when thinking through this proposal. To provide more concrete data/reasoning behind that, the circulating supply of CRV is actually lower today than it was a month ago despite CRV’s aggressive emission schedule because of the strong incentives created to lock up CRV and earn cash flow via Convex. That’s quite an amazing statistic given the majority of Curve’s yield actually comes from the emission of their own token and shows how powerful this could be for MTA’s tokenomics. In addition, we have a much higher base yield that’s less reliant on MTA emissions, which positions us to remain an attractive place to LP even @ scale of large TVL. We really just need ~5% yield to come from the pooled boost to start to look comparatively better. In that case, MTA emissions make up a comparatively small % of yield, thus sell pressure is lower on an incremental (per unit of TVL basis) and counteracted by the amount being locked away to earn cash flow by pooling.

Aggregators and large depositors (think funds on behalf on institutional capital entering the space, Web2 apps like blockfi, etc.) will likely continue to grow in share of capital allocation (think how trad fi evolved from individual stock picking → ETFs managed for you), so it’s critical that we accommodate them. This implementation accommodates them in a way where the incentives make sense. Yield aggs have comparatively more capital and want to LP, but can’t buy MTA to access the boost to get attractive yield. Individuals want to hold MTA and earn cash flow from it, but don’t have the scale of capital to take advantage of their boost. Further, by creating an additional way to earn cash flow from MTA, you’re also creating additional demand for the token that doesn’t even exist yet today. MTA is well-prioritized in this model.


Chiming in here - firstly @Cold_Summer thank you for taking the time to lay out your proposal here for us all to consider.

A lot of what I wanted to say has already been covered by @james.simpson, and the primary question I have in my head too revolves around the dev work needed to make these changes to the mStable protocol. I’ll leave that to @alsco77 and @naddison to weigh in on.

From a different perspective, I think we are at a point in the project’s life where we should be open minded about experimentation with what mStable is and how we shape the protocol. A proposal like this, with its rationale and a hypothesis of the benefits we expect to see, articulated in a clear way, is worth pursuing in my opinion. Assuming the dev work isn’t a prohibitive hurdle, which I hope it won’t be, I am for us pursuing this proposal.


Thanks for that explanation Cold Summer.

How’s this as a summary?

Negatives to mitigate:

  • aggregators dumping earned tokens

Mitigation strategies:

  • additional cash flow from Convex style pool
  • reduced supply as smaller users lock up their MTA to get cash flow
  • additional TVL and system revenue from aggregators deposits > more buy back and make
  • increasing % of buybacks to say 30% (maybe we can do that on a tvl kpi basis? wdyt?)

I wonder if we can merge this convex style pool into staking v2? :thinking:

1 Like

Also, would it be possible for Convex to incorporate us? Or are they completely affiliated with Curve? @Cold_Summer

Just brainstorming here re increasing MTA utility (separate to MTA pooling):

  • Deploy a pool w/ a required min-cap & timelock.
  • Users deposit mUSD/mBTC to pool.
  • When min-cap threshold is met, the expected interest rate (or a % of) is taken as an upfront fee.
  • Use fee to purchase MTA & lock for pool timelock length. Mint imUSD/imBTC & deposit to imUSD/imBTC Vault.
  • MTA can be withdrawn pro-rata by users at any time & their principle (+ staked MTA pro-rata) is unlocked at the end of the timelock.

tl;dr: use upfront interest to purchase & lock MTA; users receive boosted rewards + interest in MTA

EDIT: Realise this is a little off-topic re proposal – just exploring other circular narratives for MTA lockup + group boosts

Just so I understand this correctly:

  • this is a separate idea to the MTA pool for boosting, extending on the concept for mAssets.
  • how is the “expected interest rate” determined? are you suggesting people sell a “yield token” that represents any yield earned during the term of lock, creating fixed rate save rates? Usually the reason for this is for speculating on Save’s interest rates or locking in a rate. Sounds like you are suggesting the protocol buys it or takes it as a fee?
  • Protocol then uses the yield token to buy back MTA (with a balancer pool?). Where does imUSD and vault come into it?

I’m a little confused :sweat_smile:

Maybe I ran with this too quickly haha

  • Idea is separate to MTA pool for boosting
  • It’s basically just a syndicate for imAssets. An upfront fee taken (once there is enough capital in the pool) that approximates to interest gain over the timelock period. Fee is used to purchase MTA for the pool and give a boost to depositers. Timelock period ends, the pool has accrued in interest roughly the fee taken for MTA (might be a little more / less depending on performance of Save & how high/low fee % was set to).

Ahh ok I think I understand now.

  • User deposits imUSD/imBTC etc.
  • Pays say equivalent of say 8% APY, proportionate to length of lock
  • That fee is used to buy back MTA which is given to depositors
  • Those in the pool get a boost for MTA rewards on mStable
  • User earns interest over the period roughly equal to fee taken at the start, so they are close to net when the lock is over, but have gained the boost


Correct! They get the boost & the pro-rata fee taken in MTA (once it’s unstaked after timelock)

1 Like

Awesome proposal @Cold_Summer :exploding_head:

From a user perspective (MTA holder), would you expect this to be a separate protocol/product like Convex or offered as part of the native mStable dApp?

Side question: what happens after this discussion? Say there is informal agreement this is a good idea, what happens next?


Good summary, and just a point to chew on is that this general approach has proven to be successful, so it’s not like we’re walking in completely blind. The goal of raising this now is definitely to take advantage of synergies with staking v2 (excuse my ignorance of any work that’s already been done, but perhaps this could be a key part of that redesign?).

Regarding the Convex point, Curve gave Convex a bounty to design the system and I believe it was completed in about ~4.5 months (someone correct me if I’m wrong there). Keep in mind Curve has many more pools and Convex also introduced their own token as an additional complexity, so that timeline could potentially be less if we tried to do it in-house (Alex is welcome to provide more color on that). Convex does seem to have very close ties to Curve, so I’m not sure how they would feel about working with us considering we could be seen as a “competitor” to Curve. They also would likely want to introduce their own token and/or have a cut of the revenue flow their way, so there are trade-offs with trying to engage them, but it might be worth exploring.

@itsJeremiahS we’ll have to figure out what the implementation exactly could look like (some of that discussion above), but ideally we could make it a tab on our front end, so it’s easy to navigate to. Seems like most agree this is a good idea (I’ve spoken to Alex as well), but now the major implementation question comes in the form of determining bandwidth of the dev team and/or potentially pursuing an external mercenary build from someone like Convex themselves, which comes with its own set of trade-offs/hurdles like I mentioned above.


Good to know. I think as they are a separate project it is worth asking them if they are planning to make this a generalisable product for DeFi. We can then explain to them that mStable is a great fit as the next integrated project.

@alsco77 are you able to look at the code base and give us a tdlr on feasibility of doing this assuming no help from them?

1 Like