When providing liquidity to an already-created Uniswap V3 pool, you are offered the option to provide liquidity across the price range [0,∞] (effectively performing as a Uniswap V2 LP position). My question is why is the created LP position assigned a tickLower of -887272 and tickUpper of 887272? I'm interested in why those specific tick values were chosen to represent the price range [0,∞].
Uniswap V3 – Why Ticks [-887272, 887272] Represent the Price Range [0, ?]
liquidity-providermathuniswapv3
Related Solutions
Concentrated liquidity is more capital efficient because with increased concentration, the same amount of tokens invested creates greater depth of liquidity.
From Uniswap's blog:
By concentrating their liquidity, LPs can provide the same liquidity depth as v2 within specified price ranges while putting far less capital at risk.
An informal way how to define capital efficiency is to see it as the ratio between the capital invested and the value generated.
- Situation A: $1 generates 1 units of value.
- Situation B: $1 generates 2 units of value.
The capital in situation B is used in 2 times more efficient way.
The main function liquidity pools is to let trading to happen. All else being equal, a pool is more attractive for traders if it has deeper liquidity, because deeper liquidity -> reduced price impact for trades. It means that value (efficiency) of capital is greater if it is used to achieve greater depth of liquidity in the pool.
Some math-based analysis follows.
Exactly how inefficient are v2 pools? Uniswap v2 is a traditional constant-product automated market maker (AMM). The liquidity L is defined with the help of the formula
x * y = L^2,
where x and y are the amounts of assets in the pool. Let's say the initial price of ETH is P0 = $2000, and that someone puts 1 ETH and 2000 DAI in the pool. In this case the value of L is sqrt(2000) or approximately 44.7.
Now for a different price P the amount of ETH in the pool is sqrt(P0 / P), for instance for P = $8000 the pool has 0.5 ETH and for P = $500 it has 2 ETH. This means that 50% of the pool's capital is reserved for ETH prices below $500 and above $8000. Moreover, 10% of the pool's capital is reserved for prices 100x different from the current price, that is, above $200,000 and below $10 per ETH. Sure, these prices are not impossible, but is it really sensible to allocate as much as 10% of capital for these extreme scenarios?
The consequence of the capital being so spread out is that the price impact of trades in v2 pools is high unless the amount of capital is huge.
In v3, LPs can set the price range [Pa, Pb] of each position, where Pa is the minimum price and Pb the maximum price. The virtual liquidity of such a v3 position / pool is defined as:
For instance, if someone believes that ETH is going to trade in the $500-$8000 range they can set these range endpoints and be 2x more capital efficient. Verify this in code:
L = sqrt(2000) # v2 liquidity value for 1 ETH + 2000 DAI position
P = 2000 # initial/current price
Pa = 500 # range min price
Pb = 8000 # range max price
# amount of ETH to match the v2 liquidity
x = L * (sqrt(Pb) - sqrt(P)) / (sqrt(Pb) * sqrt(P))
# amount of DAI to match the v2 liquidity
y = L * (sqrt(P) - sqrt(Pa))
The result is x=0.5 (ETH) and y=1000 (DAI) as expected. 2x less ETH and DAI needed to achieve the same liquidity depth!
Expanding this further:
[P / 4, P * 4] price range -> 2x capital efficiency
[P / 2, P * 2] price range -> 3.41x capital efficiency
[P / 1.2, P * 1.2] price range -> 11.48x capital efficiency
[P / 1.1, P * 1.1] price range -> 21.49x capital efficiency
[P / 1.05, P * 1.05] price range -> 41.49x capital efficiency
[P / 1.01, P * 1.01] price range -> 201.5x capital efficiency
Meaning that for stable pairs, v3 pools can easily be hundreds of times more capital efficient than v2.
For more experimentation, the Uniswap's blog also have a nice interactive calculator at the end of the "Capital Efficiency" section.
In Uniswap V2, all liquidity provider (LP) positions fall in the price range [pa, pb] = [0, Infinity]. The value for liquidity is fungible across all positions and is calculated as follows:
This means that the value of liquidity is directly proportional to the values of x and y tokens provided, and the only way to get the same exact value of liquidity is to provide an amount of underlying tokens that falls on the curve described by the formula above.
In Uniswap V3, LP positions are more fine-tuned and have an additional level of depth. Uniswap V3 introduces the concept of concentrated liquidity, where positions are not only described by the amount of liquidity provided but also the price range [pa, pb] over which that liquidity is provided. Liquidity is described by the following formulas:
By examining the Uniswap V3 formulas, we see that the value of liquidity is directly proportional to the values of x and y and inversely proportional to the width of the price range. If we calculate the amount of liquidity that results from providing an amount of tokens x1 and y1 across a price range [pa, pb], it should be possible to get the same exact value of liquidity by providing a smaller amount of both tokens x2 and y2 across a narrower price range [pc, pd].
Therefore, in Uniswap V3, the liquidity units are not fungible across positions with different price ranges and are only locally fungible within positions that lie within the same price range.
Best Answer
In Uniswap V3, the formula for calculating the price from a given tick is the following:
By looking up Uniswap V3's codebase, we find that the price is represented by the variable
sqrtPriceX96of typeuint160. Where:And:
By using both formulas above and plugging in the maximum tick value of
887272, we find the following:We know that in Solidity, the conventional way of representing the value of ∞ would be to use the maximum integer value allowed by a type. The max number we could obtain with a
uint160(i.e. the type ofsqrtPriceX96) is:Therefore, we conclude that the chosen maximum tick of
887272is just enough to produce asqrtPriceX96that is still lower than the maximum value allowed by the typeuint160. And most likely, the minimum tick value of-887272was chosen to represent a price of zero for symmetry.