Adding and removing liquidity: what the transaction actually does

The short answer

Adding liquidity deposits both assets into the pool account and mints an LP token representing a pro-rata claim on everything the pool holds. Removing liquidity burns that token and returns the corresponding share of the current balances. The word current is doing most of the work in that sentence.

Because the claim is on the pool as it stands rather than on the specific tokens supplied, the basket that comes back is almost never the basket that went in. Trading during the stay rebalanced the pool, and the claim rebalanced with it. Fees, where the venue keeps them in the reserves, are already included in what comes back.

Everything else in this entry follows from that one structural fact. The transaction mechanics, the ratio requirement, the exit arithmetic and most of the mistakes providers make all trace back to treating an LP token as a receipt for deposited assets when it is a share of a moving balance.

What adding liquidity does

The add instruction takes both token amounts from the provider, transfers them into the pool's token accounts, and mints LP tokens to the provider in proportion to the increase in pool size. The claim itself is an ordinary SPL Token program mint, which is why an LP token appears in a wallet exactly like any other balance. If the pool held a certain amount and the deposit increases it by five per cent, the provider receives LP tokens equal to five per cent of the new supply.

Crucially the quoted price does not change. A deposit at the prevailing ratio increases both reserves proportionally, so the ratio is untouched and the pool quotes exactly what it quoted a moment earlier. What changes is the product, which is to say the depth. A deposit makes trades cheaper without moving the price, which is the whole function of liquidity provision.

The pool programs themselves document this proportional accounting rather than leaving it implicit, and Raydium's protocol documentation describes deposits and redemptions in those terms. For the very first deposit into an empty pool the situation is different, because there is no prevailing ratio. The initial depositor sets it by choosing the two amounts, and that choice is the pool's opening price. Every later trader is trading against a price that somebody simply picked, which is worth remembering when a newly created pool quotes something surprising.

On the reading side, an add is easy to identify: LP supply rises, both reserves rise, and the ratio between them barely moves. No swap can produce that combination, which makes it one of the cleanest signatures in pool data.

What removing liquidity does

The remove instruction burns some or all of the provider's LP tokens and transfers out the corresponding fraction of both reserves. A provider holding five per cent of supply receives five per cent of each reserve, whatever those reserves currently are.

Again the ratio is unchanged, because both reserves fall proportionally. The pool quotes the same price after a withdrawal as before it, but it is shallower, so the next trade of any size moves the price further than it would have. This is why withdrawals matter to traders who have no position in the pool at all: they change what everyone else's execution costs.

The signature is the mirror of a deposit and equally clean: LP supply falls, both reserves fall, and the ratio holds. Any reading that sees both balances shrink together should immediately stop attributing the change to trading, because no swap can take assets out of both sides at once.

Partial withdrawals and dilution

Nothing requires a provider to exit all at once. Burning part of a holding returns the corresponding share and leaves the rest in place, which is how most large positions are actually managed. The arithmetic is identical, applied to a smaller fraction.

What does change over time is the fraction itself. A provider's share falls whenever somebody else deposits, because supply grows while their holding does not. A position that began as a tenth of a pool can be a fortieth some weeks later without its owner doing anything at all, and any assessment that assumes the original share is measuring the wrong claim.

The ratio requirement

A classic pool requires deposits at the prevailing ratio. This sounds like a formality and has a practical consequence that catches people out constantly: to enter a pool you must already hold the two assets in the right proportion, or acquire them, and acquiring them means trading, which means price impact.

Interfaces that offer to deposit a single asset are doing the trade for you. That is convenient and entirely legitimate, but the cost is real and it is paid before the position exists. On a thin pool the swap needed to balance a deposit can cost more than several days of fee accrual, and it is invisible in any later accounting of how the position performed.

The same applies in reverse on exit. A provider who wants to end up holding one asset receives two and must trade one for the other, paying impact again, this time against a pool they have just made shallower by withdrawing from it. Planning the exit as a two-step operation rather than one is the difference between an expected outcome and an unpleasant surprise.

A worked round trip, illustrative

Run the same example with the price of A falling instead and the pool hands back more A and less B, which is the same mechanism pointing the other way. In both directions the pool ends up holding more of whichever asset performed worse. That is not a flaw; it is what providing a two-sided quote means.

A sequence for adding

1. Read the pool before the interface Pull both raw reserve balances and the LP supply. This establishes the ratio you will be depositing at and gives you a baseline to compare against later.
2. Build the ladder for your own size Work out what your balancing swap will cost in price impact before you make it. On a thin pool this is frequently the largest single cost of the whole exercise.
3. Decide the range if the venue has one A concentrated position needs an interval. Narrow earns more while the price stays inside and stops entirely when it leaves. Wide earns less per unit and keeps quoting.
4. Check where the fee actually goes Confirm whether the venue retains fees in the reserves or accrues them separately, because that decides whether your claim grows on its own or requires a claim action.
5. Record the entry state Write down both reserves, LP supply, your share and the ratio at the moment of deposit. Without that record no later assessment of the position is possible.

Checks before removing

• Recompute your share from current LP supply rather than assuming it is what it was at entry, since other deposits dilute it.
• Work out the basket you will receive at the current ratio, so the composition is not a surprise.
• Estimate the price impact of any swap you intend to make afterwards, against the pool as it will be once you have withdrawn from it.
• Check whether unclaimed fees exist separately and whether burning the position forfeits or transfers them.
• On concentrated venues, confirm whether the price is currently inside your range, because that determines which asset you receive.
• Compare the outcome against what holding both assets would have produced, so the comparison is made deliberately rather than avoided.

The last check is the one most often skipped, and it is the one that turns a provider into an informed provider. Being able to state plainly how a position performed against holding is uncomfortable in some periods and useful in all of them.

Concentrated positions differ

On a concentrated venue the position is not a fungible share of the whole pool. It is a specific interval with its own accounting, usually represented by a distinct position account rather than a fungible token, an arrangement set out in Orca's developer documentation. That difference propagates through everything.

While the price sits inside the range, the position earns fees at a rate reflecting its outsized contribution to depth in that region. When the price leaves the range, the position is entirely in one asset and earns nothing. It has not been liquidated and nothing has been lost beyond the opportunity, but it is now an idle holding of a single token rather than a liquidity position.

This makes range choice the dominant decision, and it makes the position an active one. Providers who set a narrow range and stop paying attention frequently find the position out of range and inert. Providers who reposition often pay swap costs each time. Neither is wrong and both are choices with a price, which is worth understanding before rather than after.

Two position types compared

Mistakes that cost real money

The first is treating the LP token as a claim on deposited assets. It is a claim on current balances, and every consequence of that follows automatically. Providers who understand this stop being surprised by their exit basket.

The second is ignoring the balancing swap. Entering and exiting both usually involve a trade, and on thin pairs those two trades can dominate the economics of the entire position. Counting them is straightforward and rarely done.

The third is assuming fee income covers the gap against holding. Sometimes it does; there is no rule that says it must, and the size of the gap depends on how far the price ratio moves, which nobody controls. Any framing that presents fee accrual as compensation guaranteed to arrive is describing a wish rather than a mechanism.

The fourth is confusing activity with earning. Fees accrue from flow through the specific position, so a pair that is busy on another venue or at another price does nothing for a position sitting outside that flow. Anyone studying the movement side of this, including operators of Solana volume automation who care where routed trades actually land, ends up looking at the same routing and range data that a provider should look at before choosing an interval.

The last is treating a lock as a guarantee. A locked position cannot be withdrawn for its term; every unlocked position in the same pool still can, and the lock ends. Reading a lock as a statement about the pool rather than about one position is a specific and common error, and it belongs on this list because the mistake is about accounting rather than judgement.

Questions this entry gets asked