WritingAMM Liquidity Pool Mechanics: What Protocol Builders Need to Know — Clixo
6 min readamm, liquidity-pools, defi, protocol-design, beginner

AMM Liquidity Pool Mechanics: What Protocol Builders Need to Know

An introduction to AMM liquidity pool mechanics for DeFi protocol builders — how pools price assets, how LPs earn fees, and how to integrate pools safely into your protocol.

If you are building a DeFi protocol that needs to access on-chain liquidity — whether for swaps, liquidations, yield routing, or treasury management — you need to understand how AMM liquidity pools actually work at a mechanical level. "There's a pool, send tokens, get tokens back" is not enough to build on safely. This guide covers what protocol engineers need to know before integrating or building on top of AMM liquidity pools.

What an AMM Liquidity Pool Is

An AMM (Automated Market Maker) liquidity pool is a smart contract that holds two or more tokens and allows anyone to swap between them without a counterparty. Instead of matching buyers and sellers, the pool itself acts as the counterparty using a pricing formula. The most common formula — used by Uniswap V2 and many others — is the constant product invariant: the product of the two token reserves must remain constant after every trade.

The pool contract does three things:

  1. Accepts liquidity deposits from LPs and issues share tokens representing their ownership
  2. Executes swaps according to the pricing formula, collecting a fee on each swap
  3. Returns underlying tokens plus accumulated fees when LPs redeem their shares

There is no order book, no bid-ask spread negotiation, and no privileged market maker. The code runs autonomously.

How AMM Liquidity Pool Pricing Works

The spot price of token A in terms of token B is simply the ratio of their reserves:

price_A = reserve_B / reserve_A

When a swap occurs, the trader sends in token A and receives token B. The contract calculates how much token B to release by preserving the invariant. After the swap, reserve_A is larger and reserve_B is smaller, so the price of token A has fallen and the price of token B has risen.

This means that every trade slightly moves the price. The larger the trade relative to the pool's reserves, the more the price moves. This price movement is called slippage, and it is the primary cost of trading in illiquid pools.

For protocol builders, this has two consequences:

  • When your contract initiates a swap, always set a minimum output (slippage tolerance) to protect against sandwich attacks
  • Never use the pool's current spot price as an oracle — it can be manipulated within a single block to any value

How Liquidity Providers Earn in AMM Pools

Every swap charges a fee, typically 0.3% of the input amount. This fee is not sent anywhere — it stays in the pool, slightly increasing the reserves. Over time, the total pool value grows. When an LP redeems their shares, they receive a proportional share of a larger pool than they deposited into, and the difference is their fee income.

The fee income per LP is proportional to their share of the pool and the trading volume through the pool. An LP with 10% of pool shares earns 10% of all fees generated.

The complication is impermanent loss: when the price ratio between the two tokens changes, the LP's position at redemption time is worth less than if they had simply held the tokens outside the pool. Impermanent loss and fee revenue work in opposite directions — LPs are profitable when fees exceed accumulated IL.

Reserve Manipulation and Flash Loan Considerations

A flash loan allows an attacker to borrow an arbitrarily large amount of tokens within a single transaction, use them, and repay them before the transaction ends. Combined with AMM swaps, this enables:

  • Temporary reserve manipulation to shift the spot price
  • Liquidation attacks on lending protocols that use AMM spot prices as oracles
  • Arbitrage between pools that have drifted from each other

If your protocol reads an AMM reserve ratio at any point to compute a price or make a decision, that reading can be manipulated in the same transaction that calls your contract. The defense is always to use a TWAP — a time-weighted average over multiple blocks — rather than the current spot price.

Integration Patterns for Protocol Builders

Swapping from within a smart contract: Most AMM routers accept a deadline parameter (a block timestamp) and a amountOutMin (minimum acceptable output). Always pass realistic values for both. A deadline of block.timestamp or zero is effectively no deadline protection. An amountOutMin of zero provides no slippage protection at all.

Multi-hop swaps: Some trades require routing through multiple pools (e.g., tokenA → ETH → tokenB). Each hop adds slippage and gas. Router contracts handle this automatically, but your contract needs to account for the cumulative worst-case slippage across all hops when setting amountOutMin.

Reading pool state: If you need to read pool reserves for any computation (not price feeds, but for understanding pool composition), use the pool's getReserves() function rather than reading storage slots directly. getReserves() returns the last-updated values, which on Uniswap V2 update at the end of each transaction. Be aware that these values are still manipulable within the same transaction block by the same caller.

Liquidity provision: When your protocol adds liquidity to an external AMM pool as part of treasury management or bootstrapping, be aware that the pool will execute an on-chain ratio check. If you deposit in a ratio different from the current pool ratio, the excess tokens are refunded. Calculate the required ratio from current reserves before constructing the deposit transaction.

Pool Depth as a Security Parameter

When assessing the security of any protocol interaction with an AMM pool, pool depth (total reserve value) is a key variable. Thin pools are cheap to manipulate; deep pools are expensive.

A useful rule: for any pool you use as a price source or liquidation venue, the depth should be large relative to the maximum position size in your protocol. If your lending protocol allows positions that dwarf the pool's reserves, a sophisticated attacker can manipulate the pool price to trigger favorable liquidations.


AMM integration looks straightforward until the first incident. The details — slippage protection, deadline enforcement, oracle selection, reserve manipulation awareness — are where protocols get hurt. If you are building a protocol that depends on on-chain liquidity and want engineering review of your AMM integration, talk to Clixo.