> ## Documentation Index
> Fetch the complete documentation index at: https://docs.levery.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Provide Liquidity

> Provide liquidity to permissioned pools by creating range-based positions (full-range or custom-range) under institutional policies.

Liquidity provisioning supplies assets to an AMM pool so swaps can execute with deterministic, on-chain settlement. In an institution-operated Levery venue, liquidity is expressed as a **range-based position**: each position defines a **minimum price** and **maximum price** and contributes liquidity according to where the pool price sits relative to that band.

The same mechanism supports both:

* **Full-range positions** (maximally wide band), and
* **Custom-range positions** (finite band for higher concentration).

<Frame>
  <img style={{ borderRadius: "0.5rem" }} src="https://mintcdn.com/levery/pk16WeWTbZLJRyem/images/levery-invest-dark.jpg?fit=max&auto=format&n=pk16WeWTbZLJRyem&q=85&s=249b45ba6c15aa8bf6be380eb3b583b5" alt="Create Position" className="block dark:hidden" width="2880" height="1800" data-path="images/levery-invest-dark.jpg" />

  <img style={{ borderRadius: "0.5rem" }} src="https://mintcdn.com/levery/pk16WeWTbZLJRyem/images/levery-invest-dark.jpg?fit=max&auto=format&n=pk16WeWTbZLJRyem&q=85&s=249b45ba6c15aa8bf6be380eb3b583b5" alt="Create Position" className="hidden dark:block" width="2880" height="1800" data-path="images/levery-invest-dark.jpg" />
</Frame>

***

## How range-based positions behave

A position is defined by:

* **Pair**: `Token0 / Token1`
* **Range**: **Min Price** and **Max Price**
* **Liquidity**: the minted on-chain amount derived from deposited token amounts and the selected ticks

Fee accrual follows a simple rule:

* **LP fees accrue** when swaps execute while the position is **active**.
* A position is **active** when the pool price is **within** the selected range.
* If the pool uses **dynamic LP fees**, the realized LP fee rate can vary under the pool’s configured logic.

<Note>
  Authoritative outcomes are on-chain. Interface values are derived from contract state, logs, and indexer
  reconciliation, and can be independently verified via transaction hashes and state reads.
</Note>

***

## Price direction and deposit composition

Prices are displayed in a consistent quote direction. Deposit requirements are determined by the relationship between the current price and the selected band:

<CardGroup cols={2}>
  <Card title="Price inside the selected range" icon="arrows-left-right">
    The position requires **both tokens**. The interface typically computes the corresponding amount on the other side so the deposit matches the selected range geometry.
  </Card>

  <Card title="Price outside the selected range" icon="arrow-trend-up">
    The position becomes effectively **single-sided**:

    * **Below range** → Token0-only
    * **Above range** → Token1-only
  </Card>
</CardGroup>

<Callout type="warning" title="Two-sided deposits are mandatory when price is inside the band">
  If the current price is inside the selected range and one side is zero, the position creation transaction is rejected.
  Both token amounts must be provided (often via auto-fill on the second side).
</Callout>

***

## Full range vs custom range

Full range and custom range are two strategies over the same range-based position model.

<Columns cols={2}>
  <Card title="Full Range" icon="maximize">
    Uses the widest admissible band for the pool. The position is typically active across most market states overall now.

    Suitable when prioritizing continuity of activity and minimizing out-of-range events, accepting lower fee density per unit of capital.
  </Card>

  <Card title="Custom Range" icon="sliders">
    Defines a finite Min/Max band around a target price region. The position becomes inactive when price exits the band.

    Suitable when maximizing fee density near an expected trading band, accepting a higher probability of moving out of range.
  </Card>
</Columns>

### Ticks and range granularity

Ranges are implemented using discrete **ticks**. Each pool defines a `tickSpacing`, which constrains the minimum step size for range movement.

Operationally:

* Slider selection snaps to tick boundaries.
* Min/Max step controls adjust by tick increments.
* Zoom affects visualization only; it does not alter the selected tick boundaries.

***

## Costs, fees, and what accrues

Liquidity provisioning involves distinct accounting categories:

<CardGroup cols={2}>
  <Card title="LP fees (earned)" icon="receipt">
    Accrue when swaps execute while the position is active. Realized earnings depend on executed volume, fee configuration (static/dynamic), and the position’s liquidity share at active ticks.
  </Card>

  <Card title="Network gas (paid)" icon="gas-pump">
    Required for approvals and for the position creation transaction.
  </Card>
</CardGroup>

<Card title="Service fees and policy constraints" icon="building-columns">
  Service fees are not charged on liquidity events (mint, increase, decrease, collect, close). They are applied only on swap execution flows.

  Liquidity provisioning can still be subject to institutional controls, such as eligibility checks, allowlists, and risk-tier rules, enforced by the venue’s policy layer.
</Card>

***

## Pricing layers and provenance

The Invest page commonly uses two pricing layers with different objectives:

<Columns cols={2}>
  <Card title="Execution-relevant pool price" icon="link">
    Range geometry, in-range status, and token composition are derived from the pool’s on-chain state (e.g., sqrtPrice/tick). This is the source of truth for execution outcomes.
  </Card>

  <Card title="Fiat valuation and history" icon="chart-line">
    Fiat conversions and historical charts are backed by institution-approved pricing feeds (oracle and indexed market data), supporting auditability and consistent reporting.
  </Card>
</Columns>

***

## Create a liquidity position

<Steps>
  <Step title="Open Invest for the target pool">
    Access the pool’s Invest screen (commonly via **Pools → Invest**). Validate:

    * the chain/network where the pool is deployed,
    * the pair (`Token0 / Token1`),
    * and the displayed price direction used for Min/Max inputs.
  </Step>

  <Step title="Connect a wallet and align the network">
    Select **Connect Wallet** and connect a wallet authorized to interact with the institution’s venue.

    If the wallet network does not match the pool’s chain, execution is blocked until the wallet network is switched. Some connectors can request a network switch; otherwise, manual selection in the wallet is required.
  </Step>

  <Step title="Select range strategy and define the band">
    Choose **Full Range** for a maximal band or **Custom Range** for a finite band.

    For Custom Range:

    * set the band using the slider,
    * refine Min/Max using numeric inputs,
    * and apply tick-step controls for precision.
  </Step>

  <Step title="Enter deposit amounts">
    In **Deposit Tokens**, enter the intended contribution amount.

    The interface computes deposit composition from:

    * current pool price state,
    * selected tick boundaries,
    * and range liquidity math (mapping token amounts to minted liquidity).

    When the current price is inside the band, the second token side must be populated (commonly via auto-fill). When price is outside the band, the deposit can be effectively single-sided.
  </Step>

  <Step title="Complete token approvals (ERC-20 only)">
    ERC-20 deposits generally require allowances before funds can be pulled during position creation. Many Levery deployments use a hardened two-layer allowance model:

    1. **Token → Permit2** (token allowance granted to Permit2)
    2. **Permit2 → Position Manager** (Permit2 allowance granted to the pool’s position manager)

    Each approval is an on-chain transaction and requires gas. Native-currency legs do not require ERC-20 approvals.
  </Step>

  <Step title="Submit and confirm position creation">
    Submitting broadcasts a single on-chain execution that:

    * mints liquidity for the selected ticks, and
    * settles the token pair transfer required for that mint.

    The interface typically performs a preflight simulation to surface common failures early (missing approvals, insufficient balance, invalid range ordering, or policy enforcement).
  </Step>

  <Step title="Verify and monitor the position">
    After confirmation:

    * the position becomes visible in **Positions**,
    * in-range status and composition are tracked over time,
    * and fee accrual is exposed through on-chain accounting.

    Many Levery deployments represent positions as **non-transferable position tokens** (soulbound), binding control to the owner wallet rather than enabling transfers.
  </Step>
</Steps>

***

## Troubleshooting

<CardGroup cols={2}>
  <Card title="Create button disabled" icon="ban">
    Typical causes: wallet not connected, network mismatch, pool state not loaded, or missing token metadata required to compute deposits.
  </Card>

  <Card title="Both token amounts required" icon="triangle-exclamation">
    If current price is inside the selected band, both sides must be non-zero. Single-sided deposits only succeed when
    price is outside the band.
  </Card>

  <Card title="Approval required" icon="key">
    One or both allowance layers may be missing. Complete Token → Permit2 and Permit2 → Position Manager approvals, then
    retry after confirmations.
  </Card>

  <Card title="Provisioning not authorized" icon="shield-check">
    Some pools restrict liquidity providers. If provisioning is blocked by policy or allowlisting, an institution
    administrator must enable liquidity permission for the account.
  </Card>

  <Card title="Simulation failed / transaction reverted" icon="bug">
    Common causes: insufficient balance, stale allowance state, invalid tick ordering, or enforcement by pool policies and
    permission modules. Refreshing state after confirmations can resolve indexer-latency symptoms.
  </Card>

  <Card title="Network mismatch" icon="shuffle">
    Wallet network must match the pool’s chain. If connector switching fails, manual wallet network selection is required before retrying.
  </Card>
</CardGroup>

<Card title="Information useful for support and reconciliation" icon="life-ring">
  When escalation is required, provide: chain id, pool id, selected Min/Max, deposit amounts, and transaction hashes for
  approvals and the create-position attempt.
</Card>

***

## Risk notes

Liquidity provisioning is market exposure, not guaranteed yield.

<Columns cols={2}>
  <Card title="Range and activity risk" icon="wave-square">
    When price exits the selected band, the position stops earning fees until price returns. Narrower bands can increase fee density but increase the probability of range exit.
  </Card>

  <Card title="Composition and performance risk" icon="scale-balanced">
    Token composition changes as price traverses the band. Relative to holding the tokens, performance may underperform depending on price path and fee capture (impermanent loss dynamics).
  </Card>
</Columns>

<Card title="Smart contract and network risk" icon="shield-halved">
  Outcomes depend on contract behavior, network finality, and execution conditions. Institutions typically mitigate risk
  through audits, controlled deployments, and operational monitoring.
</Card>

<Callout type="info" title="Institution policy applies">
  Eligibility checks, allowlists, and pool-level controls can restrict liquidity provisioning. If provisioning is
  blocked, resolution requires an operator action under the institution’s governance and compliance process.
</Callout>