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 @apricity0x 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.
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
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.
2 Likes
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.
Below is the MTA in Feeder Pool vaults verses the amount of MTA distributed to the vaults and the 2/3 amount locked for 26 weeks.
Data source Dune Analytics
Below is the MTA that will be unlocked from the Feeder Pools after the 26 weeks locking period expires.
Data source Dune Analytics
Below is the governance fees collected from the Feeder Pools
Data source Dune Analytics
Feeling the need to poke and revive this conversation: We have until the 30th of August to enact a new mechanism (including all governance steps).
The last rewards under the extension are to be distributed on the 23rd of August.
Questions that remain open:
- What will be the long-term reward distribution schedule (@jwpe outlined a suggestion earlier for a 6-year schedule with decreasing rewards)
- How are rewards to be distributed? Is an automated distribution to the pools possible to include within this successor proposal given the timeframe? (@alsco77 , @naddison )
- How do we carve out rewards for Polygon, MTA LP Pools in general and for other general BD opportunities?
Thanks for the poke @dimsome - good to bring this up again.
With the extension coming to an end soon, and with the new staking contracts about to come out, I’d propose to simply extend the current MCCP for an additional 4 to 6 weeks in order to give the development team enough time to focus on the most important task at hand, and give ample time to really develop a system that will carry the rewards sound into the future, without needing to re-visit them again anytime soon.
We might also want to consider dropping the rewards a little bit more for this extension, in anticipation of a greatly overhauled system, and in line with the suggestions above, but not sure if that is needed or required for such a short time span.
1 Like
I am thinking now that we might decide on the topline and long-term emission schedule in this proposal, while the distribution can be done via the current methodology. Once the automated gauges are launched, the topline emissions are already in place and we can then decide how these will be distributed.
I’d be keen on reducing emissions over time.
4 Likes
Sorry for the radio silence lately - buried badly in irl work. Have plans to add content to the Forum over the coming weeks and catch up on what I’ve missed. Feel this is an important topic to chime in on first given the time-sensitivity.
I see 3 important considerations in determining a future emissions pathway.
(1) Both broader market conditions and mStable’s development are very dynamic. Given this context, establishing an automated, linear emission schedule doesn’t optimize for the best outcomes. We’re much better off voting on a quarterly basis in my opinion. Let’s say we have a new product launch coming up we want to bootstrap. We need to ensure the emission schedule is flexible to increase around that launch.
(2) Linear decrease over 6 years doesn’t make much sense. Emissions are meant to bootstrap the product and generate sticky users/network effect. If it takes us 6 years to do that, we’re candidly ngmi. In addition, once emissions reach such a low point, the marginal utility of an incremental emission is immaterial (i.e. not much different from zero emissions). As a result, we should condense the emissions over fewer years (3-4 years) and go all-in on bootstrapping a large user base/network effect during that time period with a steeper emission cliff given the marginal utility dynamic mentioned above. mstkETH is a DeFi building block for the future. We go all in on that in the shorter time horizon.
(3) Lastly and most importantly, the current structure of emissions where we are vesting user rewards over 6 months fundamentally prevents mStable from maximizing the utility of our emissions (i.e. we are throwing away $$ at the expense of the treasury, holders, and product traction). Let me explain.
Given the vesting of rewards, any rational actor must discount the yield being offered based on the uncertainty that by the time the actually receive the yield, there is a decent probability p(MTA decrease in price), such that they may underwrite the yield as 25% rather than an advertised 40% (numbers are just an example). While we are emitting 40% worth of yield, we are attracting only 25% yield worth of capital. Even if this discounting is not done explicitly, people do this implicitly in their consideration that the rewards are locked & that accompanying uncertainty. Even if the user makes the wrong assumption that MTA will decrease in price over time (i.e. MTA actually increases in ~6 months), they still must consider this risk in their capital allocation - the process is independent from being right/wrong.
As a result, we are never reaching the full utility of the emissions we are giving out because a certain % of them are being “discounted” during that underwriting process (whether explicit or implicit).
Therefore, we arrive at a mismatch of incentives in the current scheme. Liquidity providers (fPool LPs, Savers) want instant liquidity on their rewards and will accept a lower boosted yield for it. MTA stakers want to lock up and earn more cash flows from their MTA because they believe in the token and the protocol, but most do not have the capital to get the most out of their boost.
Convex solved this mismatch with the pooled boost. We must use that pooled boost solution to maximize the utility of our emissions. More on the other reasons why that’s important here. You’re seeing the encumbrance of not having this mechanism play out in real time with the need to try to make this Badger loan manually, which also comes with no direct value accrual to MTA stakers.
Let’s lock up the stakers who are the individuals who will actually contribute to the project and give the liquidity providers instant liquidity to better align incentives, maximize utility and bootstrapping effect from our emission schedule, and prevent us from wasting emissions to risk underwriting.
3 Likes
Howdy folks
Read through most of the thread on my lunchbreak, and this post from Dimsome seems to have the most concise breakdown of what needs to be decided upon.
- I would favor a shorter distribution schedule. 4 years seems like a good number, and would represent a split between the more aggressive schdules I’ve seen in the thread and the longish one. I don’t think 6 years is bad though. Its just that 6 years is a long time in crypto. Well, so is 4. I think there’s some persuasive weight to a distribution time that takes awhile; it says “we’ll still be here.” I think there’s a useful psychological point to be made that acting like we’ll be around a long time will help ensure we are around a long time, if that makes sense.
- Since I haven’t been around and paying attention long enough to know why the distributions are done on a weekly basis, my thought is that it is a nice way for users to see “they’re still alive.” I understand it’s more cognitive overhead for the folks controlling the multisig to have to do this every week though. Ultimately, it’s not my responsibility so I feel out of place telling someone else how much they should be working.
- It’s hard for me to say anything about this in particular, because of my view of the MTA token. I personally don’t view the MTA token as a capital asset, because currently it doesn’t act like one. It acts like a governance token that is still in its distribution phase. I definitely have a lot of opinions on the MTA token that don’t fit into this discussion though, so all I can say is that I prefer more distribution over less distribution. OTOH I would dearly love for the vesting period to be eliminated. I haven’t voted in any governance despite having 5 figures in the Save vault because I’m in various lockups until November at the earliest. I don’t want to buy tokens either, for reasons that are out of scope of the discussion.
I don’t know how much this helps. If there’s some other specific point to be weighed in on, just let me know. With more specificity, I can be more useful I think.
1 Like
As this discussion continues to progress, I want to just highlight this point made here by derc within the context of what I mentioned above. As everyone knows, emissions are a very useful tool in the toolkit for a protocol bootstrapping a userbase. Everyone also knows they do, however, come at a cost. Thereby, the goal of an emission schedule is to max(utility) and min(cost).
Notice that by merely decreasing emissions you are decreasing both utility and cost - net/net you don’t really end up in a better place. You could have the same level of emissions, but if you improve the mechanism by which those emissions are distributed (my point #3 above), you end up in a better place. Heck, you could actually increase the rate of emissions, but as long as your improvements to the distribution mechanism outpace the costs you’re still better off.
Thereby, while they have the reputation, more emissions = bad. It’s really not the amount of emissions, but the design of the mechanism. For proof, look no further than the Curve ecosystem. CRV is up over 115% YTD vs. btc. Its supply has inflated over 130% YTD, yet it’s handily outperformed the digital SoV. Again, not about nominal inflation, rather good ponzinomics - layering in value accrual to the token, creating well-aligned incentives between holders/LPs, and earning cash flows for locking up the token. Just food for thought.
2 Likes