Uniswap v2, v3, and v4

Uniswap’s versions are easy to flatten into “v4 is newer, so it replaces v3.” The docs do not say that. v2 pairs, v3 pools, and v4 pools are different contracts, and the interface described in the January 2025 launch post can route across them. This guide is about what an integrator has to stop assuming when the version changes. The Uniswap overview explains a single swap.

Liquidity, and the claim that represents it

v2 liquidity is uniform. The LP token is an ERC-20 claim on a share of both reserves. Any two holders of the same pair token are in the same position, scaled by balance. Fees stay in the reserves and raise the value of that token. There is no range to manage and no NFT to transfer.

v3 liquidity is a choice of range. The concentrated-liquidity documentation and the v3 whitepaper define the range by ticks of 1.0001^i. A position earns fees only inside its ticks. The claim is an ERC-721 from NonfungiblePositionManager, because two ranges are not fungible. Fees are collected to the position. They do not rebase the NFT’s token id.

v4, the current overview says, keeps concentrated liquidity and changes the receipt again. Positions are managed by PositionManager with ERC-6909 accounting inside one contract, not by a v3-style NFT per position. Code that transfers a v3 position token by ERC-721 safeTransferFrom is not a v4 migration.

Nothing in these docs converts a v2 LP token into a v3 NFT or a v4 position. Migration is a withdraw and a new deposit, and the v4 deposit may include a hook address in the pool key.

Settlement

v2’s pair looks at token balances. The factory documentation’s model is: transfer tokens to the pair, then call the method. The pair’s stored reserves are compared with its actual balances. Flash swaps are the exception the flash-swap guide describes: tokens leave first, and the callback must return enough that the product still holds after the 0.30 percent fee.

v3 pulls payment. The swap guide says the pool calls uniswapV3SwapCallback and enforces sqrtPriceLimitX96. The caller learns what it owes during the swap. A router that still “transfers first” as if it were a v2 pair is using the wrong sequence.

v4 batches payment. The architecture page says PoolManager records deltas and settles when the unlock finishes, so a route through several pools does not transfer the intermediate asset. The swap guide names unlock and final balance settlement as the v4 path, with hooks able to run before and after. Flash accounting is an optimization of settlement. It is not a change to the concentrated-liquidity curve inside a tick range.

Fees and pool identity

v2’s documented pool fee is 0.30 percent, the 997/1000 factor in the flash-swap guide. A pair is identified by its two tokens. The factory will not deploy a second pair for the same two tokens.

v3 pools are identified by the two tokens and a fee tier. The whitepaper connects fee tier to tick spacing: a lower fee can use a tighter grid. The same token pair can have several pools. A router picks among them.

v4 identifies a pool by a key that includes the hook. The hooks page says the hook is fixed at initialize. Two pools with the same tokens and fee and different hooks are different pools. A hookless v4 pool is the concentrated-liquidity case. A hooked pool is that case plus whatever the hook is allowed to do. The permission flags are part of the design: a hook cannot silently gain a callback it did not declare.

Protocol fee is a separate switch. The overview says governance can enable it within limits. It is not the LP fee, and it is not automatically on because a version number increased.

What v4 does not discard

The constant-product relationship still prices an active range. Price impact still grows as a trade consumes in-range liquidity. Out-of-range positions still hold one asset and earn no fees. User-level limits — minimum output, maximum input, deadline — are still router concerns, as the swap guide describes them for integrations generally.

The core contracts remain, in Uniswap’s wording, non-upgradeable. A hook can be written by anyone and can itself be a proxy. That is a new place for upgrade risk, at the edge of a pool, not a reversal of the core-immutability claim.

A practical reading of “which version”

If a transaction trace shows a pair contract and a fungible LP token, it is v2 even if the user’s interface says Uniswap. If it shows NonfungiblePositionManager, it is v3. If it shows PoolManager and a hook address of zero or non-zero, it is v4. The composability article is about why those traces get mixed inside one router call.

Version status