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