MIP-7 mAsset AMM with feeders

Posted on behalf of the mStable protocolDAO

mStable has been looking at adding a new mAsset, mBTC, and with that new mAsset a new bonding curve. Adding mBTC with a new AMM was proposed by mStable protocolDAO and passed by Meta Governors here.

This forum post now requests community feedback and approval on implementation details.


As background, the AMM design used for mUSD, the first mAsset, is called the Constant Sum Market Maker, with the invariant ∑i xi = k. With the CSMM, bAssets can be minted, redeemed and swapped 1:1. However, this design introduces a number shortcomings, namely:

  • Drained bAssets: Expensive bAssets are fully drained from the basket and cheaper bAssets fill it up as much as they can.
  • Restricted liquidity: Not being able to swap with all bAssets limits the swap opportunities.
  • Reduced composability: Not being able to mint or redeem with every bAsset hinders composability with other DeFi projects.

Since the community have voiced these above concerns, the development team have been working on possible solutions. One such solution was described in MIP-6. There were various design goals the development team wanted to achieve while we tackle the problems as described in MIP-6:

  • Be able to flexibly target specific bAsset weights (i.e. max weights and minimum weights)
  • Make mAssets more composable
  • Guarantee a minimum amount of liquidity
  • Increase swap volume

Alongside MIP-6, the team has been working on another solution described in this forum post and in the soon to be released MIP-7. The mStable protocolDAO believes MIP-7 to be a superior solution in that it that will achieve the aims first described in MIP-6 as well as:

  • significantly increasing mStable’s scalability
  • reducing implementation risk
  • enabling mAsset “feeder baskets”, making mStable scalable without adding to system risk
  • leveraging each mAsset’s save rate
  • possible reweighing mAsset Earn incentives from third party protocols towards mAssets natively on mStable
  • creating an “insurance pool” of feeder basket LP tokens

Put together, MIP-7 looks to significantly increase the flexibility and security of mStable.

MIP-7 defines the application of the StableSwap invariant developed by Curve, building on the math but writing its implementation from scratch for the use in an mStable context.

This invariant is derived from nonlinear interpolation between constant sum and constant product market makers, variations of which are becoming an industry wide standard for same peg assets, similar to how Uniswap’s invariant is now a norm for volatile asset AMMs, such as Sushiswap and in crosschain solutions like Thorchain. StableSwap will be used in Balancer v2 and Sushiswap v3 have also indicated that it will implement a similar invariant. mStable team and community pass on our admiration to the Curve team for this contribution to DeFi.

The mStable protocolDAO is requesting community feedback on this implementation. The protocolDAO believes that this solution solves the goals defined by MIP-6 as well as several others, described above. As mentioned, the mStable development team have been working on this solution in parallel to MIP-6 and has completed development on both solutions.

MIP-7 mAsset basket

A modified 3 to 4 bAsset basket (with the pre-approved bAssets) that uses the mathematics of StableSwap’s trading algorithm to become a fully functional AMM, with the following mStable-specific properties:

  • AMM produces one mStable meta-stablecoin per peg, as opposed to an LP token
  • Interest and trading income are collected in mAsset terms and go to that mAsset’s Save contract (or the imAsset)
  • Each bAsset has a maximum weight, capping the risk of permanent capital loss (without max weights, if one of bAsset significantly depegs, it will effectively mean that mAsset holders will be left holding only that asset. Max weights caps this risk for mAsset holders)
  • All bAssets are automatically lent on decentralised lending markets such as Aave and Compound. Eventually this can be rebalanced according to the best available rate
  • It will be proposed that the mAsset baskets are backed by MTA through a recollateralisation mechanism


Following the deployment of MIP-7, and with guaranteed bAsset liquidity, it’s possible to extend the mAssets, offering the ability to create feeder pools which provide an important insurance layer and on/off ramps for mAssets.

mAsset feeder baskets

“mAsset feeder baskets” take inspiration from the “meta-pool” concept from Curve team. Feeder baskets exhibit the following traits:

  • There would exist n number of feeder baskets per mAsset that would be composed of 50% pegged asset / 50% mAsset
  • Incentivised, i.e. MTA Governors decide which feeder basket to incentivise and by how much
  • 0 or very low fee when trading into mAssets, making this AMM the most efficient place for mAsset liquidity
  • Permissionlessness, i.e. anyone can create them
  • Not to be backed by MTA
  • The 50% mAsset requirement is comparable to a “listing fee” where users must contribute to mAsset liquidity in order to start a new feeder.
  • This 50% mAsset requirement also leverages the save rate for that imAsset while adding to mAsset utility and liquidity
  • Feeder baskets could reweight incentives from from Earn pools now on third-party platforms to liquidity natively on mStable, and in so doing:
    • bring mAsset liquidity back to mStable, effectively doubling possible TVL
    • incentivise baskets with no impermanent loss, making these popular with yield farmers

Feeder baskets as mAsset internal insurance primitive:

Feeder baskets could be used as a primitive to secure mAssets in the event of one of the stablecoins in the mAsset basket failing. This is because in the event of one of the mAsset basket’s bAsset’s failing, the value of that mAsset would logically fall. Traders would then trade out of the mAsset and into the opposing pegged asset in each feeder basket, effectively filling up each feeder basket with that mAsset.

It is proposed that:

  • mStable creates an insurance pool where users can choose to stake their feeder basket LP token for a certain fixed time period. The longer the time staked the higher the MTA return. This would be an implementation of the existing MTA staking contract.
  • In the unlikely tail risk event of a permanent capital loss in a bAsset in an the mAsset Basket, the LP tokens within the insurance pool would be used to re-collateralise the mAsset Basket.
  • All or a percentage of the mAsset that is in the feeder baskets at the time of a recollateralisation would be burned.
  • In this extreme scenario, minting/swapping on the mAsset would halt, and holders of mAsset could then withdraw their asset at a premium (based on which % was burned). Ideally this would be used to fund a new mAsset without the affected bAsset. This recollaterlisation mechanism will be described in more detail in later MIPs and forum posts.

Feeder basket LP token incentives:

By contributing liquidity to a feeder basket, the user will receive:

  • Swap fees into the bAsset specific to that feeder basket
  • Interest from lending out Feeder basket bAssets, including the mAsset trading pair
  • Possible liquidity rewards from project’s that wish to incentivise their stablecoin on mStable
  • MTA rewards from locking the LP token into the insurance pool (see above)

Possible reweighting from mAsset pools on Earn to native feeder baskets to improve MTA tokenomics

This solution provides native and scalable mAsset liquidity on the mStable protocol. It may make sense to incentivise this native liquidity rather than mAsset liquidity on third party protocols, and thereby improve MTA’s tokenomics. Specific forum posts and snapshots will be made on this topic at a later date.


Snapshot poll: PDP13: mBTC implementation choice


i think this looks great - scalable and flexible across the platform and internalises more of the value of MTA and the rewards

1 Like

A lot to parse here, but I am for moving mStable in this direction. I look forward to unpacking a few points in depth that build on this proposal over the coming weeks:

  • How will this new AMM map to mUSD? And when we update mUSD to this new AMM, will we be re-examining which bAssets are in the mUSD basket? We removed DAI temporarily whilst the new AMM was being decided upon and built, so should consider putting it back and removing some other bAsset if we must keep it to 4.

  • I’m keen to see a rollout of mETH, mEUR, mGLD, and other stablecoin mAssets with this new structure :soon:

  • Could this Feeder basket strategy play into some broader crosschain strategy? ie could we have a feeder basket on another chain as a link to mStable, similar to Compound Cash’s “Starports”.

  • The Feeder basket insurance pool and MTA recollateralisation in future do get a bit blurry. We probably need to clearly demarcate between the two, and once done explore the design space to see if we can get any synergies from these two seperate risk management modules.

  • EARN pools and MTA rewards need to be overhauled. This is going to be a big job but likely worth doing. We should take care as this may be a high risk/contentious issue for stakeholders in the broader mStable ecosystem.

Excited to see mBTC go live. Well done team.

Oh finally should be noted that this item is now live for voting on snapshot. Votes close midnight Thursday 11th CET.


I’m in support of this proposal for these reasons:

  • the new AMM combines the best of the current implementation, specifically max weights which caps the risk in an extreme scenario with StableSwap that under normal circumstances ensures that there are always ability to swap assets thus increase the utility of the swap function
  • the feeder baskets looks like a clever way to build bridges to the core massets without scarifying the integrity of the massets, they should be able to build liquidity in the mStable protocol
  • finally I’m in agreement with deprecating the current Earn system and instead more directly incentivise the core mStable system

I am for this in favour of this for several reasons:

  • I like how this proposal uses the battle tested stableswap for the bonding curve but extends it to the mStable context. mStable now becomes a fully functional meta-stablecoin producing AMM that is risk minimised. I believe that meta-stablecoins and mAsset could now become a primitive for bridging value.
  • this "scales* mStable. A big problem with the previous implementation was not being able to add n number of bAssets per mAsset. Now we can.
  • enabling fundamental use case for mAsset is very powerful -this proposal allows mAssets to have trading pairs with every other pegged asset. Also powerful that the mAsset liquidity will leverage save rate for that mAsset and that MTA incentives can directly go to liquidity on mStable as opposed to third party platforms. The flexibility of feeders is cool to - anyone can create them. The recursive mAsset back on mstable should do great things for TVL too.
  • insurance pool is fascinating as an addition to MTA recollateralisation: I think if executed correctly, mAssets could very possibly have the highest return and be some of the more secure assets in DeFi - perfect for collateral.
  • only concern is to ensure that feeder basket LP tokens are handled well from a UI perspective: need to make sure it doesn’t confuse user experience with too much fragmentation

Excited to hopefully see this come out!


There is quite a lot to digest here, but it puts a really exciting and fresh viewpoint on the future of the entire mStable project.

Definitely feels like the birthing of a turnkey solution to not only combat the inherent issues we used to face, but sort of open up an entirely new highway to operate and work with at the same time, nice! :grin:

This also feels like a much more hardened fundamental deployment when starting to think about bridging mAssets to different blockchains, as it allows for a lot more freedom in creating liquidity and entrance and exit points if I understand this all correctly.

Since we’re now moving a lot of chess pieces at the same time (at least it looks this way from a non-developer perspective), it would feel reassuring to see that we’re battle-testing one initial deployment with mBTC first, polish to the usual mStable standard, and then ramp up rapidly towards more mAssets.

With more demand coming up from the recent market news, having a first mover advantage of other mAssets that @ScarceJim mentioned, we’re absolutely well positioned to take this emerging meta-niche safe haven by storm!

Congratulations to everyone who has come up with the initial idea, and all the work in the background to bring it to this level. I’m really impressed with what you’ve all managed to develop in such a short timeframe, and under such pressure from the community to deliver!

1 Like

I’m in full support of this proposal

  • Delivering scale to the protocol for additional underlying assets
  • Migration of liquidity from third parties into the mStable protocol is vital for improving the actual product and growing real user base

Very very nice proposal and I’m in total support of it :slight_smile:

  • mStable needs to scale and this will help a lot on that front by bringing in fresh liquidity to the protocol
  • The feeder baskets are a neat and innovative idea that add a lot of value to DeFi in general
  • Recollateralization is critical as those who earn rewards from the system should be the first ones to bear the cost in case of system failure

Good job on putting this together. Seems like the right direction - can see the benefits around ability to attract additional liquidity + leveraging innovative ideas already in DeFi. Would love to get a sense of the following:

  • Would there be benefit in removing the max weights? Understand that it prevents risk if there’s collapse of one stablecoin, but at this point, given a basket of 3-4 battle tested assets, probability doesn’t seem that high?

  • Instead of lending on Compound / Aave, could you just put it directly in a yearn vault or something similar that has historically had higher yield?

  • What would execution look like for a 100k trade between two stablecoins using this vs Curve, assuming similar levels of liquidity? Or maybe another way to ask - at what price ranges would mstable be better to use for execution?


This looks like an excellent proposal and we wholeheartedly support it.


Is this exactly what acBTC is doing? It seems that they are also stable swap to build their synthetic BTC.

Just checked them out - never heard of that project before. I think the usage of StableSwap in general is about as close as it comes. We have a number of differentiating factors (max weights, lending market integrations, feeder pool insurance, recollateralisation, leveraged savings contract) :+1: