Why the Router Exists

The Problem with Raw Pair Calls

You have built the core protocol. UniswapV2Pair exposes mint(), burn(), and swap(). These functions work. But they are dangerously low level.

If a user called pair.swap() directly, they would need to:

1. Calculate the exact output amount themselves, including the 0.3% fee math.
2. Transfer the input tokens to the pair address before calling swap.
3. Sort the two token addresses to figure out which is token0 and which is token1.
4. Set the correct amount0Out/amount1Out based on the swap direction.
5. Hope that no one front-runs their transaction and moves the price.

One mistake in any of these steps means lost funds. No safety net. No refund.

What the Router Does

UniswapV2Router02 is the safety layer between users and the raw pair contracts. It handles five critical things that the pair itself does not.

Slippage protection. Every Router function accepts a minimum output amount (or maximum input amount). If the price moves beyond this threshold between submission and execution, the transaction reverts. Without this, MEV bots would extract value from every swap.

Deadlines. Every Router function accepts a deadline timestamp. If the transaction sits in the mempool too long and executes after the deadline, it reverts. This prevents stale transactions from executing at unexpected prices hours or days later.

Optimal liquidity amounts. When you add liquidity, the amounts of both tokens must match the current pool ratio. If you send too much of one token, you lose value. The Router calculates the optimal amounts and validates them against your minimums.

WETH wrapping. Uniswap V2 pairs only hold ERC-20 tokens, not native ETH. The Router automatically wraps ETH into WETH before adding liquidity or swapping, and unwraps WETH back to ETH when returning funds. Users interact with ETH naturally.

Multi-hop paths. To swap ETH for DAI when there is no direct ETH/DAI pair, the Router chains hops: ETH to WETH, WETH to USDC (via the WETH/USDC pair), USDC to DAI (via the USDC/DAI pair). It calculates intermediate amounts and routes through each pair automatically.

The Library

UniswapV2Library is a Solidity library (using the library keyword) that contains the math the Router depends on. It handles token sorting, CREATE2 pair address computation, reserve fetching, and all the fee-adjusted amount calculations.

The Router calls Library functions for every operation. getAmountOut tells you how many tokens you receive for a given input. getAmountIn tells you how many tokens you need to provide for a desired output. getAmountsOut and getAmountsIn chain these calculations across multi-hop paths.

The Library is stateless. It does not store anything. It is pure math.

Why Two Contracts

The Library is separate from the Router because libraries in Solidity are deployed once and shared. Any contract can call UniswapV2Library.getAmountOut(). This includes other routers, aggregators, or any protocol that integrates with Uniswap V2. The math is public infrastructure.

The Router is the user-facing entry point. It combines Library math with token transfers, WETH wrapping, and safety checks into convenient functions that wallets and frontends call.

What You Build Next

In the following sections, you will implement:

1. UniswapV2Library: Token sorting, CREATE2 address calculation, reserve fetching, quote, getAmountOut, getAmountIn, and path chaining.
2. UniswapV2Router02 (Liquidity): addLiquidity, addLiquidityETH with optimal amount calculation.
3. UniswapV2Router02 (Remove Liquidity): removeLiquidity, removeLiquidityETH, and permit variants.
4. UniswapV2Router02 (Swapping): All swap variants for exact input, exact output, and ETH pairs.
5. UniswapV2Router02 (Fee on Transfer): Special handling for tokens that deduct fees during transfer.

By the end, you will have written every function in the complete Uniswap V2 protocol.