Since the launch of the Emissions Controller, more and more dials have been added and weights shifted over time to various dials. This RFC seeks to gather opinions about what we should do with dials that are underutilised.
Dials receive votes from MTA stakers and decide the allocation of newly emitted MTA. Some participants choose to actively shift their allocation while others allocate once and allow it to be dormant. This creates a dynamic in which some of the dials receive fairly few votes from a few individuals that haven’t adjusted their weights in a long while.
The effect of it that there are some dials that receive a very minor MTA allication:
- GUSD Pool: 0.1% ~ 194.66 MTA
- alUSD Pool: 0.1% ~ 194.66 MTA
- FEI Pool: 0% ~ 17.59 MTA
- HBTC Pool: 0.2% ~ 287.26 MTA
- tBTCv2 Pool: 0.2% ~ 300.45 MTA
- Visor Finance: 0.2% ~ 240.40 MTA
- (emissions as per April 28th 2022)
This leads to very little (dust) MTA to be sent to the respective recipients without offering much in value for the protocol. On the contrary, it adds gas costs to send minute amounts of MTA and the users would likely not be able to claim it without paying more in gas (therefore it’s likely to be left in the Vault).
This RFC asks to consider some options on how we can handle this in the future:
- Have a manual proposal to disabled dials each time
- Have a proposal that has some rules on when we disable dials.
- Should we disable some underutilised dials following this RFC?
This RFC seeks to gather opinions about how to proceed with these dials. This would set nice precedence and allows us to have more clarity on the approach in the future.
Disabling certain dails that are not in much use would make the distribution more efficient and use the MTA in dials that actually get used.
- Mitigate dust MTA in Vaults
- More gas efficient distribution
- Risk of removing dials that someone would like to continue to vote for
The Big Question
Should we remove some dials? And if so, should we establish a process for the future?
Let’s hear some opinions on this and we could then decide to formally create a proposal from this discussion.
Hey @dimsome and thanks a lot for bringing this up, an important point in further streamlining the protocol and its myriad of processes!
Basically, I think we should be hesitant around removing dials, as that requires constant supervision and evaluation power by some core contributor, and goes against the spirit of decentralization in my opinion.
If Meta Governors chose not to allocate to a particular dial, it simply means that this portion of the ecosystem is not deserving of any MTA at this particular time, which is totally fine.
Fair point on the dust transactions though, and I think it makes a lot of sense to create a dust threshold moving forward, similar to the Maker Vault DAI dust threshold that requires a particular deposit to be reached before a vault can be opened.
How do you feel about an initial dust limit of 10k MTA to begin with, and see how it goes? This would “store” MTA in the dial until 10k MTA is reached, and then disburse the MTA over x weeks linearly to avoid abuse of the system (considering it costs a lot of gas to abuse the system in the first place, I think it might be enough, but keen to hear your opinion on this).
Alternatively, we could always collect dust per epoch (for instance, if a dial doesn’t get more than 1k MTA per epoch) and then it gets automatically disbursed to MTA stakers once x MTA have collected in the “dust-storage”, which could just be the dial itself in order to save on gas. If we chose this way, we got to take care that if a dial suddenly receives a lot of MTA, on how to handle disbursement, or simply resume usual operations then in order to avoid abuse or being able to game this process.
Thanks for bringing this up @dimsome .
I tend to take a slightly different view to mZeroNine on this, mainly because I favour simplicity in the design of the system. I agree that we should be careful about centralizing the power to remove dials, but I think that this can be achieved in a governance-minimized way by building some rules into the system. For example, if a dial gets less that X% of the vote for X epochs in a row, it is automatically removed.
I also understand that there is an argument to allow users freedom to allocate wherever they want, but it needs to be practical in terms of gas costs. I also think it’s important to keep the number of dials manageable into the future. When a dial is removed, the votes could be proportionately reallocated to the other dials selected by the user (not sure what happens if they had voted 100% on the disabled dial ).
I wouldn’t necessarily support the idea of saving MTA up to be distributed when it reaches a threshold as this adds complexity and makes rewards unpredictable. As a voter on a dial, I would expect that the emissions would be distributed smoothly in the period following voting, rather than at some future point when I may have exited the pool in question.
In saying all of that, we should also consider any solution in light of any possible changes to the role of dials as we move toward a new product direction. Eg. could there be some class of contracts that should always retain the right to a dial?
I would be in favor of creating a minimum % value for the dial to be factored into the distribution calculations. I think it’s the simplest solution that solves the problems, without taking away dials.
That could work. Although if no dials are ever removed and the number just keeps increasing, we’d need to think about how these are presented on the frontend to keep the UI manageable but avoid introducing bias.
I’m hardly a frontend guy, but for this it seems like you’d just randomize the ordering.
Just to be clear(er), when I mention taking away dials, I mean by some sort of automated action or threshold. I’m perfectly fine with dials being removed via direct governance vote.
I would be also more keen on having some kind of threshold rather than accumulating the MTA in the dial (this would make distribution very uneven).
Saying that implementing a minimum % threshold might be a bit more work because it would require the contracts to be upgraded. A simple disabling of the dials would be much simpler in this case.
Gotta check with our smart contract dev to align on the best solution, I would revert back to this thread with an answer.
Sounds good ser, let’s wait for the answer and then tackle this today in the Governance Call, or async here when we have more information!
We discussed this topic last night in our monthly governance call, and came to the resolution that the threshold approach be the most clean one, but given the current development efforts on mStable v2, a more agile approach of simply disabling the underutilized dials for the moment be the best way forward in the interim.
Just wanted to clarify that my support was specifically for disabling via governance. I’m not in favor of the protocol disabling dials under other mechanisms.
Not that it matters, I have 7400 voting power lol. But still.
Understood, there will be a governance proposal before disabling any dials.
Having said this, these are the dials I would like to propose to disable:
- GUSD Pool: 0.1% ~ 984.02 MTA
- alUSD Pool: 0.1% ~ 189.91 MTA
- FEI Pool: 0% ~ 16.53 MTA
- HBTC Pool: 0.2% ~ 269.90 MTA
- tBTCv2 Pool: 0.2% ~ 282.29 MTA
- Visor Finance: 0.2% ~ 674.06 MTA
(emissions as of May 12th 2022)
Seems like a good threshold is 1k MTA for now to revisit the dial, but of course, pending governance approval.
So how do we think about these dials and disabling them? I don’t think they add much value, especially with some of them being a mere hundred USD worth and the majority being locked in the vesting contract. Users would unlikely be able to claim without spending significantly more gas.
Sound pools, just wondering if we should be cautious around the GUSD one? It has gotten 0.6% this epoch, so there might be some interest still (maybe because of this discussion?)
Also, is it worth considering holding off for 1 or 2 weeks until the Idle dials proof themselves or are we ok with just presuming they’ll do their job?
Thanks for bringing this topic @dimsome. I also think that as new dials get added, dust should be taken care of (on the Back-End and on the Front-End)
Beyond the % of weekly MTA rewards these dials receive, I think adding in the variable of the TVL these pools are representing could help make a decision
As of now:
All these pools represent 0.79% (decreasing) of the project TVL, a very low part that is probably not the best ROI for MTA stakers
I think beyond this 1k MTA limit, we could have a TVL requirement like 200-250k, observed for a period of at least 1 month. Indeed this “watch” period could be a good way to create liquidity revival on sleeping pools
I agree, we should also factor in the Value locked in the pools as another indicator. Obviously, that should not apply to new products/pools.
Since upon request, we would want to keep this process to be voted upon, we could start flagging low participation pools and move them into a watchlist. If nothing improves, we can then move to a formal proposal and governance vote.
Pools for the first round that I would like to propose:
- alUSD FP Vault 0.11% | 182.85 MTA
- FEI FP Vault 0.01% | 30.65 MTA
- HBTC FP Vault 0.16% | 259.87 MTA
- HBTCfPmBTC/HBTC: $167.29k
- tBTCv2 FP Vault 0.17% | 271.80 MTA
- tBTCfPmBTC/tBTCv2: $150.08k
- Visor Finance 0.42% | 649.51
Pools on the watchlist:
- GUSD FP Vault 0.61% | 947.45
- fPmUSD/GUSD: 123.77k
- Vote increased slightly over the last weeks and there is over 100k, recommend to keep for now and watch how it develops
- BUSD FP Vault 5.77% | 8,911.87
- Still a significant amount, but as feeder pools don’t produce much revenue, we should keep an eye this pool. Additionally, the mUSD amounts in this pool are lent out to Iron Bank. Removing the incentives might allow us finally to migrate away from Iron Bank. Also, deposit into this pool might not be always possible since the amount that is in the cache needs to be deposited into the Iron Bank but the minting of the Iron Bank cyMUSD is paused.
- RAI FP Vault 1.70% | 2,636.79
- Is above 1k MTA and 250k in TVL. However, as feeder pools don’t generate much revenue, we should keep an eye on this.
NIce overview Herr @dimsome and I agree with this. When do you suggest we review the dials on the watch list? Should there be a formal process in place to be outlined in the formal proposal or should we play it by ear and re-assess when the need arises and the developer capacity is there?
Yeah, I would re-assess as we go and propose another change.
Will be moving forward to propose a formal MCCP with the first set of dials to disable, will post soon.