Transactions#
If borrowing and lending are long-standing financial activities, then transactions are equally so. Modern society has long moved away from the barter system of exchanging goods. The majority of transactions today are conducted in the form of legal tender, which involves the exchange of goods for credit (i.e., currency). This means that one side of the transaction uses "credit" represented in digital form, regardless of whether it is in electronic, paper, or coin form. When both sides of the transaction are represented in electronic form, transactions can be completed instantly with the help of the internet. A typical example is purchasing in-game items using electronic payment.
Cryptocurrency itself is an asset represented in electronic form that operates on the internet, and it clearly has strong transactional properties. Therefore, decentralized transaction functionality is obviously a crucial infrastructure.
Early DEX products were not significantly different from CEX in terms of design. For example, IDEX implemented on-chain order book functionality, allowing users to place buy and sell orders for tokens by sending Ethereum transactions.
The truly unique transaction method specific to blockchain appeared on Uniswap. Transactions are no longer conducted through buy and sell orders, but rather through a fixed algorithm to determine transaction prices. The following outlines the main functions of current DEX through several typical DEX protocols and a transaction aggregation protocol.
Uniswap#
In October 2016, Buterin posted on Reddit discussing a way to implement "on-chain automated market makers" in prediction markets. The goal of this post was to address a problem with on-chain transactions: lack of liquidity. While some mainstream tokens have good trading depth on centralized exchanges, decentralized exchanges such as Maker and IDEX often lack liquidity in trading pairs, with bid-ask spreads typically exceeding 10%.
The post proposed a method of calculating prices using a fixed function. First, a liquidity pool needs to be established, containing a certain amount of Token A and Token B, with quantities x and y respectively. The product of x and y is denoted as k. Transactions are completed by injecting one of the tokens into the pool and extracting a certain amount of the other token. After the transaction, the product of the quantities of the two tokens in the pool remains k. Here's an example:
-
A liquidity pool for ETH and DAI contains 10 ETH and 30,000 DAI, with a product of 300,000.
-
A trader wants to sell 1 ETH. They send 1 ETH to the pool.
-
The product of the quantities of the two tokens in the pool needs to remain 300,000. With 11 ETH in the pool, the amount of DAI that needs to be retained in the pool is 300,000/11 = 27,272.7.
-
The trader receives 3,000 - 27,272.7 = 2,727.3 DAI. The transaction is completed.
This is the prototype of Uniswap's transaction method.
Uniswap's founder, Hayden Adams, became a mechanical engineer at Siemens after graduating but was later fired. When he was at a low point, his friend recommended that he try developing Ethereum smart contracts. After a period of learning, he was ready to start a real project, aiming to create the DEX described in the above post. The end of the story is that Uniswap became the iconic project in DeFi, ranking highest in market capitalization among DeFi protocols.
Returning to the mechanism itself, in CEX, market makers need robots to place buy and sell orders to provide liquidity. IDEX continued with this trading method, but for some low-market-value tokens, holders usually have no incentive to place orders, resulting in significant spreads. However, with the x * y = k market-making method, there is no spread. The current price is the ratio of the quantities of the two tokens in the pool, which, in the above example, is 1 ETH = 3,000 DAI. Of course, the actual transaction price will be lower than this price because the injected tokens increase the relative quantity of the token, thereby lowering the price. The change in token price due to transactions is called "slippage," and in this case, the slippage is 1 - 2,727.3/3,000 = 9.1%, meaning the trader receives a price 9.1% lower than the current price. Slippage is clearly negatively correlated with the quantity of tokens in the pool. For example, if the token quantity increases by 100 times, the trader's trading loss will be much lower than 9.1%.
There are two ways to interact with the liquidity pool: trading, as mentioned above, and providing liquidity to the pool. To provide liquidity to the pool, tokens must be injected in proportion to the current ratio of the two tokens in the liquidity pool. For example, if the pool contains 10 ETH and 30,000 DAI, one can inject 1 ETH + 3,000 DAI, 5 ETH + 15,000 DAI, and so on. These users are called Liquidity Providers (LPs), and they receive LP tokens in return for the injected quantity, representing partial ownership of the pool. LP tokens can also be freely traded. Since providing liquidity to the pool can reduce traders' losses, what benefits do liquidity providers themselves receive?
This brings us to the concept of "impermanent loss," which refers to an opportunity cost. The question here is, for liquidity providers, how much loss do they incur when they provide liquidity and the ratio of tokens in the pool changes?
Let's assume an LP injects 1 ETH + 3,000 DAI into the pool, and ETH drops to 750 DAI. According to the principle of k remaining constant, this LP would have 2 ETH + 1,500 DAI in the pool. If they hadn't provided liquidity, based on the current ETH price, they would have had 1 * 750 + 3,000 = 3,750 DAI. In reality, since they provided liquidity, they now have assets worth 2 * 750 + 1,500 = 3,000 DAI. The so-called impermanent loss is the ratio of the loss compared to not providing liquidity, which is (3,000 - 3,750) / 3,750 = -20%. The loss is also -20% when measured in ETH. In fact, LPs bear losses regardless of the direction of price movement.
Therefore, LPs have no incentive to provide liquidity. In the design, 0.3% of each transaction is compensated to LPs as a fee to offset their impermanent losses, and the exchange does not charge fees.
This type of mechanism, where LPs provide liquidity and token transactions are conducted using a fixed function, is called a Constant Function Market Maker (CFMM), with Uniswap being the representative. IDEX addressed the issue of trading low-market-value tokens before they were listed on CEX, but did not effectively solve the liquidity problem. Uniswap provides an effective solution to the liquidity problem, allowing token holders to earn transaction fees without needing to develop trading robots like professional CEX market makers. For tokens that have not yet been listed on CEX, we see a significant amount of funds being provided as liquidity during active trading because active trading generates substantial transaction fees. Combined with various liquidity mining activities, Uniswap provides a way for various projects to obtain significant liquidity independent of CEX, weakening the power of CEX and greatly enhancing the practical value of blockchain. Many projects have achieved success without relying on CEX.
The obvious drawback of this approach is the inability to implement limit orders; transactions can only be conducted at the current price. For traders who want to buy low and sell high, they must develop on-chain robots, which require high technical requirements. Additionally, stablecoin exchanges can experience significant slippage, reducing the incentive to exchange stablecoins on Uniswap. Uniswap V3 has made some improvements by integrating features such as limit orders and stablecoin swaps into liquidity pools.