AMM Architectures: How DEXs Actually Work

How DEXs Actually Work

From Order Books to Automated Market Makers

Traditional exchanges use order books. Buyers place bids, sellers place asks, and a matching engine pairs them up. This works for liquid markets, but on a blockchain every order is a transaction with gas costs, block time delays, and terrible UX for market makers updating quotes constantly.

Automated Market Makers throw out the order book entirely. An AMM holds reserves of two tokens in a smart contract. Anyone can trade against those reserves at a price determined by a mathematical formula. No order book. No matching engine. Just math.

Three Fundamental AMM Architectures

Every DEX you will encounter falls into one of three fundamental categories. The math you choose defines the protocol.

1. Constant Function AMM (Uniswap V2 style)

The simplest and most widely forked. Uses the constant product formula:

x * y = k

Where x and y are token reserves and k stays constant after each trade. Price is derived from the ratio of reserves. Liquidity is spread across the entire price range (0 to infinity), which means capital efficiency is low but the design is simple and battle-tested.

Reference protocol: Uniswap V2 (Factory + Pair + Router, 3 contracts).

2. Concentrated Liquidity Manager (Uniswap V3 style)

Instead of spreading liquidity across all prices, LPs choose a price range. This concentrates capital where trading actually happens, dramatically improving capital efficiency (up to 4000x). The tradeoff: positions become NFTs (not fungible LP tokens), the math is more complex (tick-based), and LPs need active management.

Reference protocol: Uniswap V3 / Beefy CLM (Pool + TickMath + PositionManager + Oracle, 5+ contracts).

3. Temporal Function AMM (QuantAMM style)

Dynamic pool weights that adjust over time based on temporal functions. Instead of fixed 50/50 weights, the pool automatically rebalances using momentum, mean reversion, or other strategies. Supports 8+ tokens per pool. The most complex but also the most adaptive.

Reference protocol: QuantAMM (Pool + WeightStorage + TemporalOracle, 4+ contracts).

Why Math Choice = Protocol Identity

The invariant function is not just an implementation detail. It determines everything about your DEX:

• How liquidity providers earn fees
• How price impact scales with trade size
• What tokens your DEX handles well (correlated vs uncorrelated)
• Your attack surface (each invariant has unique vulnerability classes)

In this module, you will build one of these architectures from scratch, understanding every line of code and every design decision.