What is an Automated Market Maker?

Introduction

Automated market maker is the name for a way to run a market with smart contracts instead of a traditional order book. The puzzle it solves is simple to state and surprisingly hard to solve on a blockchain: if you want people to swap tokens onchain at any time, who is standing there ready to take the other side of the trade?

In traditional markets, that job is done by market makers posting bids and asks on an order book. Onchain, that model works too, but it is expensive and awkward because every order placement, cancellation, and update competes for blockspace. An AMM takes a different route. Instead of asking traders to find each other, it lets them trade against a pool of assets whose price is determined by a rule embedded in code.

That is the idea that makes AMMs click: an AMM is not primarily “automation” in the general sense; it is a machine for turning pool balances into executable prices. Once you see that, most of the rest follows. Slippage happens because the rule changes price as balances change. Liquidity provision exists because someone must supply the balances the rule reads from. Arbitrage matters because outside markets keep moving, while the pool only updates when someone trades against it.

The most influential AMMs in DeFi are a special class called constant function market makers, or CFMMs. Uniswap’s early versions are the canonical example, using the constant-product rule often written as x * y = k, where x and y are the pool’s token reserves and k is the invariant the pool tries to preserve during swaps. But that is only the simplest member of a wider family. Stablecoin-focused designs like Curve use different invariants to reduce slippage near a peg, and newer designs such as Uniswap v3 and v4 change how liquidity is allocated and how pool behavior can be customized.

To understand AMMs well, it helps to start from first principles rather than protocol branding. What problem is the market solving? What state does it keep? What does a trade do to that state? And why do those mechanics create both usefulness and risk?

How does an AMM let traders swap against a liquidity pool instead of counterparties?

An AMM replaces bilateral matching with a standing pool of reserves. Imagine a pool that holds ETH and USDC. A trader who wants USDC sends ETH to the pool and receives USDC back. A trader who wants ETH does the reverse. The pool is always available as a counterparty, as long as it has enough reserves and the smart contract accepts the trade under its pricing rule.

This is a deep change in market structure. In an order book, price comes from the set of outstanding limit orders. In an AMM, price comes from the current reserves plus the trading function. The reserve state is the market. If the pool has relatively more ETH and less USDC than before, the quoted exchange rate shifts accordingly.

That is why AMMs are often described as using a bonding curve or invariant. The exact formula differs by design, but the mechanism is the same: the contract permits trades only if the post-trade state still satisfies a rule. In the constant-product case, the rule is that the product of reserves should not decrease. This gives the market a deterministic way to quote increasingly worse prices as a trader pushes the pool further from its starting balance.

The appeal onchain is straightforward. A smart contract can always evaluate a formula. It does not need a centralized operator to continuously refresh quotes. It does not need a specific market maker logged in and actively managing orders. And anyone with the required tokens can usually become a liquidity provider by depositing into the pool and sharing in trading fees.

That permissionless quality is a major reason AMMs became foundational to DeFi. They turned market making from a specialist activity into a pool-based protocol primitive that wallets, apps, and other contracts could call directly.

How does a constant‑product AMM (x * y = k) price trades?

The canonical starting point is the constant-product AMM used by Uniswap v1 and v2. Suppose a pool holds x units of token A and y units of token B. The trading rule is that the pool should preserve the invariant x * y = k, where k is a constant absent fees and liquidity changes.

Here is the intuition before the notation does any work. If a trader adds more of token A to the pool and removes some token B, then x rises and y must fall in a way that keeps the product roughly unchanged. Because the trader is removing token B from a smaller and smaller reserve as the trade continues, each additional unit gets more expensive. That is the built-in source of slippage.

A worked example makes this concrete. Imagine a pool begins with 10 ETH and 20,000 USDC. At that moment, the reserve ratio suggests a price near 2,000 USDC per ETH. But that is only the current marginal price for a very small trade. If a trader sends in enough USDC to buy a noticeable amount of ETH, the pool’s balances change during the trade. The ETH side becomes scarcer inside the pool, and the quoted price rises against the trader step by step. The average execution price is therefore worse than the starting spot price.

This is not a bug. It is the mechanism that protects the pool from being emptied at a stale price. An AMM cannot promise infinite quantity at one fixed quote unless it has some external balance sheet willing to absorb the risk. Instead, it offers a schedule: small trades get prices close to the current ratio, while larger trades move the pool further and pay more for doing so.

Fees are usually added on top. In Uniswap v2, trades normally pay 0.30%, with a possible protocol fee switch that can redirect part of that fee. Economically, fees do two things at once. They compensate liquidity providers for supplying inventory, and they make it a little harder for tiny arbitrage trades to churn the pool constantly.

Why do arbitrageurs adjust AMM prices to match external markets?

A common first misunderstanding is to think the AMM itself “knows” the fair market price. It does not. It only knows its own reserves and its own rule.

If ETH suddenly rises everywhere else but the ETH/USDC pool has not yet been traded, the pool is now stale. It is still willing to sell ETH too cheaply relative to outside markets. Arbitrageurs step in, buy underpriced ETH from the pool, and often sell it elsewhere for a profit. Their trading continues until the AMM’s price is pushed into line with the broader market.

This may sound parasitic, but it is actually structural. Arbitrage is the mechanism that keeps AMMs connected to external reality. Without it, pools would drift away from the rest of the market and become useless as trading venues.

Research on CFMMs formalizes this more generally. A wide family of AMMs can be described by a trading function over reserves, and under mild assumptions arbitrageurs are incentivized to move the pool toward externally consistent prices. In that sense, AMM prices are not discovered internally the way an order book aggregates many standing opinions. They are often pulled into alignment by traders reacting to external prices.

This is also why using an AMM’s instantaneous spot price as an oracle can be dangerous. Spot price is cheap to manipulate for a single block if the pool is thin enough or the payoff from manipulation is large enough. Protocols therefore often prefer time-weighted average prices, or TWAPs, derived from cumulative pool observations over time. Uniswap v2 accumulated block-start prices so external callers could compute TWAPs, and Uniswap v3 moved historical observations further into the core design, adding more onchain checkpoints and a geometric TWAP construction.

The general lesson is simple: AMMs can be a data source, but a live trading price and a robust oracle are not the same thing.

What do liquidity providers supply and how does that create LP risk?

The reserves inside an AMM do not appear by magic. They are supplied by liquidity providers, or LPs, who deposit tokens into the pool in return for a claim on fees and the pool’s changing inventory.

This is easy to misread as passive yield. Mechanically, it is closer to outsourcing rebalancing to a formula. When you deposit both assets into a constant-product pool, you are agreeing to let the AMM continuously sell the asset that is going up and buy the asset that is going down, according to its invariant. If outside prices move, arbitrageurs trade against the pool, and the pool’s composition changes. As an LP, you end up holding a different mix than if you had simply held the two assets untouched.

That difference is the basis of impermanent loss, the classic AMM LP risk. If one asset strongly outperforms the other, the pool will tend to leave you with less of the outperforming asset than a passive hold strategy would have. The loss is called “impermanent” because if prices return to their original relative level, the difference can shrink or disappear. But if you withdraw after a divergence, the loss relative to holding is realized.

The deeper point is not the name. It is the mechanism. LPs earn fees because they are supplying inventory to traders, but they are also selling options of a kind: they are exposing themselves to being rebalanced by arbitrage when the world moves faster than the pool updates. Recent work often frames a related cost as loss-versus-rebalancing, or LVR: the adverse-selection cost LPs suffer when stale AMM prices are picked off by better-informed traders.

This is why “LP APR” can be misleading when stated without context. Fee income is only one side of the economics. The other side is how much value leaks through adverse selection and inventory rebalancing. An LP position is not just a savings account. It is an actively risk-bearing market-making position, whether the user manages it actively or not.

Which AMM bonding curve is right for different assets and use cases?

Once you understand that an AMM is a rule for converting reserves into prices, the next question is obvious: why use only one rule?

The constant-product rule is attractive because it is simple and robust. It always provides some finite quote as long as reserves remain positive. But it can be wasteful for assets that usually trade near a fixed relationship, such as stablecoins. If USDC and DAI both aim to stay near one dollar, then an AMM that spreads liquidity across a very wide price range is using capital inefficiently. Most of that curvature is protecting against moves that rarely happen.

That is the problem Curve’s StableSwap design addresses. It uses an invariant with an amplification coefficient, usually written as A, that makes the pool behave more like a constant-sum market near balance and more like a constant-product market when the pool becomes imbalanced. Near the peg, this means much lower slippage for the same capital. Far from the peg, the design becomes more defensive so the pool still cannot be drained at an unrealistic fixed price.

This illustrates a general truth about AMM design: there is no universally best invariant. The right shape depends on the assets and on what tradeoff you want. Constant product is broad and simple. Stable-swap style curves are better for near-pegged assets. Weighted multi-asset variants support portfolio-like pools. Concentrated liquidity makes capital placement explicit rather than uniform across all prices.

So “AMM” is better thought of as a design pattern than a single formula.

How does concentrated liquidity (Uniswap v3) change capital efficiency and LP management?

Uniswap v3 changed the economics of AMMs by changing where liquidity lives. In earlier constant-product pools, LP capital was effectively spread across the entire price range from almost zero to almost infinity. In practice, most trading happens in a much narrower band, so much of that capital sits idle.

Uniswap v3’s defining idea is concentrated liquidity: LPs choose a price range over which their liquidity is active. Inside that range, the position behaves like a much larger virtual constant-product reserve than the actual deposited tokens alone would suggest. Outside that range, the position becomes inactive and is effectively converted into one of the two assets, depending on which side price moved to.

This improves capital efficiency because LPs are no longer forced to fund prices they do not expect to matter. But the consequence is not free. Narrower ranges mean more fee concentration when price stays inside the range, and more abrupt loss of activity when price leaves it. The position stops earning fees while out of range and may need active management to become useful again.

The onchain implementation also becomes more complex. Uniswap v3 discretizes price space into ticks, where price levels follow p(i) = 1.0001^i for integer tick i. Pools constrain which ticks may be initialized using tickSpacing, trading off granularity against gas and accounting cost. The core pool tracks liquidity and square-root price rather than raw reserves in the most direct way, because this makes swap and tick-crossing calculations more efficient.

This is an important example of a broader AMM pattern: conceptual elegance often becomes implementation bookkeeping onchain. The invariant is only part of the design. Real protocols must also choose data structures, precision formats, checkpoint strategies, and gas tradeoffs.

You can see similar ideas outside Ethereum. On Solana, Orca’s Whirlpools also use concentrated liquidity, giving LPs range-based positions and developers SDKs to manage swaps and liquidity. In the Cosmos ecosystem, Osmosis provides AMM tooling and routing infrastructure for pool-based trading across its network design. The market structure idea is not chain-specific, even though the contract architecture and developer interfaces differ a lot.

How are AMMs used as composable infrastructure in DeFi?

As DeFi matured, AMMs stopped being only places where users manually swap tokens. They became settlement infrastructure that other contracts compose with.

Routing is a good example. If many pools exist for related assets, the best trade may split across multiple AMMs or cross several hops. Research on CFMM routing shows that, under common assumptions and ignoring some fixed costs, finding an optimal route across a network of AMMs can be cast as a convex optimization problem. In practice, DEX aggregators use this logic in approximate, latency-sensitive ways to search for better execution.

flash swaps and flash-loan-like patterns are another example. Uniswap v2 introduced flash swaps, allowing a contract to receive assets first, run arbitrary logic, and repay by the end of the same atomic transaction. This made AMMs deeply composable with arbitrage, collateral refinancing, liquidations, and other protocol flows.

Uniswap v4 pushes the infrastructure angle even further. Its design introduces hooks, externally deployed contracts that can run custom logic before or after specified pool actions. It also adopts a singleton architecture, where one contract manages all pools, plus flash accounting, where internal net balances are tracked during an operation and only settled externally at the end. This reduces pool deployment costs and makes AMM behavior more customizable. But it also means that “an AMM pool” can now be much less uniform than before, because hooks can alter fees, accounting, and execution behavior.

At that point, the term AMM starts to mean less “one fixed curve” and more “a programmable liquidity venue with invariant-based settlement at its core.”

What are the main risks and limitations of AMMs?

AMMs are powerful, but they are not free liquidity machines. Several frictions fall directly out of the mechanism.

The first is slippage. Every meaningful trade moves price unless the pool is extremely deep or specifically designed for near-par assets. Thin liquidity makes this worse, and fragmented liquidity across fee tiers or venues can make the effective market shallower than headline TVL suggests.

The second is LP risk. Fees may or may not compensate for inventory losses, and concentrated liquidity can amplify both fee opportunity and exposure. Some empirical work on Uniswap v3 found that, over a studied sample and period, aggregate impermanent loss exceeded aggregate fees for the selected pools. That does not prove LPing is always unprofitable, but it does underline that fee revenue must be weighed against rebalancing losses rather than viewed in isolation.

The third is MEV and transaction ordering risk. Because AMM prices are deterministic and public, pending swaps can be anticipated. Bots can bid for ordering priority, sandwich trades, and extract value from users or LPs. The broader MEV literature shows this is not an edge case but a structural property of transparent blockchains. Mitigation tools such as private order flow or protected routing can help, but they do not erase the underlying incentive problem.

The fourth is smart-contract and implementation risk. AMMs may look mathematically clean while still failing through ordinary software bugs, integration mistakes, or unsafe token interactions. The Curve pool exploits linked to a Vyper compiler bug are a useful reminder: the invariant is not the whole system. Token transfer semantics, reentrancy protections, and compiler correctness matter too.

Finally, AMMs are only as good as their assumptions about the assets they trade. Stable-swap curves work well near a peg, but if the peg breaks, the same low-slippage region that once looked efficient can expose LPs to severe imbalance. Concentrated liquidity works well when LPs choose useful ranges and can manage them, but it underperforms if price spends long periods outside the chosen band. Every gain in efficiency usually comes from specializing to a narrower set of conditions.

How does custody and signing interact with AMM settlement in production systems?

Many users encounter AMMs through wallets and frontends and never think about the signing model underneath. But in production systems, especially exchange infrastructure, settlement design matters.

A concrete example is Cube Exchange’s use of a 2-of-3 threshold signature scheme for decentralized settlement. The user, Cube Exchange, and an independent Guardian Network each hold one key share; no full private key is ever assembled in one place, and any two shares are required to authorize a settlement. This is not part of AMM pricing itself, but it is a good illustration of how AMM-based or DeFi settlement can be combined with cryptographic custody designs that reduce single-key risk.

That distinction is worth keeping clear. The AMM decides how prices and reserves update. The custody and signing system decides who can authorize movement of assets and under what trust assumptions. In real DeFi systems, both layers matter.

Conclusion

An automated market maker is a smart-contract market that prices trades from pooled reserves using a rule instead of matching orders on a book. The memorable idea is this: the pool’s balances are the market, and the invariant tells the market how to move when someone trades.

Everything important follows from that. AMMs make onchain liquidity continuously available and composable. They also create slippage, depend on arbitrage to stay aligned with the outside world, and push risk onto liquidity providers through rebalancing and adverse selection. Different AMM designs are different answers to the same question: what pricing rule best fits these assets and this market?

Once you see AMMs that way, the landscape becomes much easier to read. The formulas differ, but the structure is the same: reserves, rule, trade, rebalance, consequence.

How do you trade through a DEX or DeFi market more effectively?

Trade through a DEX or DeFi market more effectively by focusing on liquidity, execution method, and explicit slippage control. On Cube Exchange, fund your account and choose an execution approach that matches the pair’s depth and your urgency; for larger sizes, prefer staged or limit-based execution to reduce price impact.

1. Fund your Cube account with fiat on‑ramp or a supported crypto transfer. Deposit the token you plan to spend or the settlement currency you prefer.
2. Open the market or swap page for the pair and check liquidity indicators: pool depth, quoted spread, and fee tier or implied swap fee. Use deeper pools or pairs with narrower spreads for immediate fills.
3. Choose an execution method: use a market order or swap for immediate completion, or place a limit order (or split the trade into multiple smaller swaps over time) to control average price and reduce slippage on thin markets.
4. Set a slippage tolerance or price limit, review estimated execution price, fees, and network details, then submit the order. For large orders, consider slicing manually into smaller fills and monitor fills against the live quoted price.