Liquidity and LP structure

EN source master · P08-L06 · 45 minutes estimated · needs_review

Pool reserves and LP ownership answer different questions. Reserves describe assets held for a specified pool mechanism; LP claims describe rights to change or redeem a position. “Liquidity locked” is incomplete without the relevant claim, fraction and withdrawal conditions.

P07 introduced depth and order impact. Here the skill is identifying the rights structure behind the reserves, rather than repeating price-impact calculations. You will distinguish a fungible share model from an individually specified position.

Identify the pool and its two assets

Begin with network, exact pool identifier, protocol/version and both asset identifiers. A pool containing a familiar ticker is insufficient. A quote asset may be wrapped or bridged; its displayed symbol cannot establish what it represents.

Record reserves at a context and name the units. Dollar liquidity additionally requires a valuation source and methodology. This exercise supplies token and quote units, no dollar values. A tool's large aggregate liquidity number cannot establish one pool's withdrawal rights.

LP means liquidity provider; an LP token represents a pool claim under its specific mechanism. NFT means non-fungible token; here it identifies a particular range position, not a uniform reserve fraction. A pool can hold reserves while its own claim tokens sit elsewhere. Do not read the project token's holder list as the LP-token holder list. They are different assets with different supply and authorization. An investigation needs to connect the exact pool to its claim representation.

Understand fungible LP shares

In the Uniswap v2 pattern, liquidity tokens represent pool contributions and can be redeemed through the specified burn mechanism for underlying assets [S08-POOLS]. The percentage calculation belongs to that mechanism, not every protocol using the phrase LP.

For the fictional simple share model, a holder's fraction is its claim units divided by all issued claim units. Include nonredeemable units in that denominator if the supplied model says they remain issued. Excluding them would overstate other holders' proportions.

At a frozen context, multiplying the fraction by reserves gives a model entitlement. Actual withdrawal amounts need current balances, protocol arithmetic, fee effects and any token-transfer behavior. Do not promise an exact future received amount from a stale snapshot.

Burning LP claims to redeem reserves is not the same as sending claims to an inaccessible address and leaving reserves in place. The same word burn can obscure two different effects. Record whether claim supply changes, whether reserves move and which operation occurred.

Follow custody and withdrawal permissions

An LP holder can be an ordinary account, a locker contract, a vault or another position manager. If custody is mediated, identify who may withdraw and under what conditions. A locker balance is not a verified lock unless the relevant code and configuration constrain its release.

Record exact claim quantity, expiry/delay, beneficiaries, approvals/operators, emergency paths and whether permissions can change. A claim “locked until next year” needs a concrete time basis. This exercise uses S5 as a synthetic release boundary; it is not a calendar date.

A lock covering30% does not lock100%. A lock on one pool does not cover other pools for the same asset. A timelocked claim may still have different fee-collection or transfer permissions, depending on the protocol. Do not infer missing details.

Distinguish concentrated positions

Uniswap v3's position manager records a particular token pair, fee tier, tick range and liquidity [S08-POSITIONS]. The position representation must be inspected with its manager and context. A count of position NFTs is not a percentage of the pool's reserves.

Two positions can have different ranges and therefore different active contributions. Dividing one NFT by ten NFTs does not establish10% of liquidity. Even a liquidity value should not be casually converted to a uniform pool-reserve fraction without the range/price model.

The fixture supplies two position records but deliberately omits current price and detailed entitlement computation. You can verify that their ranges differ. You cannot calculate each position's current amounts, active share or withdrawal receipts from the NFT count alone.

Owner, operator and custody are distinct. A permissioned manager might act for a position owner. Name which permission is supplied and which is unknown. Never infer that a transferred position means underlying project tokens were sold into a market.

Avoid safety conclusions from claims

Verified limits on withdrawal establish a particular restriction. They do not establish that token transfers cannot be paused, supply cannot change, quote collateral is sound or users can exit through every route. Liquidity rights are one slice of the asset review.

Conversely, available withdrawal rights are capabilities, not proof that a withdrawal will occur or that an actor has bad intent. Preserve them without turning the table into a buy/sell recommendation. Commercial labels and creator status do not change observed reserve or claim data.

Produce a reproducible rights note

Write the share denominator, context, mechanism and conditions. If the fixture supplies a complete rule, grade against it. In a real case, request code/configuration evidence before treating a locker label as an enforced boundary.

A useful note can read: “Under the S0 model, C has 60% of issued claims and L30% with release only at S5. The two separate range positions cannot be compared by count.” This reports exactly what was calculated and why other claims remain unresolved.

• Reserve: balance associated with a pool at a context.
• LP claim: mechanism-specific right associated with provided liquidity.
• Redemption: exchange of claims for underlying assets under rules.
• Custody: holding arrangement, not necessarily unrestricted withdrawal.
• Range position: liquidity specified within price/tick bounds.
• Lock coverage: precise fraction and scope of constrained claims.

ILLUSTRATIVE — FIX-P08-06. SIM-EVM-A, pool PAIR-A, standard simple pro-rata model, S0. All1000 claim units remain issued. Reserves are200,000 BASE-A tokens and 400 QUOTE-A units. Ignore integer rounding, fees, tax and intervening activity.

A separate v3-style pool has position N1 with range[100,200] and N2 with range[150,300]. Each is one position NFT. Price, operators and amount-entitlement data are absent. These are not positions in PAIR-A.

OBSERVED in fixture: Claim quantities and the supplied complete simple locker rule are recorded; N1/N2 differ in range.

INFERRED: C holds60%, L30%, R1%, O9% of issued PAIR-A claims. C's S0 model entitlement is 120,000 base and 240 quote.

UNKNOWN: Real locker code, future reserves, v3 active share and operator rights.

INSUFFICIENT EVIDENCE: L's30% cannot establish all liquidity locked. N1/N2 count cannot establish equal reserve rights. These fictional rules are not verification of any deployed lock.

Mixing project-token and LP-token supply; removing inaccessible but issued claims from denominator; confusing custody with enforced lock; estimating concentrated shares by NFT count; and turning a lock into global safety.

Calculate each claim fraction and C's hypothetical redemption amounts at S0. Compute ordinary redeemable claim coverage before S5 under the fixture. Explain why “two NFTs means 50% each” is unsupported.

• Verify pool, protocol/version and both exact assets.
• Identify the correct claim representation.
• Preserve all issued units in the stated denominator.
• Inspect custody, operators and release conditions.
• Use range-aware reasoning for concentrated positions.
• Bound calculations to their snapshot.

LP analysis maps reserves to mechanism-specific rights. Lock coverage and position ownership need precise scope.

Reserves are not withdrawal authority. A partial lock stays partial. Counting NFTs does not measure concentrated liquidity share.

Show PAIR-A reserves linked to 1000-unit claim ledger with 60/30/1/9% segments and S5 release boundary. Separate N1/N2 range panel with price/entitlement unknown; never convert NFT count to reserve share.

Illustrative LP rights under declared rules; no verified deployed lock.

Use deterministic SVG/HTML or charts with text alternatives, dark navy/black and restrained cyan, electric blue and violet. Label every quantity and uncertainty. At 390px stack panels; 768px/desktop and Arabic RTL verification remain future asset work. Keep identifiers LTR and factual axes/edge directions unchanged. Use only the official supplied ZECOIN mark if branding is added. Both records are specifications, not delivered assets.

Use RADAR for the lesson's bounded educational purpose only if network support, exact identity, fields and provenance are verified. No runtime endpoint or provider capability is asserted by this content. Use the embedded offline fixture without paid access. Missing data stays unknown; no wallet connection, transaction signature, token launch or live trade is required. Academy progress, payments and referrals never change Radar evidence. A Diagnostic Passport preserves observations and limits, not a price prediction or safety certificate.

• Uniswap v2 Pools — Fungible LP contribution and redemption claims, specific to v2. Checked 2026-09-30.
• Uniswap v3 Fetching Positions — Position manager, token pair, fee, ticks and liquidity fields. Checked 2026-09-30.

Documentation supports mechanisms, not fictional dataset values. All examples and exercise records are original ILLUSTRATIVE material, frozen in this file. S0/S1 are synthetic context labels; observedAt is null because no live or historical ledger measurement was collected. Re-review documentation and actual deployed behavior before any publication or integration.

P08-L07 after the worked exercise and quiz review.