Uniswap v2 LP tokens: check the pool assets behind your balance

A Uniswap v2 LP token balance describes a share of a particular pool, not a quantity of either token inside it. For a read-only accounting snapshot, divide your LP balance by the pair’s total LP supply, then apply that fraction to each recorded reserve. Match each reserve to its token address and decimal scale.

This produces a way to describe an existing position. It is not a guaranteed withdrawal amount, a profit calculation or an instruction to remove liquidity. A wallet row labelled UNI-V2 is only a starting point: many different pairs use that label.

Find the pair before interpreting its LP balance

Uniswap’s v2 pool explanation describes liquidity tokens issued to providers. The official LP token implementation uses the same name and symbol across pairs. A symbol alone therefore cannot identify which assets a holding represents.

Start with the network and full pair contract address from a known liquidity transaction or the protocol interface you already trust. Confirm the factory through the official v2 deployment list, and check that the intended tokens correspond to that factory’s pair. A copied name or a contract exposing familiar methods is not proof of an official deployment.

The pair contract is also the LP token contract in this v2 implementation. Read its token0() and token1() addresses before using reserve figures. reserve0 belongs to token0; reserve1 belongs to token1. Do not assign the two amounts by the order of ticker symbols on another screen.

Keep this procedure scoped to ordinary Uniswap v2 pairs. A fork, a managed vault or a concentrated position may use different accounting. A Uniswap v3 position NFT needs its own position record rather than this LP-supply calculation.

Gather one consistent set of quantities

For a directly held LP position, collect these reads from the verified pair and token contracts:

Read or field	Meaning	Unit to preserve
Pair balanceOf(account)	LP tokens held by this account	LP units
Pair totalSupply()	All issued LP tokens	Same LP units
Pair getReserves()	Recorded reserves on each side	Raw token integers
Pair token0() and token1()	Addresses identifying the two assets	Full addresses
Each token’s decimals	Scale for its raw reserve amount	Its own scale

Prefer a common block for all reads. If the reader only offers separate latest-state calls, save their times and mark the comparison as potentially inconsistent. A trade, deposit or withdrawal between calls can change the inputs.

LP balance and total supply must use the same scale. Dividing two raw LP integers is valid for the fraction, as is dividing two correctly formatted LP quantities. Mixing a raw integer with a formatted number is not. For the reserve outputs, use each underlying token’s decimals independently; the token-decimal guide explains that conversion. Unknown metadata stays unresolved rather than defaulting to 18.

Do not subtract locked or otherwise inaccessible LP tokens from the reported total supply to make your percentage larger. This calculation uses the contract’s issued supply, not a guessed circulating supply. If the supply is zero or an essential read fails, stop the calculation and record the missing input.

Work through a labelled snapshot

Consider a hypothetical pair whose figures are already formatted into readable units. It has 500 LP tokens issued, and your account directly holds 5 LP tokens. The recorded reserves are 80 units of token A and 24000 units of token B. These are invented quantities, not a live pool or price quote.

The LP fraction is 5 / 500 = 0.01, or 1%. Applied to the recorded reserves, it gives:

• Token A: 80 * 0.01 = 0.8 units.
• Token B: 24000 * 0.01 = 240 units.

The resulting record is one LP position with a reserve-based equivalent of 0.8 A and 240 B at that snapshot. It is not 5 A plus 5 B, and the reserve quantities are not dollar prices. No assumption that B is a stablecoin is needed.

Do not add the LP token’s displayed value and the value of those same underlying quantities as two separate holdings. Tokens independently held outside the pool are a separate balance. When a dashboard already looks through the LP token to its underlying assets, establish what is included before adding anything manually.

This also differs from measuring performance. Your current reserve share does not tell you the original quantities deposited, subsequent flows, costs or what simply holding the original assets would be worth. The impermanent-loss comparison covers that separate question.

Understand why this is not a redemption promise

The pair implementation records reserves separately from its actual token balances. Its burn calculation uses balances and can mint protocol-fee LP tokens before selecting the total supply. Integer division also rounds the calculated amounts. A fraction of earlier recorded reserves must therefore not be presented as the exact amount a removal transaction will deliver.

The transaction can occur in a different state from your observation. Token-specific transfer rules can affect received amounts too. Use the protocol’s current removal estimate and conditions if you separately decide to transact; do not send LP tokens directly to the pair or call its low-level burn function as part of this inspection.

Reserve quantities already reflect the pool’s recorded state. Adding an extra fee-income estimate to those quantities can count value twice. This guide does not calculate a fee payout, future yield or a current protocol-fee rate.

Custody creates another boundary. If LP tokens were staked or deposited into a vault, your wallet’s direct balanceOf can be zero while that service records a claim for you. Inspect the known deposit and the service’s own accounting. Do not assign the service’s entire LP balance to your account, and do not reuse the simple wallet calculation for a vault receipt token without its conversion rules.

Save a record you can check again

These steps are based on the public documentation and source inspected on 28 October 2026. They were not tested against a live wallet or pool for this article.

1. Verify the position. Record the network, pair, factory, account and both underlying token addresses through trusted protocol records.
2. Establish where the LP tokens are held. Distinguish direct wallet ownership from staking, vault or other custody records.
3. Collect a consistent snapshot. Save LP balance, issued LP supply, both reserves, their token mapping and decimal scales, with a block or observation times.
4. Calculate only when the inputs are usable. Divide matching LP units, then apply the fraction separately to both reserves. Preserve enough precision; do not round the fraction to zero before multiplying.
5. Label the result and reconcile once. Mark it as a reserve-based accounting estimate, retain custody and missing-data notes, and check whether another portfolio row already represents the same position.

These public reads do not require a wallet signature, approval or recovery phrase. A request to move funds is outside this procedure. You have a useful result when you can explain which pair you hold, what its reserve quantities represent and why the snapshot differs from a withdrawal quote. Leave unresolved fields unknown rather than turning a display gap into a precise balance.