🌊 The Story of Uniswap V1 Architecture

Uniswap V1 was like the “baby AMM,” the original proof-of-concept that showed automated liquidity pools on Ethereum could really work. At its heart, the architecture is built around three types of contracts:

Factory Contract

This is the “government registry” — it creates new exchanges and keeps track of which exchange belongs to which token. Only one exchange per token is ever allowed so liquidity doesn’t fragment more than it already does. Think of it like the registrar’s office stamping an official license saying, “TokenX now has an exchange at address Y.”

Exchange Contract (per token)

This is where the magic happens. Each ERC‑20 token has its own exchange contract that pairs it only with ETH. The exchange has all the functions to:

ERC‑20 LP Token Contract

When you add liquidity, you get back an ERC‑20 representing your share of the pool. In V1 these LP tokens weren’t widely transferable—more like receipts than tradable assets, meant to record ownership and later burn on withdrawal.


⚙️ Interaction Flow: How People Used It

If you were using V1 as a trader or developer, here’s what happened step by step:

  1. Check if a pool exists: You ask the Factory if there’s already an exchange for your token. If not, you create one.
  2. Add liquidity: You deposit ETH and tokens in equal value amounts. The exchange returns LP tokens to mark your share.
  3. Do a swap: You can do ETH → Token or Token → ETH. If you want Token A → Token B (say DAI → USDC), you’re stuck making two hops through ETH. First swap Token A → ETH, then ETH → Token B. Double fees, double slippage.
  4. Remove liquidity: You give the LP tokens back, the contract burns them, and you get your proportional share of both ETH and the other token, plus your cut of the fees.