[EthReweightQueuer] Proposal to improve reweight mechanism & maintain peg

Never mind these last couple posts. I realized what I’m trying to get at is at least a lot more complicated than I confidently understand at the moment. And likely not a problem at all.

One additional thought : to avoid introducing a new qFEI-ETH token bearing the volatility of under-peg FEI (and outsourcing it to the open market), we could also make TRIBE assume that role. It takes more coding, but I think it’s more elegant.

Rationale : TRIBE holders have confidence that FEI will get back to peg, because they control the PCV to make it happen (and can vote to make it happen). They should, therefore, be comfortable with buying FEI at .99$ regardless of market conditions, because they know they’ll be able to make a 1% profit on it soon.

That “1% profit” is a parameter set by governance. Short term, given the situation, it could make sense to have it at ~5%, but in the long run it’s probably better to have it around 0.3%, like a Uniswap fee, and make sure the peg stays closer to 1$.

Step 1:

  • 1000$ worth of TRIBE get staked in EthReweightQueuer.
  • EthReweightQueuer borrows 300$ worth of ETH from the PCV, and owe 300 FEI to the protocol.
  • The 1000$ worth of TRIBE are now owned by the protocol (PCV increases by 700$).
  • If the TRIBE value drops sharply, the TRIBE can get liquidated for ETH.

Step 2 :

  • FEI get redeemed for ETH in the EthReweightQueuer at 99% peg price.
  • After 300 FEI, EthReweightQueuer is out of ETH (it keeps 1%).
  • The “queue is full”, and anyone can ask EthReweightQueuer to trigger a reweight.
  • On trigger, EthReweightQueuer pays back the 300 FEI loan, then reweight happens.
  • EthReweightQueuer takes a new loan.
    • if the TRIBE/ETH price changed, the loan can be larger or smaller than before.
  • EthReweightQueuer uses the 1% remaining ETH to buy TRIBE (staking rewards).

The loan to value of 30% & liquidation threshold could also be tweaked by governance. There is no need to borrow a large portion, a safe borrow for ~10% of the TRIBE value would decrease the chance of liquidation & would just fill the queue sooner (trigger more reweights).

Some bots will probably try to snipe the “1% remaining ETH to buy TRIBE” transaction & sell right after, but to do so, they will need to have bought TRIBE in the first place, so I don’t think it’s problematic.

Effects:

  • Anyone can exit whatever the market conditions at a small premium to TRIBE holders :money_with_wings:
  • TRIBE guarantee a price floor to FEI :exploding_head:
  • Single-token stake farming for TRIBE holders (stake TRIBE, get more TRIBE) :chart_with_upwards_trend:
  • PCV increases :lock:
  • There is buy pressure on TRIBE when PCV goes down (a period where there should be some opposing sell pressure on TRIBE) :muscle:
7 Likes

Hey Eswak, this is awesome. Really like what you’ve proposed here.

1 Like

Well spotted. Yes, this means FEI by design is unusable. Damn!

Because if you got a reward of say 10% and sold at a burn of 8% you have still made a profit of 2%. However, this needs a time lag and thus the bot needs to time it and leave the peg/burn/reward to be such that this arbitrage can happen. We cannot rule out such an occurrence and that too repeatedly.

This means that large sell trades won’t happen on the Uniswap incentivized pool, because slippage is doubly punished with burn there. But for large low-slippage trades you probably want to use a secondary market like Curve or Uniswap-v3 anyway.

2 Likes

This logic makes a lot of sense to me, intuitively users should be able to redeem at the collateralization ratio. I’m thinking we may not even really need a reweight queuer in that case because we can just have a portion of PCV set aside for this.

The obvious necessary piece is a collateralization oracle, as spot deployments of PCV can be manipulated

1 Like

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

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

1 Like

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

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.

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

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?

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

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.

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

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?

I made a pull-request on this topic here.

2 Likes

Added some comments, this is awesome :slight_smile:

Gg man for your initiative