Uniswap V2

Uniswap V2 is the second version of the Uniswap protocol, launched in May 2020. It is a decentralized exchange protocol built around a constant-product automated market maker — every swap obeys the x * y = k invariant, and liquidity providers earn a 0.3% fee on every trade.

V2 introduced several innovations over V1: ERC-20-to-ERC-20 pairs (V1 only supported ETH-to-ERC-20), on-chain TWAP price oracles via cumulative accumulators, flash swaps as a native primitive, and a protocol fee switch (unused but available).

Architecture

Uniswap V2 is four contracts:

• UniswapV2Factory — deploys and tracks Pair contracts using CREATE2 for deterministic addresses.
• UniswapV2Pair — the AMM itself; one instance per token pair; holds reserves, mints LP tokens, executes swaps.
• UniswapV2Router — a convenience wrapper for users, handling slippage, deadlines, and multi-hop swaps.
• UniswapV2Library — pure helper functions for the math (quote, getAmountOut, getAmountIn, sortTokens).

The Pair also inherits from UniswapV2ERC20, a standard ERC-20 with EIP-2612 permit signatures that represents LP token ownership.

Why It Is the Most-Forked Contract Ever

Uniswap V2 became the canonical AMM design for two reasons: the code is small and clean (the Pair contract is ~200 lines), and the license is permissive (GPL-3.0). Within a year of V2's launch, dozens of forks deployed on other EVM chains — SushiSwap (initially a fork with added incentives), PancakeSwap (on BSC), SpookySwap (on Fantom), QuickSwap (on Polygon), Trader Joe (on Avalanche), and many more.

This is also why understanding Uniswap V2 is foundational for anyone working on DeFi. If you read code in the DEX space, you are almost always reading a descendant of V2. If you ship a DEX, you are almost certainly building on top of, or diverging from, V2's patterns.

Known Attack Surface

Uniswap V2 forks have been the source of many exploits, not because V2's original code is broken, but because forks often diverge in subtle ways:

• Fee-on-transfer tokens that deduct a cut during transfer break the Pair's balance math unless explicitly handled. Some forks ship without this handling.
• Rebasing tokens (where balances change without transfers) corrupt reserves without any visible transaction.
• Oracle manipulation via flash swaps — the spot price inside a Pair can be distorted instantly; any protocol reading the spot price (instead of the TWAP) is vulnerable.
• First-depositor inflation attack — a pool with a fresh Pair can be manipulated by donating tokens to make subsequent depositors get a tiny LP share. The original V2 mitigates this with MINIMUM_LIQUIDITY locked at 1000 wei, but many forks remove or modify this.
• Reentrancy during callback — the swap() function must use a reentrancy lock because the flash-swap callback hands control to untrusted code.

The Zealynx DeFi Security Framework includes a full Uniswap V2 security checklist derived from 300+ real audit findings across V2 forks.

Evolution: V2 → V3 → V4

Uniswap V3 (2021) introduced concentrated liquidity — LPs choose a price range, earning fees only when the price is in range. This is substantially more complex: tick math, non-fungible positions, and price-range accounting. V3 is not a simple extension of V2.

Uniswap V4 (2024+) added "hooks" — customizable plugin logic that runs before, during, and after swaps, giving pool designers programmable behavior. V4 also moved to a singleton architecture (one core contract for all pools) for gas efficiency.

V2 remains deployed, actively used, and the easiest AMM to reason about. It is the version you build from scratch first if you want to understand this class of protocol — which is why it is Zealynx Academy's first build module.