AMM Liquidity Pool Mechanics: What Protocol Builders Need to Know

AMM liquidity pools provide on-chain liquidity for swaps, liquidations, yield routing, and treasury management. Protocol integrations need to account for pricing, fees, slippage, and the ways pool reserves can be manipulated.

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

A reserve-ratio spot price can be manipulated within a transaction. Evaluate a time-weighted price or another suitable oracle, then test its liquidity, update frequency, staleness controls, and manipulation cost against the value at risk.

Integration Patterns for Protocol Builders

Swapping from within a smart contract: Set a meaningful amountOutMin and a caller-supplied deadline. A deadline derived from block.timestamp during execution does not limit time spent waiting to execute. In Uniswap V2’s router, a zero deadline is already expired and reverts. An amountOutMin of zero provides no minimum-output protection.

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.

---

Review slippage limits, deadlines, oracle selection, and pool depth before relying on an AMM for protocol operations. Discuss an AMM integration with LinkIT.