LP tokens usually divide a common pool claim into interchangeable units. A liquidity position NFT identifies one separately tracked position, such as a chosen price range in Uniswap v3 or v4’s PositionManager. Transferring either token can change who controls the claim without withdrawing the underlying assets. The contract version, manager and current position state determine what the new owner can collect.
A wallet can display “150 LP tokens” beside “1 position NFT,” but those numbers measure different things. The first may be a divisible share balance. The second counts an identifier. Neither number, by itself, tells you the underlying token quantities or their value.
Interchangeable units need a common claim
In Uniswap v2, each pool issues its own fungible ERC-20 liquidity token. Units issued by the same pool contract participate in the same reserve claim. Tokens from another pool are different assets, even if their wallet labels both say UNI-V2. Uniswap’s v2 pool documentation explains how pool tokens represent contributions and are burned to retrieve underlying liquidity.
For a simplified snapshot, the claim on each underlying token is the LP balance divided by total LP supply, multiplied by that token’s pool balance. Swaps and fees can change the balances behind each unit. The original deposit is therefore a historical input, rather than a fixed redemption package.
Consider a hypothetical existing pool containing 40 A and 80,000 B, with 2,000 LP units outstanding. Alice owns 150 units. Assume balances equal reserves, ordinary token transfers, no intervening swaps or deposits, and no protocol-fee mint dilution or rounding effects during these operations. Total supply includes all outstanding units, including any inaccessible ones.
Alice’s fraction is 150 / 2,000 = 7.5%. Her proportional claim is 3 A and 6,000 B. She transfers 50 LP units to Bob:
| State | Alice’s LP units | Bob’s LP units | Pool supply |
|---|---|---|---|
| Before transfer | 150 | 0 | 2,000 |
| After transfer | 100 | 50 | 2,000 |
| After Bob redeems all his units | 100 | 0 | 1,950 |
The transfer itself sends no A or B out of the pool. Alice now controls a claim on 2 A and 4,000 B; Bob controls a claim on 1 A and 2,000 B. Those claims add back to the original 3 A and 6,000 B.
If Bob then redeems, he receives 1 A and 2,000 B. The pool retains 39 A and 78,000 B. Alice’s pool share rises from 5% immediately after the transfer to approximately 5.1282%, but her claim remains 2 A and 4,000 B: 100 / 1,950 times the remaining balances. A larger percentage after another provider exits need not mean more assets.
The actual v2 pair contract computes burn proceeds from balances and supply after checking protocol-fee minting. Live calculations must include that state, token decimals and integer rounding. The example deliberately removes those complications so transfer and redemption can be compared directly.
A position identifier carries different information
Concentrated liquidity allows separately configured price ranges. Two positions in the same pool can have different bounds, liquidity and fee histories. Counting their NFTs as two equal pool shares would discard the information needed to determine their claims.
Uniswap v3’s NonfungiblePositionManager source associates each token identifier with position data, including bounds, liquidity, fee-growth checkpoints and owed tokens. The NFT provides an ownership interface for that record. Its liquidity parameter, L, is not a balance of A, B or dollars.
This is a manager convention. The v3 core position library identifies core positions by owner and tick boundaries; an NFT wrapper is not required by the idea of concentrated liquidity itself. A different manager or vault can expose a different ownership instrument.
| Question | Plain v2 pool token | v3 position-manager NFT |
|---|---|---|
| What does the wallet balance count? | Divisible units of one pool’s token | Distinct position identifiers |
| Can a transfer split the instrument? | Yes, by transferring some units | A normal NFT transfer moves the whole identifier |
| Which state determines principal? | Pool balances and LP supply | Position liquidity, bounds and pool price |
| Where are swap fees accounted? | Within the pool reserves | Separately from position principal |
That fee-accounting difference is documented in Uniswap’s fee overview. Adding a separate fee estimate to a v2 reserve claim can count the same value twice. The pool fees versus net return guide extends this distinction into a complete performance ledger.
Follow one NFT through three different operations
Take a separate hypothetical v3 position, NFT 712. Its current principal is 5 A and 24,000 B, its L is 1,200, and accrued uncollected fees are 0.08 A and 120 B. These are stipulated snapshot inputs, not a live pool quote or an instruction to deposit those amounts.
Keep price and range fixed, assume no additional swaps or fees between steps, and ignore gas and rounding. For unchanged price and bounds, removing one quarter of L removes one quarter of principal. Token A and B have no assumed dollar value here.
The opening fees in this ledger are assumed to be reflected in the manager’s stored owed balances. In a live position, tokensOwed0 and tokensOwed1 alone can omit later fee growth. Collection updates that fee accounting for a funded position before payment. The v3 manager’s collection logic shows this update.
Alice first transfers the NFT to Bob. The same position, including its uncollected claim, is now under Bob’s ownership. Uniswap’s ownership explanation explicitly distinguishes this transfer of ownership. There is no underlying-token payout from the transfer alone.
Bob next decreases L by 300, or 25% of 1,200. Released principal is 1.25 A and 6,000 B. Under the v3 manager, decreasing liquidity credits owed tokens; collection is the separate operation that sends them to a recipient. Its decrease-liquidity guide demonstrates both calls together.
Assume Bob has collected nothing earlier and then collects all owed tokens to his own wallet:
| Confirmed state | L | Principal A / B | Owed A / B | Cumulative receipt A / B |
|---|---|---|---|---|
| Bob receives NFT | 1,200 | 5 / 24,000 | 0.08 / 120 | 0 / 0 |
| Bob decreases L by 300 | 900 | 3.75 / 18,000 | 1.33 / 6,120 | 0 / 0 |
| Bob collects all owed tokens | 900 | 3.75 / 18,000 | 0 / 0 | 1.33 / 6,120 |
The middle row’s owed balance combines released principal and previously earned fees: 1.25 + 0.08 = 1.33 A, and 6,000 + 120 = 6,120 B. Calling that entire amount “fees” would misclassify the withdrawal.
After collection, remaining principal plus wallet receipts is 5.08 A and 24,120 B. That exactly matches opening principal plus fees. Collection changes the location of the claim; it does not create another 1.33 A and 6,120 B of income.
As an alternative to decreasing liquidity, Bob could collect fees while leaving L unchanged. Uniswap’s v3 collection guide shows fee collection while maintaining custody of the NFT. Transfer, decrease and collection answer three different questions: who controls the record, how much liquidity remains, and which tokens reached the recipient.
If Bob later removes the remaining liquidity and collects everything, the NFT can still exist with zero liquidity and zero owed tokens. In the v3 manager, explicitly burning the NFT requires those balances to be cleared first. Possessing an NFT therefore does not establish that it remains funded.
Read v4 at the correct contract layer
Uniswap v4’s supplied PositionManager contract also mints ERC-721 position NFTs. That does not make every token balance within v4 a position NFT.
The PoolManager also supports ERC-6909 currency claims. Uniswap’s ERC-6909 guide describes using those balances to resolve currency obligations. A claim denominated in one currency is a different object from an NFT identifying liquidity across a price range. Record the contract and identifier before interpreting either balance.
The v3 operation sequence also needs translation. v4’s PositionManager guide uses commands and currency-settlement actions; fee collection can use a zero-liquidity decrease followed by a take action. Its decrease guide pairs reducing liquidity with actions that deliver the resulting currencies. Check the complete transaction payload, recipient and hook configuration rather than assuming a familiar method name establishes the result.
Check the ownership path before valuing the position
The most useful worksheet starts with contract state and ends with confirmed receipts:
| Record to save | What to validate |
|---|---|
| Chain and contract address | The displayed token is the intended pool share, manager NFT or vault receipt |
| LP balance and total supply | Both refer to the same fungible pool token and state reference |
| NFT owner and token identifier | The current owner controls the intended position record |
| Pool, range and liquidity | The position is funded and its principal calculation uses matching state |
| Fee checkpoints and owed tokens | Current fee growth is included; released principal is identified separately |
| Approvals and custody | The proposed caller has the required authority and the destination can manage the claim |
| Operation and recipient | Transfer, decrease, collect and burn produce the intended state and payout |
| Receipt and valuation timestamp | Actual quantities reconcile before applying a price or reporting-currency mark |
Several failure cases follow directly. An NFT marketplace image may persist after all liquidity is removed. A missing wallet display does not prove the position was redeemed. An LP token deposited into a separate staking or vault contract requires checking that contract’s withdrawal rights; the depositor’s wallet balance alone no longer describes the custody path.
Approvals also matter. ERC-721 permits approved addresses or operators to transfer NFTs, and its safe-transfer interface checks contract recipients for the required receiver response. A receiving contract must still support the intended management workflow. These are token-standard rules, not guarantees about recoverable principal.
A funded position can also be outside its active range; the out-of-range liquidity guide explains the resulting inventory and fee eligibility. For valuation, identify whether the mark uses a spot price or TWAP oracle, then record its time. Neither ownership format supplies a price guarantee.
The same discipline applies to other wrappers: a transferable token’s label does not reveal its economic exposure. The daily-reset leveraged-token example follows a different mechanism that likewise requires reading the rules behind the token.
Before transferring or withdrawing, write down the exact claim, the current controller and the expected underlying-token receipt. After confirmation, reconcile those three records. A token moving wallets and assets leaving a pool should appear as different events in that ledger.