✅ [RFC] Increase Governance Fee Flow to Treasury

Summary

This RFC would like to gather feedback surrounding the further increase of the governance fee flow from the protocol to the treasury from all sources due to the recent downturn in overall interest on Aave & Compound, as well as in preparation for a prolonged bearish market sentiment in the wider crypto ecosystem.

Abstract

Before the launch of the Emissions Controller last year, the protocol used the governance fee revenue in the Buyback & Make pool on Balancer.

Since then, we rerouted these governance fees to purchase MTA directly off the market and distribute to stakers. This left the treasury and protocol with no organic way of capturing revenue and accruing value back to the treasury, and thus forms the basis of this RFC to remedy this.

We subsequently overhauled this fee flow in MCCP 20 in order to redirect 50% of these fees back into the TreasuryDAO.

It is now suggested to increase this fee flow to 75% or even 100% towards the treasury, as in the current bear market condition, the Treasury needs to ensure a sufficient runway for the protocol.

Currently, the mStable Protocol liquidates 50% of protocol fee rewards into MTA which is then streamed to stakers, and it is suggested to use these rewards for the increase in treasury fee flow.

As previously mentioned, it is suggested to increase the fee flow from all sources, which will also include the upcoming Convex Metavault and any further Metavaults until another proposal be made to alter this suggested fee flow model.

This change in fee distribution will also significantly reduce the selling off of inflationary MTA rewards and not needlessly punish stakers, as they are already receiving a substantial amount of rewards through the Emissions Controller.

Motivation

With the recent tumbling of the Terra ecosystem, we’ve seen a drastic reduction in total market capitalization allocated towards cryptocurrencies, and as our treasury is still heavily allocated in native governance tokens, we have to ensure means and ways on how the protocol will continue tho thrive and endure in a potentially prolonged bear market.

We initially granted stakers additional inflationary MTA rewards to steward the Emissions Controller towards the best returns for the protocol, but this has not been the case if we look at the historical performance of the Emissions Controller.

Thus, I believe that rewarding stakers singularly through the Emissions Controller is a valid and sufficient way to incentivize them to stake their tokens, as well as make allocations on the Emissions Controller that would not deviate away significantly from the current allocations they’re making.

Additionally, if we were to increase the governance fee flow to the treasury, we would immediately make available more runway for community-funded ventures, of which the Ecosystem subDAO can only partake when the funds are available beyond funding the Builder subDAO core operations.

Pros

  • The MTA token and the mStable protocol will start accruing more value due to less sell-offs
  • The protocol will be able to generate more revenue than before to fund operations
  • Save significant amounts of gas on the cumbersome process of exchanging native mAssets for MTA to distribute to stakers
  • Stop stakers from receiving inflationary rewards on top of inflationary rewards

Cons

  • MTA stakers will receive only Emissions Controller MTA, so most likely will cap that dial moving forward or decide to unstake

Next Steps

It is suggested that the community comment on this RFC in the coming days, and bearing no significant opposition or change in ideation, we would move ahead with this RFC in the coming weeks and create a formal draft proposal on Github to be used for review.

Meta Governors are encouraged to provide as much feedback as possible until then, so we can create the best possible outcome for mStable and its users.

I disagree with this proposal. While I agree with all the context and the motivation, I think that we have already hurt the community and the stakers with MCCPs 23 and 24. Instead, I propose that we raise our fees from 10% to 20%. Save APY has consistently been outstandingly high, and reducing it 11% (which is what what would be impacted if we raise the fee 10 pp) wouldn’t hurt it as much, and it would double our revenues.

The main risk of this proposal is to impact TVL, but in these market conditions, I doubt we will see many safe stables yielding as much as imUSD, even after the rise of fees.

Still, let’s consider a scenario in which there’s actually an outflow of capital because of a decrease in the APY.

  • Considering the current share of mUSD in Convex (~50%), after an increase of 10pp in the fee, there would need to be an outflow of 20% of the current mUSD deposited in save to bring up the APY to the same level as before.
  • There’s no reason to assume that mUSD liquidity in Convex would get impacted, as for them the APY would remain the same.
  • This means that total circulating supply of mUSD would be reduced 10%.
  • Since out fees are double than before, even after this outflow of capital, we would still be making 80% more of revenues.
2 Likes

I like this proposal and in light of the upcoming Meta Vaults it reduces the complexity greatly, while allowing the protocol to reach a level at which it can sustain itself.

  • As it stands we share 50% of the generated revenue and after all the costs this comes down to a net negative for the protocol. We share revenue but should share profit, but there is no profit.

  • This is not sustainable and we need to build up our foundation of profit before opening up the fee switch to stakers. The Stakers would benefit more from a protocol that is sustainable and can operate in profit, than one that shares revenue but cannot reach a sustainable level.

Last week for example: 1,154 mUSD was collect in fees from Mainnet mUSD over the last week. 577 mUSD was sent to Treasury and the other half bought 3,255 MTA for MTA and mBPT stakers.

This is not good, and not a substantial amount for the stakers. The cost to do this operation is already another cost.

3 Likes

I favor the proposal, because I was never a fan of the buyback mechanism (over it’s two implementations).

That said, I also like @nesk’s counter to raise the basefee.

So…why not both?

3 Likes

Whoa, this boggles my mind, I would’ve never put the two together, but why yes, why not both?

Would there be a huge opposition from doing both and quadrupling the treasury sustenance for the long-term?

I feel @soulsby would be a great input here as well for the further road down this rabbit hole!

Thanks @mZeroNine for kicking off this discussion.

I am very supportive of directing 100% of revenue toward the treasury at this time. I don’t believe it makes sense to be sharing revenue with MTA stakers until mStable has reached profitability. The basic assumption driving this is that $1 invested into growth must be higher EV than $1 paid out to stakers now. If this is the case, it is in everyone’s best interest long-term to direct revenue towards extending the runway to allow mStable to reach product market fit and profitability.

The inflationary rewards from the emissions controller still provide incentive to stake MTA, and the increased revenue to the treasury should boost long-term outlook for MTA value.

I would also be supportive of increasing fees on the V1 product, but since this is likely to represent a smaller share of revenue as Metavaults are launched, I believe that this is less critical to long-term success than ensuring that revenue is directed toward funding the project.

1 Like

Yeah, I would not like to increase the fees for V1.

  • It will be a minor increase for the treasury
  • It will further reduce APY for Savers
  • It will not make us materially more profitable, our V2 will

Thanks for the feedback everyone!

So, as it stands, we have a slight disagreement in terms of increasing overall fees vs redirecting more existing fees away from stakers towards the treasury.

Personally, I think we should keep this first portion of RFC strict and only have it be concerned with the split of revenue to treasury vs stakers in the following proposal format

  • Increase fee flow to 75%
  • Increase fee flow to 100%
  • Do not increase fee flow

If we allow for a 2nd variable to enter, the voting options will increase to a level that makes it very difficult to assess and increase the timeframe of the RFC significantly. I’d rather open up discussions in a 2nd part of this RFC that is concerned with the idea of increasing overall protocol fees to 15% or 20% in the following format:

  • Increase protocol fees to 15%
  • Increase protocol fees to 20%
  • Do not increase protocol fees

We could subsequently create 2 separate TDPs (TDP 48.1 & TDP48.2) in which we can tackle these votes & discussions separately to keep the options limited and easy to understand.

For the sake of debate, we should continue to treat it as a single topic moving forward here until we found basic consensus and are happy with the overall looks on this, after which I would create said TDPs for in-depth discussion.

The next step would be to determine if anyone is very unhappy with the above approach and has strong opinions on it and then take the rest from there :sunglasses:

1 Like

Let’s limit the discussion here to one point only, as you said. And let’s limit the options to:

  • Increase fee flow to 100%
  • Do not increase fee flow

This intended change is not so much for the current set of products (although it would make handling fees much easier), but is more generally and signal for the next Meta Vaults.

We should strive to hit a point of sustainability before turning back on the fee switch to stakers. Also, I think stakers shouldn’t just get a portion of the fee for doing nothing, but this is a longer discussion.

Changing the fee to 20% or some other number is only really relevant for our current product, and it would not make us materially better funded. Meta Vaults would not respect this and handle fees differently, so I don’t think this is worth doing and discussing.

3 Likes

Agreed.

That said, I do like this proposal too. However, let’s keep it separate from this RFC.

I would be in favor of increasing the flow.

2 Likes

I guess responding to this question begs the question “wen metavaults?” Because, if a fee increase RFC/vote could be resolved and implemented in, let’s say, a month, and lasted for 6, would that be worth discussing?

1 Like

Fair points, and since I was the only one that originally proposed the 75% option, happy to just see these two alternatives go to a vote.

Also agreed on tackling it separately, if @nesk is cool with this as well. If there are no other objections or strong opinions, I will be crafting a formal proposal in the coming days and then publish it early next week for further iteration! :sunglasses: :v:

I’m cool with that, agree that makes sense to tackle it separately.

I greatly appreciate this example. It illustrates that it is not a large amount of MTA allocated compared to that issued by the emissions gauge. It can be precisely quantified for the example week of 13.1% of MTA rewards for one sided Stakers and 6.8% of MTA rewards for BPT Stakers.

                 Name   Percent    Distributed         Revenue            Total
 MTA Staking Contract   14.41        14,589.52        2,128.41        16,717.94
 BPT Staking Contract   16.98        14,898.59        1,126.69        16,025.27

The higher MTA price goes the lower a % of MTA rewarded this will become. Directing 100% of revenues to the Treasury in order to produce a sustainable product is the most sound decision. Share profits not revenue.

1 Like

This line of reasoning is exactly what is required to determine the optimal fee rate. It is a keen observation that adjusting the fee rate will impact Save (S) and not Convex (C). Then it is utilizing the ecosystem to produce a new equilibrium that produces the same yield for Save and a higher protocol revenue.

total          T = S + C
revenue        R = a T 
protocol fee   p
yield          y = (1 - p) * R / S                                   

I have replicated @nesk’s findings. In order to fix y, but double p the impact would be on S.
In @nesk’s proposed rates, p is doubled and thus save becomes a fraction of Save (qS).

1. (1 - p) a ( 1 + C/S)    = (1 - 2p) a (1 + C/(qS))
2. (1 - p) a ( 1 + C / S)  = (1 - 2p) a (1 + C/(qS))
3. (1 - p) (1 + C/S)       = (1 - 2p) (1 + C/qS)
4. (1 - p) + (1 - p) C/S   = (1 - 2p) + (1 - 2p) C/qS
5. p + (1 - p) C/S         = (1 - 2p) C/qS
6. qpS + (1 - p)qC         = (1 - 2p) C  
7. q                       = (1 - 2p) C / (pS + C - pC) 
8. q                       = (1 - 2p) C / (p(S - C) + C)

S and C currently equal 21.3m and p equals .1 which implies q = 0.8 just as @nesk claimed.
The procotol should be selecting the the value of p which maximizes pR.

       maximize_{p} pa(qS + C)  s.t. q = (1 - 2p) C / (p(S - C) + C) 
       maximize_{p} (1 - 2p)p CS / (p(S-C) + C) + pC

For the current values of S and C the optimal p is around 0.5.
image
Also plotted are if S and C were currently 10m. Same optimal value but with a less steep curve.

image
Although the acutal optimization is a bit messy. Qualitative analysis of the graphs shows that the optimal p = S / T.

2 Likes

Thanks so much for the fantastic input everyone! That’s super then, and I’ll mark this RFC as passed and start chopping away on the TDP!

Since there seems to be actual interest in the community around raising fees for the Save product, I’d suggest either @nesk or @Jeshli port some of the ideas voiced here into a more formal draft RFC (hit me up if you need help with that) on the forum to take the next step with that. :sunglasses: :v: