SIMP-3: Change Short-Farm Maximum Reward Allocation from 40% to 100%

A lot of people probably aren’t reading the forums. Would be nice to have these changes visible on the main site.

I’m not sure exactly which changes you want visible on the main site?

Communication around governance takes place in the forum. When we post the actual governance poll, it show on the governance page and it will link to this forum post. If the poll is approved and goes into effect, then the APR on the site will reflect these changes and the documentation will be updated for the same.

There a lot of UX options. A simple solution could be to use a small amount of space at the top of “My Page”. It could read something like:

Recent News

Staking rewards are going to change! Staked long positions will earn less for assets with a high premium.

(URL to proposal)Read More(URL to proposal)

Key requirement would be to have a lead time between a proposal getting voted in and it being enacted. Would only make sense for major changes, not every proposal. Wouldn’t need to be up all the time either. However, I’m not sure how well all this plays with the governance mechanisms as it relies on lead time.

If functionality like this existed, there could have been a “Minimum Collateral Ratio for mKO is going up to 130%” notice for a week before the change went live, which I’m sure many would have appreciated.

The bigger issue is that no one wants to code/host/maintain a replication of information that is already available on the webpage. I’ve seen literally no movement around the idea.

In terms of complexity and maintenance, this is basically a banner that would need someone to type one or two sentences a month. I don’t see the issue.

It would also encourage users to get more involved in the forums. Given recent events, it’s pretty clear that information is not making its way into the hands of a number of Mirror users. This is a simple low cost solution to solve that.

Great! Git for the UI is at

Please submit a pull request with initial banner design

1 Like

I’m happy to put my technical product owner hat on and help organize this feature, but that would require a little more cooperation and a little less snark :confused:

Can we get this to a poll? Would definitely be a good first step to addressing the premium mess. Props to the steering committee.

1 Like

I apologize for the snark. I am an unpaid volunteer working in these issues because they’re interesting and because I care about people. There has been a lot of people that have never done anything for mirror telling the rest of us that are working for free that we should be doing better.
It’s a fully decentralized protocol. Anybody with a good idea can take initiative and push their idea forward.

1 Like

SIMP-3 will go to poll within the next six to eight hours.

1 Like

Totally get it, no worries. I’m also quite new to Mirror as well as open source in general, so I don’t really understand how things work. Still learning.

I am serious about helping though. What I can do is write up a proposal on how this feature would work, get community buy in, and organize requirements in a way that would minimize development time. Maybe we can get the feature implemented in 4 hours instead of 4 days (yay planning!) - which would be great given the limited front end resources.

What I would need though is a little 1:1 time with a front end developer who’d build the feature. I don’t know how to best approach this.


There are a couple of front end developers in the MSC channel in discord that can help with this if you’re interested in driving it. Hit me up on discord @josephsavage#1439


Everybody time to vote!


You’d have more empathy for his snark (which was barely perceptible!) if you saw some of the other threads of mirror users literally making demands to the MCR to change this and fix that. I don’t understand why the community doesn’t have more appreciation, or at least graciousness

1 Like

I’ll admit I’m far from an expert and don’t really know the underlying mechanisms regarding MIR distribution, but a few things come to my mind, after thinking about the proposal:

  1. It sounds like a temporary, workaround-like action, in order to desperately get a grip on the premiums getting out of control. It’s clear from the start that it cannot stay that way and will have to be re-adjusted once the premiums are back to normal, right?
    No offense, but is that really the right course of action? There has to be some deeper, underlying issue.
    Is the idea to get mASSETS back to peg and in the meantime identify and tackle the real issue for depeggging over time? In the end, staying close to the peg has to be the goal. And actually I think that final solution would naturally bring the premiums back in line, otherwise it wouldn’t be the correct solution. Maybe I’m wrong though… :wink:

  2. The 6 user groups… well. My use-case for Mirror is in fact to only short-farm mSLV and mIAU, using aUST. No hedging at all. Reasoning is that I think it’s very unlikey for gold or silver prices to dramatically explode, they’re mostly hovering around the same baselines. How does that fit into the mentioned user groups?

  3. User group DN - Mirror Only: That’s exactly what Aperture is doing, right? How would the proposed change affect them (and their users of course) and are those automated strategies maybe a bit of a cause for the whole situation?

I believe you have misunderstood how sLP MIR distribution works. Shorts only get rewards when there is a premium. The proposal is simply removing the current cap at 40% so that potentially all MIR rewards on an asset go to short positions when the premium is large enough. You can read more about LP/sLP MIR distribution in the documentation.

Imo the proposal makes sense, also long term. I see the 40% cap as only a precaution taken when the sLP rewards were first implemented.

I would love for someone to describe exactly how the change will be implemented tho.


It should be just changing a single parameter: “short_reward_weight: Decimal::percent(40),” → “short_reward_weight: Decimal::percent(100),


I looked at the smart contract and made a couple of observations:
-The formula to calculate short rewards seems highly over engineered (in my opinion).
-It also looks like they were a bit sloppy and hard coded the calculation to converge towards ~40%. In addition to a hard cap at 40%.

No disrespect to the engineers at TFL, they were probably under time pressure, and also could not foresee us discussing this limit a year later.

But changing this limit will require updating the smart contract itself. Does anyone in the MSC have the necessary permissions and competence to do so?


Two potential scenarios here:

  1. Original devs see successful poll and step in to help get the change over the line. In that scenario I’m not sure whether they have a shortcut to push it through or whether it would have to go through a deployment poll. I would hope there is a second poll, as it exposes weird governance risk otherwise.
  2. After poll is approved by community then MSC uses their treasury to post a bounty for the work. In that scenario there would 100% be a deployment poll and you can vet the work done before voting for/against.

This poll is NOT about whether the technical implementation of the change is safe, but IS about whether the community agrees the change should be done before MSC commits our very limited budget to it.


I don’t see it as sloppy myself. You can’t have everything configurable otherwise it hard to predict dangerous combination of parameters.

Yes it is only one line change to the contract. It does need review to make sure the is not some consequence we haven’t thought of. I have reviewed myself and do not see any issue.

I am pretty sure this it is possible to get the contract migrated via governance polls alone in the case the original team doesn’t response.