Proposal: Implementing an adaptive YFI issuance which rebalances daily to keep the iearn pool the highest yield stablecoin pool by a small margin.
FOR: Implement adaptive issuance with the following rule: Every fixed number of blocks, consider all stablecoins pool with liquidity > 10 million dollars , compute the max APY from those pools and set the YFI distribution to be such that the yield of the iearn pool for the period (all yield included) is max APY from other pools+5% (at current snapshot YFI price).
AGAINST: Keep things as is
I think that we can all agree that the spirit of iearn is to push defi primitives to their natural boundary.
If we ask the question “what should be the optimal issuance target for liquidity mining at time t?”, there is IMO two natural answers:
-No issuance, which I was leaning towards at first but has the drawbacks that we know.
-Issuance that makes a pool slightly more profitable than all the other stablecoins pools.
This is why I propose that our issuance schedule stays targeted to keep the iearn pool slightly more profitable (say 5%) than the other stablecoin pools (with a threshold on the minimum depth for the pools we take into account) and is rebalanced accordingly at fixed intervals.
This provides a fantastic value proposition for the iearn pool which is very much in line with the original iearn products (optimal yields) and ensure that we keep both a low issuance and do not waste YFI in liquidity mining issuance.
The only drawback that I see is that other projects might see it as unfair competition and start being somehow hostile towards iearn.
Another interesting consequence of this adaptive issuance is that it creates some “AMPL like” economics where the higher the price the lower the issuance.
Hey @brisket, can you structure you proposal a bit? Here is a how-to Proposal How-To
I second this. Format this and let’s go!
@brisket I think this is the right approach - the middle ground so to speak. I sketched something similar here Proposal 0: YFI Supply
- Variable weekly issuance.
- Targeting is based on yield set relative to the yield available in the rest of the ecosystem (opportunity cost of capital).
- Issuance is function of target yield, previous week’s VWAP price, weighted TVL.
- Reduces wasteful switching activity between protocols (which also reduces network congestion).
- Reduces wasteful incentive provision.
This is a great idea. @brisket @markpui Are you able to formalize into an emission formula representing this?
If you can get the mechanics of this proposal down, it’s pretty brilliant. Currently, all of the other protocols are static in their issuance schedules. This would create an adaptive protocol that would automatically adjust to stay more profitable, without being so much more profitable that it wastes excess tokens.
Wouldn’t this require some sort of oracle to monitor other stablecoin pools return? That would introduce significant risk to the total supply.
This might look fancy on paper, but I would argue that it’s unnecessary. APY does not need to be stable. It should be an open system: people come if they find it profitable which drives down the APY, then some will leave which drives the APY back up.
Also, it requires oracles which could make the system more vulnerable. Again, it’s not a stablecoin, its market price does not need to be stable. It can be driven by demand and supply.
This could be set by governance on a weekly basis. It might not track perfectly, but we can easily be an oracle for this purpose.
I would suggest that if we do adopt this, we target matching the APR of the next competitive pool, it would be a much more neutral stance and we really don’t need whatever additional liquidity we’d get by targeting higher.
You assume that everyone will aim to fix the APY though… This will end up like Maker or Kyber.
I think targeting slightly higher provides a much better value proposition for the pool and would incentivize LPs to stick in the pool.
There would be heated arguments on what the APY should be every week. Everyone has their own agenda. While that’s ok, I would rather see the community focus on other issues. This is why I’m not keen on this active intervention.
I do not think there is need for debate. We could set the rule to take into account every stablecoin pool with liquidity >10 million , compute the max APY from those pools and set the YFI distribution for the day to be max APY+5% at current YFI price.
What if YFI price drops significantly, do we adjust the rate? Or we just kick the can down the road?
Not necessarily, we can hardcode a max cap to prevent crazy abuse.
We do need not to, the value proposition form the LPs is to know that they are never far from the optimal yield. Switching pool is very costly, especially at current gas price, so this is a strong sticking point
It might “waste” YFI after all, because it will keep attracting liquidity and then more YFI needs to be allocated to stay on top and then more people switch over to ypool and we need more YFI…and so on.
This is counterbalanced by the fact that more liquidity means more fees collected making YFI more valuable
If YFI drops significantly post-vote (real possibility, given volatility), thereby reducing yield, then:
(1) Yield-sensitive liquidity providers will adjust accordingly if the next best yield elsewhere outweighs switching costs + reduced yield.
(2) There is a weekly reset in YFI issuance to arrive at the new targeted competitive yield (kick the can down to the end of the week, so to speak).
On the other hand, while I advocate adaptive issuance, there are also problems with adaptive issuance e.g.
(1) Price gaming to manipulate yield: Given present low circulating supply, there may be incentive for people to distort the YFI price to manipulate the targeted yield. Hence, I think some weighting across the week helps solve this.
(2) Targeted yield computations are difficult because a single Oracle may not yield accurate calculations. E.g. a formula to maximise based on range of computed yields on Predictions Exchange may not take into account additional airdrop value missed. An example is the mstable pools which combine MTA rewards + BAL rewards while P.E. only displays return on BAL liquidity.