Pancakeswap

Pancakeswap liquidity is divided into LBAMM price bins and CLAMM ranges

Pancakeswap liquidity is capital assigned either to discrete LBAMM price bins or continuous CLAMM ranges in PancakeSwap Infinity. An LBAMM swap consumes one active bin at a fixed price under a constant-sum rule, then advances to the next funded bin. A CLAMM position uses constant-product math across a chosen range. The split decides price movement, inventory conversion, position representation, and when deposited tokens earn swap fees.

Fund a bin position from pair selection to confirmation

An Infinity LBAMM position starts with an existing bin pool and ends with fungible shares in specific price bins. The selected bin step, active price, fee mode, hook, and distribution shape belong to that exact pool.

1. Select the network, token pair, and Infinity Bin pool on the liquidity screen.
2. Inspect the active bin, adjacent price levels, swap fee, and attached hook.
3. Choose a bin interval and distribute capital uniformly or with a deliberate skew.
4. Enter the two token amounts and review their allocation across the selected bins.
5. Approve the requested tokens, confirm the transaction, and inspect the resulting position.

The active bin accepts both sides of the pair at its fixed ratio. Bins away from it hold one token until price reaches them. After token approval, BinPositionManager transfers the required assets and mints shares for every funded bin. Removing liquidity reverses that process: selected shares are burned, and the corresponding reserves return to the wallet.

A pool must already contain a valid initial price before later providers follow this workflow. Creating a new pool adds another decision because its first transaction establishes the active bin. Joining an established pool avoids setting that starting point, yet the provider still chooses where capital sits around it.

Where flat pricing ends

An LBAMM active bin executes at one price because its normalized reserves follow a constant-sum curve. Zero curve-driven price impact applies only while that bin has enough output inventory; the swap fee still reduces the amount received.

Once a trade exhausts the relevant reserve, execution moves to the next funded bin. Its price differs by the configured bin step. Empty bins create a larger discrete move because the pool skips directly to the next price level containing liquidity. A large order therefore crosses several flat segments rather than receiving one flat price across its entire route.

Capital outside the active bin remains in the position, but it does not serve current swaps. Those bins become useful when market flow reaches them again. A narrow layout concentrates more inventory near the market and requires more frequent repositioning. A wider layout stays reachable across a larger move but places less depth at each level. In either case, token conversion changes the position's value relative to simply holding both assets.

LBAMM and CLAMM at their hard boundaries

LBAMM and CLAMM place liquidity around market price through different invariants. LBAMM divides execution into constant-sum bins, while CLAMM applies constant-product pricing across initialized ticks inside a selected range, as documented in Working with pancakeswap.

PancakeSwap V3 users will recognize the CLAMM model. Each provider chooses lower and upper prices, and the resulting position is non-fungible. Price changes continuously through the constant-product curve while it crosses initialized ticks.

LBAMM assigns a separate fungible share class to each funded bin. Providers at the same pool-and-bin combination own interchangeable claims on that bin's reserves. Flat local execution removes reserve-ratio price movement inside the bin, but it replaces the smooth CLAMM curve with discrete price transitions. Neither model keeps inactive capital earning fees outside its chosen levels.

How the bin step converts IDs into prices

The LBAMM bin step fixes the proportional distance between adjacent price levels. For stored currency order, the protocol derives bin price from P(i) = (1 + s / 10,000)^(i - 8,388,608), where s is the bin step and i is the bin ID.

One bin-step unit equals 1 basis point, or 0.01%. A step of 10 creates 0.10% spacing, while 25 creates 0.25% spacing. The increase compounds from bin to bin because each level multiplies the previous price by the same ratio. Wider spacing needs fewer crossings for a large move; narrower spacing gives finer price resolution.

A 24-bit bin ID uses 8,388,608 as the zero exponent, so that center ID maps to a protocol price of 1 before decimal normalization. A uint24 identifier spans 0 through 16,777,215, while the bin step occupies a 16-bit pool-parameter field. Core price calculations use 128.128 binary fixed-point numbers. Conversion helpers expose an 18-decimal fixed-point form, and token decimals determine the final human-readable quote. Reversing token order displays the reciprocal price without changing the underlying bin.

Uniform, skewed, and one-sided bin layouts

An LBAMM liquidity layout determines how much inventory each selected bin receives. A uniform layout spreads shares across the interval, whereas a skewed layout places more capital toward one side of the active price.

Bins on one side hold the token offered when price moves in that direction. Bins on the other side hold the counter-token. The active bin carries the mixture currently available for two-way swaps. Placing funds entirely beyond the active price creates one-sided exposure: market movement must reach those bins before they serve trades, and continued movement converts the deposited token into its pair asset.

BinPositionManager identifies each share class from a pool ID and bin ID. Its BinFungibleToken accounting resembles ERC-1155 multi-token balances, though the implementation omits the ERC-1155 URI function and receiver callback. One wallet can therefore hold many bin IDs, transfer them in batches, or remove only part of a funded layout. CLAMM's non-fungible position model packages its range differently.

Fee accrual follows active liquidity

LBAMM fee accrual belongs to bins that actually process swaps. Earned amounts increase those active-bin reserves, so withdrawing the position includes fees in the returned token amounts rather than presenting a separate fee balance to collect.

Infinity pools choose static or dynamic fees when initialized, and that fee mode is immutable. A static fee stays fixed. A dynamic fee requires a hook that updates the charge through swap logic. At contract precision, 100 fee units represent 0.01%, 1,000 represent 0.1%, 10,000 represent 1%, and 100,000 represent the LBAMM maximum of 10%.

Static Infinity pools allocate a protocol fee equal to 33% of the LP fee, subject to a 0.4% cap. Dynamic-fee pools carry a 0% protocol fee under this structure. An imbalanced addition to the active bin also triggers a composition fee. That charge prevents a provider from using minting as an implicit swap at a lower cost than ordinary pool execution. Network gas remains separate from every pool-level fee.

Hooks and transaction-wide accounting

Infinity hooks attach programmable behavior to a pool's liquidity lifecycle. Hook permissions cover before and after callbacks for 5 actions: initialization, swapping, adding liquidity, removing liquidity, and donating pool tokens. That creates 10 directional callback points.

The PoolManager checks the registered permissions at each relevant action. Dynamic-fee logic runs through a hook before a swap, while other hooks adjust liquidity handling or attach pool-specific rules. The hook forms part of the PoolKey, so two pools with the same currencies remain distinct when their hook configuration differs.

Flash Accounting records every currency delta during one transaction and settles the net balance at its end. EIP-1153 transient storage keeps that temporary state for exactly 1 transaction. The Vault also supports ERC-6909 internal currency claims. Universal Router coordinates multi-step calls, while Permit2 handles authorized ERC-20 transfers. These components reduce repeated transfers without changing which bins own the final reserves.

Why Infinity separates pool logic from the Vault

The PancakeSwap Infinity architecture separates asset custody from pricing logic. A shared Vault holds currencies, while BinPoolManager and CLPoolManager apply their respective invariants through singleton contracts containing many pools.

Generally, PancakeSwap V3 deployed a separate contract for each pool. Infinity creates a pool as state inside its selected manager. A PoolKey binds 6 fields: 2 ordered currencies, a hook, a PoolManager, an LP fee, and pool-specific parameters. For LBAMM, those parameters include the bin step; for CLAMM, they include tick spacing.

This separation lets another PoolManager introduce a different curve without redeploying the Vault. Native-token support also permits direct pairs such as BNB/CAKE or ETH/USDC instead of requiring WBNB or WETH at the pool boundary. ERC-20 pairs such as USDC/USDT still use token transfers and approvals.

By contrast, Pancakeswap liquidity therefore separates the pair decision from the execution design. LBAMM suits a provider who wants explicit price shelves, fungible per-bin shares, and controllable inventory shapes. CLAMM suits continuous pricing across a custom range and packages that range as one non-fungible position. The decisive trade-off is how price movement converts inventory between rebalances.

Pancakeswap liquidity - common questions

Published: 28 Jul 2026