If I provide liquidity to a Uniswap V3 pool with a set fee, and I provide x amount of token0 and y amount of token1 within a certain price range, let's call it [pa, pb], and I receive a value of L (positions[id].liquidity). Would it be possible to get the same value of L by providing smaller amounts of both token0 and token1 (lower capital value) to a narrower price range? This would mean that liquidity units are not fungible across different price ranges as the same value for L could be obtained by providing a smaller capital value over a narrower price range.
Uniswap V3 Liquidity – Are Liquidity Units Fungible Across Different Price Ranges
mathuniswapv3
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 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 sqrtPriceX96 of type uint160. 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 of sqrtPriceX96) is:
Therefore, we conclude that the chosen maximum tick of 887272 is just enough to produce a sqrtPriceX96 that is still lower than the maximum value allowed by the type uint160. And most likely, the minimum tick value of -887272 was chosen to represent a price of zero for symmetry.
Best Answer
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
xandytokens 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
xandyand inversely proportional to the width of the price range. If we calculate the amount of liquidity that results from providing an amount of tokensx1andy1across a price range[pa, pb], it should be possible to get the same exact value of liquidity by providing a smaller amount of both tokensx2andy2across 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.