[EthReweightQueuer] Proposal to improve reweight mechanism & maintain peg

Ideas
44

That sounds like a mandatory first step, whatever backstop PCV redeem mechanism we put in place.

Cheers for identifying that topic in the middle of all the potentially-controvertial things I proposed here. Let’s start with that, we’ll see what we build on top later.

Wouldn’t that cause some problems ? If instead of redeeming at peg, circulating FEI became large liquidity providers of the ETH-FEI incentivized pool, reweights would cost a lot to the protocol. They could even become >50% liquidity providers :

  • 30$ of ETH PCV is allocated to the “PCV redeem at peg” contract
  • 70$ of ETH PCV remains in the Uniswap pool
  • 80 circulating FEI can become majority liquidity providers in the pool

I’m sure one could design attacks around reweights & liquidity providing to drain ETH out of the PCV in that case. This is why I suggested an ETH redeem mechanism at peg that is closely tied to the reweight and EthUniswapPCVController. ETH PCV would remain tied to the pool & not sent elsewhere.

Seems like the maximum portion of PCV that can be allocated to the “redeem contract” is determined by the collateralization ratio too.

1 Like
45

What about keeping a small reserve, say 5% that tops up whenever it gets low on some fixed schedule?

1 Like
46

Probably safer for the protocol :slightly_smiling_face: I can’t prove it though

You may want an instant top-up if the content of that small reserve drops below X%, otherwise it will recreate the situation when bots sniped the reweight. Bots can snipe the top-up and exit at peg, while everyone else is locked with FEI and the market price remains low. Eventually bots will buy FEI to make profit on the top-ups so the market price will get back to peg, but expect some chaos like after launch :frowning_face:

BTW, the behavior you are describing is similar to a “reweight queuer” and regular forced reweights :sweat_smile: and my answer similar to triggerable reweights when the queue is full.

In fact, if bots get to exit first & push price back to peg in multiple arbitrage loops, I think it’s simpler to don’t code anything new and just trigger reweights on a fixed schedule.

Would it be possible to allow some whitelisted addresses to swap at peg on the EthUniswapPCVController, out of direct incentives ? In that case, we could code a smart contract, whitelist it, and make it redeem FEI at peg without having to set up a side reserve / queuer. That contract would need to be disabled when the protocol becomes undercollateralized, obviously.

2 Likes
48

Great discussion happening here! If I understand well, If there is a limited space to sell at peg bot will always frontrun other sellers and be the first to sell in the reweight. But maybe a misunderstood some part of the queue solution.

I was thinking that the dutch auction in a balancer smart pool could be more safe to provide a fair exit to everyone and increase FEI slowly to $ 1.

49

This is a very innovative and well thought our project. I hope it achieves what it sets out to do.

50

FEI Bonds?

Has it been considered to introduce FEI Bonds?

FEI-BONDs would pay a higher interest rate based on term and discount from peg goal of $1. Basically holders of FEI, would pay people to forgo selling now under peg and pay them to lock up FEI in a FEI-BOND for some term. FEI Holders pay them through the minting inflation of the FEI interest paid on the FEI-BOND.

Also, If the PCV is invested it would be generating income with which to pay for the FEI interest paid to FEI-BOND holders.

DeFi needs a proper term structure for synthetic dollars.

Thoughts?

51

If you think about it, buying under peg & taking the minting rewards is kind of a like a bond for someone that believes FEI will be back to peg.

I’d like it if we figure out a way for TRIBE to fill that role, instead of introducing more ERC20s, ideally.

2 Likes
52

I agree, it kind of is like a bond. The bond idea trades current collateral ratio (should improve it) for future collateral ratio (should depress it). It introduces a time dimension.

53

I should point out, it is better to lock up that inflation, rather than have it immediately available for trading.

54

Sorry if what I say here repeats an idea that’s already been dealt with. I’ve read many posts here carefully, but certainly not the entire thread.

@Eswak I know that early on some people confused your proposal with a proposal to batch sell pressure and sell it on the incentivized uniswap pool immediately after a reweight, before any bot get’s a chance to dump their bag.

The limitations of this idea are clear: if too many people pool, they will get a raw deal; they will end up selling their FEI considerably under $1 in a way that’s out of their control.

But, in principle, it has two virtues: (1) it interacts simply with the existing design; (2) it’s not a price floor, whereas FIP-1? (with a question mark) is. It’s obvious why the first is a virtue. The virtue of the second is a little more subtle. My argument is that it is a virtue because we’re only likely to implement something like this if FIP-1 (without a question mark) doesn’t pass. In that case, the community will have clearly expressed its vote against a price floor.

I think one of the most attractive goals of your proposal is that it protects the interests of small bags from the actions of bots and whales. And I think any proposal that promises to achieve this will be overwhelmingly popular.

So here’s the idea, imprecisely stated:

Instead of implementing a new contract that simply batches all of the sell pressure, we implement a contract that continually batches sell pressure, stratified by the price that each seller is willing to accept.

This contract is very flexible. At any time, anyone that’s wants to sell FEI above $0.99 can send the FEI to the contract, telling it this much. Anyone that’s willing to sell FEI above $0.98 can send the FEI to the contract, telling it this much. Anyone that’s willing to sell FEI above $0.97 can send the FEI to the contract, telling it this much. And so on… Similarly, as long as the contract hasn’t sold their FEI, anyone that’s sent FEI to the contract can redeem it, paying only the ethereum network fees involved.

By the time a reweight happens, the contract will have a pool of FEI it can sell above $0.99, a pool of FEI it can sell above $0.98, a pool of FEI it can sell above $0.97, and so on. Considering the liquidity in the incentivized pool and the effects of direct incentives, it will determine that it can batch x FEI and sell them above $0.99. If there are more than x FEI in the pool of FEI it can sell above $0.99, it will pick x FEI from that pool, according to a random distribution that is lightly weighted by how long each FEI has sat in the pool. And it will sell those FEI on the incentivized market. Otherwise, it will take all of the FEI in the pool of FEI it can sell above $0.99, and as many more FEI as it can take from the pools with fewer constraints. And it will sell those FEI on the incentivized market. Then it will determine that it can still sell y FEI above $0.98. And it will do the analogous steps to determine which FEI to sell above $0.98. And so on: it will do this with each strata (>$0.99, >$0.98, >$0.97, etc) until it reaches an empty strata.

I have enough understanding of solidity to understand that safe random algorithms are a difficulty, but I don’t have enough of an understanding of solidity to know if it’s possible to implement safe random algorithms. But I think randomness is important. For if we were simply to sell the FEI according to the time at which it reached each pool, then bots would still have an advantage in terms of how quickly they can dump their FEI onto this intermediate contract.

In principle, though I have by no means proved this to myself, this design should constrain all of the complexity to one or a few helper contracts without messing with existing contracts. And it should remove the current advantage that bots and whales have in the instants after reweight.

What do you think?

55

I made a pull-request on this topic here.

2 Likes
56

Added some comments, this is awesome :slight_smile:

57

Gg man for your initiative