Uniswap: From Zero to Infinity
TechFlow Selected TechFlow Selected
Uniswap: From Zero to Infinity
Uniswap has been continuously pushing boundaries to address these issues and enhance user experience.
Navigating Web3 tides with focused insightsAuthor: Luke, Investor & 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.
Introduction
Unquestionably, Uniswap is the most widely used decentralized application. It has persistently pioneered innovative solutions and redefined industry standards. This article delves into Uniswap’s remarkable journey of development—from zero to infinite possibilities. By examining the features of each Uniswap version, we reveal how it effectively tackles new challenges and adapts to evolving demands. Furthermore, we explore how recent advancements in cryptocurrency are shaping the future of decentralized exchanges (DEXs). Get ready for a journey from zero to infinity.
v0: Proof of Concept
Before Uniswap, EtherDelta was the only notable decentralized exchange (DEX), but its user experience was extremely poor.
Industry leaders such as Alan Lu from Gnosis and Vitalik proposed the concept of automated market makers (AMMs), offering an alternative approach to on-chain trading compared to traditional order book models.
Features
Constant Product AMM
Uniswap employs the constant product formula (x * y = k) to determine asset prices. In this formula, x represents the reserve of the traded asset, and y represents the reserve of the pricing asset. When tokens are withdrawn (bought) from the pool, a proportional amount must be deposited (sold) to keep k constant. The token price is determined by the ratio of tokens within the pool.
Source: Uniswap
It's worth noting that other AMMs use different mathematical formulas to represent liquidity curves—for example, Curve’s Stableswap and Balancer’s weighted pools.
Problems
Uniswap v0 was essentially a proof of concept, meaning many issues remained unresolved. Two major problems were:
1. Supported only single ETH/ERC20 trading pairs.
2. Supported only a single liquidity provider (LP).
v1: Functional Decentralized Exchange (DEX)
Features
On November 2, 2018, Uniswap v1 launched on Ethereum mainnet. This version supported multiple liquidity providers using internal tokens to track fees and collateral. It introduced a factory contract enabling anyone to add any token to trade against native ETH, providing a functional DEX. However, several issues still needed resolution.
Problems
Since all tokens traded against ETH, users could easily swap one ERC20 token for another via ETH as an intermediary in a single transaction. However, this method had a drawback: when frequently executed swaps involved stablecoins like DAI/USDT, relying on ETH as an intermediary became inefficient. Direct token pairs were preferred in such cases.
v2: Money Lego
In May 2020, Uniswap v2 launched, introducing multiple upgrades that enhanced trading flexibility and expanded feasibility.
Features
ERC20/ERC20 Trading Pairs
A key difference with Uniswap v2 is the ability to create LP liquidity pools between any two ERC20 tokens, not just pairing ERC20s with ETH. This feature is more practical for liquidity providers, who can now maintain more diversified positions denominated in various ERC20 tokens, including stablecoin pairs.
Price Oracles
Uniswap v2 provides on-chain price data usable by numerous DeFi applications. These price feeds are resistant to manipulation and thus highly valuable. The mechanism adds the price at block end to a cumulative price variable in the core contract, weighted by how long a specific price persists. This variable essentially represents the sum of every second’s Uniswap price over the entire history of the contract.
Source: Uniswap
External contracts can leverage this variable to accurately track time-weighted average prices (TWAPs) over any specified interval. By reading the cumulative price of an ERC20 pair at the start and end of an interval, calculating the difference, and dividing by the duration, one obtains the TWAP for that period.
Source: Uniswap
Flash Swaps
Uniswap v2 also introduced flash swaps—a variation of Aave’s pioneering flash loans. This feature allows any user to withdraw as many ERC20 tokens as desired from a pool without upfront cost or execution conditions, provided they return an equivalent value (plus fees) before the transaction ends.
Flash loans have gained notoriety due to frequent associations with attacks on DeFi protocols. However, the real issue lies not in flash loans themselves, but in existing vulnerabilities within protocols. The atomicity of flash loans eliminates typical upfront capital requirements associated with cross-pool arbitrage and obtaining leveraged margin positions.
Problems
Although innovative and beneficial for facilitating new markets and liquidity, this AMM still suffers from inefficiencies. For instance, when handling low-volatility tokens, liquidity is only needed within a narrow price range. Yet, the current design distributes liquidity uniformly across all price ranges.
v3: Capital Efficiency
Uniswap v3 adopts a groundbreaking concentrated liquidity design, aiming to become the most flexible and efficient AMM.
Features
Concentrated Liquidity (CL)
In Uniswap v2, liquidity is evenly distributed along the x*y=k price curve, providing liquidity across the full zero-to-infinity price spectrum. However, for most pools, much of this liquidity remains underutilized.
In Uniswap v3, liquidity providers can concentrate their capital within specific price ranges, achieving higher effective liquidity around expected prices. Through customization, LPs can build personalized price curves aligned with their preferences. These individual positions are aggregated into a single pool, forming a unified curve for traders to execute against. The result benefits both traders and LPs: reduced slippage due to high liquidity concentration within custom ranges, and higher fee earnings for LPs.
Concentrated liquidity is particularly valuable for stablecoin pairs (e.g., stablecoins and liquid staking derivatives), which typically trade within tight price bands. However, for volatile pairs, CL requires more sophisticated liquidity management techniques. Continuously managing positions effectively may be challenging for ordinary retail LPs.
Range Orders
With concentrated liquidity, v3 introduces a new type of order called range orders, complementing market orders. LPs can deposit a single token within a custom price range (above or below the current price). If the market price enters the specified range, the system smoothly sells one asset for another while continuing to earn trading fees.
Range orders function similarly to "limit orders," but with reversibility—if the price reverses, so does the order—while still earning fees during the process. Barry Fried (@BarryFried1) provides detailed examples of how to use range orders in his post.
Multiple Fee Tiers
Instead of a single fee tier, Uniswap v3 introduces three separate fee tiers per trading pair—0.05%, 0.30%, and 1.00%—allowing LPs to receive appropriate compensation based on varying risk levels.
Advanced Oracles
Uniswap v3 makes significant improvements to price oracles. Instead of storing just one cumulative price variable, it stores a set of variables, making it easier and cheaper to build advanced oracles—including simple moving averages (SMA), exponential moving averages (EMA), outlier filtering, and more.
Problems
Lack of Flexibility
While concentrated liquidity and fee tiers provide greater flexibility for LPs and enable new strategies, Uniswap v3 fails to adapt to the rapidly evolving features and innovations in AMMs and markets. To integrate additional functionalities like TWAP orders, limit orders, advanced oracles, and dynamic fees, a complete re-implementation of the core protocol would be necessary.
Certain features—such as the price oracle first introduced in Uniswap v2—enable integrators to utilize decentralized on-chain pricing data. However, this comes at the cost of increased gas expenses for swappers and limited customization options for developers.
Complex Liquidity Management
As mentioned earlier, managing concentrated liquidity poses significant challenges for new LPs, especially for volatile pairs. While several automated liquidity management protocols exist, most employ simple rebalancing strategies designed for pegged assets. Unfortunately, these strategies often fail for volatile pairs, as longer block times, rising gas costs, and increasing hedging expenses limit their effectiveness.
Moreover, since each LP’s concentrated liquidity position differs, LP tokens are inherently non-fungible. They must be represented as non-fungible tokens (NFTs), posing integration challenges for other DeFi protocols.
Numerous excellent projects are actively addressing this using various strategies, including rebalancing, dynamic hedging via money markets, perpetual contracts, and options. Atis Elsts (@atiselsts_eth) has written an outstanding series on LP strategies—highly recommended.
Value Leakage
Among all issues, value leakage stands out. Although not unique to Uniswap v3, it has gained attention due to increased AMM trading volume and adoption since its launch. Value leakage primarily stems from DEX systems in the following forms:
Traders end up paying higher slippage than necessary due to front-running and sandwich attacks.
Liquidity providers lose value through CEX-DEX arbitrage (also known as impermanent loss rebalancing).
To solve these issues, we need more customizable features and complex designs beyond Uniswap v3—an even more expressive and powerful DEX platform.
v4: The Ultimate Platform
Built upon previous generations of AMM models, Uniswap v4 aims to become the ultimate efficient and customizable DEX platform by introducing “hooks.”
Efficiency
Singleton
In Uniswap v3, each pool is created as a separate contract via a factory contract. In contrast, in Uniswap v4, all pools coexist within a single smart contract (known as a singleton). This singleton model significantly reduces costs related to pool creation and multi-hop trades.
Flash Accounting
In Uniswap v4, the singleton model uses flash accounting to optimize asset transfers. Unlike v3, where assets move in and out of the pool after every swap, v4 only settles net balances, greatly reducing accounting costs. Using transient storage (proposed in EIP-1153), setting and clearing storage slots becomes cheaper—essential for flash accounting to operate efficiently.
Source: Uniswap
Native ETH
Uniswap v4 reintroduces support for native ETH trading, bringing several benefits: lower gas costs for traders, reduced transfer costs, and elimination of wrapping overhead.
Customization
Hooks
Hook contracts (or hooks) are externally deployed contracts that execute predefined logic at specific points during pool operations. This is what makes v4 so expressive and customizable. With hooks, features previously built into the protocol (like oracles) and entirely new capabilities requiring independent protocols can now be implemented.
Uniswap v4 currently supports eight hook callback functions:
-
beforeInitialize/afterInitialize
-
beforeModifyPosition/afterModifyPosition
-
beforeSwap/afterSwap
-
beforeDonate/afterDonate
The diagram below illustrates the logic flow of swap hooks. Dedicated boolean flags allow custom code execution before and after swaps—forming the foundation for developing advanced features such as oracles, dynamic fee systems, auctions, and sophisticated order types. We will explore these concepts in greater depth below.
Swap Hook Flow
Oracles
In prior versions, oracles were integrated directly into the Uniswap core protocol. While this simplified integration for other protocols and lowered costs, it reduced customization options and increased costs for swappers. With the introduction of hooks, oracle design possibilities expand dramatically. This enables creation of manipulation-resistant oracles—such as trimmed mean oracles and volatility oracles—and allows customization of who bears the cost of oracle updates. For example, a hook contract with ETH balance can pay gas fees instead of burdening the first swapper—a more sustainable approach. Despite optimizations, oracle design remains challenging—e.g., TWAP oracles can sometimes be manipulated and lag behind current prices.
Uniswap Labs introduced another interesting price oracle—the censored price oracle. It calculates the geometric mean price of assets in the liquidity pool while limiting intra-block price movements. By censoring prices, this on-chain oracle mitigates large trade impacts and enhances resistance to manipulation attempts.
Dynamic Fees
While Uniswap v3 introduced additional fee tiers for LPs to choose from, these fee structures remain static and do not account for current market conditions. As a result, LPs’ services are not adequately compensated.
Alex Nezlobin (@0x94305) proposed a simple yet effective dynamic fee system that considers the price impact from the previous block and applies different fee rates for buyers and sellers. As shown in the figure below: when the CEX price moves to p*, above the current AMM price p_AMM, the sell fee decreases by δ, while the buy fee increases by δ. The value of δ is proportional to the change in AMM price. The goal of this dynamic fee system is to distinguish between arbitrage flows and uninformed flows—arbitrage being more likely autocorrelated with price changes.
Designing a robust dynamic fee system presents several challenges. One challenge involves integrating off-chain signals such as CEX prices, liquidity depth, and volatility. Additionally, various on-chain signals—including address, size, and execution timing—may be unreliable for distinguishing informed from uninformed flows, making effectiveness hard to assess. Moreover, ensuring fees never drop below zero is crucial to protect LPs from losses.
Auctions
Hooks can also serve as mechanisms to implement auctions, helping redistribute value back to LPs. Auctions can be categorized as pre-trade or post-trade depending on timing.
Pre-trade auctions occur before the auctioned block. This concept was initially proposed in a research paper discussing MEV-capturing AMMs (McAMMs). Under this method, the right to perform the first swap in an AMM before a block is auctioned, and the bid value is redistributed afterward. However, this bidding process faces challenges—it inherently involves option pricing, which can be highly complex. Additionally, since block proposers have final authority over whether to accept blocks containing transactions, censorship issues may arise. Ensuring fair and efficient allocation of bid value proves difficult. Also, there's no guarantee the winning bidder executes first, potentially worsening experiences for other traders.
Post-trade auctions happen after volatility realization—meaning CEX prices have changed, but subsequent blocks haven’t been submitted yet. These auctions improve efficiency but face challenges requiring trusted parties or trustless off-chain infrastructure. Trusted parties raise concerns about censorship and bid privacy. Designing trustless systems is far more complex. Post-trade auctions also face risks of proposers colluding with bidders—e.g., timely excluding arbitrage trades. Another major issue is latency in bidding, reaching consensus on winning bids, and distributing them to block builders—all needing completion before the next block submission. Finally, ensuring sufficient competition to capture adequate value may prove difficult. Sorella Labs (@SorellaLabs) leads efforts in tackling these challenges with advanced infrastructure and mechanism design.
Diamond Hooks
The Diamond protocol was originally designed as an LVR-minimizing AMM. Under Diamond, block proposers run auctions to capture arbitrage opportunities between the external market price and the pool’s own price. Auction proceeds are shared between the Diamond pool and proposers in an incentive-compatible manner.
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 proposer’s committed price. Swaps are executed only if sufficient collateral exists to restore the price to the committed value. Arrakis (@ArrakisFinance) is currently collaborating with Conor McMenamin (@ConorMcMenamin9), one of the Diamond protocol authors, to develop this using v4’s hook contracts.
Advanced Order Types
Hooks also support more advanced order types, greatly enhancing trader experience. Common order types include limit orders, stop-loss orders, take-profit orders, and TWAPs.
Limit Orders
Traders can submit on-chain limit orders to hook contracts. When the price reaches the specified minimum tick, the order executes. However, compared to traditional finance (tradfi) limit orders, these on-chain orders suffer a clear disadvantage—they cannot be canceled without gas fees. This leads to a high unfilled order rate.
Time-Weighted Average Market Maker (TWAMM)
A viable solution is implementing a Time-Weighted Average Market Maker (TWAMM) to facilitate large order execution. This approach breaks large orders into small chunks and ensures they execute first, preventing sandwich attacks. Additionally, TWAP order fees could be reduced since they usually involve uninformed flows. However, challenges include high gas costs and determining who should bear them.
Other Hooks
Several other functionalities can be achieved using hooks. Here are some ideas:
-
A yield-generating hook that lends out-of-range liquidity into money markets to boost capital efficiency.
-
Pools combining xy=k liquidity curves with concentrated liquidity.
-
Pools charging withdrawal fees to LPs to reduce immediate liquidity attacks.
Suning (@msfew_eth) shares creative hook ideas on GitHub. Aiden (@aiden0x4) also published an excellent open directory of hooks.
zkAMM and zkHooks
ZK coprocessors empower smart contracts to access data insights similar to those offered by Dune Analytics—all without compromising trust due to zero-knowledge (ZK) proofs. ZK coprocessors in AMM design represent an emerging research area. With hooks, seamless integration of zero-knowledge proofs into Uniswap v4 is now possible, ushering in a new era of zkAMMs.
HyperOracle (@HyperOracle) demonstrated a zkAMM implementation based on Uniswap v2, where addLiquidity calculations are moved off-chain. When users add liquidity, computations involving token amounts, prices, and LP share distribution are required. In this implementation, HyperOracle’s zkGraph captures addLiquidity events, performs necessary calculations, generates proofs, and publishes them. This zkAMM includes an integrated automation layer that verifies the proof and mints LP tokens for users.
Diego (@0xfuturistic) introduced a zkAMM (zkUniswap) implementation based on Uniswap v3, where part of the AMM swap calculation is offloaded to Risc Zero’s (@RiscZero) zkVM. When users execute swaps in a pool, several parameters—including amount to swap, fees, and post-swap price—must be computed. Originally performed on-EVM in Solidity, in this new setup, relayers pick up swap inputs and perform computation off-chain. Relay nodes then publish outputs and proofs. The AMM validates the proof and settles the swap. zkUniswap implements a lock-auction mechanism for concurrency control. While current performance matches EVM, efficiency can be greatly improved through parallelization of batched swaps.
Proof of trading volume is another AMM use case. Brevis (@brevis_zk) presented an interesting example: designing a fee rebate hook based on historical trading volume, similar to volume-based fee discounts on centralized exchanges (CEXs). VIP traders can now compute their monthly trading volume off-chain and submit low-cost zero-knowledge proofs to the blockchain to asynchronously verify their VIP status. Once verified, subsequent trades can use post-swap hooks to access a “VIP fee tier table” populated by a zero-knowledge coprocessor, automatically applying appropriate fee rebates. Maru Network (@marunetwork) is currently developing a trustless volume oracle as the initial use case for its ZK coprocessor network. Implementing trustless volume oracles enables DEXs to fairly and transparently distribute rewards, proportionally incentivizing liquidity and user activity to create positive flywheel effects. Using ZK proof aggregation services like NEBRA (@nebrazkp) UPA (Universal Proof Aggregation), verification costs can be reduced—NEBRA UPA aggregates proofs from multiple circuits and sources into a single proof, lowering amortized validation costs.
In summary, the concept of zkAMM involves leveraging ZK coprocessors or ZK oracles to offload computation from the EVM and validate proofs on-chain. These computations—potentially far more complex than standard swap and liquidity adjustments—could include calculating dynamic fees based on recent market volatility, proving historical user counts in specific pools, or implementing rebalancing strategies using complex machine learning algorithms. The possibilities are infinite, as any computation ultimately results in O(1) verification cost, no longer constrained by EVM computational limits.
v4 Challenges
Uniswap v4 brings efficiency and customization to AMM design space, enabling pools with diverse characteristics and functionalities. This is a major advancement—but comes with predictable costs: increased pool count exacerbates liquidity fragmentation, making routing more challenging.
UniswapX
UniswapX addresses liquidity fragmentation by outsourcing routing complexity to an open network of third-party fillers. These fillers compete to execute swaps using on-chain liquidity (such as AMM pools) or their private inventory. This intent-centric design lets users declare desired outcomes and rely on professionals to fulfill them.
These fillers are advanced agents equipped with sophisticated routing algorithms, high computational power, and substantial financial capital. They compete under predefined auction mechanisms to deliver optimal execution for users. Users also benefit from price optimization, ensuring their execution performs at least as well as direct trades from Uniswap AMM pools.
The architecture of the UniswapX protocol is illustrated below. Swappers submit intent orders via the Uniswap API, structured as Permit2-executable off-chain signatures. Permit2 is a well-designed model ensuring secure transfer of user-held tokens. Fillers devise various strategies to fulfill these orders using any available liquidity venue—on-chain or off-chain. Finally, order reactors resolve UniswapX orders. They verify specific order types, parse them into inputs and outputs, execute based on filler strategies, and confirm successful fulfillment.
Source: Uniswap
Currently, in Uniswap Labs’ interface implementation of UniswapX, the protocol operates in two phases. The first is the RFQ phase, where whitelisted “quoters” respond to orders with quotes. The winning quote gets an exclusive period to fulfill the order. If unfulfilled, it enters the second phase—the Dutch auction phase—where any filler can participate. The plan is to make the quoting system fully permissionless in the near future.
Source: Hayden Adams' “On-Chain Trading” talk at EthCC
Intent-centric design offers the following benefits:
-
Aggregates liquidity sources for better pricing.
-
No gas token required—even for cross-chain swaps.
-
Internalizes maximum extractable value (MEV) through price optimization.
-
Failed trades incur no fees.
Challenges
-
Make the quoting system permissionless—e.g., using a robust reputation system.
-
Attract more fillers to ensure competitive and permissionless auction environments.
Future: Infinite Game
DEX evolution doesn’t stop here. For crypto to achieve mass adoption, several other issues remain. Markus Schmitt (@_haikane_) from PropellerHeads (@PropellerSwap), collaborating with Frontier Research (@FrontierDotTech), authored an excellent article deeply exploring what constitutes a great DEX and identifying unresolved problems. According to the article, an excellent exchange should offer:
-
Trust: Ensure transparency before, during, and after trades, minimizing custody risks.
-
Best Price: Consistently deliver best or competitive pricing.
-
Fairness: Prevent order abuse and ensure equal treatment in pricing and fees for all users.
-
Speed and Availability: Deliver fast trade processing and maintain high availability to avoid delays and inconvenience.
-
Information: Help users make informed decisions by providing order monitoring, settlement price estimates, and useful guidance on limit orders and slippage.
-
Liquidity: Showcase strong liquidity pools across various asset pairs, instilling confidence in favorable pricing.
If a DEX’s smart contracts are considered secure, trust can be established. DEXs don’t hold user assets. Today, information available to traders is quite extensive. The permissionless nature of AMMs allows users to create and trade any asset pair. However, due to blockchain limitations, optimal pricing, fairness, speed, and availability aren’t always guaranteed. Gas fees, delayed prices, and fragmented liquidity all impact user experience.
To address these issues, the number of L2s and L2-based DEXs continues to grow. Routing, order batching, and request-for-quote systems are becoming increasingly sophisticated. More MEV-aware channels are being deployed to prevent front-running and ensure fair value distribution. Efforts are underway to develop order flow auction markets to minimize value leakage for DEX users. The introduction of hooks and ZK coprocessors has greatly expanded AMM design possibilities, enabling more complex logic and intensive computation without sacrificing trust.
Additionally, a range of AMM-based protocols effectively stack “money legos.” Some help novice users automate liquidity rebalancing or leveraged farming—such as liquidity managers. Others leverage concentrated liquidity (CL) positions to create margin trading, perpetuals, options, and structured products.
AMMs have grown exponentially due to their permissionless listing, passive liquidity, and ease of trading. However, this convenience brings several issues explored earlier. Uniswap continuously pushes boundaries to solve these issues and enhance user experience. As Dan Robinson (@danrobinson) noted in his SBC23 talk, DEX design is an infinite game. As DEXs become more widespread in the future, new challenges will emerge—requiring innovative solutions.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@SevenXVentures
