Impermanent Loss in Plain English: Liquidity Pools and Costs

Impermanent loss in plain English is the gap between what your tokens are worth inside a liquidity pool and what they would be worth if you had simply left them in your wallet. It appears when the price of one token moves relative to the other, and it is what makes an «add liquidity» task more expensive than it looks at first glance. Below: how a pool works, where the loss comes from, what to calculate before depositing and which risks sit alongside.

This article explains the mechanics and a way to count costs; it does not recommend providing liquidity or avoiding it. The numbers in the examples are conditional and used for illustration only. Nothing here is a price or yield forecast or a guarantee of a reward. This is not financial, tax or legal advice.

How a liquidity pool works

A classic decentralized exchange (an AMM) has no order book and no human counterparty. Instead there is a pool: a smart contract holding two tokens. Swaps happen against that pool, and the price follows a simple rule: the product of the token amounts stays constant, x * y = k. When a trader takes one token out, they must put the other one in, and the ratio between them shifts. That is how the in-pool price tracks the market: if a token is being bought up, it becomes more expensive relative to its pair, and arbitrageurs align the price with the rest of the market.

The pool is filled by liquidity providers (LPs). They deposit both tokens in equal value and receive LP tokens in return, a receipt confirming their share of the pool. By burning LP tokens you can withdraw your share, but in the proportions the pool holds at that moment, not the ones you started with. Impermanent loss lives in exactly that gap.

An LP earns fees from every swap: a small percentage of the swap amount is split among providers in proportion to their shares. The fee size depends on the pool and the protocol.

A conditional example: where the loss comes from

Take an illustration with round numbers, unrelated to any real token. The pool holds 10 tokens A and 1,000 stablecoins S, so 1 token A costs 100 S and k = 10,000. The whole pool is worth 2,000 S, and let your share be 100% (easier to count).

Suppose the market price of A doubles to 200 S. Arbitrageurs will take A out of the pool until the in-pool price matches the market. The condition x * y = 10,000 at a price of 200 gives roughly 7.07 tokens A and 1,414 S. Counting:

In the pool: 7.07 A at 200 S plus 1,414 S, about 2,828 S in total.
If simply held: 10 A at 200 S plus 1,000 S, 3,000 S in total.
The gap: about 172 S, or roughly 5.7% of the hold value.

That is impermanent loss: in this example the pool handed over part of the «rising» token and replaced it with the stablecoin. Three important properties. First, the loss is measured against «just holding», not against zero: the position can grow in money terms and still lag behind holding. Second, it is symmetric: a halving of the price gives the same share, about 5.7%. Third, it is «impermanent» only in the sense that it vanishes if the price returns to the start; if you exit at a changed price, the loss becomes real. For comparison, with a fourfold price change in the same scheme the gap would be 20%: the further the price moves, the larger the gap.

Fees work in the opposite direction. To offset the 172 S from the example, the pool would have to collect that much in fees for you during the time you are in it. Whether that is enough depends on trading volume, and nobody knows it in advance.

Concentrated liquidity in brief

In some protocols the provider chooses not the whole price range but a limited segment. While the price stays inside the segment, the same funds take part in more trading volume, so fees grow, but sensitivity to price change is higher too. When the price leaves the bounds, the position turns entirely into one of the two tokens and stops earning fees until the price returns. A narrow range means more fees per unit of capital and more risk, plus the need to watch the position and rebuild it when necessary, which costs gas again.

Risks beyond impermanent loss

Smart contract risk. A pool is code. A bug or vulnerability can lead to a loss of funds regardless of price. An audit lowers the probability but does not zero it.
Token risk. If the other side of the pair is a little-known token, its price can fall almost to zero, and the liquidity in the pool ends up in a devalued asset. It can be worse: a token with special rules in its contract that cannot be freely sold.
Permissions. To deposit tokens you must grant the contract an approval. Excess and unlimited approvals are worth revoking, as described in the article on revoking token approvals.
Fake pools and sites. A pool with a similar token name or a phishing interface looks like the real thing. The source of a contract address should be checked independently.
Tax consequences. Depositing and withdrawing may count as reportable events in your jurisdiction; record keeping is covered in the article on airdrop taxes and record keeping.

Why an «add liquidity» task costs money

Projects sometimes include liquidity provision in the criteria because the protocol itself needs it. But for you it is one of the most expensive tasks on the list: it requires capital, not just gas. What to count before depositing:

Gas in and out. The approval, the deposit, possible range rebuilds, the withdrawal. Exiting is a transaction too, and on a high-fee network it can eat a noticeable part of a small position.
The impermanent loss scenario. Estimate with your own numbers what happens if the price changes twofold in either direction, as in the example above. If that loss is unacceptable to you, the position is too large.
Market risk of the tokens. You hold both assets, and each can fall. This risk is separate from impermanent loss.
Opportunity cost. The same funds could sit somewhere else or stay in the wallet.
Holding time. If a criterion requires keeping the position for weeks, the loss and the risks accumulate all that time.

The sum of these items is the real price of one task, and it should be compared with what you think the possible reward is worth, remembering that no reward is promised. A general way to make that comparison is in the article on whether an airdrop is worth it, and how liquidity tasks relate to other kinds of activity is in the article on types of airdrop tasks.

Tying this to the catalog

Before providing liquidity for a task, it helps to understand what stage the project is at. A project page in the CoinDropster catalog shows its status: Potential, Confirmed, Snapshot, Verification, Reward available or Distributed. At Snapshot or later, new actions usually no longer change anything, and paying gas and position risk for them makes little sense. In-app checklists with progress and deadlines help you not lose steps, and status-change tracking spares you a daily check. The decision about capital stays with you and should rest on your own calculations, not on someone else's promises. View tracked airdrops →