MTA rewards post MCCP-4

Summary

On July 12th, the last emission of 276,923 MTA will go out for EARN rewards as agreed upon in the governor approved MCCP-4 MIP. Beyond that date, we do not yet have consensus around how MTA rewards will be distributed.

IMHO We should use this moment as a chance to rethink MTA rewards and the total supply emission from a first principles line of reasoning. Lots has changed over the last 3-6 months, and some of our current MTA rewards can obviously be reallocated in more optimal ways to accrue long term value to the mStable protocol and mStableDAO.

Screenshot_2021-06-29_at_4.24.09_PM
A summary of MCCP-4 emissions

We have some existing commitments:

  • MTA rewards to Polygon/Matic for Save on Polygon (3 months from July 5th. c.20.5k MTA per week)
  • MTA rewards for FRAX pool (3 months from July 5th. c.20.5k MTA per week)

Topline things to align on

The topline considerations for us to quickly align on are below. Obviosuly there is much more to consider, but I think we should initially focus our conversation on finding consensus regarding:

  • How much MTA in total should go out on a weekly basis after MCCP-4
  • Where it goes (what are we trying to incentivise?)
  • How often it is distributed (weekly at present)

Goals

  • I personally think we should lock MTA emissions in into perpetuity. Think of it as the rest of MTA’s mining reward emission (like for a POW coin). We should signal publicly and with certainty what token inflation looks like for the rest of MTA’s emission. I feel many sophisticated market participants are (rightly) worried about the vagueness of MTA’s long term supply emission and this has meant they have remained on the sidelines.

  • Automate the emission distribution process as much as possible. The current setup where rewards are sent out each week is outdated given where mStable is today.

Low hanging fruit

I see some no brainer changes we can make to better accrue value to mStable. I’d be interested to see what other Metanauts think are the obvious “quick win” type changes we can make to the current emission.

  1. The 5k weekly MTA/ETH Uniswap v2 emission.

We are sending 5,000 MTA every week to Uniswap v2, whilst the protocol’s emphasis should be on bolstering liquidity on Uniswap V3 for its improved capital efficiency.

I suggest the mStableDAO simply redirects this 5,000 MTA amount to a Visor actively managed LP position for MTA/ETH on Uniswap v3. This has the following benefits:

  • Improved liquidity support from v3’s capital efficiency gains
  • Compliments the mStableDAO’s existing 1 sided MTA liquidity in Bancor
  • The DAO keeps custody of the 5k MTA per week, instead of it being handed out to liquidity miners many of whom dump the token. Value accrues in the protocol treasury
  • The depth of liquidity would grow over time, and reach a point where it is sufficient and the emission can be stopped
  • Trading fees accrue to mStableDAO for MTA/ETH pair into perpetuity
  • No risk of angry farmers losing out on IL from contributing MTA/ETH LP tokens

Broader considerations

This is the start of one of the largest discussions in mStable’s young life as a project. Reframing rewards in the long term will touch many other parts of the mStable protocol that are already in existence or scheduled in the roadmap. I’ve listed some items for consideration below, however this list is not exhaustive:

  • Staking rewards in the long term? How will we do rewards for staking V2?
  • Eth L1 vs L2s, both today with Polygon but also 6 months from now with other L2s live
  • Liquidity Utilisation Ratios - can we continue to flexibly reward pools based on performance whilst locking in an emission plan into perpetuity? I think we can but the devil will be in the details.
  • Rewarding STAKED MTA instead of unstaked MTA. Like AAVE currently does.

Metanauts assemble :rocket: I look forward to hearing your responses.

3 Likes

To help with the discussion, the following Dune Analytics query shows the Weekly MTA distributions.

1 Like

Weekly MTA distribution in USD value at the time of the distribution

2 Likes

Thanks Nick. Very helpful to see.

Are we able to find any stats on how rewards compare to TVL, trade volume, mAsset supply, APYs, or other key metrics?

To me, these two statements seem to be in tension with each other. By this I mean, if you accept that things have changed a lot in the recent past, it seems like a reasonable guess that things will change a lot in the near future. In a time of heavy change, keeping optionality generally seems wise, but locking an emissions policy in a very firm and long-term way limits optionality.

@jwpe how do you think about the tension here?

FWIW I agree with your low-hanging fruit suggestion. But that 5k is something like 2% of the volume listed on @naddison’s first chart, so I assume the meat of the discussion is the bigger emissions targets (pools, save, staking)?

One last question: I think that @naddison’s charts don’t include the Sablier emissions to team/investors/advisors, correct? I think that’s important to also note in this discussion for scale. One thing the market is likely to look at is overall emissions rate, whether that’s team payments or pool incentives or what have you. They’ll perhaps judge different kinds of emissions differently, but I think it’s important for us to have the overall number in mind as we continue through this discussion, in addition to the more fine-grained numbers that are zoomed in only on rewards/community incentives. Thanks as always!

2 Likes

Great points Java, and yes the two things are very much in tension, which is why a discussion is needed I feel. mStable and DeFi will continue to change in ways we can and cannot foresee, and the intent is to create a skeleton for things which will benefit from more certainty (like total emission projections) whilst maintaining the flexibility to be able to change reward flows (as we will surely have to do as other L2s go live, and eventually as we migrate to ETH2). Part of it also is to move away from the current emission process that risks a manual error translating into an on chain problem (ie incorrect emission amounts being sent out by mistake one week)

I think we can commit to a “topline” emission, whilst preserving governance’s discretion over how its allocated. Similar to a hose with a known rate of flow out, that we can then choose to divert to any arbitrary destination. However this is me speculating without any input from the devs, who I’m sure will have an opinion on feasibility :sweat_smile:

And yes, the meat of the discussion will be around the larger figures. It plugs into Staking v2, which I think is the other critical path process we should be running concurrently to this one. Lots to unpack there, and we as a team will be presenting our collected thoughts on that soon.

Re. total emission charts inclusive of Sablier streams, I’d love to see one too! I gave up with the maintenance of the old MTA supply emission model months ago as it got far too complex and other demands became higher priority. Dune charts are much more aesthetic anyway.

1 Like

One thing that I would strongly advocate is to simplify the MTA rewards calculations.

I had a look at MCCP 4 and it does make a lot of sense to allocate funds according to volume and TVL of Pools. But there are a few issues with this approach:

  • The rewards calculations are based on the past week’s volume and TVL, a Feeder that gains more traction attracting more MTA rewards incentivizing further that pool. In essence, it’s a feedback control system with a 1 week lag time. Due to the unpredictability of the market in general (input), I think it’s hard to model such a system and behave it the way we intend to.

  • Changes or additions to this system are difficult to do. The rewards change with each feeder pool added.

  • Also, there is no predictability in this. Let’s say we intend to have a partnership with some co-incentivization. Normally, I would suggest we do 1 to 1 incentive matching in USD value. With this system, we cannot predict how much of the MTA rewards we would distribute to that co-incentivized pool.

Therefore, I would be in favour of a much simple way of calculating rewards that allow for predictability and potentially a way to automatically distribute rewards.

2 Likes

That’s correct. The above charts do not include the Sablier emissions. They only include what’s emitted to the different vaults. I’ll get a chat that includes the Sablier emissions.

Nick

1 Like

Here’s the main MTA holders Dune Analytics

4 Likes

I’ve done some modelling to arrive at a proposed emission. This is very rough, and all the parameters are open for discussion. Topline info below sers:

  • 30d reward cycle/epoch instead of a weekly cycle (this means the reward numbers are 4x the existing weekly numbers). I see this as better suited to the time it would take for governors to change rewards, and it lessens the overhead of onchain distribution.

  • 6 year total emission out to 2027 as mentioned in MCCP-4

  • Locks in topline emission number, but the granular breakdown of where these tokens go is fully determined by governance. Doesn’t discriminate between L1 / L2 rewards.

  • Assumes no long term inflation. Supply capped at 100m MTA and thus the emission ends without a tail going forever to zero.

  • Allocates MTA to other sources, such as The Swiss Association, a portion for the GrantsDAO, and a portion for future full time contributors. These are placeholder values I’ve input, so people who feel strongly about the allocation to these other entities should make their positions heard. I note here that the amount the Swiss Association will get could vary widely depending on external factors. I’ll let @james.simpson speak to this as its a key piece of mStable’s long term structure. These numbers should not set an expectation and are there more because I just had to put some filler value in, so that I could share this now (as time is against us).

The benefits as I see them are that this proposed long term emission gives certainty to long term MTA supply emissions, whilst keeping enough flexibility for the tokens to be allocated where they seem fit by governors at the time.

We could also trail off rewards more aggressively in the short term and make the tail “fatter” or “longer” to address concerns about the amount of tokens hitting market over the next 6-12 months.

By doing locking this in once and for all, it eliminates the need/risk for the emission to be altered in future. Were this to not be “baked in”, I personally feel it exposes a malicious governance attack vector where the token supply emission could be changed to the detriment of the protocol. A feature of Bitcoin is the fact that its supply emission into perpetuity is known. It also frees up our governance bandwidth to “higher order” things such as strategy and growth.

Looking forward to everyone’s thoughts here.

https://docs.google.com/spreadsheets/u/1/d/e/2PACX-1vR1CjGajfVZbMpmdYRzmuzbP71tD1zCIED5frlXlT7AcCF4eZZ2FOEQHmoK4tfGRSjr1t-CeyGdTE8o/pubhtml

3 Likes

I’m still in the process of trying make sense of all the details, and considering if there’s any valuable feedback I can provide, but in the meantime I wanted to make a quick suggestion.

It seems we’re very much up against the clock on this. Is there any possibility (technical or otherwise) or value in implementing a much shorter, immediate 30-day/60-day/90-day emissions schedule to give us more runway and time to think this through for the longer term? Perhaps performing some analysis on other protocols’ emissions schedules that share our market segment and/or have similar tokenomics (currently released vs max supply) would be valuable for assessing what works and what we want to change given our own protocol, token, and ecosystem.

As for some immediate feedback on the above points, I think the monthly (30d) epoch system is much better than weekly. I could also see value in making thicker “step downs” with 60d or 90d epochs and operating on a quarter system. Gives plenty of runway for developer time, as well as ample time for partnership programs and integrations (consider our 3m emissions of MTA and MATIC rewards on polygon).

5 Likes

Finally found some time to comment on this, and many thanks @jwpe and @naddison for doing a lot of the heavy lifting on this already.

I think an epoch-based system is a lot more smooth than the current weekly emission system to the addresses, as it seems very stressful to spend a good portion of manual labor on a weekly basis to distribute rewards per hand in this fashion.

I’m not yet 100% sold on pre-funding each contract with the full amount of allocated MTA, instead of performing this operation on a quarterly or even yearly basis, as when the contract changes, we would need to re-allocate funds either way into the new contract, and therefore it might make sense to do this in one fell swoop regularly for all contracts compared to each contract when the need arises, right? But I’m not tech-savvy enough to weight the pros and cons of each, and leave this to the big brains to decide.

Regarding the numbers, they feel sound to me, but I think we can always adjust the emission later down the line via vote if we really saw some urgent need to. I love the fact that we would keep distribution dynamic, as it alleviates the need to re-calculate emissions every time we add a feeder pool or a new product into the suite, and simply take the rewards from the existing schedule.

I’m a very big fan of removing MTA/ETH incentives from Uniswap altogether and channeling them into the aforementioned Visor NFT to have it actively managed by the team. Just to drive the idea home, our recently deployed passive DAI/MTA position on Uniswap v3 has already hauled in over $5k in fees, so the potential passive return for the treasury in ETH and MTA is significant, not to mention the other benefits highlighted by @jwpe on top of some nice exposure within the Visor Finance ecosystem, as well as opening the possibility for other collaboration opportunities with them down the line.

One additional thought along these lines is if we should set aside a predetermined amount to fund collaborations and other initiatives from the mStableDAO towards other protocols and DAOs, as with the above spreadsheet it looks like the treasury will have 0 remaining MTA to work with, is this right? I’d suggest keeping at least some MTA reserved for this, as it would feel weird not holding any native stock in the treasury for any unforeseen things, what do you think?

If we wanted to have some sort of backstop in place in order to consider the valid concerns of @lonetree, we could bake in a mandatory review by the mStableDAO and Meta Governors at the end of each year to review the current emissions, and sign off on keeping them, or performing slight adjustments to them if need be?

I know we’re short on time with this, so just getting the horse into the race makes sense, and as we all know fixing something already running is more difficult than doing it upfront, but perhaps here we could see it more like a race with some pit-stops along the 6-year long cruise to the destination?

Stoked to move this forward along the other v2 improvements, and wanted to close with the thoughts that we should definitely consider handing out the staked version of our MTA for v2 and moving forward, as we already struggle hard with dumping, and this will put a natural virtuous cycle in place for this, and help with offsetting gas costs and enable more efficient distribution to real supporters and believers of the protocol.

As a matter of fact, we should potentially consider handing out the staked version or other derivatives of our token (KPI options for instance) for certain pools and positions where it makes sense to, but I feel this would blast the discussion out of proportion right now, and most likely can be tackled and added on later down the line.

2 Likes

Currently around 276,800 MTA is released weekly to SAVE, MTA Staking, Feeder Pools, and Uniswap V2 liquidity pool.
The suggested schedule would mean that 969,232 for the first month is distributed. How would we choose where and is this including future liquidity mining programs? Are you suggesting we follow the same formula as in MCCP4 for Save and Feeders?

Good thoughts all, my responses:

@lonetree the easiest stopgap would be to carry on the existing weekly distribution schedule, say, for a month or 6 weeks, whilst we hash out details of a new emission. As much as I’d love to do a 30/60/90 day epoch now (its my preference), we probably should debate the changes as a whole then implement in one go. (ie we should not start changing the emission curve piecemeal)

One quick solution could be to go back down the MCCP4 emission curve. So on July 19th we would emit 242,308 MTA for a 6 week period, as was done previously between May 17th to June 21st (see image below). We’d then rehash the long term emission curve from that new starting point which is doable.

@shubidoobi I think the migration away from the UNI v2 liquidity pool is a no brainer. Lets start a conversation with Visor to get a 5k weekly 1 sided MTA LP contribution happening that they would actively manage?

Also, the model does set aside MTA for these types of collaborations via the GrantsDAO allocation, at least that was implied when I put the numbers in. We can opt to to hold some tokens in treasury just as long term unallocated.

@shubidoobi @Dimsome lets set a time aside next week for @naddison and I to walk you through the on-chain plumbing of how rewards are actually distributed, I think this will answer your questions about how we choose where tokens go when they get distributed.

Next steps as I see them:

  • Agree on stopgap emission amount and period and post related snapshot for governance on July 12th for voting

  • If there’s appetite/no objections, also queue a snapshot vote to move the 5k weekly Uni v2 LP emission to an actively managed Visor position on v3. Also to go to vote on July 12th. (Assumes Visor team says we can do it and we deem it to be worthwhile)

Haven’t really fully digested all that’s here, but at a high level I just wanna echo @lonetree’s point about a stopgap period. In addition to the reasons he provided, we’re in a big evolution phase right now of the project with a lot of things in the air–staking v2, mstkETH, Convex style boosting layer, L2 deployments, etc etc.

I think we need to determine more of a concrete direction on those key developments before designing the emission schedule. It makes sense to me to design the emission schedule that suits the product. i.e. should we budget more emissions for Q1 2022 if we want to bootstrap the mstkETH product around the merge, etc. (assuming the merge happens somewhat on time). To @Javalasers’s point, there’s a lot of moving parts here. I understand the desire to lock in and automate, but not sure that’s feasible right now given the multitude of variables both within mStable’s plans and the broader landscape. Fixed decisions in an uncertain landscape seem incompatible if we’re optimizing for the best outcomes.

1 Like

To extend this graph a bit, this would mean a distribution like this:

2 Likes

Upon some reflection, I personally am now leaning toward a more aggressive reduction of emissions. This is due primarily to some data about returns to the mStable protocol from feeder pools. TLDR they provide very little value to mStable when contrasted against the magnitude of how much MTA is being given out.

This data will be shared soon. But with this in mind I propose this also as an alternative, in line with @alsco77’s recommendation. It reduces rewards 1 step lower, to the levels they were at in late April/early May.

1 Like
  • I think a quarterly or epoch-based emissions cycle makes sense given mStable’s current development and upcoming roadmap as we have the flexibility to flex rewards to areas of growth
  • However, I think some transparency on how much is allocated for each period/epoch would be helpful. Instead of a weekly emission curve, we could do quarterly or semi-annually and allow some flexibility when required
  • A strategy for allocating MTA rewards need to be derived: how much goes where MTA liquidity pools, mAsset liquidity pools on 3py platforms, mAsset Feeder Pools, staking etc

I think as a stop gap measure reducing MTA rewards based on recent performance data makes sense as we figure out the emissions schedule in the coming weeks.

1 Like

Im going to double back on myself here. I usually don’t flip flop, but looking at the BD and partnership commitments in the pipeline, and the MTA promised for these collaborations (across both Polygon and L1) I have changed my vote to 242k MTA per week as initally proposed.

Here’s the latest MTA distribution chart with the Polygon distributions added

The Dune Analytics query for this is

The Polygon amounts need to be manually added to the DA data so it may not be up to date in the future.