[Proposal] Dynamic reward distribution

The last week has exposed limits in the current design of Mirror Protocol, with mAsset premiums frequently being 15-25 % compared to the oracle price. Based on the relative performance of the MIR token to the rest of the market, this is hurting adoption and confidence in Mirror Protocol. To restore market confidence we should add a protocol mechanism which will prevent similar mAsset pricing issues in the future. This means we must find a way to fix the underlying issue of supply and demand for mAssets.

This proposal is an attempt to formalize a suggestion made here, taking into account the given feedback as well as highlighting the areas where further discussion may be required. The advantage of this particular solution is that it should be able to dynamically adjust to changing market conditions, bringing mAsset peg stability both in bull markets and bear markets.

Definitions

  • Net short: A user has a net short position in an mAsset when the amount of a particular mAsset that the user owns is lower than the user’s current minting balance for that particular mAsset. E.g. A user mints 100 mExample. Of the minted assets the user sells 42, puts 13 in a liquidity pool, burns 37, and holds on to the remaining 8. Since mExample is doing well, after a while the liquidity pool ownership only entitles the owner to 7 mExample, due to impermanent loss. The net short position is then: shares minted - shares owned or burned = 100 - 7 - 8 - 37 = 48.

Proposal

  • An acceptable spread range (ASR) is defined to be ±2 % from the oracle price (or some other suitable percentage value).

  • Initial reward distribution is a ratio of 80:20 for LP:net shorts (applied to both current LP staking rewards as well as current pool trading fees). [1]

  • The average price spread of an mAsset is evaluated against the ASR at regular time intervals.

  • During evaluation, the reward ratio between net shorts and liquidity providers is re-balanced, increasing one at the expense of the other. With ±2 % as ASR, if oracle price*1.02 < mAsset price, net short reward is increased. If mAsset price < oracle price*0.98, net short reward is decreased. If mAsset price is within the ASR, no reward change is made.

Giving exact parameters for how the re-balancing should occur may be hard at this stage since it is likely to be an evolving problem, but three main approaches come to mind.

Option 1, Seeking long-term equilibrium

  • The time average price spread of an mAsset is evaluated once daily when the main markets are closed (to give the market some time to balance volatility during the day), e.g. 00:00 GMT.

  • Reward re-distribution happens gradually, e.g. by 4 units every evaluation period. So after the first evaluation period the reward distribution ratio can be 76:24, 80:20, or 84:16, based on the price spread during the first period.

Option 2, Seeking short-term equilibrium

  • The time average price spread of an mAsset is evaluated every minute.

  • Reward re-distribution curve is steep. E.g. re-distributing e^(|price spread percent| - 1) units of the reward every interval when the price spread is outside the ASR (1 % ASR may work better than 2 % here). If the resulting units to be re-distributed is greater than the maximum that can be re-distributed, only the maximum is re-distributed. So if the time average price spread is -4 % during the first evaluation period, e^(|-4| - 1) = e^(3) = 20 units would be shifted to LP giving a reward ratio of 100:0 for LP:net shorts in the next period.

Option 3, Setting the devs free

  • We bestow upon the protocol devs the uh… incredible honour of fine tuning the model parameters of a continuously evolving system. They can freely adjust the re-distribution parameters for three months, within the framework given by this proposal. This experimentation period can be extended via future proposals. When the experimentation period ends, the parameter values used during the majority of the last 72 hours of the period are locked in (giving some margin to prevent last minute hacks from interfering).

[1] The 80:20 starting ratio is a bit arbitrary but basically comes from the fact that a minter has to put in at least 150 % of the capital of a normal buyer of the stock, so if both do LP staking the minter has to put in a total sum of 250 % of the mAssets used (UST + collateral), while a normal buyer can put in 200 % (UST + mAssets). Equal profitability per invested dollar would mean the minter should get 250/200 = 1.25 = 100/80 higher reward, which would come from the minting. Note that there is a lot of handwaving in this argument and in fact the minter would have to lose all mAssets due to impermanent loss for things to actually add up. It is just a starting value though, the important thing is that we start somewhere instead of nowhere.

Topics for discussion

  • Which of the three options above is the best? Since finding a good solution may require some experimentation to get right I’m personally leaning towards option 3. What we are actually trying to do is to solve a control theory problem, so utilizing methods from that domain such as a PID controller may improve the final result.

  • There is a possible extension of this proposal for those cases where the mAsset is priced too low, and the reward allocation for net shorts is already at 0. In those cases one could make it even less attractive to be net short by creating a negative interest rate on net short positions. In practice this would mean that the protocol seizes a portion of the collateral for the minted mAssets in question and automatically uses this to increase the size of the UST side of the mAsset pool, so that the mAsset price increases. The problem we have at the moment is however that too few mAssets are being minted and sold to the market, so since this mechanism would make it a bit less attractive to mint, the question is if we still want to add it in now?

Motivation

Minting an mAsset and then selling it to the market (either directly or by being a liquidity provider) is essentially the same as shorting the asset. It is also the only way to increase the supply of mAssets. In other words, you can only be long in an mAsset if someone else is actively shorting it.

Compare this to the regular financial markets. A company makes an IPO and creates a number of shares that represent ownership in the company. The company does however not provide any collateral apart from this ownership stake. It does not have to add money to its collateral as the share price goes up. Essentially this would be like an mAsset minter not having to adjust the collateral at all [2]. We can thus conclude that the supply of mAssets will be lower than for regular stocks, since the supply side does not have this type of collateral free mint but relies only on short selling.

We know that short interest in most stocks in regular financial markets is a great minority, usually around 4 %. Assuming that the same will also be true for Mirror Protocol, we will have a situation where 4 % of the market will have to supply mAssets to the other 96 %. This will obviously create a supply-demand imbalance and a price premium compared to normal shares.

On top of the above argument, owning an mAsset is generally more attractive than owning the underlying stock. Sure you miss out on dividend and voting rights, but instead you get LP staking with 200-300 % APR, the ability to trade the asset 24/7 and extremely low fees/barriers to entry. It seems natural then that the equilibrium price of an mAsset will be higher than that of the underlying asset, necessitating an extra reward for those with a net short position so supply can keep up with demand.

[2] This is indeed one of the possible solutions being discussed in the forum, reducing collateral ratio to let minters profitably liquidate their positions instead of increasing the deposited collateral. The problem with this idea is that even with only a 105 % collateral ratio minters will only be incentivized if the mAsset premium to oracle price is greater than 5 %, which is still quite a lot. Also, should the price of an underlying asset suddenly shoot up by 10-20 % (e.g. because of positive news outside of trading hours), the owners of mAssets will lose out on any profit above 5 % since the collateral only covers 105 % of the price.

Risk analysis

Here I try to go through the possible risks and risk mitigations I’ve identified for the proposal. Let me know what I missed in the comments.

  • Someone could try to manipulate the reward distribution in favour of the LPs or net shorts. In practice this is unlikely to be profitable since it requires manipulating the average price while everyone else in the system is working against you, so any profit will be shared with many others while the costs will be borne alone.

  • If a large part of the LP rewards go to net shorts, the APR for staking will decrease and so liquidity in the pools could suffer. In practice liquidity pool rewards are still likely to be attractive even if 75 % of rewards go to net shorts, since many pools on Uniswap and Sushiswap have rewards around 50-100 % APR for assets which are likely to be far more volatile than those currently on MIR.

  • Especially for option 2 above, there is a risk that rewards will swing wildly, making the rewards less predictable. This could hurt participation. A solution would be to seek long term equilibrium according to option 1 instead, or to increase the cost of taking short term positions through the use of fees.

  • If there is a high turnover of minted positions, the 1.5 % protocol fee when closing a minted position could cause governance staking rewards to spike compared to pool rewards, causing low pool liquidity. This could especially be problematic with option 2 above. An easy solution would be to reduce the protocol fee or redistribute some of it to stakers.

  • During the weekends no new mAssets can be minted, so there is a natural reduction of supply. This could possibly cause spikes in rewards for net shorts during the weekends. Hopefully the market will learn to anticipate this, and keep the impact minimal, but if not, a freeze of some sort to changes of reward distribution when the mAsset cannot be minted could be one way to tackle the issue.

4 Likes

Glad you bring this idea up; it is almost exactly the same mechanism I have proposed internally. I am against option 3 as it would be against the idea of decentralization, but it would allow us to easily test the SP-PV error. :upside_down_face:

As a side note, given the nature of this control problem, I think we would need to look carefully at the PID-type approach for stochastic optimization.

One possible problem in the definition of Net Short. if it’s only looking at wallet balance of mAsset, one can game it easily by transferring it to another wallet.

Not exactly sure about the meaning of burning the shares.

The proposed mechanism should be able to reduce the premium of mAssets, but i think we can consider incentivizing liquidity (which imo should be the simpler method) first before implementing mechanism to incentivize shorting?

Maybe we can implement some sort of incentive multiplier based on mAssets minted so that it’s not more cost efficient to “buy and stake” vs “mint and stake”? 1.25 is a good start.

After the incentive gap is eliminated and more effective liquidity is added as a result, only then we can encourage shorting effectively (else the fluctuation will be large due to low liquidity, making it very hard to fine tune the parameters).

I like the line of reasoning, a well thought through proposal. I will need let it sink in a bit before properly reacting to it.

For now, I would like to note that spreads have been coming down significantly the last few days. With several new mAssets being added this week, rewards will come down heavily as well i suspect. Let’s see how that impacts spreads before bringing anything to a vote.

Thanks for writing up the proposal!

  1. I think it’s fine to distribute the award between Minters and LP, don’t have to worry about net shorts. As long as MCR is not set too low, it is fine for someone to mint some mAsset to put into the LP to get guaranteed awards

  2. I prefer something like option 2 with a wider ASR so rewards swing less dramatically, and also make price manipulation more unprofitable. Currently I don’t think an asset deviating 5%(or even 10%) from the oracle price is a big issue. However, once it gets out of hand (25%+) it will more significantly affect confidence in the system. Because of the potential long term damage to the system, I think it is better to rollout a solution soon so it can be optimized and make the next surge (or drop) in premium smaller

  3. I am not familiar with a PID system but something that optimize the reward distribution sounds much better than any arbitrary settings.

  4. If non-market hours is an issue, we can make reward to only go out during market hours?

  5. I think one possible way to prevent mAsset price being too low is by allowing mAssets holder to recall the security for a fee. What that means in practice is, the mAsset holder can force conversion of the mAsset into UST at a a discount (say 5%-10%) to the oracle price in the future (say the end of the next business day). A random minter(s) will be forced to get mAsset back at the discount.

Great to hear there’s internal work along similar lines!

It is true that option 3 would increase centralization temporarily. I think there will probably be numerous adjustments required over a short time though, so it may make the process smoother. “If you want to walk fast, walk alone”, as they say. Of course, one could also argue that optimizing process smoothness may in the end not be the most important goal.

Never used PID for a stochastic problem before, but I think short term stock movements are usually modeled as random walks, so maybe that could be a starting point if you want to develop a full model? Or one could just take the good old trial and error route.

@TJTJTJ
With burning I just meant closing the minted position.

True, it is in fact possible to hedge a net short wallet by having another wallet net long. Creating some sort of liquidity incentive mechanism like you describe could be one way to get around it. Other possible ways could be either to find a better method to keep track of net short positions, or thinking of a solution to make net long positions have the exact opposite effect from net shorts (so they cancel out).

Food for thought.

@wvl
Premiums are indeed dropping, and probably part of the rapid premium increase last week can be explained by a high user inflow and high staking APR. At the same time, similar situations may happen again in the future, so last week essentially worked as a stress test of the Mirror Protocol, and the protocol failed. If people are to trust the system long term there probably needs to be some safeguards in place to ensure the protocol works both when the market is calm, and during highly volatile/pressured situations like what we saw last week.

The nice thing about this particular proposal is that it will revert to the current situation if no net short reward is required. So if it turns out that the loss of the peg was a one off event that never occurs again, no harm will come from implementing the proposal. But if a similar situation would occur again, the proposal should prevent things from getting out of hand.

@KC_crypto
Thanks for the feedback! Will think this through.

Thanks for putting this together @KC_crypto

I agree that dynamic incentives, correlated to the peg deviation of mAssets, and distributed to minters is probably our best option if significant premiums are still observed as more liquidity gets locked in Mirror

A few observations

I believe it would be simpler to reward minters irrespective of their net trading position, the goal is to create incentives for users to add inventory to mAssets. Either the minted liquidity is added to the selling pressure helping to reduce the premiums, or it’s added to the liquidity already staked for the mAsset/UST pair and will therefore reduce the APR of said pair - this is beneficial to the protocol either way.

Yes I do prefer it as well - we would need to sort out the possible ways to game the system by keeping CDP open during the weekend (need to put more thinking into it)

Please note that this will have the perverse effect of displaying lower APRs on Terra vs Ethereum (at constant liquidity) since we would only alter the distribution mechanics of the Terra side of Mirror

I hear that one somewhere! Another thought to build on. On traditional exchanges when there is an in-balance the short are paid by the long or vice versa via funding rate.

Would there be a way to recreate that mechanism on-chain? We are kind of doing it with newly minted MIR but would there be a possible other source of funding like Anchor?

The locked CDP in UST interest could be paid to either the longs or the shorts based the where the terra price is compared to the oracle.

Someone made a comparable proposal here : Rewarding Minters with UST from overpriced LP pool - #5 by KC_crypto

I’m still undecided actually on how minting should be incentivized (only net short positions vs all minters ?)

I feel that using the CDP to pay long and short is a good way to incentivize as the mechanism is more sustainable then looking at the MIR supply distribution.

I am not sure how that could work though as it would require ANCHOR or something similar to use the CDP to generate a yield…

Thank you for the great input everyone! To sum up I think the biggest problems found with the solution proposed in this thread was:

and

As you’ve probably seen, there is a new version of Mirror Protocol in the works, described in more detail here. I note that it seems like the next version of the protocol will feature a sort of funding rate for long and short positions, which should solve the first problem mentioned above since net long wallets will have the opposite reward effect to net short wallets. Also, since it is a new protocol version I guess it should be possible to update the contracts on non-Terra platforms, fixing the second issue mentioned above as well.

Hopefully the other feedback given here and in other threads will also provide useful input for designing V2 of Mirror Protocol!