Original author: Luke, investor and researcher at SevenX Ventures
Special thanks to Alex from Maru Network, Brad from Uniswap Labs, Dong Mo from CelerNetwork, Shumo from Manta Network, and Suning from Hyperoracle for their valuable discussions, insights, and feedback on this article.
Preface
There is no doubt that Uniswap is the most widely used decentralized application. It relentlessly pioneers innovative solutions and redefines industry rules. This article will delve into Uniswap’s amazing development journey, which started from scratch in the past and has endless possibilities in the future. By studying the characteristics of each version of Uniswap, this article reveals how it effectively responds to various new challenges and adapts to changing needs. Additionally, this article explores how recent advances in cryptocurrencies are shaping the future of decentralized exchanges (DEX). Get ready for this journey of development from zero to infinity.
v 0: proof of concept
Before Uniswap, EtherDelta was the only decentralized exchange (DEX) that received much attention. However, the user experience is very poor.
Many industry leaders (Alan Lu and Vitalik of Gnosis) have proposed the concept of automated market making (AMM), a technology that offers an alternative to on-chain trading compared to the traditional order book model.
characteristic
Constant product AMM
Uniswap utilizes the constant product formula (x * y = k) to calculate the price of an asset. In this formula, x represents the reserves of trading assets and y represents the reserves of priced assets. When a token is withdrawn (bought) from the pool, a certain proportion of the amount must be deposited (sold) to keep k constant. The ratio of tokens in the pool determines the price of the token.
Source: Uniswap
It is worth noting that other AMMs use different mathematical formulas to represent liquidity curves. For example, Curve’s Stableswap and Balancer’s weighted pool.
question
Uniswap v 0 is essentially a proof-of-concept, which means there are still many questions yet to be resolved. The two main issues are as follows:
1. Only applicable to a single ETH/ERC 20 trading pair.
2. Only applicable to a single liquidity provider (LP).
v1: Functional Decentralized Exchange (DEX)
characteristic
On November 2, 2018, Uniswap v1 was launched on the mainnet. This release supports multiple liquidity providers using internal tokens to track fees and collateral. This version uses factory contracts to allow anyone to add any token to trade with native ETH. This version provides functional DEX. However, there are still some issues that need to be resolved.
question
Since all tokens are paired with ETH, users can easily exchange any ERC 20 token for another ERC 20 token in a single transaction using ETH as an intermediary. However, this method has a disadvantage: if it involves the exchange of frequently operated stablecoins such as DAI/USDT, each exchange relies on ETH as an intermediary, and the efficiency will become low. In this case, direct token pairs are preferred.
v2: Money Lego
In May 2020, Uniswap v2 was launched. This version made multiple upgrades to the Uniswap protocol, enhancing the flexibility of transactions and expanding the feasibility of transactions.
characteristic
ERC 20/ERC 20 trading pair
The significant difference of Uniswap V2 is that ERC 20 tokens can be added to LP liquidity pools with other ERC 20 tokens, instead of just pairing ERC 20 tokens with ETH. This feature is more useful for liquidity providers, as they can now maintain a more diverse range of ERC 20 token-denominated positions, including stablecoin trading pairs.
price oracle
Uniswap v2 provides on-chain price information that can be used by numerous DeFi applications. This price information cannot be easily manipulated and is therefore extremely valuable. This mechanism adds the price at the end of the block to the core contract’s cumulative price variable, which is weighted by the length of time a specific price has existed. This variable essentially represents the sum of Uniswap prices per second over the entire history of the contract.
Source: Uniswap
This variable can be utilized by external contracts to accurately track the time-weighted average price (TWAP) for any given time interval. Reading the cumulative price of an ERC 20 token pair at the beginning and end of the time interval, calculating the difference between the two and dividing it by the length of the time interval gives you the TWAP for that specific period.
Source: Uniswap
Lightning exchange
Uniswap v2 also introduces flash exchange, a type of flash loan pioneered by the lending market AAVE. This feature allows any user to withdraw as many ERC 20 tokens from the pool without any upfront costs and without performing any actions, provided that the equivalent value of tokens (plus fees) is returned at the end of the transaction execution.
The flash loan feature has gained a bad reputation as it is often associated with various attacks against DeFi protocols. But the real problem isn’t flash loans, it’s existing loopholes in the protocol. The atomic nature of flash loans eliminates the upfront capital requirements typically associated with operations such as inter-pool arbitrage and obtaining margin leverage.
question
Although the AMM is innovative and useful in facilitating trading and liquidity in new markets, there are still inefficiencies. For example, when dealing with low volatility tokens, liquidity is only needed within a smaller price range. However, the current design distributes liquidity evenly across all price ranges.
v3: Capital efficiency
Uniswap v3 adopts a breakthrough centralized liquidity design and is committed to becoming the most flexible and efficient AMM.
characteristic
Centralized Liquidity (CL)
In Uniswap v2, liquidity is evenly distributed along the x*y=k price curve, providing liquidity for the entire zero to infinity price range. However, for most pools, liquidity is not fully utilized.
In Uniswap v3, liquidity providers are able to pool their capital within a specific price range to obtain higher liquidity at expected prices. Through this customization, liquidity providers are able to construct personalized price curves that match their preferences. These individual positions are then aggregated into a single pool, creating a unified curve against which users can trade. The results are beneficial to both traders and liquidity providers: traders experience less slippage and liquidity providers earn higher fees due to the high concentration of liquidity within the custom range.
Centralized liquidity is extremely valuable for stablecoin trading pairs such as stablecoins and liquidity-staking derivative tokens. These assets tend to trade within a smaller price range. However, for more volatile token pairs, centralized liquidity requires more advanced liquidity management techniques. It can be challenging for the average retail liquidity provider to effectively manage their positions on an ongoing basis.
range order
With centralized liquidity, this release introduces a new order type called range orders as a complement to market orders. Liquidity providers are able to deposit single tokens within a custom price range (above or below the current price). If the market price enters a specified range, one asset can be sold for another along a smooth curve while still earning transaction fees in the process.
Range orders function similarly to limit orders, but have the disadvantage of being reversible - when the price reverses, the order will also reverse. However, fees can still be earned in the process. Barry Fried (@BarryFried 1) provides a detailed example of how to use range orders in this post.
Various fee levels
Uniswap v3 no longer uses a single fee tier, but instead introduces three separate fee tiers for each trading pair - 0.05%, 0.30% and 1.00%, so that liquidity providers can receive appropriate compensation for taking on different levels of risk. compensation.
Advanced Oracle
Uniswap v3 brings significant improvements to price oracles. This version no longer stores just one price accumulation variable, but a set of variables, making it easier and cheaper to create more advanced oracles, including simple moving averages (SMA), exponential moving averages (EMA) , outlier filtering, etc.
question
lack of flexibility
Although centralized liquidity and fee tiers provide liquidity providers with greater flexibility and facilitate the implementation of new strategies, Uniswap v3 failed to adapt to the ever-changing features and innovations of AMMs and the market. In order to integrate additional features such as TWAP orders, limit orders, advanced oracles, and dynamic charging, it was necessary to reimplement the core protocol.
Through certain features, such as price oracles originally introduced in Uniswap v2, integrators are able to leverage decentralized on-chain pricing data. However, the trade-off is increased gas costs for converters and a lack of customization options for integrators.
Liquidity management is complex and difficult to understand
As mentioned before, centralized liquidity management can be challenging for newer liquidity providers, especially for more volatile trading pairs. While several automated liquidity management protocols already exist, most of them employ simple rebalancing strategies designed for pegged assets. Unfortunately, these strategies are often ineffective for more volatile trading pairs, as long block times, increased gas costs, and rising hedging costs will limit their effectiveness.
Additionally, LP tokens are inherently non-fungible as each liquidity provider’s centralized liquidity positions vary. It can only be represented by non-fungible tokens (NFTs), which poses challenges for other DeFi protocols looking to integrate with it.
Many excellent projects are actively addressing this issue using various strategies including rebalancing, money market dynamic hedging, perpetual contracts, and options. Atis Elsts (@atiselsts_eth) has written an excellent series of articles on LP strategies, which I highly recommend.
value leakage
Among all the problems, value leakage is the top priority. While this issue is not unique to Uniswap v3, it has attracted attention due to increased AMM trading volume and increased adoption since its launch. Value leakage mainly originates from the DEX system, in the following form:
Due to front-running and sandwich attacks, traders end up paying more slippage than they actually need to.
Liquidity providers lose value through CEX-DEX arbitrage (aka relative loss rebalancing)
In order to solve the above problems, we need to provide more custom functions and complex designs compared to Uniswap v3. We need a more expressive and powerful DEX platform.
v4: The ultimate platform
Uniswap v4 is built based on the AMM model launched in previous generations. By introducing hooks, it aims to become an efficient and customizable ultimate DEX platform.
efficiency
Singleton
In Uniswap v3, each pool is created as a separate contract through the factory contract. In Uniswap v4, all pools coexist in a single smart contract (also called a singleton). This singleton model significantly reduces the costs associated with creating a pool and executing multi-hop transactions.
Flash Accounting
In Uniswap v4, the singleton mode uses lightning accounting to optimize asset transfers. Unlike v3, where assets are moved in and out of the pool after each exchange, the v4 system only transfers based on net balance, which greatly reduces accounting costs. With transient storage (proposed in EIP-1153), it is cheaper to set up and clear storage slots, which are required for Lightning Accounting to run efficiently.
Source: Uniswap
Native ETH
Uniswap v4 once again introduces support for native ETH transactions, which will have several benefits: traders can enjoy lower gas costs, achieve lower transfer costs, and avoid additional packaging costs.
customize
hook
Hook contracts (or hooks) are externally deployed contracts that execute predefined logic at specific points during pool execution. This is why v4 is so expressive and customizable. Through hooks, it is possible to implement features that were previously built into the protocol (such as oracles) as well as new features that previously required independent protocols to implement.
Uniswap v4 currently supports the following eight hook callback functions:
beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate
The figure below shows the logical flow of the redemption hook. There is a dedicated boolean flag that allows custom code to be executed at these specific points before and after the exchange is performed. This is the basis for developing advanced features such as oracles, dynamic charging systems, auctions, and advanced order types. Well explore these concepts in more depth below.
Exchange hook process
Oracle
In previous versions, oracles were integrated into the Uniswap core protocol. While this makes integration with other protocols easier and less expensive, it comes at the cost of fewer customization options and increased costs for converters. However, with the introduction of hooks, the design possibilities of oracles are greatly expanded. This provides the opportunity to create manipulation-resistant oracles such as tail price oracles and volatility oracles. Additionally, it is now possible to customize who bears the cost of updating oracles. For example, a hook contract with an ETH balance could be used to pay for gas, rather than having the first redeemer bear the cost (which may not be sustainable). Although optimized, oracle design still faces challenges. For example, the TWAP oracle is sometimes susceptible to manipulation and tends to lag current prices.
Uniswap Labs has launched another interesting price oracle, the truncated price oracle. The oracle calculates the geometric mean price of assets in the liquidity pool and limits price changes within a single block. By truncating prices, this on-chain oracle mitigates the price impact of significant transactions and increases resistance to manipulation attempts.
Dynamic fees
Although Uniswap v3 introduced additional fee levels for liquidity providers to choose from, these fee systems are still static and do not take current market conditions into account. Therefore, liquidity providers are not fully compensated for their services.
Alex Nezlobin (@0x 94305) proposed a simple and effective dynamic fee system that takes into account the price impact of the previous block and applies different fee criteria to buyers and sellers. As shown in the figure below: when the CEX price moves to p*, that is, when it is higher than the current AMM price p_AMM, the selling fee decreases by δ, while the buying fee increases by δ. The value of δ is directly proportional to the change in AMM price. The purpose of this dynamic fee system is to differentiate between arbitrageurs and uninformed flows. Arbitrage flows are more likely to be autocorrelated with price changes.
Source: https://twitter.com/0x 94305/status/1674857993740111872
Designing a robust dynamic fee system presents several challenges. One challenge is how to integrate off-chain signals such as CEX prices, liquidity depth and volatility. Additionally, various on-chain signals (including address, size, and execution time) may not be reliable for distinguishing informed from uninformed flows, making it difficult to evaluate their effectiveness. Additionally, in order to limit the losses of liquidity providers, it is also important to ensure that fees do not go below zero.
auction
Hooks also serve as a means to implement auctions, which help redistribute value to liquidity providers. Depending on the time, auctions can be divided into pre-auctions and post-auctions.
The pre-auction takes place before the block is auctioned. This concept was originally proposed in a research article discussing MEV Capture AMM (McAMM). Under this approach, rights are first redeemed in the AMM before a block is auctioned, with bid values subsequently redistributed. However, this bidding process also presents some challenges as it inherently involves option pricing, which can be very complex. Additionally, since block proposers have the final say on whether to accept a block containing a transaction, censorship issues may arise. Ensuring that bid values are distributed fairly and efficiently has also proven to be a complex task. Furthermore, there is no guarantee that the auction winner will be the first to exercise his/her redemption rights, which may lead to an increasingly worsening experience for other traders.
Post-event auctions are conducted after volatility has materialized, meaning that the CEX price has changed but subsequent blocks have not yet been submitted. These types of auctions have the advantage of increased efficiency, but also pose challenges because they require off-chain infrastructure that relies on trusted parties or trustless systems. If trusted parties are used, issues around review and bid privacy arise. On the other hand, designing trustless systems is much more complex. Post-event auctions also face the problem that proposers may play tricks on bidders, such as excluding arbitrage trades in a timely manner. Additionally, there is a significant issue with delays in the process of bidding, reaching consensus on winning bids, and distributing those bids to block builders, all of which need to be completed before subsequent blocks can be submitted. Finally, it can be difficult to ensure there is enough competition in these auctions to capture adequate value. Sorella Labs (@SorellaLabs) is leading the way in addressing these challenges, leveraging its advanced infrastructure and mechanism design.
Diamond hook
The Diamond protocol was originally designed as an LVR-minimized AMM. Under the Diamond protocol, block producers conduct auctions to capture arbitrage opportunities between the Diamond pool’s external market price and the pool’s own price. The proceeds from these auctions are shared between the Diamond pool and block producers in a way that maintains incentive compatibility.
As discussed in this article, a variant of the Diamond protocol includes implementing a collateral pool to maintain the block end price based on the price promised by the block producer. The exchange will only be executed when there is enough collateral to restore the price to the promised value. Arrakis (@ArrakisFinance) is currently working with Conor McMenamin (@ConorMcMenamin 9), one of the authors of the Diamond protocol, to develop a hook contract using v4 to achieve this goal.
Advanced order types
Hooks also support more advanced order types, greatly improving the trader experience. Some common order types include limit orders, stop-loss orders, take-profit orders, and TWAP.
limit order
Traders can choose to submit an on-chain price limit order to the hook contract. When the price reaches the specified minimum price, the order is filled. However, these on-chain limit orders have significant disadvantages compared to traditional financial (tradfi) limit orders. This is mainly because on-chain orders cannot be canceled without incurring gas fees. Therefore, this creates the problem of low order-to-transaction ratio.
Time Weighted Average Market Maker (TWAMM)
One possible solution is to implement a time-weighted average market maker (TWAMM) to facilitate the execution of large orders. This approach prevents sandwich attacks by breaking large orders into small chunks and ensuring they are executed as the first transactions. Additionally, consider lowering TWAP order fees as they often involve uninformed processes. However, the challenge comes with high gas costs and deciding who should bear these costs.
Other hooks
Several other functions are possible using hooks. Here are some ideas:
A yield-generating hook that borrows excess liquidity into money markets to improve capital efficiency.
A pool with both xy=k liquidity curve and concentrated liquidity.
Provide a pool of withdrawal fees for liquidity providers to reduce instant liquidity attacks.
Suning (@msfew_eth) shared some cool ideas about hooks on Github. Aiden (@aiden 0x 4) also posted a great open directory of hooks.
zkAMM and zkHooks
ZK Coprocessors empower smart contracts to access data insights similar to those provided by Dune Analytics, all without compromising trust due to the application of zero-knowledge (ZK) proof technology. The application of ZK coprocessors in AMM design is an emerging research field. With the introduction of hooks, zero-knowledge proofs are now allowed to be seamlessly integrated into Uniswap v4, ushering in a new era of zkAMM.
HyperOracle (@HyperOracle) demonstrates a zkAMM implementation based on Uniswap v2, where addLiquidity calculations are moved off-chain. When users add liquidity, the number of tokens, price and LP token share need to be calculated. In this particular implementation, HyperOracles zkGraph captures the addLiquidity event, performs the necessary calculations, generates the proof, and publishes it. This implementation of zkAMM includes an integrated automation layer for validating the proof and minting LP tokens for users.
Diego (@0x futuristic) introduced the zkAMM (zkUniswap) implementation based on Uniswap v3, in which part of the AMM redemption calculation is transferred to Risc Zero (@RiscZero) zkVM. When a user performs a redemption in the pool, several parameters need to be calculated to complete the redemption. These parameters include the quantity to be redeemed, the fee, and the price after redemption. Initially, this calculation is performed in the Solidity contract via the EVM. However, in the new implementation, redemption inputs are picked up by relayers and calculations are performed off-chain. The relayer then publishes the output and proof. AMM verifies the certificate and settles the exchange. zkUniswap implements a lock auction mechanism to ensure concurrency control. Although its current performance is comparable to EVM, the efficiency can be greatly improved through parallelization of batch redemption.
Proof of transaction volume is another use case for AMMs. Brevis (@brevis_zk) provided an interesting example of designing a fee rebate hook based on a user’s historical trading volume, similar to volume-based fee rebates on centralized exchanges (CEX). VIP traders are now able to calculate their monthly trading volume off-chain and then submit low-cost zero-knowledge proofs to the blockchain to asynchronously verify their VIP status. Once authenticated, subsequent transactions can leverage post-redeem hooks to access the VIP fee tier table populated by the zero-knowledge coprocessor. This allows the appropriate fee rebate to be applied automatically. Maru Network (@marunetwork) is currently developing a trustless transaction volume oracle as an initial use case for its ZK coprocessor network. By implementing trustless volume oracles, DEXs will be able to distribute rewards in a fair and transparent manner. This approach can incentivize liquidity and user activity proportionally, creating a positive flywheel effect. The cost of proof verification can be reduced by using zero-knowledge proof aggregation services like NEBRA (@nebrazkp) UPA (Universal Proof Aggregation), which aggregates proofs from various rings and parties into a single proof to reduce amortized verification costs .
To summarize, the concept of zkAMM involves leveraging ZK coprocessors or ZK oracles to offload computations from the EVM and verify proofs of on-chain computations. These calculations can be significantly more complex than calculations related to conversion and liquidity adjustments. For example, these calculations may involve calculating dynamic fees based on recent market fluctuations, proving the historical number of users in a given pool, or implementing a rebalancing strategy using complex machine learning algorithms. There will be endless possibilities, since any calculation will eventually result in O(1) verification cost and will no longer be limited by the EVM computing resources.
v4 challenge
Uniswap v4 brings efficiency and customization to the AMM design space, enabling the creation of pools with different features and functions. This is a big step forward, but at a predictable cost: as the number of pools explodes, liquidity fragmentation increases, and therefore routing becomes more challenging.
UniswapX
UniswapX aims to solve the liquidity fragmentation problem with an open network that outsources the complexity of routing to third-party fillers. These fillers compete with each other to perform redemptions using on-chain liquidity such as AMM pools or their own private inventories. This design is goal-focused, with users simply declaring the results they want and relying on professionals to fill it in.
These fillers are advanced agents equipped with advanced routing algorithms, high computing power, and large amounts of financial capital. They compete with each other under a predetermined auction mechanism to provide users with the best execution. Users also get price optimization, ensuring their execution is at least as good as trading directly from the Uniswap AMM pool.
The architecture of the UniswapX protocol is shown below. Exchangers submit their intention orders through the Uniswap API, which are structured as Permit 2 executable off-chain signatures. Permit 2 is a well-designed model that ensures safe transfer of tokens held by users. Fillers devise various strategies to fulfill these orders using any available liquidity venue, whether on-chain or off-chain. Finally, the order reactor resolves UniswapX orders. They are responsible for validating a specific type of order, parsing it into inputs and outputs, executing the order according to the fillers strategy, and verifying that the order was successfully fulfilled.
Source: Uniswap
Currently, in Uniswap Labs interface implementation of UniswapX, the protocol is divided into two stages. The first is the RFQ stage, where quoters on the whitelist respond to orders with quotes. The winner of the offer then has an exclusivity period to fulfill the order. If the order is not completed, it enters the second stage - the Dutch auction stage, that is, any filler can participate in the auction. There are plans to make the quoting system completely permissionless in the near future.
Source: Hayden Adams’ “On-Chain Transaction” speech at the EthCC Conference
Goal-centered design provides the following benefits:
Aggregate liquidity sources to obtain more suitable prices.
Even for cross-chain exchange, Gas tokens are not required.
Internalize the maximum extractable value through price optimization.
There are no fees for failed transactions.
challenge
Make the quoting system permissionless, for example using an effective reputation system.
Attract more fillers to ensure a competitive and permissionless auction environment.
The future: infinite games
The development of DEX does not stop here. There are several other issues that need to be addressed in order for encryption technology to be adopted at scale. Markus Schmitt (@_haikane_) of PropellerHeads (@PropellerSwap), in collaboration with Frontier Research (@FrontierDotTech), has written an excellent article that takes a deep dive into what makes a good DEX and identifies the questions that remain to be answered. According to the article, a great exchange should offer:
Trust: Ensure transparency before, during and after the trade and minimize custody risk.
The most suitable price: Continuously provide the most suitable or competitive price.
Fairness: Prevent order abuse and ensure equal treatment of pricing and fees for all users.
Speed and Availability: Provide fast transaction processing and maintain high availability to avoid delays and inconvenience.
Information: Helps users make informed decisions by providing order monitoring, settlement price estimates, and helpful advice on limit orders and slippage.
Liquidity: Demonstrate strong liquidity pools across various asset pairs, instilling confidence in obtaining favorable prices.
If the DEXs smart contracts are considered secure, then trust can be established. DEX does not hold users’ assets. Today, the information available to traders is quite extensive. The permissionless nature of AMM enables users to create and trade any asset pair. However, due to the characteristics of blockchain, the most appropriate price, fairness, speed and availability cannot always be guaranteed. Gas fees, lagging prices, and fragmented liquidity all affect user experience.
To solve these problems, the number of L2 and L2-based DEX is increasing day by day. Additionally, routing, order batching, and quote request systems have become increasingly complex. To prevent front-running and ensure fair value distribution, more and more MEV-aware channels are being put into use. In addition, we are working hard to develop an order flow auction market to minimize value leakage for DEX users. The introduction of hooks and ZK coprocessors also greatly expands the design possibilities of AMM, supporting more complex logic and heavy calculations without affecting trust.
In addition, there are a series of AMM-based protocols that effectively stack “money Lego”. Some protocols help novice users automate liquidity rebalancing or leverage mining, such as liquidity managers. There are also protocols that utilize concentrated liquidity (CL) positions to create margin trading, perpetual trading, options and structured products.
AMMs have experienced exponential growth due to their permissionless listings, passive liquidity, and ease of trading. However, this convenience also brings about several problems we discussed earlier. Uniswap has been constantly pushing boundaries, striving to solve these problems and enhance user experience. As Dan Robinson (@danrobinson) pointed out in his SBC 23 talk, DEX design is an infinite game. As DEX becomes more and more popular in the future, new challenges and problems may arise, and innovative solutions will be needed.
