Uniswap V3 ticks - dive into concentrated liquidity

for token1 (Δy), and

for token0 (Δx)

You can find these calculations in the computation of the swap functions getAmount0Delta() and getAmount1Delta().

The next important point of the UniswapV3 implementation is tickSpacing. This variable sets the "step" between ticks that are allowed to have liquidity. For instance, if tickSpacing is set to 60, only ticks such as 0, 60, -60, 120, -120, … can be initialized and own real liquidity from providers. tickSpacing provides pool creators with the ability to choose whether they want a smaller step between ticks and more "dense" pool (more granular price steps, but more expensive cross-tick swaps because the swap will cross more ticks) or a more "sparse" pool, which would make the price steps larger (less ticks crossed = less gas, but less precision for LPs).

Let's track the swap process in UniswapV3, stopping at interesting places in code and describing them. At this stage, we will skip or briefly touch on logic branches that are not directly related to liquidity, price, token amounts, and tick crossing.

Let's start with the swap() function. The input parameters related to the swap set the direction of the swap (zeroForOne) and the target values: the swap should either reach a specified target amount (amountSpecified) or price (sqrtPriceLimitX96). These values are used to set the slippage restrictions, acting as barriers that halt the swap when the required token amounts or price limit is reached.

After initializing the swap cache and setting the starting values, we enter the main swap loop here, working while
(state.amountSpecifiedRemaining != 0 && state.sqrtPriceX96 != sqrtPriceLimitX96).

The core of the swap is this part (the computeSwapStep() function):

Here, we receive the new state.sqrtPriceX96 and calculate a new state.amountSpecifiedRemaining which will stop the crossing of next ticks if target values are reached.

Going deeper into the computeSwapStep() function, we encounter the segment of code that determines the next price here (showing only one branch):

So, the compute SwapStep() function returns us the new sqrtPriceX96 and the in/out amounts of tokens "left" after the current tick processing.

Let's return to the swap() function. We check if the price has changed to next available one here. If the price has changed and reached the next initialized tick, we perfom tick crossing here:

ticks.cross stores new values (fees, timestamp, oracle values) in the mapping with ticks (we will discuss it later) and returns liquidityNet that will be used to increase/decrease the liquidity of the swap (state.liquidity), and, later, the global liquidity of the pool (here).

At the end of the swap, we calculate target amounts (amount0 and amount1) here and perform callbacks.

Liquidity in Uniswap V3 is provided by creating "positions" owned by users. This mechanics differs from Uniswap V2, where liquidity ownership was implemented through ERC20 LP tokens. In UniswapV3, a "position" is an object owned by a user, holding a certain amount of liquidity plus a range of ticks (from tickLower to tickUpper). As can be seen, mint and burn operations are very similar. In case of minting, liquidity is added to a position, while in case of burning, liquidity is subtracted.

Now, let's dive deeper into the creation/deletion of a position to the _updatePosition()
function. It accepts tickLower and tickUpper, liquidity to add/remove (liquidityDelta) and the current pool's tick.

A very effective example of UniswapV3 mathematics is evident in this part of _updatePosition(). You may think that LPs should allocate liquidity across ALL ticks within the range from tickLower to tickUpper (matching tickSpacing, of course) but, in the code, we see only TWO updates:

of the lower and upper ticks. It's very effective, but what's going on here? How to collect the fees from ALL ticks in this range without storing the liquidity values in each tick? First, let's address the fees.

A very detailed article, describing fees distribution is here.

The main concept of Uniswap V3 fees involves tracking the "outside" fees amounts "above" and "below" the tick and storing these values within the tick. These fees amounts are computed using the following formulas from the whitepaper:

(where fo(i) is the feeGrowthOutside value stored by the i-th tick, fg - total amount of accumulated fees in the pool)

But the implementation uses only ONE value to track these fees amounts, which is the feeGrowthOutside* value inside the tick (we discuss only one of them because there are two stored values for token0 and token1).

Applying the formulas above, the "outside fees" value for the given tick (feeGrowthOutside*) equals:

• the cumulative number of fees BELOW tick i if it is to the LEFT of ic
• the cumulative number of fees ABOVE ticki if it is to the RIGHT of ic

(ic - current price tick, i - observing tick)

The first case: i < = ic, we're moving to the right, feeGrowthOutside stores the "left" part of fees:

The second case, i>ic , we crossed current price tick, now feeGrowthOutside stores the "right" part of fees:

The ticks are crossed sequentially, so, each time the tick is crossed, feeGrowthOutside changes to the "left" or "right" part of the global fees.

This design simplifies the computation of the fees, "belonging" to a given range a lot (il - lower tick, iu - upper tick):

We simply subtract "fees below lower tick" and "fees above upper tick" from global.

In addition, let's recall that feesGrowth* is measured in "tokens-per-liquidity-unit", so the calculation of the target fees amounts is straightforward as well. We modify the user's position by removing liquidity(here), then calculate the fees here in the ticks.getFeeGrowthInside() function, which implements the formulas above here:

So, in order to calculate the fees collected within the tick range, we need to read the state of only two ticks and the global state, making it very efficient. The same algorithm works for providing liquidity, calculating, and updating new feeGrowthInside* values for lower and upper ticks.

[NOTE] Maybe you mentioned that there are no restrictions on tickSpacing anywhere, and, it seems like LPs can set any tickLower and tickUpper. But this check is performed inside the flipTick() function, which turns ticks on/off.

Now let's take a look at how the ticks are organized. Our first stop is the struct Info in Tick.sol - the main information about the tick:

There is no need to track the price inside the tick because the tick number itself represents the current price, and the swap price can be effectively calculated from the liquidity and swap amounts.

There are two liquidity variables: liquidityNet (ΔL) and liquidityGross(Lg). When we cross the tick, totally removing the reserves of one token, then liquidityNet of this tick becomes zero (L=√xy while x=0 or y=0). However, we anyway need something to indicate that some LP positions are referencing this tick. So, we track the liquidityGross value which represents the sum of liquidity, provided to this tick by LP(s).

To track the state of the ticks (initialized or not), we need a "map" of the ticks which can be used for searching the next tick when price goes up or down. In UniswapV3, ticks are organized in a 256-bit bitmap in a uint16 index (mapping(int16 => uint256)), where each tick number (int24) addresses the 16bit index word and one particular bit from 256 bit space:

When we want to find the next initialized tick, we use the nextInitializedTickWithinOneWord() function from TickBitmap.sol. Depending on the search direction, we set all bits below or above the current tick to zero and check if the result is non-zero. Then, we use BitMath.mostSignificantBit() or BitMath.leastSignificantBit() function to identify the nearest initialized tick. It's interesting that these functions use sequential shifts of bits, employing a binary search rather than a one-by-one search. This approach divides the search space by half on each iteration, resulting in at most log₂256 iterations instead of 256 iterations.

Then, we use the next tick price to continue the swap process here, as discussed earlier.

In this article we desribed the main technical design of Uniswap V3 concentrated liquidity. This design serves as an excellent example of how a solid mathematical model can lead to the effective implementation of a relatively complex algorithm. This design significantly reduces gas costs for operations like swaps and liquidity provision, making them close to constant even when involving large amounts of internal entities within the protocol.

Uniswap V3 effectively leverages the sequential nature of tick crossings, updating only the values required to maintain the pool state consistent. Meanwhile, the fee system is designed in such a way that enables thousands of liquidity providers to have positions over different price ranges without the need for "order books" or processing each position separately.

This approach does make the operations with Uniswap V3 more complicated for external services. They need to perform some external computations to provide end users with necessary information such as slippage, price ranges, state of the pools, etc. Though this is typical in the blockchain world. Fortunately, there are many projects and services available to assist users in working with Uniswap V3.

The "concentrated liquidity" concept is indeed popular in modern DeFi and is used in many projects. Therefore, if you want to implement your own solution or audit a project that uses such algorithms, remember that there are effective solutions available. Don't forget to examine them, as any logic working with many entities in one call in smart-contracts can be tricky. See you in our next articles!