Analyzing DeFi Trading Product Uniswap V3 Concentrated Liquidity, Protocol Fees, Price Oracle

Examining DeFi Trading Platform Uniswap V3's Concentrated Liquidity, Protocol Fees, and Price Oracle

Source: Keegan Xiaogang

UniswapV3 was launched in May 2021. Compared to UniswapV2, it has undergone significant changes and has become much more complex. The main changes are as follows:

• Introduction of the Concentrated Liquidity mechanism

• LP Tokens have become non-fungible tokens (NFTs)

  • Simplifying DeFi: The Rise of MC2 Finance
  • Postponed Fraud Trial of Mango Markets Exploiter: A Delayed Showdown
  • The Untamed Journey of DeFi Phenomenon SafeMoon Thriving Against All Odds, Even Amidst Securities Violations!

• Each trading pair can have multiple pools with different fee rates

• Protocol fee governance is more flexible

• Improved price Oracle

The most significant change is the introduction of the Concentrated Liquidity mechanism. Concentrated Liquidity means that Liquidity Providers (LPs) can “concentrate” their liquidity within any price range they choose by “limiting” it. In UniswapV3, when users add liquidity, they need to set a price range, as shown in the image below:

By default, this price range is the full range, i.e., **(0, ∞)**. LPs can modify the low and high prices to any values they desire, effectively setting their desired price range of liquidity provision. Once a limited price range is set, the provided liquidity will only be effective within that price range. To better understand this, let’s look at an example.

There are two LPs, A and B, who provide liquidity within different price ranges. A provides liquidity within the range (1000, 2000), while B provides liquidity within the range (2000, 3000). When the trading price is 1500, the transaction will only occur with the liquidity provided by A, and the transaction fee will belong to A. B’s liquidity will not participate in any transaction and will not receive any fees. However, when the price rises to 2500 and enters the price range (2000, 3000), the transaction will only occur with the liquidity provided by B, and the transaction fee will belong to B. A’s liquidity becomes ineffective and will not receive any fees. When the price falls back to the (1000, 2000) range, A’s liquidity becomes effective again, while B’s liquidity becomes ineffective.

The Concentrated Liquidity mechanism aggregates the liquidity of many LPs within the price range that includes the current price, effectively improving the capital utilization of the pool. For example, the liquidity distribution of USDC/ETH in the image below:

Most of the liquidity is concentrated around the current price, which is a common state for most pools.

However, the implementation of the Concentrated Liquidity mechanism has greatly increased its complexity. The underlying mathematical principles are not easy to understand, and it has also introduced other concepts, such as tick.

In UniswapV3, the liquidity provided by LPs is divided into multiple different price ranges. To facilitate the calculation of liquidity and fee distribution for different ranges, UniswapV3 divides the entire price range into multiple discrete price points. These price points are called ticks. Each tick corresponds to an actual price, and their relationship can be represented as follows:

This formula shows that when the tick is 0, the price is 1; when the tick is 1, the price is 1.0001; when the tick is 2, the price is 1.0001^2. In other words, the price difference between adjacent price points is 0.01%. Of course, the tick can also be a negative value, indicating that the price p is less than 1.

When adding liquidity to UniswapV2, the value of two tokens is equal. Until you remove the liquidity, the value of the two tokens remains equal. But in UniswapV3, it is not the case. Let’s explain with the following image:

In the above image, the current price of ETH/USDC is 1806.97, and the price range for liquidity addition is (1699, 1900). However, it can be seen that when adding 1 ETH, the corresponding amount of USDC is not the current price of 1806.97, but it has reached 2184.99. The values of the two tokens are not equal. In addition, after adding liquidity, if the price of ETH/USDC falls, the amount of ETH in your liquidity will increase, while the USDC will decrease. On the other hand, if the price rises, the amount of ETH in your liquidity will decrease, while the USDC will increase.

Based on this feature, the limit order function can also be implemented. For example, assuming the current price of ETH is 2500 and the user believes that the price may fall below 2000, they can set a very short range around 2000, such as (1999, 2000). In this case, because the entire price range is lower than the current price, the user only needs to provide liquidity in the form of USDC. This is equivalent to the user placing a limit buy order at a price of 2000. When the price falls and enters the price range of (1999, 2000), someone will trade and swap the USDC in that range for ETH (actually WETH) until the price completely crosses the upper limit of the price range, and all the USDC in the pool are swapped for ETH. At this point, when the user withdraws liquidity, it is equivalent to the limit buy order placed earlier being executed. However, compared to traditional limit orders, there are two points to note:

• If the price cannot cross the entire price range, only a portion of the USDC will be swapped for ETH

• After the conversion is completed, the liquidity needs to be removed, otherwise if the price returns to the price range, the ETH in the pool will be swapped back for USDC

In UniswapV2, liquidity is shared by the entire pool, and each person’s share can be represented by shares, which can be exchanged with each other. Therefore, ERC20 Tokens can be used as liquidity tokens. But in UniswapV3, after adding the limitation of price ranges, liquidity is no longer shared. Each added liquidity is basically unique. Therefore, it is no longer suitable to continue using ERC20 as liquidity tokens, but ERC721 is very suitable, and each added liquidity is also called a position, which can be represented by a separate NFT.

In UniswapV2, each trading pair has only one liquidity pool, and the transaction fee rate is uniform at three-thousandths. However, UniswapV3 can create pools with different fee rates for the same trading pair, that is, the uniqueness of a Pool is composed of three fields: token0, token1, and fee. Initially, it supported fee rates of 0.05%, 0.3%, and 1%, and later in November 2021, through DAO governance, it added support for a fee rate of 0.01%.

In UniswapV2, there is also a protocol fee, which, like the transaction fee, is a globally-based fee. If protocol fees are enabled, you can receive 1/6 of the transaction fee. However, the protocol fee setting in UniswapV3 is more flexible and is no longer fixed at 1/6, but can be set at 1/N or 0, where N is configurable within the range of 4 <= N <= 10. Moreover, different protocol fee rates can be set for each pool. For example, Pool A can be set at 1/6, Pool B at 1/8, and Pool C at 0.

Price oracles have also been upgraded. We have already introduced the oracles of UniswapV2 and UniswapV3 in the blockchain oracle chapter. Here, I will add one more point: In V2, the method is to directly record the accumulated values of prices and divide them by the time interval when used, which is an arithmetic average. In V3, the accumulated value is log(price, 1.0001), which is the power of the price, and it is divided by the time interval when used, which is a geometric average. Geometric averages can better reflect the true prices and are less affected by short-term fluctuations. Additionally, using geometric averages is also because the contract records tick numbers, which are integers related to prices, so calculating the tick number directly saves gas.

In terms of the code architecture, the changes between UniswapV3 and UniswapV2 are not significant. At the contract level, there are mainly two libraries:

• v3-core

• v3-periphery

v3-core has two core contracts:

• UniswapV3Factory: the factory contract

• UniswapV3Pool: the liquidity pool contract

v3-periphery also has two core contracts:

• NonfungiblePositionManager: the position management contract

• SwapRouter: the exchange router contract

Unlike UniswapV2, the Router contract is no longer the sole entry point for adding liquidity, removing liquidity, and exchanging transactions. These liquidity-related functions are now placed in a separate NonfungiblePositionManager contract, while the SwapRouter is mainly used for transaction entry.

In the subsequent articles, we will explain these four core contracts one by one.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!