The mathematics behind the number
A concentrated position is described by a single scalar, its liquidity L. For a range between Pa and Pb at current price P, the token amounts held are:
x = L · (1/√P − 1/√Pb) and y = L · (√P − √Pa)
Valuing those at P and solving for a known deposit value V gives the liquidity the deposit buys:
L = V ÷ (2·√P − P/√Pb − √Pa)
Everything else on this page follows from that one line. Capital efficiency is the same expression compared against the full-range case, where the denominator collapses to 2·√P. Token composition at any later price is the pair of amount formulas evaluated there, clamped to a single asset outside the bounds. The derivation is set out in the Uniswap v3 core whitepaper and worked through in Uniswap v3 Ticks and Position NFTs.
What each input means
- Current price — the base asset quoted in the second asset of the pair. The required deposit ratio follows from where this price sits inside the range, which is why a range skewed above spot needs mostly the base asset.
- Range bounds — the prices between which your liquidity is active. The contract stores them as ticks, so a real pool will round to the nearest usable tick for its spacing.
- Deposit value — total value supplied, in the quote currency. The split between the two assets is determined by the range, not chosen.
- Pool daily routed volume — the volume actually executing against this pool at this fee tier. Aggregated figures across all tiers of a pair overstate it substantially.
- Active liquidity — the value of liquidity quoting near the current price, which is the correct denominator for your share. Liquidity Depth and Execution explains how to measure it.
- Time in range — the fraction of the period price spent inside your bounds. Multiply, do not ignore: a position earning well while active and in range 40% of the time earned 40% of that.
Capital efficiency against time in range
The narrow end of this table is the figure marketing pages quote. The right-hand column is the one that decides outcomes, and it is specific to the pair rather than to the protocol.
| Band around spot | Capital efficiency | What has to be true |
|---|---|---|
| ±2% | 100.5× | A pegged pair, or a position you rebalance daily |
| ±5% | 40.5× | A tight correlated pair with an active operator |
| ±10% | 20.4× | A liquid major, monitored weekly |
| ±25% | 8.3× | A volatile pair held through normal movement |
| ±50% | 4.2× | A high-beta pair, or a long unattended horizon |
The product of efficiency and expected time in range peaks at an intermediate width, not at the narrow end. Concentrated Liquidity Strategy derives that objective function and the rebalancing rules that follow from it.
Reading the result
Three lines carry the decision. Composition at the end price tells you what you will actually be holding, which is frequently the part people discover after the fact rather than before. Fee income needed to break even is the revenue the range had to generate to offset the divergence it took. Net result versus holding is the only figure that answers whether the position was worth funding.
A negative net result on a strongly trending pair is expected behaviour rather than a mistake. The position sold the winner on the way up, which is what a bounded market-making range exists to do. The error is choosing that structure while holding a directional view that contradicts it.
Limitations of this model
- Endpoint pricing. The divergence figure depends only on the start and end price. Two paths reaching the same place cost different amounts to market-make, a gap measured by loss-versus-rebalancing.
- Static liquidity share. Your share is held constant, when in practice other providers add and remove liquidity around the price, often crowding in exactly when fees are highest.
- Friction excluded. Gas, approvals, rebalances and exit price impact are outside the model. On smaller positions they dominate; see LP Gas Costs.
- No incentives. Emission rewards are excluded deliberately, so that the fee-funded case is visible on its own. Value them separately at a realisable price, as set out in Yield Farming Explained.
- Tick rounding. Real pools round bounds to usable ticks for the pool's spacing, so a live position will differ slightly from the exact bounds entered here.
Sources
The position mathematics, fee accounting and risk statements implemented here come from protocol specifications, peer-reviewed and preprint research, and public-sector analysis of automated market making.
- Uniswap v3 Core Whitepaper (Adams et al., 2021)
- Concentrated Liquidity (Uniswap Developer Documentation)
- Impermanent Loss in Uniswap v3 (Loesch et al., 2021)
- Risks and Returns of Uniswap V3 Liquidity Providers (Heimbach et al., 2022)
- Automated Market Making and Loss-Versus-Rebalancing (Milionis et al., 2022)
- Miners as intermediaries: extractable value and market manipulation in crypto and DeFi (BIS Bulletin No 58, 2022)
Frequently asked questions
What does this Uniswap v3 liquidity calculator do?
It implements the tick mathematics of a bounded concentrated position. Given a price range, a deposit value and a current price, it derives the position liquidity L, the token amounts the position holds now and at any future price, the capital efficiency against a full-range position, estimated fee income, and the result against simply holding the deposited assets.
How is capital efficiency calculated?
As the ratio of liquidity achieved per unit of deposited value against a full-range position of the same value. For a range from Pa to Pb around a current price P, that is 2·√P divided by (2·√P − P/√Pb − √Pa). A ±10% band around spot gives roughly 20×, and a ±2% band roughly 100×.
What happens when the price leaves my range?
Below the lower bound the position is entirely the base asset, because the curve bought all the way down. Above the upper bound it is entirely the quote asset, because it sold all the way up. In both states fee accrual stops until price returns inside the bounds.
Does this work for Raydium CLMM and PancakeSwap v3?
Yes for the position mathematics. Raydium CLMM, PancakeSwap v3 and most concentrated designs use the same tick and liquidity accounting as Uniswap v3, so token composition, capital efficiency and range behaviour carry over. Fee tiers and incentive programmes differ by venue, so enter those from the pool you are modelling.
Why does the fee estimate need active liquidity rather than TVL?
Fees are split among liquidity active at the traded price, not among all deposits. On a concentrated pool much of the total value locked sits in ranges the market never visits and earns nothing, so it should not appear in the denominator of your share.
Is the fee estimate a forecast?
No. It is an arithmetic consequence of the volume, fee tier, liquidity share and time-in-range you enter. Change any input and it changes. It says what the position would have earned under those conditions, not what any pool will pay.