Price impact

Impact is a ratio, and that is the whole insight

In a constant-product pool, the price is the ratio of the reserves and every trade changes that ratio.¹ What determines the move is the fraction of the reserve your trade consumes. A $10,000 buy against $100,000 of quote-side reserve and a $1,000,000 buy against $10,000,000 of reserve produce identical percentage moves, because both consume 10%.

The relationship is not linear. Consume 2.5% of the reserve and the pool's quoted price moves about 4.8%. Consume 5% and it moves about 9.3%. Consume 10% and it moves about 17.4%. Doubling the trade more than doubles the damage, and the curve steepens the further out you go, which is why a pool that felt adequate in testing can behave badly the first time somebody trades at real size.

The design consequence follows immediately. Price impact is not a property of your token, your community or your narrative. It is a property of one number, the reserve, that you chose at seeding and can change at any time by adding to it.

One trade, two numbers, and why both are called price impact

Every swap has an average execution price, which is the total received divided by the total sent, and it is worse than the pre-trade price because the curve moved while the trade was filling. Every swap also leaves the pool quoting a new marginal price, which is worse still, because the marginal price reflects the full reserve change and the average does not.

Both get labelled price impact in different places. Trading interfaces usually show the first, since it is what the trader pays. Charts, oracles and everybody else see the second, because it is the price the pool now quotes. The formal literature on constant-product markets works with the marginal price when analysing arbitrage and price dynamics, since that is the number an arbitrageur trades against.²

Neither is wrong. Reporting one without saying which is, and in a constant-product pool the gap between them is close to a factor of two.

The arithmetic, shown in full

Take a pool holding 5,000,000 project tokens and $500,000 of stablecoin. The product of the reserves is 2,500,000,000,000 and the quoted price is $0.10. A holder sells 250,000 tokens, which is 5% of the token reserve. Fees are excluded to keep the impact arithmetic clean.

After the sale the token reserve is 5,250,000, so the stablecoin reserve has to be 2,500,000,000,000 divided by 5,250,000, which is $476,190.48. The seller therefore receives $23,809.52. Their average execution price is $23,809.52 divided by 250,000, or $0.09524, which is 4.76% below where they started.

The pool is now quoting $476,190.48 divided by 5,250,000, or $0.09070. That is 9.30% below the pre-trade price. One trade, two numbers, both correct, both called price impact by somebody.

Anything the difference between them touches is worth checking. If your model sizes a treasury sale using the execution number and forecasts the resulting chart using the same figure, it has understated the price effect by nearly half.

Impact does not stop at the trader

The marginal price a pool is left quoting is what everything downstream reads. Any contract taking a spot price from a shallow pool inherits the full move from the last trade, which is why the original Uniswap v2 design accumulates the relative price at the beginning of each block so other contracts can compute a time-weighted average over an interval instead.¹ A spot read from a thin pool is not a price, it is the residue of whoever traded last.

For a project this becomes a real exposure the moment anything is collateralised, borrowed against, or settled at an onchain price. A trade large enough to move the pool 20% is also a trade large enough to trigger whatever is keyed to that number, and the cost of arranging both is the cost of the trade. Surveys of AMM-based exchange designs treat this manipulability as a first-order property of the model rather than an implementation flaw.³

Sizing a pool from an impact budget

Work backwards, and use one method consistently. Name the largest single trade the design has to absorb. Name the price move you will accept for it, and say explicitly whether that is the execution figure or the marginal figure. Then solve the curve for the reserve that satisfies it.

Do it for at least three trade sizes rather than one, because the impact curve is convex and a single point tells you nothing about its shape. The output is a depth target the pool must hit before launch proceeds, expressed as a number that somebody has to fund. That is a more useful artefact than a liquidity percentage in an allocation table, and it is the same conversation held in units that mean something.

Paradigm's decomposition of decentralised exchange trading cost keeps price impact separate from trading fees, slippage and gas for exactly this reason: only the first responds to how you seeded the pool.⁴

The mistakes that show up in launch models

Designing for the wrong trade distribution is the common one. A pool sized for $2,000 retail buys is hostile to the seed investor unwinding a position, and a pool sized for institutional flow is expensive to fund and mostly idle. The distribution comes from your cap table and your community, and it is knowable before launch.

Quoting a single impact figure is the second. Impact is a curve. One number from the middle of it describes nothing.

The third is treating impact as a marketing problem. Low price impact does not mean the token is healthy, it means the pool is deep. Those are different claims, and only one of them says anything about whether the business underneath the token is working.