Price impact, explained properly

What impact actually measures

A constant product pool holds two reserves and derives a price from their ratio. When you buy, you add one asset and remove the other, which changes the ratio and therefore the price. Your order does not execute at a single number; it executes along a curve that you are moving as you go.

Price impact is the size of that movement. It is not a fee, nobody collects it, and it is not charged to you as a line item. It appears as receiving fewer tokens than the quoted starting price implied, which is why it is easy to miss.

The critical property is that it depends on the ratio between your order and the pool's reserves, not on the absolute size of either. One SOL into a pool holding ten is enormous. The same one SOL into a pool holding a thousand is invisible. The order did not change; the market did.

Impact is not slippage, and the difference matters

These get used as synonyms constantly, including by interfaces that should know better.

The practical consequence is important. If your swaps are failing on slippage in a thin pool, widening the tolerance does not fix the underlying problem; it converts reverted transactions into worse fills. The actual fix is a smaller order, because that reduces the impact rather than accommodating it. The failure guide covers how to tell which of the two you are hitting from the transaction log.

How it scales, and why the curve surprises people

Impact does not grow linearly with order size. Doubling your order more than doubles the movement, because each unit you buy is priced against a pool you have already shifted.

This is why the difference between a swap that is one percent of a pool and one that is five percent is far larger than five to one in practice. It is also why splitting a large order into several smaller ones genuinely reduces total impact rather than merely spreading it out, and why routing across several pools reduces it further still: each pool sees a smaller fraction of its own depth.

For campaign design this produces a clean rule. Reaching a target volume with many small swaps rather than a few large ones costs less in impact, produces better trade-count and unique-address figures, and lowers the slippage failure rate at the same time. The only cost is a larger wallet fleet, and what that actually costs is arithmetic covered in the fleet sizing guide.

One more consequence follows from the non-linearity and it is easy to miss. Because impact grows faster than order size, the worst possible configuration is a small number of large swaps into a shallow pool, and the difference between that and the same volume delivered in small pieces is not marginal. Teams that discover their campaign produced a jagged chart almost always find this was the cause, and they usually reach for slippage settings first because that is where the visible errors appeared.

The round trip pays it twice

This is the part most people do not price in when planning a campaign.

A campaign buys and later sells. The buy pushes the price up and fills at an average above where it started. The sell pushes the price back down and fills at an average below where that leg started. You have paid impact in both directions, and the position nets out to roughly nothing while the money spent on moving the price does not come back.

In a deep pool this is negligible and the round trip costs little more than the venue fees. In a thin pool it is the dominant cost of the entire campaign, larger than fees, larger than network costs, and completely invisible on any invoice. It shows up only as a volume figure that cost more than expected and a chart with steps in it.

Different pool types behave differently

Constant product pools behave as described: predictable, smooth, impact derived from reserves. The reserve figure means what you expect.

Concentrated liquidity pools are deeper than their headline suggests when the price sits inside the posted ranges, and far shallower when it does not. Impact can be near zero and then jump sharply as you cross out of a range, which produces the discontinuities people mistake for a bug.

Bonding curves have impact defined by the formula rather than by deposits, and it changes as the curve fills. Early buyers move it more in percentage terms than later ones.

The unifying advice is to stop reading liquidity figures and start simulating trades. Total value locked describes how much money is in a venue; impact describes what happens when you trade against it, and only the second one predicts anything, and only the second one predicts anything.

A worked comparison makes the round trip concrete. Suppose 60 SOL of target volume routed as thirty round trips of one SOL each, into a pool where a one SOL order moves the price about two percent. Each leg gives up roughly that much against the mid price, and there are sixty legs. The arithmetic is uncomfortable: a meaningful fraction of the budget has gone into moving a price that ended up back where it started, with liquidity providers on the other side of every one of those moves. Now run the same 60 SOL as six hundred swaps of a tenth of a SOL. Each one moves the pool by a small fraction of a percent, the aggregate given up is a fraction of the first case, and you have ten times the trade count to show for it.

Using it as a planning number

1. Simulate the buy a real trader would make. Read the impact. That is your visitor's experience.
2. Simulate the sell. Pools are asymmetric more often than not.
3. Find the size where impact stops being trivial. That is your ceiling for campaign swaps, and it should be comfortably below it.
4. Divide your target volume by that swap size. That is roughly the number of swaps, and therefore the fleet you need.
5. Re-check after anything changes. Depth moves, ranges drift, and a number from last week describes last week.

That sequence turns an abstract concept into the two numbers that actually plan a campaign: how large each swap can be, and how many of them you need. The campaign console does the same arithmetic against your token's live pools if you would rather not do it by hand.