Uniswap V3 has introduced individual positions for certain price ranges, so that market makers can allocate capital in a more concentrated way, which can improve the capital efficiency up to 4000x as cited [1]. This technique mainly consists of two parts: the position management method implemented by ERC-721, and the liquidity aggregation model of the pool.
It is easy to understand the choice of using ERC-721, as we all know that the LP token of Uniswap V2 is an ERC-20, but due to the limitations of the ERC-20 model, individual position management is not easy to achieve. Either a new contract needs to be created each time a position is established, or one need to add data structures and methods to ERC-20 protocol be able to manage their position, resulting in an ERC-721 like protocol in the end.
However, as we will discuss below, the standard ERC-721 model is not the best way to tokenize individual positions, there should be better ways to do. But first, we should discuss the purpose and value of the underlying asset tokenization model.
Tokenization of underlying assets, as adopted by today’s major DeFi protocols, means that users deposit their assets in a pool contract and obtain a number of tokens as deposit certificates. Nevertheless, in most situations (except for the newly designed Uniswap V3), the pool contract is the same as the token contract. Although the latter is not absolutely necessary, it simplifies the relationship between the underlying assets and the tokens.
The combination of these two aspects creates a “dual-layer assets” pattern, separating the process of underlying assets from the tokenized one, and brings two key abilities to the so-called “LEGO” pattern in the DeFi-world.
First, tokenization creates a derivative asset, generating a new kind of liquidity independent from the underlying assets. For example, the cToken in Compound, or the UNI-V2 token of Uniswap, have already been accepted by a large number of platforms that support the transacting and staking of them, hence significantly increasing the overall liquidity of asset owners.
Second, the processing of two kinds of assets is independent and has no impact on each other, which simplifies the asset management and makes the liquidity of the underlying assets pool more stable. For example, when users need to sell, stake, or change the owner’s address of an asset, they only need to use the standard transfer function of the token protocol, with no need to develop any corresponding management functions in the pool protocol. They also don’t have to withdraw and re-deposit the underlying assets, so that the liquidity of the pool remains unchanged.
From our point of view, since these two capabilities are the key to the LEGO pattern of the entire DEFI-world, the tokenization model of a DEFI protocol should make use of them to the greatest extent. It is worthwhile to make an effort in finding the suitable tokenization mechanism in different scenarios, even if it means creating a new token standard.
For Uniswap V3, a problem is that although the standard ERC-721 protocol is suitable for individual position management, it does not maintain the above-mentioned capabilities that a tokenization model should provide. We will use two scenarios as examples:
Position Modification
Uniswap V3 allows the modification of the price range of an existing position. Of course, this is a must-have feature. However, sometimes users may not be satisfied with simply changing the price range. For example, a user has invested 1 million U.S. dollars on the ETH-USDC pair at the price range of 1500–2000, later he may wish to transfer 300,000 U.S. dollars to the price range of 1000–1200 to deal with the predicted price drops. In the current implementation of Uniswap V3, what this user can do is withdraw 300,000 U.S. dollars from the current position and create a new position corresponding to the new price range. This obviously does not achieve the purpose we discussed above, which is to avoid withdrawing a user’s underlying asset to maintain the stability of the pool of funds.
Assets Liquidity
With the LP token of Uniswap V2 has already becoming a widely recognized asset, the LP token of V3 should be no exception. Therefore, the processing of this kind of asset such as staking, or transacting will become a common demand. However, due to the limitations of the ERC-721, it is impossible to provide a flexible solution in this scenario. For example: If there are two platforms providing the V3 LP token staking services, and one is unable to judge which platform is more profitable, the simplest way is to deposit 50% of the assets in each platform. This is now impossible in Uniswap V3, because a single ERC-721 token cannot be split into two parts.
The answer from Uniswap is some kind of (ERC-20 based) re-fungible solutions via peripheral contracts or through other partner protocols, but this is clearly far from satisfactory. On the one hand, if an ERC-20 contract needs to be created for each ERC-721 token, it will lead to a contract fragmentation problem, which makes it difficult for the platforms receiving LP tokens to handle. On the other hand, if we use the packaging mechanism to aggregate multiple tokens, it will not only increase the difficulty of users to manage their assets, but also face the problem of a complex price determination mechanism. It is easy for those familiar with the re-fungible solution in the field of NFT artifacts to understand that this model is not suitable for complex financial assets like position LP tokens.
In general, the LP token implemented using standard ERC-721 protocol is far from competitive to the management capability and asset liquidity of LP tokens in ERC-20 standard. If Uniswap V3 implements the LP token this way, it may have a significant negative impact on the emerging and booming LP token market.
The reason why we are able to make a quick and in-depth analysis of the above questions is that we have encountered the same situation when designing the fix-term lending products as well as investment certificate products, and we believe our solution is also applicable to the LP of Uniswap V3, which helps to improve liquidity and management capabilities.
The answer is a new type of asset protocol, which we call ERC-3525. In short, ERC-3525 is a kind of NFT that supports quantity in an individual token, and can be split, merged and partially transferred based on this. Never the less, in order to better support the “dual-layer assets” model, ERC-3525 have also added an underlying asset description capability at the protocol layer to support and standardize the implementation of this token. Moreover, in order to have effective interactions with the existing DeFi infrastructure, ERC-3525 is compatible with the ERC-721 at the implementation level, so that any protocol supporting the standard ERC-721 is also able to handle ERC-3525.
Technically, this protocol contains the following interfaces (only partially listed):
function safeTransferUnitsFrom(address from, address to, uint256 tokenId,uint256 targetTokenId, uint256 transferUnits) external; function split(uint256 tokenId, uint256 newTokenId, uint256 units) external; function merge(uint256 tokenId, uint256 targetTokenId) external; function approveUnits(address to, uint256 tokenId, uint256 units) external ;
where “units” represents the amount contained in one NFT.
Based on the quantitative attributes, and the capabilities of splitting, merging, and partially transferring, one can hypothesize that the problems mentioned above in regards to Uniswap’s V3 LP token are able to be solved as well.
Asset Management Flexibility
For example, when you want to transfer a part of a position to another price range, you only need to split the LP token representing the existing position into two parts, and conduct changes of the price range to one of the them, without needing to withdraw the assets first. For operations such as transferring, transacting, staking and more, similar operations can be. Moreover, as there is a corresponding relationship between the amount of LP tokens and the underlying assets, the value of the LP token assets is clear. There is no need to use other peripheral protocols or aggregation methods to make them re-fungible to ERC-20, which means that users and other DeFi protocols can obtain the handling ability which is close to the ERC-20 LP tokens.
Same contract for LP and Pool
Furthermore, because ERC-3525 has increased the ability to describe the underlying asset at the protocol layer, the mapping relationship between the token and the underlying asset are as flexible as ERC-20, which makes it easy for Uniswap V3 to reunite the LP token and the fund pool contract into one, returning to the simple and clear “dual-layer assets” model adopted by V2 and most of the DeFi protocols at present.
From the perspective of Uniswap as a DEX, this solution may only be the option. In the documentation of V3, it specifically mentioned the protocol split between LP tokens and the pool as intentional. However, from our aspect, the “dual-layer asset” model still has significant advantages in enhancing the liquidity of LP assets and reducing the trust costs, so it is still worth considering.
Of course, there are many other aspects to consider for this model, such as the problem of exceeding EIP-170 limit due to the large size of ERC-721 base protocol implementation, etc., as we encountered and solved in past practice.
In general, DeFi protocols has already reached a stage that requires more complex and higher-dimensional financial product design and implementation, patterns like individual position management will emerge more and more. In this trend, in order to maintain the liquidity and management flexibility of assets like LP tokens, it is necessary to seek a new type of asset protocol, with ERC-3525 being the solution we have come up with.
[1] Introducing Uniswap V3. https://uniswap.org/blog/uniswap-v3/
