An AMM Pool Is a Formula, Not a Market Maker

"Market maker" suggests someone deciding what to quote. On many decentralised exchanges nobody does: a contract holds two piles of tokens and applies one equation.

Thesis, stated once: an AMM pool quotes from a formula over two reserves. Slippage and MEV both follow from that formula meeting a public, ordered blockchain, and TVL measures how much is deposited, not whether any of it is safe. Mechanism only.

The pool: two reserves and one rule

An automated market maker (AMM) is a smart contract that holds reserves of two assets and quotes trades from a fixed formula over those reserves, rather than matching buyers and sellers in an order book.

One widely documented formula, and the one this note uses, is the constant product; other AMMs use other curves. Suppose a pool holds x units of asset A and y units of asset B. The contract keeps x · y = k: after any trade, the product of the reserves must not fall. The Uniswap v2 whitepaper, cited as a reference description, not an endorsement, describes a pair that maintains "the invariant that the product of the reserves cannot decrease." Its pair contract checks the product after every swap, with the swap fee factored in, and reverts the swap if it has fallen.

There is no order book and no one setting a rate. The whitepaper says the marginal rate, fees aside, "can be computed by dividing the reserves of asset a by the reserves of asset b." Read the other way round, as how much B one unit of A fetches, the quote is the ratio y / x. It changes only when the reserves change, and it tends to track outside markets because, as the whitepaper notes, arbitrageurs trade against the pool when it drifts.

Slippage: size against reserves

Slippage is the difference between the rate a trade was quoted and the rate it actually receives, caused by the trade's own size relative to the reserves and by other transactions that land before it.

The first cause is built into the formula. Adding A to the pool means the contract must release enough B to keep x · y constant, and each extra unit of A releases a little less B than the one before. A trade tiny relative to the reserves barely moves the ratio; a large one moves it a lot. In the extreme, adding an amount of A equal to the whole existing reserve doubles x, so y must halve, and the pool's ratio of B to A falls to a quarter of where it started. Deeper reserves soften the effect; they do not remove it.

The second cause is timing: a quote uses the reserves when the transaction is prepared, but it executes against the reserves at inclusion, after any trades that land first.

The slippage-tolerance setting is the bound a trader signs to cover both. In the reference router contract, a swap carries an amountOutMin and a deadline. If the output would fall below that minimum, or the deadline has passed, the transaction reverts. A tolerance is not a target. It is the worst outcome you have agreed to accept.

MEV: whoever orders the block

Maximal extractable value (MEV) is the value whoever orders a block's transactions can capture by including, excluding or reordering them, for example by placing trades around a visible pending trade.

Ethereum's MEV page defines it as value extracted "by including, excluding, and changing the order of transactions in a block." A signed transaction is broadcast to a pool of pending transactions until it is included. On a public mempool, anyone can see it before it executes: its pool, size and slippage bound.

Sandwiching is the standard example. A searcher who sees a large pending trade places one trade just before it, which moves the ratio against the victim, and one just after, which captures the difference. In our reading of the router code, the victim's own tolerance sets how far that can go, because their transaction still executes as long as the output stays at or above amountOutMin. Ethereum's page states the cost plainly: "Users who are sandwiched face increased slippage and worse execution on their trades." Under proposer-builder separation, specialised block builders do the ordering and bid for inclusion, so ordering power sits with builders and validators rather than with any pool.

Flashbots, a research and development organisation formed to mitigate MEV's "negative externalities", documents private submission routes that keep transactions out of the public mempool. In our reading, that changes who can see a transaction before inclusion. It does not remove ordering power; it moves the trust to whoever operates the route.

TVL: deposits, not safety

Total value locked (TVL) is the market value of the assets deposited in a protocol's contracts at a given moment; it measures deposits, not how safe, sound or useful those contracts are.

One data aggregator's methodology page defines it as "total value locked inside a platform / protocol's own contracts by users". Most of the page covers what to include or exclude, and it warns that TVL "may also be inflated through circular or non-backed assets." So TVL is a methodology choice as well as a measurement.

Three things follow, in our reading rather than the methodology page's. Because TVL is reserves multiplied by market rates, it moves when those rates move even if no one deposits or withdraws. A large figure means a large target, not an audited contract. Depth softens slippage; it says nothing about whether the code is sound.

What this is not

This is not a guide to swapping, providing liquidity or choosing a pool, and it names no venue to use. Uniswap v2 is cited only as a published reference for the constant-product formula. It contains no prices, currency figures, fees, yield or returns, and says nothing about whether depositing in a pool pays. It is not a trading or MEV strategy, and it does not call any protocol safe because of its TVL. CryptoDecentral has not tested any contract or service described here; mechanisms are as documented on 13 November 2026. Not legal or financial advice.

The one-line takeaway: the pool's quote is a ratio, your tolerance is the worst case you signed, and the block's order is decided by someone else.

Related on CryptoDecentral

• Who Holds the Coins Mid-Trade? CEX, DEX and Escrowed P2P
• The Website Is Not the Contract: Who You Trust Before You Sign
• Self-Custody Without Verify-Before-Trust Is a Slogan
• A Threat Model Is Not a Fear List
• What Transparent Ledgers Leak — and Why On-Chain Privacy Matters
• On-Chain Privacy Is Not Network Privacy: Node Choice, Tor, and I2P

Further reading (primary)

• Uniswap v2 Core whitepaper (constant-product invariant, marginal price)
• UniswapV2Pair.sol (invariant check) and UniswapV2Router02.sol (amountOutMin, deadline)
• ethereum.org: Maximal extractable value and Transactions
• ethereum.org: Glossary (liquidity pool)
• Flashbots docs
• DefiLlama: What to include as TVL? (methodology)