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.
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.
I feel like it’s still too early to use the genesis event as any indication as to what the burn/reweight dynamic should or shouldn’t be. Based on observing the Discord, it seems like immediate dumpers skewed the operation.
Maybe a “rapid dump” black swan plan makes sense to consider, but otherwise I’d like to see FEI run as intended for a bit to see what happens (especially after the first reweight).
Definitely a good idea.
It will give another function to TRIBE which will be another reason to hold and give it extra value.
If the system evaluates in a way that TRIBE holders have an option to preswap which will be included and executed in the reweighting atomic transaction - up to a certain amount which should be calculated/capped taking into account the PCV and the holdings of each user -, the protocol can benefit from this and will also favor long time supporters.