[Discussion] Transitioning mAsset collateralisation model


Transitioning mAsset collateralisation model from {bAsset basket + MTA staking} to {bAsset AMM + MTA staking}

The AMM would implement a bonding curve optimised for stablecoins, similar to Curve’s. To mint mAssets, bAssets are deposited into the mStable AMM, and receive mAssets in return (ie LP tokens of the mStable AMM). In the case of a peg loss, bAssets can be removed from the AMM through governance.


The current collateralisation system allows 1:1 bAsset swaps which carries negative consequences to protocol functionality and revenue when max weight caps are reached.

Using an AMM negates the need of max weight restrictions.


mStable currently has three distinct revenue streams:

  1. lending of underlying bAssets,
  2. minting/redeeming of mAssets, and
  3. fees for swaps between bAssets

The current basket model with 1:1 swaps necessitates the use of max weight restrictions, meaning that the least valuable bAssets will be at max weights, while more valuable bAssets drained from the basket.

This leads to negative consequences for all three revenue streams outlined above.

  1. basket will mostly consist of low-value bAssets that also fetch low lending rates;
    lending yields are down
  2. minting/redeeming functions become restricted (eg if DAI trades above peg, mUSD holders are unable to redeem to DAI directly);
    revenues from minting/redeeming are down
  3. swaps are limited to only the remaining bAssets;
    revenues from swaps are down

An AMM model would be “elastic” in managing bAssets, and partially mitigate the above problems.
The ratios of bAssets being healthier, most external [mAssets + bAsset] pools will no longer needed (eg mUSD + USDC pool), as mStable’s mint/redeem functions will be sufficiently robust. Side product is that MTA rewards can be focused elsewhere.

There are several AMM protocols and stablecoin issuers. However there are synergies to implementing both under a single protocol, maximising the utility of TVL. This is potentially a great opportunity for mStable to leverage its existing MTA staking model, and strengthen its moat by deploying an AMM.


  • healthier collateral system (elastic bAsset ratios)
  • allows addition of above-peg bAssets (eg sUSD) without instant drain
  • diversified, robust revenue streams (lending + swaps)
  • less dependency on external liquidity pools
  • strong moat through vertical integration (AMM-based stablecoin issuer)


  • Overhaul in collateral system, migration would be required

To illustrate the potential benefits of integrating an AMM, consider Defidollar (DUSD), an overcollateralised stablecoin backed by Curve LP tokens.

DUSD is secured from peg loss events by allowing staking of DUSD, which earns yield. However, the Defidollar system is only integrated with Curve to the extent that its LP tokens are used to mint/redeem.
The collateralisation guarantee therefore stops at the mint/redeem facility.
What does that actually mean? DUSD stakers suffer losses at every redemption event when the protocol is undercollateralised (total assets < DUSD supply).

However, an AMM-based mStable would not have the same limitation. Because of the full vertical (AMM reserves => mAsset issuance), stakers only have to suffer losses when governors vote to purge a bAsset in the AMM.

I have mentioned Curve a lot here, but beyond the bonding curve, Mooniswap’s virtual balances and Balancer’s custom weights are additional features worth considering when constructing the AMM.

1 Like

Great analysis @notreallyleg - you are on the money there. I think the major benefit from this improved AMM would be the composibility offered - being able to rely on the withdrawal of a given bAsset rather than having to content with the max weights.

An AMM model would be “elastic” in managing bAssets, and partially mitigate the above problems. The ratios of bAssets being healthier, most external [mAssets + bAsset] pools will no longer needed (eg mUSD + USDC pool), as mStable’s mint/redeem functions will be sufficiently robust. Side product is that MTA rewards can be focused elsewhere.

Well said.

Overhaul in collateral system, migration would be required

I actually suspect that it may be possible to do this without a full asset migration, and keeping the asset backed 1:1 in unit terms to maintain the core premise of the asset - although it would likely be a lot more efficient were it to be built from the ground up again.

In terms of capping risk and making the curve more efficient, I see room to innovate somewhere in between Stableswap and 1:1

1 Like

Amazing! I’m a huge fan of the improvements Stableswap and Mooniswap both brought to the table, excited to see what we end up with here.
Dodo has a radically different approach that I found very interesting, but that requires integration with an oracle, while the others don’t.

1 Like

This is a fascinating topic for the direction of mStable. It is probably true that a product that combines the Y pool from Curve and the recollateralization feature of mStable would be extremely compelling and find immediate traction!

However, it is hard to disregard the merits of the current 1:1 straight line bonding curve. Eventually basket assets will likely return to their peg and swapping bAssets will serve broader purposes (e.g. interacting with different protocols or in different jurisdictions) without worrying about arbitrage.

It might be possible to have a product that operates like a typical AMM now, but can transition if/when bAssets are closer to their peg. Something like the “A” factor that governs the bonding curve for the pools on the Curve platform. As bAssets return to their peg Meta governors can vote to adjust the curve so users can trade closer to a 1:1 basis.

Perhaps it is possible to solve the issues identified most efficiently by playing around with different fee structures or even researching more funky trading curves beyond my mathematical knowledge.

I think this is a seriously important issue for us to consider.

There are several great things about the current 1:1 bonding curve. It provides a venue for arbitrage between stablecoins in a way that can offer users a large spread. Imagine a 200bps spread between stablecoins - it is economically rational to arb this spread even if the mStable fee is at 50bps. With max weights, mstable then caps the risk of users filling the pool with a broken stablecoin. This means mStable can stay away from the race to the bottom in fees that platforms like curve etc are playing.

Negatives are mainly about the fact that without large volatility the stablecoin basket becomes static, weighted towards the least valuable assets. It means that if a stablecoin tracks above peg for a long time (susd dai), no one will mint with them.

I think we should look at improving the curve if it doesn’t affect the core integrity of the mStable system. Since everything is premised on 1:1, it is not an easy problem, but there is the potential that it dramatically increases the efficiency of trading, increasing fees for savers, and critically increasing our composability.

The main question I have is how a new curve will affect the 1:1 premise of the system; work with max weights or not; and finally how we are able to cap risk without oracles like we currently do if we get rid of max weights.

Research and protocol dev Onur has a bunch of thoughts on this so he should chime in soon.

also awesome analysis @chuckle17 @notreallyleg

1 Like

My suggestion in the Discord was to have a variable fee rate for any swap, based on the state you leave the basket in -it’s calculated weight after the swap.

You can have a base fee, let’s say 1% or whatever it is now. Then an additional fee based on the end state.

Swap fee = base fee + basketWeightFee

You can have a curve like say, basketWeightFee = 1/x^2 (simplified), where as the calculated basket weight approaches 0, the fee exponentially approaches infinity to discourage drawing down below a set amount.

Could have both positive and negative fees. Positive fees for drawing down below the desired basketWeight, and negative fees for leaving the final state above the basketWeight.

Could have either the inflection point at the desired basket weight to make the penalties and rewards symmetrical if you want to, or weighted towards penalising and instead make a y solution equal zero at the desired basketWeightFee.


Brief example of the latter where x axis is the basketWeight from 0 to 100%, and 50% is the desired level, which accrues a 0 additional fee (y axis). Adjust the curve however you like to incentivise what you want to see.

Fees could be paid in MTA or whatever although this would increase gas for transfers.

Might not work as I haven’t modeled the economics of it all, but could stop the “why would I deposit DAI into here, I paid 1.02 for it” issue, especially if they get rewarded that extra .02 somehow after depositing. Could even be a dynamic curve based on Oracles as well to keep it up to date with external market forces.


I like the idea @Thylacine and thanks for the research. One thought - how do we keep the mAsset collateralised 1:1 if we are giving out positive fees? My thinking was that there could be a pool of mUSD that got burned to the degree of the positive fee payout. New mUSD would subsequently be minted and sent to save when the negative fees were accrued. The volume in this pool could also affect the fee rate

Sorry I used positive/negative fees from the perspective of the user, not mStable. Positive fee = a charge for the user (gain for mStable), negative fee = rebate for the user (payment from mStable).

I guess I was talking about charging fees from swappers who are leaving the baskets in a worse place than when they started (according to some pre-defined desired state). If you don’t use MTA, which could get tricky, maybe it could come out of the asset they are swapping to. Isn’t this how the fixed trading fee works? Why couldn’t it be the same mechanism? Just instead of being fixed, it’s calculated based on a desired state you want to incentivise.

These fees can be collected and placed in save or earn, and paid out to swappers when required?

But this might be close to no longer being 1:1:1 pegged - one of the main purposes of the platform, since the elastic fee essentially acts as the spread between the stables you are swapping.

I don’t really have a comprehensive solution, just brainstorming with you all.

1 Like