[Discussion] Set a minimum percentage amount held for each asset in the mUSD basket

Summary:

Set a minimum percentage amount held for each asset in the basket proportional to all other assets in the basket to increase representation of every stablecoin in the basket and avoid having assets completely drained from the basket while having others overrepresented.

Abstract:

This proposal sets a minimum percentage amount with each asset that cannot be withdrawn via redemption or swap proportional to the weight of all other assets in the basket in order to guarantee a minimum amount of representation of each of the assets in the mUSD basket.

The current situation is a mix of 2 or 3 different assets being overrepresented in the basket, while the other ones are underrepresented or non-existant in the basket due to volatility and arbitrageurs taking advantage of the swap and redemption feature.

This proposal would ensure that a minimum percentage of each asset is contained in the basket, regardless of volatility or fluctuations on the market, and give a more accurate representation of what a unit of mUSD should be.

Motivation:

If mStable wants to truly be a mix of many of the current stablecoin projects, it needs to have a representation of each asset in its underlying basket. Due to the nature of a decentralized stablecoin being naturally more volatile, I propose that a limit is set in the code to stop withdrawals from that part of the basket within a set treshhold (perhaps between 5 to 10% of the total volume represented in the basket).

I have seen DAI being mentioned as dead weight in the code of the basket, and right now this is true. It also becomes a more centralized coin overall if we do not secure a basic amount of stability in each asset in the basket.

There is no mutual benefit for mUSD holders to being able to withdraw all underlying assets without keeping a proportion in regards to the total weight of the basket. Having a reserve in the basket of each asset seems mandatory to ensure diversification, and this number should be maintained as the basket grows and shrinks, proportionally to all the other assets in the basket.

There is already an upper percentage limit of how much of a stablecoin the basket can contain, so it seems logical to also implement a lower percentage limit of how much of a stablecoin it should contain.

Pros:

  • Better diversification of the collateral within the basket
  • Better representation of a truly mixed stablecoin
  • Safeguard against a failing peg of a different overrepresented asset
  • A more professional looking front-end representation of the basket
  • Better options of future yield farming integration that would otherwise not be possible (due to a lack of a basic collateral in form of DAI or a different stablecoin)
  • More safety for MTA token holders in case of a peg failure
  • Easier to negotiate with other platforms about integrating mStable, as more assets are truly represented and cannot be manipulated out of the basket

Cons:

  • More limitations with redemptions
  • More limitations with swaps
  • Might take a while to reach the recommended minimum allocation unless incentivized by the protocol (maybe with more mUSD generated per underrepresented asset until treshold is reached)
  • Might over/de-value the mUSD due to impossibility to swap/redeem all of the underlying collateral of one asset

Looking forward to hearing your thoughts. This has been something that bugged me since the inception of the protocol, and as I picked up a nice chunk of MTA today, I felt it was finally time to get some feedback and thoughts to see and understand better of why this might have not been considered before, or why it should or shouldn’t be considered now.

Happy Friday and enjoy the start into the weekend guys!

3 Likes

Thanks @shubidoobi for this thoughtful discussion topic.

@chuckle17 and @notreallyleg brought this up on Discord before, and I know it got lost so I’ll link it.

I quote @chuckle17

having minimum weights would ensure there is some of each asset in the basket which has value in terms of optics (the pool does not looked “drained” of the asset) but also is valuable to diversify the passive income from the basket assets

for instance DAI has consistently high returns on lending platforms but mstable SAVErs do not experience these higher rates since there is little to no DAI in the mUSD basket typicially so far

and @notreallyleg

I was thinking about this, and the upside is that yes, we retain exposure to some of these coins, but functionally, it doesn’t actually do much, because swaps/mint/redeem functions are still limited once those limits are hit

so from that perspective I think the benefits are quite limited

One possibility is to drastically hike fees for transactions that drain low weight reserves beyond some limit, but I don’t like that idea very much because it’s basically being a poor AMM

The team is researching on a new upgraded AMM model that can manage this basket with possibly cheaper gas fees - they might be able to weigh in on this. Of course, any community suggestions and feedback is appreciated.

Yes, I had thought the team had decided to use an upgraded AMM model. I was also told that gas fees would increase if there was ever change from a max of 55%. Gas fees are a big concern. In theory I like your idea but most of the yield for SAVE comes from swaps, and as such, I don’t think a minimum does a whole lot. The AMM may solve this—also users will not want to pay gas for a swap just for it to fail if there are minimums and maximums.

Good discussion.

Thanks @shubidoobi for raising this topic formally and @derc for sharing my thoughts from discord. It is likely not detrimental to have minimum basket weights for mAssets. It is true that users will not be able to trade or redeem for these basket assets just as if they were 0% of the basket. This outcome might be confusing for users, but no more confusing than for users that try to mint an mAsset with a basket asset that is at its maximum weight.

The concern is probably that setting minimum basket weights does not add much to the protocol. Increased exposure to lending rates for these assets and marginal improvement for the optics of the pool are not worth additional coding complexity and associated gas costs. Another benefit for consideration, however, is that users redeeming mAssets for basket assets according to their weights will actually receive each of the assets that are supporting the mAsset. Again, this is not efficient from a gas perspective, but could be considered a positive outcome.

1 Like

Some good arguments here to be found, thanks a lot.

I think adding a minimum from a visual point will be very easy and not confusing at all. You literally make the first 5 or 10% of each asset progress bar red, with a treshhold vertical line at that stage. I believe a 5 year old would understand the meaning of such a visual pointer.

Also, we would only suffer the swapping losses impermanently, as we only need to reach the treshold of each asset before it becomes swappable. I dare say the extra fees missed out on after the treshold is established is negligible compared to the potential benefits of being able to play with underrepresented assets in the yield farming and savings game moving forward.

Also, we haven’t yet agreed upon the fact that it will make the mUSD token more resistant against shocks, as well as give a clearer representation of the current worth of all USD assets in the basket.

So far, I see only a small change in the code necessary, and the arguments given so far do not convince me that this wouldn’t be something worth considering for the longevity benefit of this project.

Don’t forget that we will also face this issue with all future mAssets, as not all of them behave the same way. This might be a great teaching ground for when mBTC comes, and we want to make sure to have a fair distribution in the underlying assets when not all are pegged the same way (tBTC comes to mind immediately.)

Regarding the gas fees, I think it’d be time to consider a L2 solution as well and see also optimistic Ethereum on the horizon now.

We’re not talking projects that are years away, so soon gas fees will be a non-issue for most users, at which this topic here would just resurface with the same parameters, excluding the gas fee argument.

2 Likes

Thanks for the proposal @shubidoobi.

Re setting hard minimum weights: This has the same problem with hard max weights, that is, swaps cannot take place as soon as one bAsset reaches the limit.

However, we do plan to use the concept of minimum weights—just not as hard limits. We are currently researching how to implement a dynamic draining fee, which increases as the weight of a bAsset decreases below a certain minimum weight. If we were to implement this, the hard max weights would be removed too.

2 Likes

Hey @osolmaz,

That’s super cool, much more elegant this way, and super excited to hear about this! =)

1 Like

I was told that adding min weights and max weights other than 55% would cause significant gas price increase. Can anyone speak to the gas costs? We should avoid raising gas costs on end user swaps.

I think adding PAX & BUSD will help keep the basket more diversified. If you haven’t already voted, please vote for both. Both are issued by Paxos but BUSD is especially used by binance. Both are important to be added so I’d appreciate your vote to add them to the basket CLICK HERE