One evolution thread: V1 (primitive), V2 (composability), V3 (concentration), V4 (programmability).
Fixed case across all sections: x=200, y=200, amountIn=20 (A→B). V3/V4 rows use explicit illustrative assumptions for local depth and hook fee behavior.
| Version | Scenario assumption | Output B | Avg (B/A) | Impact |
|---|---|---|---|---|
| V1 | full-range CPMM, 30 bps | 18.1322 | 0.9066 | 9.339% |
| V2 | same pricing path, pair primitive | 18.1322 | 0.9066 | 9.339% |
| V3 | illustrative 2× local active depth, 30 bps | 18.9932 | 0.9497 | 5.034% |
| V4 | same local depth, illustrative 15 bps hook fee | 19.0204 | 0.951 | 4.898% |
V1 proves a core idea: a pool can quote swaps directly from reserves, without an order book.
Its invariant is:
In the running case (x=200, y=200, amountIn=20 A), V1 is the baseline execution path.
For A input:
Fees are applied on input first, so effective input is smaller than raw input.
The mechanism worked, but architecture was still narrow. V2 keeps the same math and turns it into a composable pair standard.
V2 is the composability upgrade, not a pricing rewrite.
It keeps CPMM at pair level:
So in the same running case, output stays close to V1—the trade path is still reserve-curve based.
Liquidity still spans the full theoretical range. Simple UX, but low capital efficiency.
That bottleneck leads to V3: concentrate depth where flow actually is.
V3 introduces concentrated liquidity: depth is allocated by tick ranges instead of spread uniformly.
In the running case, concentrating liquidity around spot increases local depth and reduces impact.
LPs move from passive exposure to active range management. Tick crossing and rebalancing turn microstructure into an operational problem.
This naturally sets up V4: if range behavior can be configured, execution policy can be configured too.
V4 keeps V3’s concentrated-liquidity base and adds programmable execution.
Two additions define it:
In the running case, realized output now depends on both curve state and policy logic (for example fee behavior in hooks).
Protocol teams can express differentiated behavior natively, instead of rebuilding custom layers outside the AMM.
Evaluation shifts from "curve only" to "curve + policy + implementation quality".
| Version | Pool model | LP style | Extensibility | Operational complexity |
|---|---|---|---|---|
| V1 | full-range x·y=k | passive full-range | low | low |
| V2 | pair-based x·y=k | passive full-range | medium | low |
| V3 | concentrated by ticks | active range mgmt | medium | high |
| V4 | concentrated + hooks | active + programmable | very high | very high |
Execution quality is governed by order size / active liquidity, not notional size alone.
CPMM spreads depth across the full range; concentrated models place depth around selected ticks.
| Model | Liquidity shape |
|---|---|
| CPMM (x·y=k) | full-range hyperbola, uniform across prices |
| StableSwap | near-peg flatter zone, tails approach CPMM |
| CLMM (ticks) | liquidity allocated by tick intervals |
Use net LP return ≈ fee income − LVR − operating costs.
Hooks make behavior programmable and shift risk from pure curve math to policy logic and implementation quality.
| Hook pattern | Primary objective | Main risk |
|---|---|---|
| dynamic_fee | adapt spread to volatility regime | wrong regime detection harms flow |
| limit_order_like | conditional execution around trigger price | execution starvation / stale trigger logic |
| oracle_aware | robust parameter updates with external signals | oracle lag or manipulation surface |