Exchange without an order book
An automated market maker uses a smart-contract liquidity pool and a pricing formula instead of a traditional order book. A buyer and seller do not need matching orders at the same moment because the trade occurs against two assets held in the pool. Automation does not guarantee a fair price or prevent loss.
Pools and pricing formulas
A common constant-product design changes the quote to preserve the product of the two reserve quantities. Buying one asset reduces its pool balance and adds the other, making each additional unit more expensive. Arbitrage trades tend to bring the pool price back toward prices in outside markets.
Price impact and slippage
A trade that is large relative to pool liquidity moves the average execution price farther from the initial quote. A wider slippage setting improves the chance of execution but permits a worse price and more exposure to transaction-ordering attacks. Evaluate size, minimum output, and network fee together.
Liquidity-provider revenue
Liquidity providers deposit both assets and receive a share of trading fees. Realized revenue depends on actual volume, pool share, selected price range, and rebalancing costs rather than the headline fee rate alone. Concentrated liquidity can stop earning fees when the market leaves the chosen range.
Risks behind the yield
A change in relative prices can leave the provider with a different result than simply holding both assets, often described as impermanent loss. Contract bugs, oracles, token design, administrator controls, and congestion add further dependencies. Only afterward is it clear whether fees compensated for those costs.
Checks before a swap
Before swapping, verify the official contract, both pool assets, total liquidity, recent volume, estimated price impact, minimum output, and approval amount. Before providing liquidity, model the asset mix and exit path under several price scenarios rather than relying on fee APR. An AMM replaces intermediary discretion with coded pool rules.