Blockchain and Web3 Development: DeFi and Tokenomics - Automated Market Makers, Uniswap V2/V3, Constant Product Formula

Study Guide – Automated Market Makers (Uniswap V2/V3, Constant Product Formula)

What This Is

An Automated Market Maker (AMM) is a smart?contract?based liquidity pool that replaces order?books with a simple math rule—most famously the constant?product formula?x?*?y?=?k. Anyone can deposit two tokens, and traders can swap against the pool instantly, without needing a counter?party. The first real?world proof?of?concept is Uniswap, where a user swaps 1?ETH for ~2,500?USDC in a single transaction, and the price automatically adjusts according to the pool’s balances.

Key Terms & Code Snippets

• AMM (x·y?=?k) – The core invariant: the product of the two token reserves (x and y) stays constant (k). When you add one token, the other must be removed to keep k unchanged.
• Liquidity Provider (LP) – An address that deposits equal?value amounts of two ERC?20 tokens into a pool and receives LP tokens representing its share.
• LP Token (ERC?20) – A receipt minted by the pool contract; holders can later redeem it for the underlying assets plus accrued fees.
• Swap Fee (e.g., 0.30?%) – A small percentage taken from each trade and credited to LPs; in Uniswap?V3 the fee tier is selectable per pool.
• Tick & Price Range (V3) – V3 lets LPs concentrate liquidity in a custom price interval (tickLower?/?tickUpper), dramatically improving capital efficiency.
• getAmountOut (Solidity) – Helper that applies the constant?product formula and fee to compute how many output tokens a swap will return.

solidity function getAmountOut(uint amountIn, uint reserveIn, uint reserveOut) internal pure returns (uint) { uint amountInWithFee = amountIn * 997; // 0.30% fee-1000?3 uint numerator = amountInWithFee * reserveOut; uint denominator = reserveIn * 1000 + amountInWithFee; return numerator / denominator; }

• swap (V2 Router) – The external function a dApp calls to trade tokens; it pulls the input token, runs the invariant check, and sends the output token.

js const tx = await router.swapExactTokensForTokens( ethers.utils.parseUnits('1.0', 18), // amountIn 0, // amountOutMin (slippage) [tokenA.address, tokenB.address], // path wallet.address, // to Math.floor(Date.now() / 1000) + 60 // deadline );

• sqrtPriceX96 (V3) – Fixed?point Q64.96 representation of the current price; used for precise math without floating?point errors.
• feeGrowthGlobalX128 – Tracks cumulative fees per unit of liquidity; LPs claim fees by comparing the current value with the snapshot taken when they minted LP tokens.
• delegatecall vs call – V3 pools use delegatecall to execute user?provided hooks (e.g., flash swaps) while preserving the pool’s storage context.

Step?by?Step / Process Flow

1. Write the Pool Contract – Clone the Uniswap V2 core repo or use the V3 periphery library. In Remix, add UniswapV2Pair.sol (or UniswapV3Pool.sol) and import OpenZeppelin’s ERC?20.
2. Compile with Hardhat – Run npx hardhat compile using Solidity?0.8.19 (the version Uniswap V3 ships with).
3. Deploy to a Testnet –

bash npx hardhat run scripts/deploy.js --network goerli

The script should:
- Deploy the factory (UniswapV2Factory or UniswapV3Factory).
- Call createPair(tokenA, tokenB) (V2) or createPool(tokenA, tokenB, fee) (V3).

4. Add Liquidity – Using Ethers.js, approve both tokens, then call addLiquidity (V2) or mint (V3) with the desired price range.

5. Swap via Router – In your front?end, instantiate UniswapV2Router02 (or V3 router) and invoke swapExactTokensForTokens. Verify the output amount matches the getAmountOut calculation.

Common Mistakes

• Mistake: Supplying unequal token values when creating a V2 pair.
  Correction: Always deposit tokens with the same USD value; otherwise the pool starts with a skewed price and LPs lose capital.

• Mistake: Forgetting to approve the router contract before calling swap.
  Correction: Call token.approve(router.address, amount) first; otherwise the transaction reverts with “ERC20: transfer amount exceeds allowance”.

• Mistake: Using tx.origin for access control in a flash?swap callback.
  Correction: Use msg.sender (or a role?based onlyOwner) because tx.origin can be spoofed through a malicious contract, opening a re?entrancy vector.

• Mistake: Ignoring the price?range parameter in V3 and depositing liquidity across the entire curve.
  Correction: Choose a tight tick range around the current price to earn higher fees per capital; otherwise you earn the same as V2 but pay higher gas.

• Mistake: Relying on block.timestamp for deadline checks in the router.
  Correction: Use a reasonable buffer (e.g., now + 300) and enforce a maximum slippage; miners can manipulate timestamps by up to ~15?seconds.

Blockchain Developer Interview / Practical Insights

1. “Explain why an AMM can’t guarantee a specific price.” – Interviewers expect you to mention the invariant (x·y?=?k) and that price is derived from pool balances, which shift with each trade.
2. “Differentiate Uniswap V2’s constant?product from V3’s concentrated liquidity.” – Highlight that V2 uses a single global k, while V3 splits liquidity into ticks allowing LPs to allocate capital where they expect most trades.
3. “What are the gas?implications of using delegatecall in a V3 pool?” – Show you know that delegatecall preserves storage but adds ~10?k gas overhead; it’s acceptable for flash?swap hooks but should be minimized.
4. “How would you audit the fee?distribution logic?” – Mention checking feeGrowthGlobalX128 updates, ensuring LPs can’t claim more than their share, and verifying that rounding errors are handled with uint128 arithmetic.

Quick Check Questions

1. Scenario: A contract calls router.swapExactETHForTokens but sets amountOutMin = 0.
   Answer: This opens a front?running risk; the attacker can push the price just before the swap, causing the user to receive far fewer tokens. Always set a realistic amountOutMin based on slippage tolerance.

2. Scenario: An LP adds liquidity to a V3 pool with tickLower = -887272 and tickUpper = 887272.
   Answer: That’s the full?range (same as V2) and defeats V3’s capital efficiency; the LP will earn lower fees per capital compared to a concentrated range.

3. Scenario: A developer uses require(reserve0 > 0 && reserve1 > 0) inside the swap function.
   Answer: The check is unnecessary because the invariant already prevents division?by?zero; it adds extra gas and can block legitimate first?swap initialization.

Last?Minute Cram Sheet (10 one?liners)

1. Never trust tx.origin for auth – it can be hijacked via a malicious contract.
2. k = reserve0 * reserve1 – the constant?product invariant; any deviation reverts the swap.
3. V2 fee = 0.30?%-multiplier 997/1000 – used in getAmountOut.
4. V3 fee tiers: 0.05?%, 0.30?%, 1?% (encoded as 500, 3000, 10000).
5. sqrtPriceX96 = price * 2^96; use FullMath.mulDiv for precise arithmetic.
6. Gas tip: Store reserves in a single uint112 slot (reserve0, reserve1) to stay under the 32?byte slot limit.
7. Compiler version: Uniswap V3 contracts compile cleanly with pragma solidity ^0.8.19;.
8. LP token decimals = 18 – matches ERC?20 standard; use balanceOf to compute share.
9. Flash swap: Call swap with amount0Out or amount1Out >?0 and implement uniswapV2Call (V2) or uniswapV3SwapCallback (V3).
10. Common attack vector: price manipulation via large single swaps; mitigate with maxSwap limits or time?weighted average price (TWAP) oracles.