✅ [RFC] Consolidate fees for swaps and redemptions

Summary

This RFC proposes to consolidate all fees (swap and redeem) for all products: mUSD, mBTC and Feeder Pools. Currently, the fees of different products vary by quite a bit. By consolidating the fees, mStable products become easier to understand and communicate. This RFC does not propose changing the governance fees (from lending platforms and rewards).

Abstract

The current fee structure is very fragmented, a few examples:

  • mUSD bAsset swapFee is 3bsp, redemptionFee is 6 bsp.
  • mBTC bAsset swapFee is 2bsp, redemptionFee is 6 bsp.
  • Feeder Pools varies by Pool swapFee 6-4bsp, redemptionFee 6-4bsp.

This structure is not very transparent, not easy to remember nor to document. Therefore I propose we consolidate all the swap and redemption fees into one simple to remember the number.

The questions therefore I want to open for discussion is: What should be the fee for swaps and redemptions? (Open to discuss here first the options and then vote?)

  • Free (We want to max deposits and double down on earning revenue from lending markets. This makes depositing into mUSD and mBTC only a consideration of the incurred slippage)
  • 1 bsp (Super cheap, but still something for the Protocol)
  • 2 bsp (Rather low, we want to focus mostly on revenue from lending markets with some smaller supplementation from swap and redemptions)
  • 4 bsp (Average, kinda around the area we are right now)
  • 6 bsp (More fees from swaps, probably fewer deposits)

Motivation

This would make the products easier to understand. One Fee to rule them all!

Additionally, we should really reconsider the primal use case of mStable, Save and accompanying products. Do we consider our current products to generate the yield from lending markets more or from swaps and redemptions?

I personally would argue that the majority comes from the underlying being deposited into lending markets, while we cannot compete anymore with the established player Curve for swaps.

Thinking also about other protocols that want to integrate mStable’s Save, one topic that is often brought up are the redemption fees when it comes to using Save as a strategy. The redemption fees are a consideration of how often the protocol would deposit and how they would account for that. Higher fees increase the friction and reduce potentially the amounts that are deposited. In a way, the redemptionFee has to be considered as a costs upfront when depositing into Save (exit tax).

The majority of our Save revenue comes from Platform Interest, while only a smaller fraction is the trading fees. Would lowering redemption fees increase deposits into Save and therefore increase protocol revenue overall?

Source: https://dune.xyz/naddison/mUSD

Pros

  • Easier to understand fee structure
  • Easier to anticipate the fees

Cons

  • No custom fee per pool to max value extraction

Open Questions

  • One unified fee for all, good or not?
  • What fee would make the most sense? (To narrow down to a few options)
3 Likes

Interesting topic!

I agree right off the top that the fees should be unified between the pools, I think this is a no-brainer really.

To my eye, the swap basis point reduction enacted in May of last year does not seem to have generated the hoped-for increased overall revenues. Competing with Curve was perhaps required, but as I feared at the time it didn’t result in actual increased swap traffic for Savers.

On that basis, I’m not in favor of any further reduction in swap fees.

Do we have any data about deposit hesitancy from the redeem fees? Granted, this is a weak point to make, but except for the largest depositors I think the exit fee is dwarfed by gas. If the concern is coming from Gelt or another integrator, it feels like we could work this out on a case-by-case basis between projects.

I guess I need more information to say anything more about redeem fee changes. Also, since there are Major Protocol Changes afoot, I feel like any hard consensus on this is best left until after the community at large has more information.

1 Like

Anecdotally, I can add that in the GrantsDAO we’ve twice run into the fees being an issue to with Save’s composability. The problem has been that with the fee you can end up with a negative yield if you aren’t in the pool long enough. For instance, with Symphony Finance they want to use Save to earn yield for their users while waiting to fill a limit order. I would be for removing the fee entirely and focusing on Platform Interest. This could open us up to new use cases and lower slippage. Also, my feeling is that the impact wont be felt on the Save APY because that is most a factor of how much of circulating mUSD is deposited into Save vs in the wild.

I think this is a space that we still have time to get our marketshare on. Specially because there is a rise of aggregators (like paraswap) that can possibly get our swap functionality integrated.

Regarding fees, it’s very tricky. I agree with @trustindistrust that it’d be better to see some data to properly take an informed decision.

While I can see the argument for making things easy to understand, I would be hesitant to give up the ability to customize fees for different pools.

A couple of thoughts that come to mind:

  • Feeder Pools LPs essentially rely on fees producing enough income that they are better off providing liquidity than depositing into Save. If we reduce fees here, are Feeder Pools still viable as MTA rewards decline?

  • Should we differentiate between swapping in/out of an mAsset vs. using our pools for other swaps? I don’t see any reasons to reduce fees for a bAsset->bAsset swap below competitive rates as these swaps don’t add friction for Save and provide significant revenue.

  • Do the fees provide an important incentive as well as a revenue stream? Ie. can the protocol function smoothly with large volatility in TVD? If so, then perhaps we should look to reduce friction and encourage protocols like Symphony Finance to make short term deposits. If not, then fees offer an incentive to deposit for longer periods, and reducing fees could have unintended consequences.

1 Like

Data is always good. But what kind of data do you think would be interesting here to make an informed decision? See also the mUSD dune dashboard I posted.

You are probably right. Thinking we can also have 2 tier of fees. Core basket related fees (redeem and swap) is one unified fee, while feeder pool swaps and redemptions is another tier.

Probably not. But just speaking from interactions with other protocols that redemption fee from mUSD was a major blocker for an integration. So if we think that we could earn more by having more integrations that earn a yield, it could be opportune to remove redemptions fees. But if we remove redemption fees then swap fees would be easily circumvented via mint/redeem in that case.

Adding a few polls to gauge the interest.

Should feeder pools and mAssets have the same fee?

  • Unify ALL FEES
  • Differentiate between feeder pools and mAssets

0 voters

What fee would you prefer for the mAsset basket (redeem and swap)

  • Free
  • 1 bsp
  • 2 bsp
  • 3 bsp
  • 4 bsp
  • 6 bsp

0 voters

What fee would you prefer for the feeder pools (redeem and swap)

  • Free
  • 1 bsp
  • 2 bsp
  • 3 bsp
  • 4 bsp
  • 6 bsp

0 voters

I think it makes sense to consolidate revenue and streamline operations of pools given fees aren’t so different across the platform

I’m interested; what, specifically, was it about the redeem fee that these potential partners found disagreeable? For example, was it about additional disclosures to their end users about fees? Was it about cutting into their own profits? Were these protocols intending to dip in and out of the pool(s) frequently? It just seems like such an odd thing to stick on.

In any case, it seems like something that could be worked out individually between projects. If the integration was worth a lot of extra exposure and was just net positive for everyone, and this was the blocker, couldn’t we just agree to refund/credit them exits? That sets a very high bar of course, since it would be a tremendous pain in the ass. :sweat_smile: But that’s the kind of partnership I would consider the baseline in order to just eat fees that earn the protocol much-needed income.

Just chiming in here with my 2cts, perhaps slightly off-topic, but definitely related.

I do believe that the redemption fee for mUSD in general is sort of a controversial topic, as it doesn’t seem like a reliable revenue to count on for the protocol itself, while discouraging the minting of mUSD in the short term (at least to those that are aware that such a fee even exists).

I’d argue that perhaps it might be time to re-think the entire redemption process as a whole and note that placing the redemption fee on the Save Vault might be a lot more lucrative and sensible in the medium term for us.

Save is arguably our most favourite product amongst users, yet it carries no commitment at all, and I think we should seriously look at this when thinking of redemption fees in regards to mUSD.

I’d therefore argue that we should include an option in the proposal to switch fee generation from mUSD to Save and thus make it less risky to hold mUSD while at the same time finally beginning to charge a small fee to Save users for receiving such a generous amount of yield on top of MTA rewards once they’re ready to offboard or directly during the onboarding process.

This will be a win/win, as we still entice to keep mUSD in the system, but will place fees accordingly to the parties that benefit most from mUSD.

Regarding swap fees, I’m quite indifferent, but would lean towards 1bps or 0bps, as most likely we’ll have better sources to extract profit from than trying to compete there, and it will help us in so many other ways, it seems like a negligible number for now.

I agree with @dimsone that the fee structure is not very transparent. Let me try and help with that.

Firstly, the redemption fee is misleading. It only applies to redemptions that proportionally redeem from the bAssets using the redeemMasset function. That is, given an amount of mAssets, it’ll redeem each of the bAssets so the basket weights are not changed.

Redemptions that change the basket weights are treated like swaps hence are charged the swap fee and not the redemption fee. That’s the redeem and redeemExactBassets functions.

Looking at the mUSD txs, I haven’t found a single redeemMasset transaction. All mainnet mUSD redemptions use redeem or redeemExactBassets so we really need to be focusing in on setting the swap fee and just setting the redemption fee to the same value to avoid further confusion.

The following shows the history of the swap fees on mainnet for mUSD and mBTC. These are showing in percentage values so a fee of 0.02% is 2 basis points. The mUSD swap fee at the end of 2020 and the start of 2021 was 0.06%. It was then revised down to 0.02%. Late last year it was increased from 0.02% to 0.04% for a 6 week period when extra revenue was being collected for Votium bribes. The mUSD swap fee is currently 0.03%.


DA query source Dune Analytics

The below shows the weekly swap volume verses the swap fee rate for mUSD.


DA query source Dune Analytics

The above would indicate that higher fees results in higher swap volumes, but I think the higher fees is more a result of the higher TVL of mUSD. The following shows the swap fees and the total mUSD supply.


DA query source Dune Analytics

The following shows the weekly swap fees collected as an annualised percentage of the total mUSD supply. You can see an increase in swap returns when the swap fee was reduced from 0.04% to 0.02% but that dropped off over time. The returns then increased when rate was increased from 0.02% to 0.04% as part of the Votium changes. Similar to the above, I don’t think one can make any firm conclusions from this data.


DA query source Dune Analytics

The following shows the weekly bAsset swap volumes. It sums both the input and output values of each swap.
sUSD makes up most of mUSD’s swap volume followed by USDC. I suspect this is because sUSD has the most price volatility. In fact, I suspect the best correlation to swap fees collected is price volatility.


DA query source Dune Analytics

The following shows the source of the weekly swaps measured in the USD value of the outputs.
1Inch use to be the primary source of swaps but that has changed in recent months. Arbitrageurs in the below is a catch-all when the source is not currently known. Also note there is very little swap volume directly to the mUSD contract. eg come from the mStable website. Most swaps are part of an arbitrage.


DA query source Dune Analytics

The follow shows the number of weekly swaps rather than the volume in USD. The number of swaps is relatively small with less than 10 a day on average. The average weekly swap size varies between 100k to 1m.


DA query source Dune Analytics

If we zoom back out and look at the swap and redemption fees for mUSD, we see most trading fees comes from swap fees rather than redemption fees.


DA query source Dune Analytics

In contrast, the mUSD fees on Polygon mostly come from redemptions and not swaps.


DA query source Dune Analytics

The swap and redemption fees for Polygon mUSD has been 0.06% since launch.

The mBTC swap and redemptions fees have slowly dropped since launch. Like Polygon, the mBTC swap and redemption fees have been 0.06%.


DA query source Dune Analytics

I hope this helps
Nick

2 Likes

Wow, that post was tremendous! I guessed (but didn’t know) that very little traffic came through from aggregators, but the traffic from bots/arbers was a big surprise. Turns out, if we removed sUSD from the basket, we’d be kneecapping our revenues!
This provides some interesting food for thought on future basket compositions.

2 Likes

FP 6 bp.
MAsset Swap and mint mUSD free.
The FPs face an existential dilemma.
Whereas free swaps and minting/redeeming will increase the adoption of mUSD as an asset which both has lindy effect and produces revenue for the protocol (and starts the the mUSD flywheel — attracts mSavers drives more adoption).

I don’t think we should be making swaps free. That’s an important additional revenue source for savers. Take that away and it becomes less attractive for mSavers. Mints are already free.

1 Like

Another lever we have for swaps is the Amplitude Coefficient (A value). The higher the A value the cheaper the swaps are. The trade-off is a higher A value reduces the incentive to have the bAssets in the basket balanced.

mBTC’s A value started at 120 and was then ramped up to 300 where it has remained.
mUSD’s A value was initially set at 100 when it was upgraded to use StableSwaps and then ramped to 250.


Source Dune Analytics

As a comparison, the A values for some of the Curve pools are
Compound 4500
3Pool 2000
USDT 2000
TUSD 600
mUSD 200
GUSD 200
sUSD 100

I’ve been working on a historical bAsset balances v bAsset prices chart. That should shed more light on how efficient the arbitrageurs are at keeping the bAssets at market value.

1 Like

Given all the discussion and the preliminary vote, I would move forward to formally propose this with the following parameter:

  1. Swap and Reedem fees should align
  2. mAsset fees 2 bsp
  3. fPools 6 bsp

I think this could be a good solution to make the fee structure more cohesive while preserving some fees and allowing feeder pools to extract more.

2 Likes