⭕ [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)
2 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.

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.