> ## Documentation Index > Fetch the complete documentation index at: https://shield.fi/docs/llms.txt > Use this file to discover all available pages before exploring further. # Choosing a liquidity range > Range construction, inventory behavior, tick boundaries, and operational tradeoffs. A position supplies liquidity over a half-open tick interval: ```text theme={"languages":{"custom":["/languages/leo.tmLanguage.json"]}} tick_lower <= current_tick < tick_upper ``` The lower tick is included. The upper tick is excluded. That distinction affects inventory, active liquidity, and fee entitlement at the boundary. Range selection determines inventory composition, capital efficiency, execution exposure, and rebalancing frequency. A narrower range concentrates more liquidity near the current price, but it leaves the active set sooner and requires more frequent management. A wider range uses capital less intensively but tolerates larger price moves before becoming inactive. ## Decision outcome Before minting, record: * the exact pool and canonical token order * lower and upper ticks aligned to tick spacing * the current price region relative to the range * expected token0 and token1 inventory at entry * a rebalance trigger and the cost assumptions behind it The protocol does not choose a range or rebalance policy for the LP. Those are application and operator decisions. ## Start with the correct pool Pool identity includes: * Canonically sorted token0 * Canonically sorted token1 * Fee tier The fee tier is stored in fee pips, or parts per million. Common values include: | Fee pips | Trading fee | | -------: | ----------: | | 100 | 0.01% | | 500 | 0.05% | | 3000 | 0.30% | | 10000 | 1.00% | Fee tier and tick spacing are bound by administrator configuration. Both range boundaries must be multiples of the pool's tick spacing. The protocol fee setting is separate from the trading fee tier. A `fee_protocol` value of 4 assigns 4/16 of each integer step fee to the protocol, not 4 percent of trade value. Market makers should read the current setting from the slot because it changes the share left for LPs. Read [Trading fees and protocol share](../concepts/fees-and-protocol-share). ## Inventory by price region Inventory composition follows the current price region: * Below the range, the position is funded with token0. * Inside the range, the position uses both tokens. * Above the range, the position is funded with token1. These statements follow the contract's token ordering. A user interface that displays the inverse market quote must still construct amounts using canonical token0 and token1. The actual amounts are calculated from the current square-root price, the square-root prices at both ticks, and the requested liquidity. Amount0 and amount1 deltas use different rounding directions depending on whether the contract is taking tokens from an LP or crediting principal back. Do not select a range from a displayed decimal price without first applying token order and display-decimal adjustment. The public `sqrt_price` is a base-unit Q128.128 value, not a ready-made market quote. Read [Price, ticks, and square-root price](../concepts/price-ticks-and-sqrt-price) and [Native token amounts](../concepts/token-amount-normalization). ## Active liquidity and fee production Only active liquidity earns a swap step's LP fee. If the pool is below a position's lower tick or at or above its upper tick, that position does not participate in the active-liquidity denominator for the step. Fees accrue in the input token: * A zero-for-one swap adds token0 fee growth. * A one-for-zero swap adds token1 fee growth. A position that remains active through two-way flow can build entitlements in both tokens. A position near one boundary may see mostly one direction before it leaves the active range. Fee entitlement is not calculated from elapsed time or gross pool volume. It depends on: * Whether the position was active during each step * Its liquidity relative to total active liquidity * The protocol share in effect for that step * Integer rounding in fee growth and settlement ## Boundary behavior When price reaches an initialized tick, the contract: 1. Records the current step's LP fee using pre-crossing active liquidity. 2. Flips both token fee-growth-outside values. 3. Applies the tick's signed `liquidity_net`. 4. Updates the nearest initialized-tick pointers. A tick crossing completes when a step reaches the tick price exactly, including when that price equals the user's square-root-price limit. A quote engine must therefore predict the post-crossing liquidity state even if the swap stops at that boundary. For a downward crossing, the stored current tick becomes one less than the crossed tick. For an upward crossing, it becomes the crossed tick. This preserves the half-open range convention. The interaction matters for range managers. A position can become inactive at the end of an exact-limit swap even though no price movement occurs beyond its boundary. ## Tick initialization and hints The contract stores initialized ticks in a per-pool doubly linked list. A new boundary requires the tick immediately below it as an insertion hint. The contract verifies that: * The hint belongs to the same pool. * The hint is initialized or is the minimum sentinel. * `hint.tick < new_tick`. * `hint.next > new_tick`. Hints are state-sensitive. Another accepted liquidity transaction can make a previously correct hint stale. Fetch them immediately before proving or submitting the transaction. If both boundaries already exist, their current list links are reused. If gross liquidity at a boundary fell to zero, the mapping entry was removed and a later mint or increase must reinsert it. Read [Initialized tick index](../concepts/initialized-tick-index). ## Practical range tradeoffs ### Narrow range Potential benefits: * Higher active liquidity per unit of capital near the current price * Larger proportional fee share while active * Tighter quoted depth around the selected market Operational costs: * More frequent range exits * More rebalancing transactions and proof generation * More frequent fee settlement and sub-unit rounding * Greater inventory change for a given price move * Higher exposure to informed or one-sided flow ### Wide range Potential benefits: * Longer active duration across volatile markets * Fewer reactivation transactions * Lower sensitivity to stale operational signals Operational costs: * Less depth per unit of supplied capital near the current price * Smaller proportional fee share against concentrated competitors * More capital committed away from the current trading region ## Range-selection procedure For each range decision, record: 1. The reference price and its data source. 2. Canonical token order and display decimals. 3. Expected volatility and rebalancing interval. 4. Expected flow direction and fee tier. 5. Current protocol fee share. 6. Tick spacing and rounded lower and upper boundaries. 7. Capital limits and minimum output tolerances. 8. Custody and proving latency for position updates. 9. A response plan for pool pause, token pause, or position freeze. Institutional and regulated operators should preserve these inputs as execution-policy evidence. The contract proves the chosen ticks and amounts were applied. It does not establish that the range was suitable for a mandate or jurisdiction. ## Public observability The position's pool, range, liquidity, fee checkpoints, and owed amounts are public mapping data under its `token_id`. The `PositionNFT` record keeps the owner out of that mapping, but it does not hide the market-making strategy expressed by the range. Position ownership is confidential. The range, liquidity, fee accounting, and resulting performance remain public. Continue with [Minting a position](./minting-a-position) or [Market maker operations](./market-maker-operations).