How to Design a DEX from Scratch
Article: @Buidler DAO
Author: @Joseph Xu
Author's Note
In the past year or two, the AMM model algorithms that have been validated by the market as effective have rarely been updated and iterated. The core issue of AMM has gradually shifted from designing an efficient and reasonable algorithm to returning to the essence of the financial market—liquidity. Today, our topic starts from the AMM DEX and shares with everyone how we found inspiration and insight from existing AMM solutions and how we improved and innovated within these existing solutions to address the unique pain points and needs in the NFT market during the process of designing the Midaswap Protocol, an NFT liquidity protocol.
—— Joseph
Since Q3, the NFT market has experienced drastic fluctuations, with blue-chip NFTs plummeting. Regardless of the impact of various operations by project parties and issuers, liquidity remains the most important issue in the NFT market. Currently, on the EVM chain, we can roughly classify NFTs as derivatives of ETH.
In addition, whether or not you have participated in NFT trading, everyone should have noticed the rapid success of blur.io. In terms of liquidity solutions, Blur seems to have delivered a high-scoring answer from centralized exchanges/aggregators. It has almost captured the largest share of bid liquidity in this market, and as a newcomer, especially with Opensea having been in the dominant position for so many years, it has risen so rapidly. In fact, we can say that Blur has done a great job with centralized liquidity solutions. However, for dApp developers and the ecosystems on various public chains, we have always believed that centralization may only be a part of this trading market. We hope to explore how we can build our own NFT exchange on-chain, or NFT DEX. So today, we hope to discuss the following questions in the upcoming discussion:
What kind of liquidity solution should be adopted to build a decentralized NFT exchange?
When thinking about and designing decentralized NFT AMM, what can be learned from existing DEX AMM solutions?
How will ERC721 and ERC20, as completely different asset targets, differ in their AMM model designs?
Today, we will discuss and learn together with these questions, and also attempt to share the train of thought that our product Midaswap has gone through in model design.
How to Design a DEX from Scratch
Let's start with a more abstract question, which is what kind of ideological struggles do we need to go through when designing a DEX, or what choices do we need to make?
First of all, it is estimated that everyone knows that choosing an AMM curve is probably the direction that all AMM designers need to establish from the beginning. Indeed, x+y=k or x·y=k, or Balancer's more modified multi-coin pool's constant function, can all be called CFMM, constant function market maker. Here, x and y, including b in the balancer formula, actually represent the asset balances involved in this market or liquidity pool, or the supply. Based on the proportional relationship between the supply and various quantities created, they re-match and price in this market. So, considering what kind of curve to choose is often related to the target assets that the liquidity protocol believes it can attract. For stablecoin trading, such as Curve V2, it will choose a hybrid constant function market maker. Near the balance point, its model is closer to a constant function curve, while far from the balance point, it is more like Uniswap v3's constant product method. So, there is actually no perfect AMM curve, but more about finding a suitable AMM curve for your own market.
Then, everyone will face the second question, which is how we want the liquidity to be distributed. This involves two aspects, whether liquidity needs to be distributed across the entire range or within a fixed price range, or within a price range provided by LPs. This is the difference between Uni V2 and Uni V3. Uni V2 actually designed a very simple model, where it distributes two tokens across the entire range, strictly following the xy=k constant function market maker curve. However, Uni V2 also brings another problem, which is a significant decrease in capital efficiency at the ends of the curve. Uni V3 innovated in this aspect by providing LPs with a new feature, allowing LPs to provide liquidity in the range they desire, which is the range order defined by Uni V3. Its AMM curve is not a simple xy=k, but the result of countless xy=k overlays. The choice of liquidity distribution behind this actually involves another question, which is whether you want your liquidity to be horizontally or vertically distributed. There may not be a more intuitive way to explain the difference between these two, but we will further elaborate on this later.
The third and most important question is how to incentivize your LPs. LPs are actually the most important participants in DEX or games. Without LPs, there is no liquidity depth, and there is no good trading experience. So, all DEXs actually face the question of how to attract LPs. Of course, we know that all DEXs use trading fee income to attract their LPs. Some emerging liquidity protocols will create more combinational income for LPs, such as liquidity staking or some combinational gameplay of liquidity tokens, similar to how Paraspace allows Uniswap LPs to achieve more leverage through borrowing. These aspects are all to increase the attractiveness of liquidity pools to LPs. As we just mentioned, LPs are the most important factor that makes this liquidity protocol or game work. If we do not have a good mechanism to attract LPs, then this flywheel cannot operate positively.
Then we come to the fourth question, which is how should you charge your traders? On this point, the current DEXs are quite consistent, in that how to charge traders is almost determined by the person creating the liquidity pool, like Uniswap, which may have a multi-tier fee rate. Here we can mention that in Joe V2, its fee rate is a dynamic fee. We also see Uni V4 making progress in this aspect, introducing dynamic fees through hooks. Dynamic fee rates represent a more advanced product design, because dynamic fee rates can not only form a negative feedback system to balance the market, but also to some extent hedge the LPs' gratuitous losses. We will not delve too much into this part here, but this aspect is definitely something that AMM designers must consider.
Then it is choosing the LP token. There are many schools of thought on this point. Uni V2 chose ERC20, Uni V3 chose ERC721, and Joe V2 chose ERC1155. In fact, the LP token is jointly determined by the previous four choices. The way liquidity is distributed and the way liquidity is quantified in the liquidity protocol will ultimately determine the form of the LP token. Taking the difference between Uni V2 and Uni V3 as an example, Uni V2 distributes liquidity across the entire range, so at each price node, as long as the proportion of the two LP-provided liquidity assets to the total assets is the same, we consider these two parts of liquidity to be equivalent, so the LP tokens within the same liquidity pool of Uniswap v2 are homogenized. Because at every price point, we will fairly consider that they have contributed capital to the market. Uni V3, because it introduced range order (limit order liquidity), the effectiveness of liquidity itself has a new definition. Not all liquidity will participate in market trading at any time, only the liquidity within the price range will truly contribute capital to this market. So it needs to encapsulate the positions of each LP in a non-fungible way, wrapping them with an ERC721 token, which is probably the best choice for its LP token. Of course, we do not know what Uni V4 will be like next, but I think that in the case where the liquidity solution of Uni V4 does not differ greatly from Uni V3, ERC721 may still be the best choice for its LP token.
After going through the above five important decisions and struggles, we have established a rough direction for an AMM protocol. So, the process we just went through is actually to help everyone have such a brainstorming process. Only when these five aspects are not problematic, can we truly enter the gate of AMM model design, and we can start to discuss some more detailed issues.
The Difficult Triangle of NFT AMM
The previous topics discussed the design of ERC20 AMM DEX, including the mainstream AMM DEXs on the market such as Uni, Curve, Balancer, etc. Our topic today is NFT AMM. The coin pair of NFT AMM has one side as ERC721 NFT and the other side as ERC20 or ETH, such as homogeneous tokens. When these two asset targets are placed in an AMM liquidity pool, we will encounter some very inherent contradictions.
First and foremost, in the traditional NFT trading market, it relies on a bid-ask trading model, more like an order book market. In a market with a lack of liquidity on one side, the liquidity rate is very poor. Therefore, the NFT market lacks good market-making tools and sufficient buyer liquidity. All along, people have criticized the lack of intrinsic value in NFTs, and the buyer liquidity for NFTs is extremely scarce on any public chain, so the severe lack of turnover inevitably leads to liquidity depletion. So we are thinking, if NFT AMM is directly introduced into the existing AMM DEX market without any modifications, it is likely to face severe liquidity shortages on the ETH or ERC20 side. This is a problem that everyone needs to face from the beginning.
The second important and practical issue is that NFTs are indivisible for trading. Because of the non-fungible nature of NFTs, without any additional design, no NFT holder would be willing to sell 10% of an NFT to another person. This is not feasible based on the nature of the asset itself. This actually introduces a problem: our original AMM DEX is infinitely divisible within the token's precision range. If some mainstream ERC20 tokens have 18 decimal places, they can be subdivided within 18 decimal places, meaning the price curve can approach an infinite continuous curve. But NFTs have a discontinuous liquidity, which often means there is a significant liquidity gap. We need to figure out what kind of curve can connect the points together, which is also a very important issue.
At the same time, from another perspective, because Token IDs are integers for trading, the barrier to entry for NFT trading has always been relatively high. When a retail investor buys ETH, if their USDT is not enough to buy a whole Ethereum, they can choose to buy Ethereum worth 100 USDT. But when an NFT is worth 1 ETH, a user cannot spend 100 USDT to buy a certain percentage of an NFT. Previously, there have been liquidity protocols proposing the introduction of fractionalization for NFTs. Fractionalization is a simple and direct solution, but it introduces the third problem of the difficult triangle: Do fractionalized NFTs still possess the trading properties of NFTs themselves?
When an NFT collection is issued, it determines the rarity of a certain NFT ID or a group of NFT IDs based on the attributes in the metadata. Different rarities often determine the different price expectations of these NFT holders for their NFTs. Fractionalization means that all NFTs invested in the fractionalized liquidity pool are treated equally, because we cannot distinguish in a fragmented liquidity pool which part of the fragments comes from a high-rarity NFT.
This is actually the three core pain points that decentralized NFT protocols must face. If there is no compromise in these three issues, the design of NFT AMM may encounter significant difficulties.
Existing Solutions in the NFT AMM Market
Let's take a look at the existing mature solutions in the NFT AMM market. For example, NFTX fragments NFTs indiscriminately into ERC20 tokens, and then constructs trading pairs through Sushi Swap's pools. It straightforwardly bypasses the Token Decimal Conflict issue, but it also ignores the differentiation in judgment and price expectations for NFT scarcity among traders and holders. Highly scarce NFTs cannot achieve good value discovery in this type of AMM model.
Another project, Sudoswap, is the first native NFT asset that resembles an AMM DEX. Why it is said to resemble an AMM is because it has some differences in role setting compared to the typical understanding of AMM. Let's briefly introduce the Sudoswap project. It turns every liquidity provider into a counterparty for traders. Liquidity providers design their own liquidity provision plan according to the bonding curve they set. Each liquidity provider has a liquidity pool and determines whether the pool is a bidirectional pool or a unidirectional pool. A bidirectional pool means you can both buy and sell NFTs, and liquidity is provided on both sides. Bidirectional means you can exchange assets on both sides. It can also provide a unidirectional pool, for example, if you only provide ETH, similar to an LP placing a buy order for an NFT, traders can sell the NFT into this pure ETH pool. Conversely, you can provide a pure NFT liquidity pool, which is more like placing a sell order for an NFT.
So in this process, the role of LP is diminished, LPs are more like another form of trader, but to some extent can enjoy some more customized trading functions. But this brings two problems. The first problem is that if an LP has a liquidity pool, it means that the liquidity between each liquidity pool cannot be aggregated. We just mentioned that the most important issue in the NFT market is the lack of buyer liquidity. Under such a premise, if all liquidity is still fragmented into individual LP's liquidity pools, it actually still isolates liquidity to some extent. Liquidity cannot be aggregated, which to some extent goes against the original intention of AMM: AMM hopes to aggregate liquidity in a market to provide better liquidity depth, and then match a price that truly reflects the current sentiment of the market. It actually cannot achieve this, as each liquidity pool is isolated from each other and does not affect each other. From another perspective, in a single liquidity pool, the scarcity of NFTs is assumed to be the same. This means that an LP providing 3 NFTs in their own liquidity pool will not price them differently. If an LP has three NFTs of different rarities and different expectations, they may need to create three liquidity pools to meet these needs.
So these two projects are actually relatively mature projects in the NFT AMM market. These two projects have solved some of the problems we just mentioned, but they may have some trade-offs, selectively ignoring or compromising some of the issues. So what we are thinking about is whether there is an NFT model that can solve these problems well, or whether we can solve these three problems to a level that everyone can accept through an NFT model.
Bonding Curves
Next, we will give you a detailed explanation of Bonding Curves, as a prelude to the detailed solution we will discuss later. Bonding Curves are essentially a series of mathematical functions used to achieve price discovery. It actually maps the supply of assets to the asset price. It is clear from the two curve diagrams above that the left one is a linear Bonding Curve, and the right one is an exponential function Bonding Curve. In the diagrams, the green points represent the position of ERC20 in the position, and the red points represent ERC721. Taking the left diagram as an example, how is the liquidity distributed in such a liquidity pool? At the lowest price point, which is the starting point of the set price and the next point, the liquidity of FT, which is the liquidity of ERC20, is placed. The liquidity of ERC721 is placed on the three points above. When a trader buys an NFT from this liquidity pool, the middle red point will be replaced by green. This means that for every NFT bought in this market, the price will linearly increase by a constant value. For every NFT sold, the inDEX price provided in the pool will decrease by a constant value. The same applies to the exponential function, except that it changes the common difference to a common ratio.
Sudoswap is commendable for pioneering the introduction of Bonding Curves into NFT trading, which indeed provides liquidity providers with a great degree of freedom for market-making. But as mentioned earlier, in its design, the liquidity pools between LPs are fragmented, so its Bonding Curve to some extent loses the ability to describe the overall market. We cannot truly see to what extent this market is trading from a single liquidity pool. The inDEX Price traded in the market also cannot reflect the characteristics of the entire NFT Collection market, falling into a "peeking through a tube" dilemma.
Inspiration from Existing DEX
Taking into account the above pain points and the design of existing mature products, we are considering what kind of NFT AMM can solve these problems. First, we will go back to some mainstream ERC20 DEXs in the market to find some elements that can inspire or give us ideas.
First, we carefully studied Uniswap V3, which provides us with a good inspiration. First, LPs can provide liquidity within a price range, similar to the LPs in Sudoswap who set their own bonding curve for liquidity and provide liquidity within this range. So we actually have an idea, whether LPs can freely provide their liquidity in our liquidity pool according to a certain bonding curve. Based on this, we may need to supplement it with a Non-Fungible LP Token, which is an ERC721 LP certificate, to determine the position of each LP, which is actually non-fungible between them.
Then we went deeper into the protocol design of Joe V2, which made some upgrades based on Uni V3. First, the LP's Curve can be customized, allowing for the choice of liquidity sparsity and whether liquidity is globally spread across their Range Order price range. It can also choose point-like liquidity provision, and it utilizes the Liquidity Book design to achieve a trading mode similar to an Order Book at a micro level. This is a more modern liquidity distribution solution.
The most important inspiration we gained from these two ERC20 DEXs is the four points mentioned in the graph. If ERC20 DEX provides important inspiration for designing NFT AMM, the most important thing is that we should not ignore the differences between NFT Token IDs, and we should allow LPs to have differentiated expectations for their liquidity. At the same time, we should not segment LP liquidity into their private liquidity pools; we should aggregate buyer liquidity. Only aggregated liquidity can provide a better trading experience for traders, lower slippage, and a more timely trading experience. In a situation of lacking liquidity and inability to aggregate, the experience of a trader wanting to sell an NFT is poor.
Design Concept of Midaswap AMM
At this point, we can discuss how to design our own NFT AMM. Before that, we can first discuss a slightly related issue. If you have also read about Uniswap V3, you know that Uniswap V3 has its own system for measuring prices, called Ticks. Tick is actually an exponential function of 1.0001. For each increase in Tick, it multiplies the corresponding price by 1.0001, meaning Tick and price are mapped one-to-one. Why is it designed this way? In fact, all DEXs have their own price scales to extract the most effective price scale for our AMM from almost infinite prices. The liquidity in these price scales is actually ignored, and we only provide our liquidity within these Ticks we set.
Correspondingly, another mainstream design is Liquidity Bin. As the name suggests, Bin is something like a box, and we can consider the liquidity on each price scale as the height of a box that each LP stacks liquidity depth on. For example, as an LP, if I provide liquidity for USDC at the position where ETH equals 1000 USDC, and I provide 1000, then I will stack the liquidity depth at the price of 1000 to a height of 1000. If another person comes to provide 2000, they will increase the liquidity depth to a height of 3000 at that price.
Why do we mention this? In fact, Tick is relatively more in line with the incentive scheme for Uni V3 liquidity. We believe that Bin, as a vertically stacked liquidity scheme, is more suitable for discrete NFT liquidity. We can understand NFT liquidity as a small box that we can stack on the price of Bin. Each time an NFT holder or an LP comes to provide NFT liquidity at a certain price, we can understand it as placing a box at that price.
Why do we say that simply learning from a certain ERC20 DEX cannot solve the three problems mentioned above at the same time? First, there are differences in rarity between different NFT Token IDs, and the differences in value expectations generated by this are inherent to NFT assets. This is actually quite different from most ERC20 DEXs. Because the liquidity pools in ERC20 DEXs are not possible to have two traders trading at different prices at a fixed moment. So if we want to build a composite NFT market, we need to learn both the matching mode of the order book in centralized exchanges and the liquidity aggregation method in the AMM model of DEX.
So we have this design: reintroducing the unique concepts of Best Offer and Floor Price from centralized NFT markets. First, Best Offer refers to the highest NFT bid in the current market, which is the highest ideal price for NFTs in this Collection for buyers, while Floor Price is the lowest asking price for NFTs in the current market. With these two prices, a watershed is formed in the liquidity market:
Above the Floor Price, we can use the Bonding Curve liquidity provision scheme to provide NFT traders with a trading experience similar to an Order Book. For example, when an LP chooses to provide NFT liquidity in the range of 3 ETH to 5 ETH, these NFTs will be scattered according to the Bonding Curve they designed at price points from 3 ETH to 5 ETH. At any time a trader enters the market to trade, they can choose their desired NFT for trading. In a sense, this NFT has already been limited to a price by the LP. With each trade, it can experience a price increase in this LP's Bonding Curve.
The AMM model is applied below the Best Offer and Best Offer prices. Here, LPs providing FT liquidity are more like providing buy-side liquidity in the Blur market and can be considered fungible. They place their FT liquidity in the price range they want to provide liquidity, and at the same price point, their liquidity is considered equivalent and aggregated. After aggregating this liquidity, it greatly improves the trading experience for users when selling an NFT, both in terms of capital utilization efficiency and trading efficiency.
This design of an NFT market can to some extent neutralize the three pain points mentioned earlier. We have chosen a more balanced approach, providing good liquidity depth and lower NFT trading slippage without ignoring the differences between NFT Token IDs. I believe that, from the perspective of not ignoring the native trading demands of NFTs, this may be the best solution we can think of at the moment. At the same time, it is worth mentioning that Best Offer and Floor Price, as two important price indicators in the NFT market, can actually provide an on-chain Oracle for price discovery in a trading market, rather than relying on an external NFT market to assist in pricing NFTs. In addition, a purely on-chain NFT trading market provides many possibilities for composability in DeFi. For example, our LP Tokens can continue to be used for leveraged lending, and our Oracle can also assist in providing quotes for on-chain oracles. These are the reasons why we urgently need an efficient NFT AMM that can meet the needs of traders and LPs.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
