FEI has been sold at 0,85$ during the genesis event thanks to TRIBE airdrops. Every no-swappers is in latent profit when FEI effective price is > 0,85$. That’s why FEI price is moving between 0,85$ and 1$. There is no incentive that can enforce a 1$ peg, except new use cases and outside demand. No-swappers are just arbitraging themselves around 0$ profit (0,85$ FEI).
A proposal outline
It seems that we want reweight to trigger when the price deviation (m) is large, and also when m has been large for a long time, that is, when t is large. How about combining these two criteria by taking a weighted sum of the history of price deviations?
Let m_t be the price disparity at block t. Then the average deviation at block t is defined as
A(t)=m_t + d*m_{t-1} + (d^2)*m_{t-2} + (d^3)*m_{t-3} + …,
where d is a time discount parameter between 0 and 1. This A(t) is the variable that determines the mint incentive, the burn penalty, and reweights.
Both the incentive and the penalty functions would be increasing functions of A(t). For example, to keep things aligned with the current protocol, we could have something like
B = A(t)^2 * 100 * x
I = min {A(t) * x, B}
Notice that A(t) is now playing the role of m, and we no longer have w(t) as a separate variable. As long as A(t) < 1%, we have I=B. When A(t) is above 1%, B grows faster than I.
Finally, reweight can be triggered whenever A(t) > C for some constant C.
Although it looks a bit different from the current protocol, this protocol really makes use of the same two variables: distance from the peg and time. The difference is that distance and time are combined into a single variable A(t), making things simpler while still capturing the idea that reweights are triggered when the price is far way from the peg for a long period of time. Also, Mint and Burn are deflationary.
It remains to be verified that there is no way to game this protocol.
This is a great analysis. I agree that the incentives would be low but it would also achieve the more intuitive effect of reweights happening faster the further below peg we are once we cross the breakeven point. This is because the distance from the peg is multiplied onto the incentive growth rate but the ceiling isn’t also moving further away. The arbitrage condition would create buy support.
Solution 2.
Will stabilize/even out organically.
Clean / Straightforward / Simple.
I do not know if arbitrage can work when having a so high sell pressure. What could be the impact of Bots? They would sell first on the reweight?
Great initiative! I would prefer option 4) but with buying FEI with an auction design if possible.
I think the idea should be to design the protocol so that the threat of a reweight prevents people from selling too much, so that reweight does not have to happen that much.
@joey, I think we should focus on identifying and solving the problems that the current protocol has. For example, a burn cap would not change the fact that price can be stuck below $1 because purchases push back reweights.
A reweight just occurred and reset the reward: Ethereum Transaction Hash (Txhash) Details | Etherscan
The price immediately sold back to >3.5% off peg and a 15% penalty
I would like to say great news, but I am not sure that it is. Now we need to wait another day for the next reweight, even though the penalty is 15%. In fact, we need to wait another day precisely because the penalty is high.
From the discussion so far, it is still not clear to me why we want a reweight to take longer when the price is farther away from the peg.
I think it would be better for reweights to be faster when further from the peg. Options 3 and 5 help in this regard.
If nothing is changed in the reweight process, it will be exploited by the bots all over again. They accumulate FEI for $0.80-$0.90 at secondary markets and dump it as soon the reweight is complete. Some kind of auction is required. Or maybe the option to “pre-swap” FEI for ETH right after the reweight (the amount to pre-swap is based on your TRIBE holdings I guess?).
Is it possible to peg to 1 USD = FEI and remove sell penalty and bonus at the same time for a time window so people who dont trust/know good enough the project can leave and then a new positive environment can be build ?
I agree that with option 5, once the burn reaches the cap, a reweight is more likely when m is higher. But before the burn reaches the cap, a higher m still makes a reweight more difficult. Also, we still have to take care of the issue that purchases push back reweights.
I think option 3 makes relatively the most sense among the five options. But reweighting every few hours is still not enough if price crashes rapidly in between the reweighting blocks. Similarly, reweighting when a price is below some threshold, say .99, does not help when the price is stuck at .995.
I think the fundamental reason why option 3 is insufficient is because we need a continuous model of reweighting, where reweighting becomes gradually more likely as 1) price drifts farther away from the peg, or 2) price stays away from the peg for a longer period of time.
If you agree that we want 1) and 2), may I ask you to take another look at my proposal outline above?
We have discussed the tradeoffs of various implementations at length. I’ll condense here the summary of what I see based on the above comments and we can take this to a snapshot vote.
A reweight recently occurred which reset the spot price and reward rate, and then was immediately sold back down to a >3.5% deviation and 10% penalty.
Forcing reweights or increasing reweight cadence through options 1 and 3 would help after a number of reweights but also unfairly advantage bots in the short term.
Increasing the growth rate of incentives through option 2 just contracts the current status quo making it iterate faster. This would be slower to recover the peg and relieve the sell pressure than 1-3 but may make sense longer term.
Capping the burn and mint % to something reasonable like 2-5% will help make the FEI-ETH uniswap price closer to the secondary market price, which makes oracles more accurate for integrations and doesn’t punish selling as severely. It would also make reweights occur faster when further below the peg as the reward can catch up to the burn.
Selling the reserves with a fixed discount (say 5-10%) or an auction would create a price floor that can allow out a lot of the sell pressure and be increased over time to restore the peg. I think doing this in combination with potentially some of the above will be the healthiest and fairest approach.
Longer discussions on mechanism changes will be required but implementing one or multiple of the above in the short-term can help alleviate the sell pressure and restore the peg while preserving PCV. There were a lot of other great ideas discussed that are less well understood and would require more planning and testing before implementing.
The proposal is interesting. I think we’ll want to have a separate discussion around adjusting the incentive functions more properly after we can level out the current sell pressure and peg.
Great summary. Increasing reweight cadence may not suffer too much from bots if everyone knows exactly when a reweight would occur (e.g. block 100000). People would drive up the price before the reweight actually occurs.
How can we avoid bots operating in frequent reweights here?
I am afraid bet in reweights options now will reduce the PCV without restoring stability.
I like this one with an auction mechanism to use the less PCV possible.
I think this is important. We should see how it works.
Might be a good idea to mention this to broader channels.