What is a Liquidity Provider Token?

Introduction

liquidity provider tokens are tokens issued to someone who deposits assets into a liquidity pool. At first glance, they look like simple receipts: put assets into a pool, receive a token back, and later redeem that token for your share. But that plain description hides the reason LP tokens matter. They turn an otherwise messy claim on a changing pool of assets into something a wallet, smart contract, exchange, or lending system can hold and understand.

That is the central idea: an LP token is not just proof that you deposited something in the past. It is a live claim on a pool’s current state. If the pool earns fees, changes composition, or grows because other traders interact with it, the value represented by the LP token changes with it. This is why LP tokens became such an important DeFi building block. They let liquidity provision become programmable.

To see why they exist, start with the problem they solve. A liquidity pool may have many depositors and its balances may change every block as swaps happen. Without a tokenized claim, every pool would need a custom accounting system for every user, and every outside application would need pool-specific integration logic. LP tokens compress that complexity into a standard asset representation. Instead of tracking every provider with bespoke logic, the pool can say: the total ownership of this pool is divided into shares, and these shares are represented by tokens.

That basic pattern shows up across chains and protocols, but the exact token form depends on what the pool is trying to represent. In some systems, all liquidity in a pool is interchangeable, so LP shares can be fungible. In others, each liquidity position has its own price range or settings, so positions are not interchangeable and are better represented as non-fungible tokens. The mechanics are different, but the purpose is the same: represent a claim on pooled liquidity in a form other systems can work with.

How does an LP token represent a share of a liquidity pool?

The easiest way to think about an LP token is as a share certificate for a pool, with an important caveat: the certificate does not point to a fixed pile of assets set aside for you. It points to a fraction of a shared pool whose contents are constantly moving.

Suppose a pool starts empty. Alice deposits assets into it and receives LP tokens. If she is the first depositor, the protocol may mint an initial amount of LP supply according to its own accounting rules. Later Bob deposits assets in the same pool and receives newly minted LP tokens too. Now the total pool has more assets, and the total LP token supply is larger. Alice and Bob each own a fraction of the total LP supply, and that fraction determines their claim on the pool.

The key invariant is proportional ownership. If you own s LP tokens out of a total supply S, then your share of the pool is s / S. What you can redeem is not a fixed number of the original tokens you deposited, but that proportion of whatever the pool currently holds. If the pool now holds balances x and y of two underlying assets, your claim is approximately (s / S) * x of the first asset and (s / S) * y of the second, subject to the protocol’s specific accounting and fee logic.

This is the idea that makes LP tokens click: the token tracks a fraction, not a fixed amount. That is why LP token balances can stay numerically unchanged while the economic value behind them changes. A trader swaps through the pool, paying fees. Those fees stay in the pool or are accounted to positions. The pool’s assets change. Your LP token balance may still be the same, but each token now corresponds to a slightly larger claim.

A simple worked example makes this concrete. Imagine a pool with 100 units of token A and 100 units of token B, and suppose the pool has issued 100 LP tokens in total. If you hold 10 LP tokens, you own 10% of the pool. If trading activity later causes the pool to hold 110 A and 108 B after fees and arbitrage effects, your 10 LP tokens still represent 10%; but now that means a claim on 11 A and 10.8 B. Nothing about the token balance itself had to change. What changed was the state of the pool the token refers to.

That is why calling LP tokens “receipts” is useful but incomplete. A paper receipt usually records a past event. An LP token is better understood as a floating ownership unit whose value depends on current pool reserves, pool rules, and sometimes uncollected fees.

Why do protocols issue LP tokens instead of keeping internal provider ledgers?

A pool could, in theory, store an internal ledger of who owns what and never issue a token. Some protocols do this in limited contexts. But tokenizing the claim has major consequences.

The first consequence is interoperability. If the ownership claim is expressed as a standard token, wallets can display it, users can transfer it, and other contracts can accept it. On Ethereum, fungible LP shares are often implemented with the ERC-20 interface, which defines common methods for transfer and approval. That standardization is what allows an LP share from one protocol to be staked in another, posted as collateral somewhere else, or simply sent between accounts like other fungible tokens.

The second consequence is composability. DeFi systems are built by chaining contracts together. A farming contract can reward users who deposit LP tokens. A vault can accept LP tokens and automate strategies around them. A lending market can decide whether to treat LP tokens as collateral. None of this is easy if each pool keeps a private, non-transferable internal ledger. Tokenization makes the ownership claim portable.

The third consequence is separation of concerns. The pool focuses on pricing, swaps, deposits, and withdrawals. External systems interact with a tokenized claim rather than re-implementing the pool’s accounting. This modularity is one reason DeFi grew quickly: protocols could treat claims on other protocols as assets in their own right.

There is a tradeoff, though. Once the claim becomes a token, that token inherits the strengths and weaknesses of its token standard. ERC-20 approvals can be misused if integrations handle allowances poorly. Transfer semantics matter. Event emissions matter for indexers and analytics. A tokenized claim is easier to compose with other systems, but it also becomes exposed to the integration mistakes and security assumptions of those systems.

When should LP tokens be fungible (ERC‑20) versus non‑fungible (ERC‑721)?

A common misunderstanding is that LP tokens are always just ERC-20 tokens. That was true for many early automated market maker designs, but it is not true in general.

Whether an LP claim can be fungible depends on whether different providers are contributing the same economic object. In a simple pool where every provider deposits into one shared reserve under one set of rules, each share is interchangeable with every other share. If you and I both own 1% of the same constant-product pool, our claims are economically equivalent. That makes fungible tokenization natural.

This was the model behind many early AMMs. A single pool for a pair of assets, one fee setting, one shared reserve curve, one shared pro-rata claim. In that world, a fungible LP token works well because it represents identical slices of the same pie.

But concentrated-liquidity systems changed the picture. Uniswap v3 is the clearest example. There, liquidity is not just “in the pool.” A provider chooses a price range over which their liquidity is active. Two users can deposit the same assets into the same token pair but choose different ranges, and those positions will behave differently, earn different fees, and carry different market exposures. They are not interchangeable.

That is why Uniswap v3 positions are non-fungible. The protocol’s whitepaper is explicit: because positions are non-fungible, the pool contract no longer mints a single fungible ERC-20 share token. Instead, positions are represented through tokenized wrappers in the periphery, commonly as ERC-721 NFTs. Each position has unique parameters, so each position gets a unique identifier rather than a fungible balance.

This distinction is fundamental, not cosmetic. If two claims differ in how they react to price movement or fees, making them fungible would hide economically important differences. Fungibility is appropriate only when the claims are truly interchangeable.

Which token standards are used to represent LP tokens across chains?

On Ethereum and similar smart-contract platforms, the form of an LP token usually follows one of three standard patterns.

The first is ERC-20, used for fungible shares. ERC-20 defines a common interface for balances, transfers, approvals, allowances, and transfer-related events. This is the standard most people picture when they think of LP tokens: a pool mints transferable share tokens to depositors and burns them when liquidity is removed. Because ERC-20 is widely supported, these LP tokens are easy for wallets, aggregators, and other contracts to integrate.

The second is ERC-721, used when each liquidity position is unique. ERC-721 defines non-fungible tokens identified by a tokenId, with transfer rules and optional metadata. For LP positions, this is useful when a position has unique parameters such as range bounds, fee tier, or strategy settings. The token is not representing interchangeable shares; it is representing this specific position.

The third is ERC-1155, which can represent many token types from one contract, including fungible, non-fungible, or semi-fungible assets. This is less canonical for LP positions than ERC-20 or ERC-721, but it is a useful design when a protocol wants many related receipt token types managed together in one contract. Its batch transfer support can reduce transaction costs when multiple token types move at once.

Outside Ethereum, the same design problem appears under different token systems. On Solana, LP receipt assets can be implemented using the SPL token model or its extensible Token-2022 variant, which preserves core token semantics while adding optional extensions. In Cosmos ecosystems such as Osmosis, LP claims may be represented through chain-native asset mechanisms and pool-specific accounting rather than Ethereum-style contract standards. The details differ, but the underlying purpose remains the same: create a transferable, machine-readable claim on pool ownership.

How are LP tokens minted and burned when liquidity is added or removed?

LP tokens are usually minted when liquidity is added and burned when liquidity is removed. That sounds trivial, but the important question is how much to mint or burn.

The answer comes from preserving proportional ownership. When a user adds liquidity to an existing fungible-share pool, the protocol typically mints LP tokens so that the user’s fraction of total LP supply matches the fraction of pool value or reserves they contributed, according to that pool’s deposit rules. If a deposit is unbalanced or the pool uses special invariants, the exact formula can vary. But the goal is always to prevent a new entrant from receiving a larger claim than the assets they added justify.

When liquidity is removed, the reverse happens. LP tokens are burned, and the holder receives the corresponding proportion of underlying assets. Burn first, redeem the fraction of reserves implied by the burned shares. This preserves consistency between pool balances and share supply.

In standards terms, fungible LP tokens often use ERC-20 mint and burn behavior, with transfers from or to the zero address reflected in Transfer events. Indexers and analytics systems depend on those semantics to reconstruct supply changes. For NFT-style positions, the position token is minted when the position is created and burned when it is closed, but the economic claim depends on the protocol’s position accounting rather than simple pool-wide pro-rata shares.

What matters is not the token event by itself. The event is only the surface representation. The deeper mechanism is that token supply changes must stay aligned with claim creation and claim destruction. If that alignment is wrong, the token ceases to represent ownership faithfully.

How do fees and pool state affect LP token valuation?

People often ask, “What is the price of an LP token?” The question seems simple, but the answer is less stable than for a normal token because an LP token does not point to one underlying asset. It points to a changing basket plus fee rights.

In a fungible pool, the notional value per LP token is often estimated by taking the current value of the pool’s reserves and dividing by LP token supply. That gives a snapshot estimate. But even that can be fragile because reserve values depend on external prices, the pool may hold assets in volatile proportions, and fees may be embedded in reserves or accounted separately depending on design.

In concentrated-liquidity systems, valuation is even trickier. Uniswap v3 positions earn fees according to position-specific liquidity and the fee growth that occurred while the position was active in range. The whitepaper makes clear that fees are accounted separately; they are not automatically compounded into liquidity. So the economic value of a position is not just “current reserves divided by total supply,” because there may not even be a single fungible supply. Instead, valuation depends on the position’s range, active status, liquidity measure, and accrued but uncollected fees.

This is where many integrations get into trouble. LP tokens are easy to move around as tokens, but hard to price safely. A plain wallet display is one thing. Using LP token value inside lending, reward, or collateral logic is much harder, because transient pool manipulation can distort reserve-based valuations.

The PancakeBunny exploit is a vivid example from the wider ecosystem. In that incident, an attacker used flash loans to manipulate AMM pool prices, minted LP tokens during the manipulated state, and exploited reward logic that relied on the inflated LP valuation. The lesson is not that LP tokens are broken. The lesson is that a claim on a pool is only as reliable as the pricing assumptions used to value that claim.

This is also why theory around constant function market makers matters. Research on CFMMs has shown, under stated assumptions, useful bounds on reserves and incentives around price reporting. But those are model-based results, not a blanket guarantee that every LP token oracle in production is safe. The gap between protocol mechanics and integration assumptions is where many failures happen.

What can you do with LP tokens after you receive them?

Once an LP token exists, it often starts a second life beyond simple redemption.

The most direct use is obvious: it lets the provider withdraw liquidity later. But the more distinctive use is as a composable financial primitive. A farming or liquidity-mining program can ask users to deposit LP tokens and reward them for supplying depth to a market. This works because the LP token is a transferable proof of pool ownership. The reward contract does not need to manage the underlying pool directly; it only needs to recognize the LP token.

That same portability enables vaults and wrappers. A vault may accept LP tokens, stake them elsewhere, auto-compound rewards, or issue a secondary token representing shares in the vault. In more advanced designs, protocols build fungible wrappers around otherwise non-fungible positions, abstracting away position management while adding logic for fee collection and reinvestment.

This is where LP tokens connect naturally to liquidity mining. Incentive programs usually do not reward “having deposited once.” They reward holding the claim on active liquidity, which is why staking the LP token becomes the mechanism. The token is the object that proves the user still owns the liquidity position.

The cost of this composability is recursive dependency. If a vault holds LP tokens and another protocol values the vault token, the resulting asset depends on multiple layers of accounting and assumptions. Each layer can be sensible in isolation, yet the total system can become hard to reason about under stress.

What assumptions about LP tokens commonly fail in practice?

The simplest story says LP tokens are just proportional claims on a pool. That is a good start, but several assumptions can fail.

The first is the assumption of straightforward fungibility. As soon as liquidity positions differ by range, maturity, fee treatment, or other parameters, a single fungible token may no longer be an honest representation. The protocol must either keep the positions non-fungible or create a wrapper that deliberately standardizes and manages those differences.

The second is the assumption that token standards are enough. ERC-20, ERC-721, and ERC-1155 provide interfaces, not economic truth. ERC-20 can tell you a balance and let you transfer it, but it does not specify how pool shares should be priced, how fees should accrue, or how precision and rounding should be handled. Those semantics come from the pool design.

The third is the assumption that the token’s market value cleanly matches redeemable value. In practice, LP tokens can trade at discounts or premiums in secondary contexts, may be illiquid themselves, or may be hard to redeem quickly if wrapped or locked. A tokenized claim is not identical to immediate extraction of underlying assets under all circumstances.

The fourth is the assumption that transferability is always good. Transferable LP tokens are flexible, but that flexibility can create attack surface. Approval races in ERC-20 integrations, unsafe valuation methods, and composability loops all become relevant once the claim is freely movable and reusable.

Finally, there is the assumption that the pool itself is economically neutral. It is not. LP positions are exposed to trading flow, fee dynamics, and inventory changes. The token is merely the container for that exposure. Owning an LP token means owning the economics of liquidity provision, not a static savings balance.

How do LP token designs vary across blockchains and architectures?

It is tempting to define LP tokens too narrowly as “ERC-20 tokens from AMMs on Ethereum.” That is historically understandable, but conceptually wrong.

The more durable definition is this: an LP token is a tokenized claim on liquidity contributed to a pool. The claim may be fungible or non-fungible. It may live under ERC-20, ERC-721, ERC-1155, SPL-style token programs, or chain-native asset representations. The exact wrapper changes with the architecture and the pool design.

You can see the same pattern repeated across ecosystems. Ethereum protocols often expose LP claims through contract standards because that ecosystem is contract-centric and composability-heavy. Solana systems may use token-program-based assets with different account models. Cosmos-based systems may express pool shares through native denoms and module logic. These are implementation choices around a shared underlying need: represent pool ownership as an asset other software can recognize.

That is why LP tokens belong in a discussion about tokens and standards, but also why standards alone do not define them. The token layer tells us how the claim is carried. The pool mechanism tells us what the claim means.

Conclusion

A liquidity provider token is best understood as a tokenized ownership share in a liquidity pool. Its job is to turn a changing, protocol-specific claim on pooled assets into something transferable, programmable, and legible to other software.

Everything else follows from that. If all shares are economically identical, the LP token can be fungible. If each position is unique, the claim may need to be an NFT or another non-fungible form. If fees accrue, the value behind the token changes even when the token balance does not. And if outside protocols rely on the token, they must understand not just the token standard but the pool accounting beneath it.

The short version worth remembering tomorrow is this: **an LP token is not the liquidity itself; it is the on-chain claim that makes liquidity ownable and composable. **

How do you evaluate a token before using or buying it?

Evaluate a token by checking its standard, mint/burn rules, fee accrual, and approval surface before you trade or grant allowances. Use Cube to inspect the on‑chain contract links and then fund, approve, or trade the asset on Cube once you’ve validated the mechanics.

1. Open the token’s contract on a block explorer or the asset page in Cube and confirm the token standard (ERC‑20, ERC‑721, ERC‑1155, SPL, etc.) and the contract owner/minter addresses.
2. Check minting and burning history: look for Transfer events from/to the zero address and any privileged minter roles; flag tokens with permissioned minters or unlimited mint caps.
3. Verify how the LP token accrues value and fees: read the protocol docs or contract comments to see if fees auto‑compound into reserves, are held separately, or are position‑specific (e.g., Uniswap v3 range accrual).
4. Fund your Cube account, set a narrow token allowance for the exact contract and amount, then place a limit order or a market buy on Cube depending on whether you need price control.