Uniswap Clone Guide: What to Copy From Uniswap v2, v3 and v4

A Uniswap clone is a decentralized exchange built from Uniswap's open contracts or from a close copy of their design. This guide explains how each Uniswap version works, which license applies to each, what a Uniswap clone script contains, and the steps to launch one.

Version 3 made liquidity more capital-efficient, and version 4 made pools cheaper to create and easier to extend. A team that knows why v2, v3 and v4 differ can choose the design its own exchange needs. Many near-copies of Uniswap launched, and most have closed. The forks that still operate either serve a market Uniswap did not serve or change one mechanism.

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 stay the same or grow after each trade. Fees make the product grow a little with each trade.

When a trader adds token X to the pool, the contract calculates how much token Y it can release while the product stays the same. The price is the ratio of the two reserves and moves along a curve, so each larger trade gets a worse average price. This price change is called slippage, and it is the main cost of trading against a passive pool.

A v2 deployment has four main parts:

• Factory. The factory deploys one pair contract for each token pair, at an address anyone can compute in advance.
• Pair. The pair contract holds the reserves and mints and burns ERC-20 LP tokens, each of which stands for a share of the pool. A low-level swap function also supports flash swaps, where a user receives tokens first and pays for them later in the same transaction.
• Router. The router is a periphery contract for trades through several pools, and it checks deadlines and minimum outputs, which protects users from front-running and old quotes.
• Price oracle. Each pair stores cumulative prices, which other contracts use to compute a time-weighted average price (TWAP). An attacker would need to hold a false price across many blocks to move a TWAP, which is expensive.

The v2 core contracts are small and permissionless, and they have stayed in use for years. The downside of v2 is low capital efficiency: liquidity covers every price from zero to infinity, so most of it is never used.

Uniswap v3: concentrated liquidity

In v3, each liquidity provider (LP) chooses a price range. Inside the range, the LP's capital works like a much deeper v2 pool. Outside the range, the position holds only one token and earns no fees.

The v3 pool splits the price axis into small steps called ticks and tracks which liquidity is active at the current tick. Every position has its own range, so v3 LP positions are ERC-721 NFTs rather than fungible tokens. Version 3 also added several fee tiers per pair, so stable pairs and volatile pairs can charge different fees.

Three points matter for a v3 clone:

• LP management. Concentrated liquidity gives traders better prices, but LPs must manage their ranges, and many earn less than they would by holding the two assets. The gap, called impermanent loss, grows when the range is narrow. A clone aimed at retail LPs usually needs vaults or automated range managers.
• Tick math. Rounding errors and overflow in the fixed-point libraries are a common source of bugs in forks. Any change to this code needs fuzz testing and a specialist audit.
• License. Uniswap released v3 core under the Business Source License 1.1, which switched to GPL 2.0 or later on April 1, 2023, so commercial forks are now allowed under GPL terms.

Uniswap v4: singleton pools and hooks

Uniswap v4 went live on January 31, 2025 on ten chains with two changes to the architecture.

First, every pool lives inside one PoolManager contract instead of one contract per pair. This design makes new pools and trades through several pools much cheaper. The PoolManager uses "flash accounting": it records every balance change during a transaction and moves only the net amounts at the end, relying on transient storage from EIP-1153.

Second, each pool can attach a hooks contract. A hook runs custom code before and after pool creation, liquidity changes, swaps and donations. Hooks allow dynamic fees, onchain limit orders, orders spread over time, custom oracles, pools limited to verified users and MEV redistribution. None of these features needs a fork of the core. The v4 developer documentation explains the permission flags that are encoded in a hook's address.

With hooks, a clone is no longer the only way to get custom pool logic, because a team can often write a hook and use Uniswap's liquidity and integrations instead of deploying its own AMM. A faulty hook can harm every LP in its pool, so a hook that changes swap amounts needs the same audit as a full protocol.

Uniswap v2, v3 and v4 compared

What a Uniswap clone script includes

A Uniswap clone script is a ready-made package that vendors sell or publish. It usually contains a fork of the v2 or v3 contracts with a new name, a copy of the swap front end, and deployment scripts for a chosen chain. Some packages add a farm or staking contract and an admin panel for fees.

A buyer should check four things before using a clone script:

1. Changes to the core. Compare the code with the official Uniswap repository line by line. Each changed line in the pool math needs its own audit.
2. License. v2 and v3 core are now under GPL, so the fork must also be released under GPL terms. The v4 core is under the Business Source License until June 15, 2027 at the latest, and before that date production use needs a use grant from Uniswap.
3. Admin keys. Find out which functions an owner key can call, such as fee changes or pauses, and who holds that key.
4. Front-end sources. Check that the front end loads no scripts or token lists from servers the vendor controls.

A script delivers code only, without liquidity, aggregator listings, wallet integrations or an audit.

UniswapX and the Uniswap interface

Uniswap Labs also runs UniswapX, an intent-based system in which a user signs an order and competing fillers execute it in a short Dutch auction where the price moves toward the user over time. UniswapX works more like the 1inch Fusion model than like an AMM. Trade execution now depends on routing and filler competition as well as on pool design.

Much of Uniswap's market share also comes from parts outside the contracts: its front end, its SDK, its token lists and its integration into most aggregators and wallets. A clone has none of these at launch.

How to build a Uniswap clone

1. Choose the market. Examples are a new chain without a strong DEX, a specific asset class, a new fee or reward model, or a v4 hook.
2. Choose the base. Use a v2-style design for simplicity, a v3-style design for capital efficiency, or a v4 hook to reuse Uniswap's contracts. Check the license of each version.
3. Build the periphery. This step covers the router, the quoter, multicall and an off-chain routing service for trades through several pools.
4. Index and display data. Build an indexer for pools, positions and volume, plus charts and LP dashboards that show fees and impermanent loss.
5. Test and audit. Run invariant tests and fuzz tests on the math, and get at least one independent smart contract audit before launch.
6. Bring in liquidity. Seed the first pools, set rewards with an end date, and get the exchange listed by aggregators so it receives trades.

A small team can build a v2-style fork with a polished front end in a few months. A new AMM design or a complex hook takes longer and needs more audit work. The DEX development guide covers other designs, and the PancakeSwap clone guide covers the BNB Smart Chain version of the same design.

Frequently asked questions