You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is proposed that liquidity pools be connected to the Econia order book design, such that pools determine price range based on best bid/ask.
E.g. in uniswap v3, users select a price range in which to provide liquidity. But in this design, there could be a default range like +/- bps relative to best bid/ask.
Hence pool LPs, rather than selecting liquidity provisioning based on prices, and having to reshuffle their profile for market conditions, just select a sort of depth/slippage window that is relative to the order book reference price.
If we imagine an order centered on the price such that 50 A is to the left and 50 B is to the right, and an order is placed that shifts liquidity right so that it's 55 A and 45 B, then you don't really have a way to easily rebalance this order especially if it's alone.
More specifically, you need a way to rebalance all of the liquidity affected by a trade which may have crossed multiple liquidity opens/closes so it would be really complicated.
Additionally, there may need to be some kind of hysteresis/DoS prevention that prevents people from stacking the book in a certain way that exploits the pool
Per @elliottdehn a TWAP oracle could be used to determine a price that is less sensitive to manipulation, and note that there is also the question of who pays for the rebalancing operation (this could potentially be implemented as a crank operation)
The text was updated successfully, but these errors were encountered:
It is proposed that liquidity pools be connected to the Econia order book design, such that pools determine price range based on best bid/ask.
E.g. in uniswap v3, users select a price range in which to provide liquidity. But in this design, there could be a default range like +/- bps relative to best bid/ask.
Hence pool LPs, rather than selecting liquidity provisioning based on prices, and having to reshuffle their profile for market conditions, just select a sort of depth/slippage window that is relative to the order book reference price.
Per @elliottdehn:
Additionally, there may need to be some kind of hysteresis/DoS prevention that prevents people from stacking the book in a certain way that exploits the pool
Per @elliottdehn a TWAP oracle could be used to determine a price that is less sensitive to manipulation, and note that there is also the question of who pays for the rebalancing operation (this could potentially be implemented as a crank operation)
The text was updated successfully, but these errors were encountered: