Liquidity pool

What the contract holds, and what it owes

A pool contract tracks two things that are easy to confuse. The reserves are the actual token balances available to trade against. The pool share accounting is a separate ledger inside the same contract recording who is owed what fraction of those reserves. In Uniswap v2 the pair contract keeps reserve0 and reserve1 as its own state and inherits standard token mint and burn logic for the shares, so the two sets of numbers move on different triggers.³

A swap is one atomic transaction. Tokens arrive, the contract reads its reserves, applies the pricing formula, sends the output, and writes the new reserves. There is no order book, no queue, and no counterparty who agreed to your price. The pool also has no idea what the asset is worth anywhere else. It knows its own ratio and nothing more, which is why external price information only reaches a pool when an arbitrageur trades it in.

That is the whole machine. Everything a founder worries about at launch, opening price, volatility per trade, who can dump and how hard, is a consequence of two reserve numbers and one equation.

The reserve ratio is the price, and the seeder sets it

Seed a pool with 5,000,000 project tokens and $500,000 of USDC and the opening price is $0.10. Not approximately. Exactly, because the price the contract quotes is the ratio of the reserves. Choosing a launch price and choosing a seed ratio are the same decision made twice, and teams routinely negotiate the first in a term sheet and then discover the second in a deployment script.

The constant-product form of that rule, from the original Uniswap design, is that the product of the reserves stays fixed across a trade before fees are applied.¹ Sell into the pool and one reserve rises, so the other has to fall, and the fall is what the seller receives. The bigger the trade relative to the reserve, the worse the terms, and the relationship is not linear.

What a liquidity provider position actually is

Deposit into a v2 style pool and you receive fungible pool shares. The first deposit mints shares equal to the geometric mean of the two amounts deposited. Every later deposit mints shares in proportion to the existing share supply, and the very first fraction of shares, a fixed 10 to the minus 15, is permanently burned to the zero address to block a griefing attack on the share price.¹ To get your reserves back, plus whatever fees accrued to them, you burn the shares.²

Fees are not paid out separately. They stay in the pool, which grows the reserves behind each share. Uniswap v2 charges 0.30% on every trade, of which 0.25% accrues to liquidity providers and 0.05% routes to the protocol fee address when that switch is turned on.¹ Your yield is the difference between what a share redeems for now and what it redeemed for when you minted it.

This matters for treasury planning more than most teams expect. A protocol-owned pool position is not cash and it is not a token balance. It is a claim whose composition changes every time somebody trades, and it is usually the single largest unhedged position on a young project's balance sheet.

Worked example: seeding, shares, and what the fee really pays

Seed the pool above with 5,000,000 tokens and $500,000. The product of the reserves is 2,500,000,000,000, and the first mint issues shares equal to its square root, 1,581,138.83, less the burned dust.¹ The project holds all of them.

A second provider now deposits 500,000 tokens and $50,000, exactly 10% of each reserve. The contract mints them 158,113.88 shares. Total supply is 1,739,252.71, so their claim is 9.09% of the pool rather than 10%, because their deposit sat on top of a pool that already existed.

Run $4,000,000 of monthly volume through it. The liquidity provider slice of the fee is 0.25%, so $10,000 accrues into the reserves that month.¹ The second provider's 9.09% claim collects $909 of that on a $100,000 position, roughly 0.91% for the month.

That is the gross number and it is where most fee-yield marketing stops. The net number requires subtracting what arbitrage did to the composition of the position over the same month, because a constant-product pool is continuously selling whichever asset is rising. Fee income and divergence loss are two halves of one result, and quoting the first without the second is the most common misrepresentation in this part of the market.

Not every pool runs the same curve

Constant product is the default, not the only option, and the curve should be chosen against how the pair is supposed to behave. Curve's StableSwap design targets assets meant to trade near parity, described by its author as a fully autonomous market maker for stablecoins with very minimal price slippage.⁴ Be careful citing it: the published paper states plainly that it is a brief version that does not show the full invariant, so the complete amplification derivation is not in the public document.

Balancer generalises the same idea to weighted multi-asset pools, where a pool can hold a different number of tokens at different weightings rather than an implicit 50/50 split.⁵ An 80/20 pool is a real and useful shape, and it also means the provider is carrying deliberately lopsided exposure to the majority asset. That is a portfolio decision dressed as a liquidity decision, and it should be signed off as one.

For a project token against a stable or against the chain's gas asset, constant product remains the honest default, because the pair genuinely has no parity to defend. Putting a project token into a stable-optimised curve assumes a peg that does not exist.

Depth is a ratio, which is why the same trade behaves differently

In a constant-product pool, the move in the quoted price depends on the fraction of the reserve a trade consumes, not on its dollar size. Sell tokens worth 5% of the quote-side reserve and the pool price ends about 9.3% lower. Sell 10% and it ends about 17.4% lower. Sell 2.5% and it ends about 4.8% lower. The relationship is the reciprocal of the squared reserve change, which is why the curve gets punishing faster than intuition suggests.

Two consequences follow directly. A pool that looks fine against $5,000 trades can be hostile to a $50,000 trade in the same week. And a project whose holders skew toward larger positions needs materially deeper liquidity than a project with the same market capitalisation and a retail-sized holder base. Depth is specified against your holders, not against a benchmark.

Where pool design goes wrong

Three failures show up repeatedly. The first is sizing liquidity as a leftover percentage of the raise. A $2,000,000 raise putting 2% into the pool creates $40,000 of depth, which cannot absorb a single motivated seller from the seed round without disorderly movement. The allocation convention produced the number and nothing checked it against the float.

The second is quoting protocol-level totals as if they described tradability. DefiLlama's API reported Curve Finance's total value locked at $1,258,342,602.84 on 3 August 2026.⁶ Read that as a point-in-time figure across every pool and chain the protocol operates. It tells you nothing about how far a $200,000 trade moves any single pair, which is the only question a trader or a treasury actually has.

The third is leaving ownership of the pool position undefined. Somebody holds those shares, somebody can burn them, and if that is a single deployer key then your project's liquidity floor is one signature deep. Who holds the position, under what multisig or timelock, with what withdrawal policy, belongs in the mechanism design document rather than in a deployment script.

What we settle before a pool is seeded

Five things, in this order. The largest single trade the design has to service without disorderly movement, written as a dollar figure. The price move that is acceptable for that trade, written as a percentage. The reserve required to satisfy both, solved from the curve rather than guessed. The pair and curve, chosen against how the two assets are meant to relate. And the custody and withdrawal policy for the position itself.

Reverse that order and you get the pattern we see most: a liquidity allocation fixed in the token allocation table months earlier, a pool seeded to match it, and a stress test run for the first time by whoever sells first.

One framing to keep hold of underneath all of this. A deep pool does not create demand. It changes how gracefully the market absorbs whatever demand and supply already exist, which is a real and worthwhile improvement and is not a substitute for a business that people want to transact with.