The compounding math
The two-sided mint constraint, why the carry must exist, and the geometry of growth.
Two pieces of math run the compound: the mint constraint — the geometry that decides how much of a budget fits and forces the carry to exist — and the growth loop — why a percentage of fees re-minted beats the same percentage paid out, compounding into exponential depth.
The mint constraint — why the carry must exist
A concentrated position over [P_lower, P_upper] holding liquidity L, with the live price P inside the range, is worth exactly:
The ratio amount0 : amount1 is fixed by the price alone — but a harvest hands the compound two budgets fixed by the fee flow, which follows trading direction, not price geometry. Two independent constraints, one liquidity number:
No implementation could avoid it: unless the fee flow happens to arrive in the exact ratio the live price dictates — measure zero — every compound leaves a one-sided remainder. The only design choices are where it waits (on the hook, attributed to the program) and when it retries (every future harvest, forever). Swapping the remainder into ratio instead would leak value to fees and impact, and open the very MEV surface the rest of the machine closes.
If the price has left the range entirely, the position is one-sided — need on the abandoned side is zero, the mint consumes only the side the range still wants, and the other budget simply carries until the price comes back. Nothing special-cases this; the formulas above already say it.
The conservation identity
The growth loop — compounding vs paying out
Idealize a pool where each harvest cycle earns fees worth a fraction r of the position, and the program compounds share c of them. The position's value obeys:
The exponent is the whole argument: over enough cycles, any non-zero compound share beats any payout-only configuration in depth — and depth is what cuts slippage, attracts routing, and earns the next round of fees. The idealization is honest about what it ignores (fees scale with volume, not with your liquidity alone; impermanent loss applies to the added depth like any LP), which is why the app's simulator replays the loop against real parameters instead of a formula.
FAQ
What constraint does every mint satisfy?+
Uniswap's own liquidity formulas: for the position's range, L = min over both assets of the amount that fits at the current √price. The engine mints the min and carries the excess.
Which side anchors the mint?+
The scarcer side at the current price — the engine computes both candidate Ls and the smaller one wins. The other side's surplus becomes carry, not waste.
How does compound growth behave over time?+
Geometrically: each harvest re-mints a share of fees that are themselves proportional to liquidity, so position size follows roughly (1 + share·feeRate)ⁿ across n harvests.
Is rounding a risk?+
All splits floor toward the protocol's ledgers and the dust lands in the carry — conservation is exact by construction and asserted wei-for-wei in the tests.
Does the range width change the math?+
Only through the L formulas — a wider range needs more of both assets per unit of L. Full-range programs are the least ratio-sensitive; narrow ranges carry more between harvests.