What Is Concentrated Liquidity?

Introduction

Concentrated liquidity is a way of designing automated market makers so liquidity providers do not have to spread their capital across the entire price curve. Instead, they choose a price range where their liquidity is active. That sounds like a small design change, but it rewires the economics of on-chain trading: pools become much more capital-efficient near the current price, while liquidity provision becomes more strategic, more operationally demanding, and often more risky.

The puzzle it solves is easy to state. In an older constant-product AMM, a pool makes prices for every possible exchange rate from almost zero to almost infinity. But most asset pairs spend nearly all of their time in a much narrower zone. If a stablecoin pair usually trades very close to 1, then capital placed far away from 1 is mostly idle. It exists for theoretical completeness, not practical trading. Concentrated liquidity asks: why require LPs to fund all those unused prices?

That question matters because AMMs compete on depth where traders actually trade. A pool can have a large total value locked and still give mediocre execution if much of that capital sits at prices nobody touches. Concentrated liquidity moves from “fund the whole curve” to “fund the part of the curve you care about.” Uniswap v3 made this design mainstream, and similar concentrated-liquidity market makers now exist across chains, including Solana systems such as Orca Whirlpools and V3-style deployments on other DEXs.

The core idea is simple enough to say in a sentence: liquidity is only active inside the LP’s chosen range. The consequences are less simple. Inside that range, the LP behaves as if they had deployed much more effective depth than the same capital would provide in a full-range pool. Outside that range, the position stops participating in trades and becomes entirely one asset. So concentrated liquidity is not just an efficiency upgrade. It is also a bet about where price will be.

Why do constant-product AMMs spread capital thin and waste liquidity?

Start from the constant-product AMM most readers will know: a pool with reserves x and y maintains x * y = k. The mechanism is attractive because it is simple, permissionless, and always quoteable. A trader can swap against the pool at any moment, and the price moves smoothly as reserves change.

But the same feature that makes it always available also makes it capital-hungry. Because the pool supports trading across the whole price curve, LP capital is distributed across the whole curve too. That means a large fraction of deposited value is not helping at the current market price. If ETH is trading near 3000 USDC, the liquidity supporting absurdly low or absurdly high ETH prices is not doing useful work for ordinary order flow today.

Here is the mechanism behind the waste. In a full-range constant-product pool, marginal depth near the market price depends on the entire reserve distribution implied by the curve. To make the pool deep near today’s price, LPs must also supply reserves that back all the distant prices the curve could in principle reach. Those distant-price reserves are the cost of having a single elegant invariant cover everything.

That tradeoff was acceptable when AMMs were proving that on-chain market making could work at all. But once DEX usage grew, it became the limiting factor. A stablecoin pool, for example, wants enormous depth in a narrow band around parity, not equal theoretical support for a depeg to near zero or a move to many multiples above 1. Concentrated liquidity is the answer to that mismatch.

How does concentrated liquidity compress market depth into chosen price ranges?

The best way to understand concentrated liquidity is to stop thinking of a pool as one indivisible blob of capital. Instead, think of it as the sum of many smaller liquidity commitments, each active only over some interval of prices.

A traditional full-range AMM is then just a special case: every LP chooses the widest possible interval. Concentrated liquidity generalizes that design by letting each LP choose a narrower interval. The pool still aggregates all positions into one trading venue, but at any given moment only the positions whose ranges include the current price are active.

That is the compression point. The pool is not abandoning AMM pricing; it is superimposing many range-bounded AMMs. Traders still see one pool. Under the hood, however, the active depth at the current price comes from the overlap of the ranges currently “in play.”

This explains both the efficiency gain and the new risk. Efficiency improves because LPs can place capital where order flow is likely to happen. Risk rises because if price leaves that interval, the LP stops earning fees and ends up holding whichever asset the price movement has converted the position into.

An analogy helps, with limits. Concentrated liquidity is a bit like choosing where along a road to place your snowplows instead of spreading them thinly across every road in the country. You get much better service where you expect traffic. But the analogy fails in one important way: snowplows do not transform into different assets when traffic shifts, while a liquidity position does. In a CLMM, range choice changes not just where your capital works, but what inventory you end up holding.

How does a concentrated-liquidity position change inventory and fee earning as price moves?

A concentrated-liquidity position is defined by a lower price bound and an upper price bound. If the market price is inside that interval, the position is active and participates in swaps. If price is below the interval, the position is entirely in one token. If price is above the interval, it is entirely in the other token. In Uniswap v3’s terminology, liquidity concentrated to a finite range is a position.

This is easiest to see through a worked example. Imagine an ETH/USDC pool where ETH trades at 3000 USDC. An LP believes the price will remain between 2800 and 3200 for a while, so they deposit capital only in that range. While price moves within that band, traders swapping ETH and USDC interact with that liquidity, and the LP earns fees proportional to the position’s active liquidity. As ETH rises toward 3200, the LP’s position gradually holds less ETH and more USDC. If the price crosses above 3200, the position is no longer active; it has effectively been converted fully into USDC and will not earn more swap fees unless price falls back into the range.

That last part is where many newcomers misunderstand the design. They assume “providing liquidity in a range” means the capital somehow remains available around that range indefinitely. It does not. The position is only active while the market is inside the range. Outside it, the position is inert inventory. This is why concentrated liquidity often requires active management: LPs may need to withdraw, rebalance, and redeploy if market conditions change.

Very narrow ranges push this behavior closer to something like a limit order. The Uniswap v3 whitepaper explicitly notes that very small ranges can act similarly to limit orders, sometimes called range orders. If price crosses the entire range, the position flips from being one asset to the other, plus accrued fees. But it is only similar to a limit order, not identical. A true order book limit order has explicit execution semantics; a CLMM position is still an AMM position whose inventory changes continuously along a curve.

How do virtual reserves, liquidity (L), and ticks power concentrated-liquidity AMMs?

Under the hood, concentrated liquidity keeps the constant-product intuition but applies it locally. Within its active range, a position behaves like a constant-product pool with larger virtual reserves than the actual tokens it physically needs to hold. The key reason this works is that the position only needs enough real reserves to support trading inside its chosen interval, not across all possible prices.

Uniswap v3 formalizes this by tracking liquidity, written as L, and the square root of price, written as sqrtPrice. The pool does not need to store the virtual reserves directly. These state variables are enough to compute how swaps change price and how much token amount corresponds to a given amount of liquidity within the active interval.

You do not need the full derivation to understand the mechanism. The practical point is that L is a measure of how much depth a position contributes, while sqrtPrice is a computationally convenient way to update prices and token amounts efficiently. Using square root price is partly an engineering choice: it simplifies formulas and makes on-chain arithmetic more tractable.

The other key concept is the tick. In Uniswap v3-style designs, price space is discretized into ticks. Conceptually there is a tick at every price corresponding to integer powers of 1.0001, and LPs provide liquidity between two ticks. The current price sits in a current tick, and as swaps move price enough to cross a tick boundary, the pool updates which liquidity is active.

This tick structure matters for two reasons. First, it makes range management discrete rather than perfectly continuous. LPs choose lower and upper tick bounds, not arbitrary real numbers at infinite precision. Second, it creates a gas-performance tradeoff. Pools are configured with a tickSpacing parameter, and only ticks divisible by that spacing may be initialized. Finer spacing allows tighter, more precise ranges. But every initialized tick crossed during a swap imposes a gas cost, so very fine granularity makes execution more expensive.

That tradeoff is not cosmetic. It reveals something fundamental about DeFi design: market precision and computational cost are linked. Concentrated liquidity is not just a mathematical idea; it is a smart-contract system that must pay for each state transition on-chain.

Why does concentrating liquidity increase executable depth near the market price?

Capital efficiency improves because the same notional capital can support much more depth near the current price when it is not diluted across remote prices.

Suppose two LPs each deposit the same total value. The first uses a full-range position. The second concentrates around the market price. Near the current price, the second LP contributes more executable depth because their liquidity is focused where traders are actually transacting. Traders see lower price impact there, even though total deposited value may be the same.

This is why concentrated liquidity was especially compelling for low-volatility pairs. For a stablecoin pair that usually trades close to 1, a narrow range around parity can create extremely deep markets with much less capital than a full-range pool would need. More broadly, any pair whose price spends meaningful time inside a predictable region can benefit from range-based allocation.

But “capital efficiency” should be read carefully. It does not mean capital becomes universally better. It means depth is improved conditional on the price remaining where the liquidity is concentrated. If price moves far away, that efficiency disappears because the position is no longer active. So the gain is real, but it is contingent.

This is also why concentrated liquidity makes LPing look more like market making. The LP is no longer simply contributing to a general-purpose pool. They are choosing where to quote liquidity and accepting that they may need to move that quote over time.

Why are CLMM positions non-fungible and how are fees accounted per position?

In older AMMs, all LP shares in a pool were interchangeable because everyone deposited against the same curve. Concentrated liquidity breaks that symmetry. A position with range 2800 to 3200 is economically different from a position with range 2500 to 4000, even if both are on the same token pair. Their active time, fee exposure, and inventory transformation differ.

That is why Uniswap v3 positions are non-fungible. They are represented in the periphery as NFTs through the INonfungiblePositionManager. Each tokenized position has its own tick bounds, fee tier, liquidity amount, and fee accounting fields. The interface exposes lifecycle operations such as mint, increaseLiquidity, decreaseLiquidity, collect, and burn.

This non-fungibility has practical consequences. First, positions cannot be represented by a single pool-share ERC-20 in the same simple way as v2-style LP tokens. Second, fee accounting happens per position. Third, strategy tooling becomes more important because each LP may hold many custom positions rather than one homogeneous share of the pool.

Fees themselves also behave differently. In Uniswap v3, fees are not automatically compounded into liquidity. They are accrued separately in the tokens they were paid in. That choice follows from non-fungibility: because positions are distinct, automatic pro rata reinvestment is no longer straightforward. Economically, this means the LP has more explicit control over whether to harvest or redeploy fees, but it also means fee income and active liquidity are separate balances to manage.

How does range width trade off fee density against impermanent-loss and risk?

The central tradeoff in concentrated liquidity is simple: narrower ranges increase fee density but also increase exposure to being wrong about where price will be.

A narrow range puts more effective liquidity near the market and can therefore earn a larger share of fees while active. But the position is more likely to go out of range, stop earning, and become one-sided inventory. A wide range earns less fee density per unit of capital but stays active across more price movement. In practice, range width is a leveraged view on future price path.

This is closely tied to impermanent loss. Research on Uniswap v3-style liquidity finds that reducing the liquidity range increases both fees earned and impermanent-loss risk. The intuition is direct. By narrowing the range, the LP has created a more locally intense trading function. That increases exposure to price movement within the active zone and raises the chance the position will finish as an imbalanced inventory if price exits the range.

A useful way to phrase it is this: concentrated liquidity removes unused collateral, but that “unused” collateral was also cushioning your exposure across a wider set of outcomes. Capital efficiency and risk concentration are two sides of the same design.

This is why naive APR comparisons can mislead. A narrow strategy may show attractive fee generation during calm periods, yet underperform holding the underlying assets once adverse price moves, gas costs, and repositioning are included. Empirical work on Uniswap v3 has found that aggregate LP outcomes can lag simple holding, depending on pools and periods studied. That does not make concentrated liquidity defective. It means LP returns depend heavily on strategy quality, volatility, and operational cost.

How do fee tiers interact with range selection and pool volatility?

Concentrated liquidity also interacts with fee selection. Uniswap v3 introduced multiple pools per token pair at different fee tiers, initially including 0.05%, 0.30%, and 1%. The idea is that volatility and trader demand differ across assets. A stable pair may sustain a lower fee because price impact is low and order flow is frequent. A volatile or exotic pair may require a higher fee to compensate LPs for adverse selection and inventory risk.

The important mechanism is that fee tier and range width jointly determine the economics of an LP position. A narrow range in a low-fee, high-volume stable pool is a very different proposition from a narrow range in a volatile pair with a higher fee tier. The first may rely on frequent, low-margin flow. The second may rely on earning more per trade but surviving larger price moves.

Governance can add fee tiers and set parameters such as tick spacing for those tiers. That means pool design is not fixed once and for all. It can be adjusted to market structure, though those parameter choices involve tradeoffs between precision, cost, and usability.

How do LPs and traders use concentrated liquidity in practice?

In practice, concentrated liquidity supports several behaviors that were awkward or inefficient in older AMMs.

The most straightforward is passive range provision around expected price zones. An LP chooses a moderate range around the current price and earns fees while price stays inside. This is common for pairs with relatively stable or mean-reverting behavior.

Another behavior is active market making. More sophisticated LPs narrow their ranges substantially, monitor price closely, and reposition often. Research on Uniswap v3 suggests a relatively small group of more sophisticated LPs accounts for a large share of TVL and fee accrual, especially in large, lower-volatility pools. That is not surprising. Concentrated liquidity rewards better forecasting, lower operational friction, and better automation.

A third behavior is range-order style execution. An LP can place a very narrow position above or below the current price to effectively sell into a rise or buy into a decline. If price crosses the range, the position converts largely into the target asset. This can mimic some outcomes of a limit order while remaining within the AMM framework.

These behaviors are not Ethereum-specific. On Solana, Orca Whirlpools implements an open-source concentrated-liquidity AMM with SDKs for swaps, positions, and pool management. PancakeSwap V3 interfaces expose the same user-facing idea: choose the price range where liquidity is active. The implementation details differ across chains and protocols, but the underlying logic is the same: concentrate capital where expected trading will happen.

When does concentrated liquidity fail and what are the main failure modes?

Concentrated liquidity works best when ranges can be chosen and managed faster than market conditions invalidate them. That assumption can fail.

One obvious failure mode is volatility. If price moves sharply, a narrow position can leave the active range quickly, stop earning fees, and strand the LP in one asset. Re-entering with a new range requires transactions, which means gas costs on EVM chains or other operational costs elsewhere. If repositioning is frequent, costs can consume much of the apparent efficiency gain.

Another issue is information asymmetry. Because LPs can add and remove liquidity at specific ranges, more advanced actors can react tactically to visible order flow. This creates the possibility of just-in-time liquidity, where an LP mints a narrow position immediately before a large swap and burns it right after, aiming to capture fees from that trade with minimal inventory exposure. Official and academic analyses agree that JIT liquidity exists, though measured prevalence is small relative to total activity and highly concentrated among a few actors.

JIT is a good example of what concentrated liquidity changes at the market-structure level. The protocol invites more precise, more dynamic quoting of liquidity. That can improve execution for large traders in some cases, but it can also dilute fee opportunities for passive LPs and concentrate advantages in highly automated strategies. More providers does not automatically mean healthier liquidity for everyone.

There is also a composability cost. Because positions are non-fungible and strategy-specific, they are harder to use as generic building blocks than simple fungible LP shares. Wrappers and vaults can abstract this away, but then the wrapper is making strategy decisions on the user’s behalf. In other words, concentrated liquidity often pushes complexity up a layer rather than removing it.

Finally, smart-contract complexity rises. Tick accounting, per-position fee growth, crossing logic, and NFT position management are all more involved than a simple x*y=k pool. That does not invalidate the design, but it increases the importance of audits, battle testing, and careful integration.

How similar are concentrated-liquidity AMMs to order books, and where do they differ?

Concentrated liquidity makes AMMs look more like order books in one specific sense: both now have a notion of depth distributed across prices. In an order book, makers post quantities at chosen price levels. In a concentrated-liquidity AMM, LPs allocate depth across chosen ranges or ticks. The resulting liquidity distribution can be visualized somewhat like depth-of-market.

But the resemblance has limits. In an order book, resting orders are discrete commitments to buy or sell at specified prices. In a CLMM, liquidity still follows AMM math inside the range; inventory transforms continuously as price moves. So concentrated liquidity does not turn an AMM into an order book. It creates a hybrid structure where some of the economic behavior of market making becomes more explicit.

That is why the best mental model is not “v2, but more efficient.” It is an AMM that lets LPs choose where on the price axis to be market makers.

Conclusion

Concentrated liquidity exists because full-range AMMs waste capital on prices that rarely matter. By letting LPs choose where their liquidity is active, CLMMs put much more depth near the current market price and make on-chain trading far more capital-efficient.

The cost of that efficiency is that liquidity provision stops being purely passive. A concentrated-liquidity position is a view about price location, a fee-earning machine only while that view is roughly right, and an inventory transformation mechanism when it is not. That is the idea to remember: concentrated liquidity turns LP capital from “always everywhere” into “deployed where you think trading will happen.”

How should concentrated liquidity change the way you place a trade?

Concentrated liquidity packs available depth close to the mid-price and leaves much thinner depth outside the active ranges, so trade sizing and order type matter more than in full-range AMMs. On Cube, use funded account balances, limit orders, and explicit slippage controls to place trades that fit the observed depth instead of walking thin price bands.

1. Fund your Cube account with fiat or a supported crypto transfer.
2. Open the market for the pair you want and inspect the depth or price bands around the mid-price.
3. Place a limit order sized to fit the visible depth at your target price (or split a large trade into multiple smaller limit orders to avoid consuming thin bands).
4. Set an explicit slippage tolerance or hard limit price before submitting to prevent execution across thin out-of-range liquidity.