Building a Decentralized Exchange Like Uniswap: What to Learn From v2, v3 and v4

Uniswap is worth studying not because you should clone it, but because each of its versions solved a specific problem in automated market making. If you understand why v2, v3 and v4 differ, you will know which design your own exchange needs and where the real engineering effort goes.

Many near-copies of Uniswap launched and most are gone. The survivors found a market Uniswap did not serve or improved a specific mechanic.

Uniswap v2: the constant-product pool

A v2 pool holds two tokens and enforces one rule: the product of the two reserves, x · y = k, must not decrease after a trade (fees make it grow slightly). If you add token X to the pool, the contract calculates how much Y it can release while keeping the product intact. Price is simply the ratio of reserves, and it moves along a curve, so larger trades get progressively worse prices. That is slippage, and it is the core cost of trading against a passive pool.

The key pieces:

• Factory deploys one pair contract per token pair, at a deterministic address.
• Pair holds reserves, mints and burns LP tokens (ERC-20) representing a share of the pool, and exposes a low-level swap function that also supports flash swaps.
• Router is a periphery contract that handles multi-hop paths, deadlines and minimum-output checks so users are protected from front-running and stale quotes.
• Price oracle: each pair stores cumulative prices so other contracts can compute a time-weighted average price (TWAP) that is expensive to manipulate within a single block.

The lesson from v2 is simplicity. The core contracts are small, permissionless, and have held up for years. The cost is capital inefficiency: liquidity is spread across every price from zero to infinity, so most of it sits idle.

Uniswap v3: concentrated liquidity

v3 lets liquidity providers choose a price range. Inside that range, their capital behaves like a much deeper v2 pool; outside it, their position is entirely one token and earns nothing. The price axis is divided into discrete ticks, and the pool tracks which liquidity is active at the current tick. Because every position is different, LP shares became ERC-721 NFTs rather than fungible tokens. v3 also introduced multiple fee tiers per pair, so stable pairs and volatile pairs can price risk differently.

What to learn here:

• Concentrated liquidity improves prices for traders but turns LPing into active management. Many LPs underperform simply holding the assets, because impermanent loss is magnified inside narrow ranges. If you target retail LPs, you will probably need vaults or automated range managers on top.
• The tick math is subtle. Rounding errors and overflow in fixed-point libraries are where forks introduce bugs. Do not hand-edit this code without fuzzing and a specialized audit.
• v3 was released under the Business Source License, which delayed commercial forks until it converted to GPL. Always check the license on any version you plan to reuse.

Uniswap v4: singleton pools and hooks

v4, which went live in early 2025, made two architectural changes. First, all pools live inside a single PoolManager contract rather than one contract per pair, which makes creating pools and routing through several of them far cheaper. It uses "flash accounting": within one transaction, balances are tracked as deltas and only net amounts are settled at the end, relying on transient storage introduced in EIP-1153.

Second, each pool can attach a hooks contract that runs custom code at defined points: before and after initialize, add or remove liquidity, swap and donate. Hooks enable dynamic fees, on-chain limit orders, TWAMM-style orders spread over time, custom oracles, KYC-gated pools and MEV redistribution, without forking the core. The official v4 documentation describes the permission flags encoded into a hook's address.

For builders, this changes the build-vs-fork decision. Instead of deploying your own AMM, you can often write a hook and inherit Uniswap's liquidity and integrations. The flip side: a buggy hook can hurt every LP in its pool, and hooks that can modify swap deltas deserve the same audit scrutiny as a full protocol.

Comparing the three designs

Beyond the AMM: UniswapX and the interface

Uniswap the company also runs UniswapX, an intent-based system where users sign an order and competing fillers execute it, with the price decaying over a short Dutch auction. It is closer to how 1inch Fusion works than to an AMM. The lesson is that execution quality increasingly comes from routing and solver competition, not just from pool design.

Much of Uniswap's position also comes from outside the contracts: its front end, SDK, token lists and integration into every aggregator and wallet. A fork ships none of that.

What it takes to build one

1. Pick your differentiator. A new chain without a strong DEX, a specific asset class, a fee or incentive model, or a v4 hook. "Uniswap but ours" is not a strategy.
2. Choose the base. v2-style for simplicity, v3-style for capital efficiency, or a v4 hook to reuse existing infrastructure. Check licenses.
3. Build the periphery. Router, quoter, multicall, and an off-chain routing service for multi-hop paths.
4. Index and display. An indexer for pools, positions and volume; charts; LP dashboards that show fees and impermanent loss honestly.
5. Security. Invariant tests, fuzzing on the math, and at least one independent smart contract audit before launch.
6. Bootstrap liquidity. Seed pools, design incentives with a sunset, and get listed by aggregators so you receive order flow.

A straightforward v2-style fork with a polished front end can be built in a couple of months by a small team; a novel AMM or a complex hook is a longer, audit-heavy project. For other ways to structure the build, see the broader decentralized exchange development guide and the PancakeSwap-style DEX walkthrough, which covers the BNB Smart Chain variant of the same design.

Frequently asked questions