Uniswap v2 vs v3 vs v4: what changed

Decentralized exchanges (DEXs) let people trade tokens directly through smart contracts instead of through a company that matches buyers and sellers. Most do this with an automated market maker (AMM): a pool of two tokens and a formula that sets the price based on how much of each token the pool holds. If that idea is fuzzy, the companion piece on how AMMs work walks through it slowly. Uniswap is one widely studied AMM, and looking at how its versions differ is a useful way to understand the design choices behind this kind of system. This blog is independent and not affiliated with Uniswap or Uniswap Labs.

v1 and v2: the constant-product foundation

The early versions used a simple constant-product formula, often written as x times y equals k. The pool multiplies its two token balances together, and that product must stay the same after each trade. This produces a smooth price curve that always quotes some price, no matter how large or small the order.

A defining trait of this design is that liquidity is spread evenly across every possible price, from zero to infinity. The pool is always ready to trade at any price, but most of the deposited tokens sit at prices far from where trading actually happens, so they rarely get used.

Version 2 kept this curve and added several building blocks. It allowed pools to pair any two ERC-20 tokens directly, instead of routing everything through ETH. It introduced on-chain price oracles using a time-weighted average price (TWAP), so other contracts could read a manipulation-resistant price history. And it added flash swaps, which let a contract borrow tokens from a pool within a single transaction as long as the pool is made whole before that transaction ends.

v3: concentrated liquidity

Version 3 changed how liquidity is placed. Instead of spreading deposits across all prices, a liquidity provider (LP) can choose a specific price range to concentrate their tokens in. Within that band, the pool behaves as if it held far more liquidity, which can mean lower slippage for trades that happen inside the range.

This is the idea behind the phrase capital efficiency. As a design property, it means the protocol can offer deeper liquidity around the active price using fewer total tokens, because those tokens are not stretched thinly across prices nobody is trading at. It is a statement about how the contract organizes liquidity, not a promise of any outcome for a participant.

Version 3 also introduced multiple fee tiers, so different pools for the same pair could charge different swap fees suited to how volatile the pair tends to be. Because every LP can now pick a different range, positions are no longer interchangeable. They are represented as non-fungible tokens (NFTs) rather than the simple fungible LP tokens of v2.

The trade-off is real. If the market price moves outside an LP's chosen range, that position stops being used for trades and collects no fees until the price returns or the LP adjusts the range. This makes v3 a more hands-on design that often calls for active monitoring, and it interacts with risks such as impermanent loss. The piece on the risks of providing liquidity covers those in detail.

v4: singletons, hooks, and flash accounting

Version 4 keeps concentrated liquidity but reworks the plumbing underneath. Earlier versions deployed a separate contract for every pool. v4 uses a singleton architecture, where all pools live inside one contract. This can reduce the gas cost of creating pools and of routing trades that hop across several pools.

The headline addition is hooks: optional plug-in contracts that a pool can attach to run custom code at defined moments, such as before or after a swap, or when liquidity is added or removed. Conceptually, hooks let pool creators customize behavior, for example experimenting with dynamic fees, custom oracles, or limit-order-style logic. This flexibility is a tool, not an endorsement of any specific use, and a hook is only as trustworthy as the code behind it.

v4 also uses flash accounting, which tracks the net balances owed during a transaction and settles only the final differences at the end rather than moving tokens at every step. Combined with the singleton design, this is meant to make multi-step interactions cheaper to execute.

How to think about the progression

Each version trades simplicity for capability. v2 is the easiest to reason about and places liquidity passively. v3 reorganizes liquidity for efficiency but asks more attention from LPs and makes positions unique. v4 adds a flexible foundation that other developers can build on, which broadens what pools can do while also widening the surface where bugs or untrustworthy hook code could appear. More power and more efficiency arrive together with more complexity and, from v3 onward, more active management and risk.

Key takeaways

• v1/v2 use a constant-product pool with liquidity spread across all prices; v2 added arbitrary ERC-20 pairs, TWAP oracles, and flash swaps.
• v3 introduced concentrated liquidity, multiple fee tiers, and NFT-based positions, in exchange for more active management.
• v4 adds a singleton contract, customizable hooks, and flash accounting, mainly to cut gas and enable custom pool logic.
• Capital efficiency describes how a protocol organizes liquidity, not an outcome for any participant.
• Greater capability consistently comes with greater complexity and, for v3 and v4, more responsibility and risk.

If "concentrated liquidity" is new, revisit liquidity pools and the risks of providing liquidity.