Как работают liquidity pools на DEX простыми словами: LP, fees, slippage и impermanent loss

После статей про order book vs AMM, routing, MEV и price discovery пора разобрать сам базовый контейнер, внутри которого на AMM-DEx вообще происходит обмен: liquidity pool. Именно пул — это место, где реально лежат активы, откуда трейдер получает исполнение и где экономически встречаются три ключевые роли: трейдер, LP и арбитражёр.

Для технической аудитории это одна из самых полезных тем в DEX-серии, потому что она быстро переводит разговор из уровня «на сайте есть кнопка Swap» в уровень реальной механики:

  • кто именно даёт ликвидность;
  • откуда берутся комиссии;
  • почему крупный swap двигает цену;
  • почему доходность LP нельзя считать бесплатным yield;
  • как собрать LP helper, dashboard или automation layer вокруг пулов.

Если упростить всю модель до одной фразы, она звучит так:

liquidity pool — это общий капитал, из которого трейдеры покупают и продают активы, а LP за это получают комиссии и берут на себя inventory risk.

Что именно разбираем

Сегодня разбираем:

  • что такое liquidity pool и зачем он нужен AMM-DEx;
  • как деньги двигаются между трейдером, пулом, LP и арбитражёром;
  • откуда берутся fees и почему они не равны чистой прибыли LP;
  • как появляются slippage и impermanent loss;
  • какие trade-offs реально важны в пуле ликвидности;
  • как собрать похожий MVP: от onchain indexer до LP dashboard, alerting и automation layer.

Главный практический вопрос статьи такой:

как устроить пул ликвидности так, чтобы трейдерам было где менять активы, LP было зачем приносить капитал, а продукт сверху умел объяснять и контролировать риски?

Как это работает простыми словами

Представим пул ETH/USDC.

В него кто-то положил:

  • ETH;
  • USDC.

Теперь трейдер может:

  • принести USDC и купить ETH;
  • принести ETH и продать его за USDC.

То есть пул становится общим складом ликвидности, из которого одна сторона забирает актив, а другая добавляет встречный актив.

В order book-модели покупатель и продавец ищут друг друга напрямую через заявки. В AMM-модели пользователь чаще всего торгует не против конкретного человека, а против состояния пула.

Это и есть главная разница по UX и инфраструктуре:

  • не нужен классический matching engine;
  • не нужно ждать контрагента на каждую цену;
  • ликвидность доступна всегда, пока в пуле есть активы;
  • но цена зависит от размеров резервов и меняется прямо в момент сделки.

Зачем пул вообще нужен DEX

Liquidity pool нужен, чтобы решить базовую проблему: откуда брать встречную сторону для обмена в permissionless среде.

Если бы пользователь мог менять актив только тогда, когда другой пользователь прямо сейчас выставил подходящую оффер-заявку, спотовый onchain UX был бы заметно хуже. Пул решает это так:

  • LP заранее блокируют капитал в контракте;
  • контракт публикует функцию обмена;
  • трейдер приходит в любой момент и получает quote из этого капитала.

Иными словами, LP заранее выставляют миру не конкретный лимитный ордер, а ликвидность как сервис.

Кто кладёт деньги в пул и зачем

Ликвидность в пул приносят LP — liquidity providers.

Они кладут в контракт активы пары, например:

  • ETH и USDC;
  • WBTC и USDC;
  • stables вроде USDC/USDT;
  • иногда экзотические токены.

Зачем они это делают:

  • чтобы получать долю swap fees;
  • чтобы зарабатывать на большом торговом объёме;
  • иногда ради incentive rewards от протокола;
  • иногда как часть более сложной стратегии — treasury management, market making, vault automation.

Но LP не просто «включают кэшбек». Они фактически берут на себя роль пассивного market maker.

Это значит, что LP:

  • предоставляют капитал рынку;
  • зарабатывают, если поток комиссий хороший;
  • несут риск, если рынок двигается против структуры их позиции.

Как двигаются деньги внутри пула

Разберём самый простой сценарий.

Сценарий: пользователь покупает ETH за USDC

В пуле лежит:

  • 100 ETH;
  • 300 000 USDC.

Пользователь хочет купить ETH за 30 000 USDC.

Что происходит:

  1. Пользователь отправляет USDC в пул.
  2. Пул отдаёт пользователю часть ETH.
  3. В пуле становится:
    • больше USDC;
    • меньше ETH.
  4. Следующий покупатель уже увидит другую цену, потому что соотношение резервов изменилось.
  5. Часть входящего объёма удерживается как комиссия.

Экономически это выглядит так:

  • trader платит fee и price impact;
  • LP получают комиссию;
  • пул меняет структуру запасов;
  • арбитражёр, если цена ушла от внешнего рынка, может потом вернуть её ближе к рыночной.

Откуда берётся fee flow

Комиссия в AMM-пуле — это цена доступа к ликвидности.

Когда трейдер делает swap, протокол удерживает fee, например:

  • 0.01%;
  • 0.05%;
  • 0.3%;
  • 1%;
  • или другую структуру, зависящую от конкретного DEX.

Эта комиссия обычно распределяется:

  • полностью LP;
  • или частично LP и частично протоколу, если есть protocol fee.

Важно понимать:

fees платит не абстрактный рынок — fees платит трейдер, который хочет получить мгновенное исполнение из капитала LP.

Это и есть основной fee flow.

Но для LP тут есть неприятная тонкость: gross fees и net profitability — не одно и то же.

Потому что против комиссий стоят:

  • impermanent loss;
  • inventory drift;
  • арбитражное вымывание value;
  • риск плохой концентрации ликвидности;
  • smart contract risk.

Почему появляется slippage

Slippage — это разница между ожидаемой ценой и фактической ценой исполнения.

В контексте liquidity pool он появляется по трём главным причинам.

1. Сделка сама двигает цену

Чем больше размер swap относительно глубины пула, тем сильнее пользователь меняет соотношение резервов.

Если пул маленький, даже средняя сделка может заметно сдвинуть цену.

2. Между quote и исполнением проходит время

Пользователь видит цену, подписывает транзакцию, она летит в мемпул, потом включается в блок. За это время другие сделки могли уже изменить пул.

3. Пул может быть не синхронизирован с внешним рынком

Если рынок двинулся быстро, а арбитраж ещё не подтянул пул к новой реальности, пользователь может войти в момент перекоса.

Хорошая ментальная модель:

slippage — это не отдельная комиссия, а цена за конечную глубину и динамику ликвидности.

Почему LP не получают “бесплатный yield”

Снаружи LP-позиция выглядит соблазнительно:

  • положил активы в пул;
  • собираешь комиссии;
  • вроде бы получаешь пассивный доход.

Но в реальности LP постоянно держит изменяющийся inventory mix.

Если цена ETH относительно USDC растёт, то пул автоматически продаёт часть ETH покупателям. В итоге LP после роста рынка часто оказывается:

  • с меньшей долей дорожающего актива;
  • с большей долей более «тяжёлой» стороны пары.

Если цена падает, происходит зеркальная история: LP остаётся с большим количеством падающего актива.

Это и есть корень impermanent loss.

Что такое impermanent loss простыми словами

Impermanent loss — это ситуация, когда LP по итогам движения рынка оказывается в худшем положении, чем если бы просто держал активы вне пула.

Ключевой момент:

  • LP не обязательно в абсолютном минусе;
  • он может даже заработать в долларах;
  • но он заработал меньше, чем простой hold той же корзины вне пула.

Пример на пальцах:

  • ты положил ETH и USDC в пул;
  • ETH сильно вырос;
  • пул по ходу роста продавал твой ETH покупателям;
  • в конце у тебя больше USDC и меньше ETH;
  • если бы ты просто сидел в кошельке, у тебя было бы больше выросшего ETH.

Значит, по сравнению с hold у тебя появился loss.

Почему его называют impermanent:

  • пока ты не вывел позицию, loss как бы нереализованный;
  • если цена вернётся назад, он может уменьшиться;
  • но в реальной жизни LP часто закрывают позицию на каком-то уровне, и тогда loss становится вполне permanent.

Поэтому многие практики предпочитают более честный термин: divergence loss.

Как арбитраж связан с LP-риском

Это один из самых важных, но часто недооценённых моментов.

Когда внешний рынок меняется, пул не синхронизируется сам по себе. Его подтягивают арбитражёры.

Если в пуле ETH стал относительно дешёвым:

  • арбитражёр покупает ETH в пуле;
  • продаёт его дороже во внешнем рынке;
  • оставляет себе spread.

Системно это полезно: цена в пуле становится ближе к рынку.

Но для LP это значит, что часть value уходит не ему, а арбитражёру. Поэтому LP в AMM-модели фактически платит рынку за синхронизацию своей цены.

Вот почему оценивать LP-стратегию только по APR от fees — слишком наивно.

Нужно смотреть как минимум на:

  • fee income;
  • divergence loss;
  • объём арбитражных ребалансов;
  • глубину пула;
  • волатильность актива;
  • gas и операционные расходы, если позиция активная.

Кто платит, кто несёт risk, кто получает yield

Эту механику полезно раскладывать по ролям.

Trader

Трейдер платит:

  • swap fee;
  • gas;
  • slippage;
  • иногда дополнительную execution-cost через плохой route или MEV.

Трейдер получает:

  • мгновенный доступ к ликвидности;
  • permissionless swap;
  • возможность торговать без централизованного market maker.

LP

LP получает:

  • swap fees;
  • иногда incentive rewards;
  • иногда дополнительные стратегии поверх LP-позиции.

LP несёт:

  • impermanent/divergence loss;
  • inventory risk;
  • smart contract risk;
  • риск, что fee flow не покроет market movement.

Arbitrageur

Арбитражёр получает:

  • spread между пулами и внешними площадками;
  • прибыль за выравнивание цены.

Арбитражёр несёт:

  • gas risk;
  • failed tx risk;
  • конкуренцию;
  • bridge/settlement risk в межсетевых сценариях.

Protocol

Протокол получает:

  • торговый объём;
  • liquidity moat;
  • иногда protocol fee;
  • данные и точки интеграции для других продуктов.

Реальные trade-offs liquidity pool-модели

1. Простота доступа к ликвидности против capital efficiency

AMM удобно использовать, но чтобы большие сделки не ломали цену, в пуле должен лежать большой капитал.

2. Пассивный LP UX против скрытого market risk

LP-позиция выглядит пассивной только на UI. Экономически это всё равно ставка на волатильность, объём и арбитражную динамику.

3. Глубокий пул улучшает execution, но снижает оборот капитала

Чем больше ликвидности, тем лучше трейдерам. Но LP при этом может зарабатывать меньший fee turnover на единицу капитала.

4. Низкий fee tier помогает трейдеру, но не всегда LP

Если комиссия слишком низкая, объём может вырасти, но LP может не окупать риск.

5. Высокая open composability против MEV exposure

Публичные пулы легко интегрировать в routing и DeFi-композицию, но они же становятся площадкой для front-running и sandwich-рисков.

Основные компоненты архитектуры liquidity pool-продукта

Если строить не сам DEX с нуля, а практичный сервис вокруг liquidity pools, архитектура обычно делится на несколько блоков.

1. Smart contracts

Если это собственный AMM-прототип, нужны:

  • pool contract;
  • router contract;
  • LP share accounting;
  • fee accounting;
  • add/remove liquidity flows;
  • safety guards и pause logic.

Если это аналитический слой поверх готовых DEX, контрактный слой можно сократить до интеграций и read-only adapters.

2. Onchain indexer

Нужно собирать:

  • swaps;
  • reserve updates;
  • mint/burn LP events;
  • fee tier;
  • liquidity additions/removals;
  • pool snapshots по блокам.

Хранить это удобно в:

  • Postgres для MVP;
  • ClickHouse для событий и аналитики на масштабе;
  • отдельном cache-слое для быстрых quote/TVL ответов.

3. Pricing and valuation layer

Понадобится слой, который умеет считать:

  • spot-like цену внутри пула;
  • pool TVL;
  • LP share value;
  • fee accrual;
  • divergence vs hold benchmark;
  • realised/unrealised PnL.

4. LP analytics engine

Это сердце полезного продукта для LP и операторов.

Он должен считать:

  • fees earned;
  • current inventory composition;
  • estimated impermanent loss;
  • exposure by asset;
  • volume-to-TVL ratio;
  • efficiency of a given pool or range.

5. UI и dashboards

Минимально полезный интерфейс:

  • список пулов;
  • TVL;
  • 24h/7d volume;
  • fee APR;
  • realised vs hold comparison;
  • recent swaps;
  • liquidity depth around current price;
  • alerts and warnings.

6. Monitoring and automation layer

Поверх аналитики часто и рождается настоящая продуктовая ценность.

Реальные сценарии использования

1. LP dashboard для команды или DAO

Нужно видеть:

  • где стоит капитал;
  • какие пулы реально дают поток fees;
  • где divergence loss уже съедает доход;
  • какие позиции слишком концентрированы в одном активе.

2. Swap helper для трейдера

Даже если продукт ориентирован на swap, понимание пулов помогает:

  • объяснять price impact;
  • показывать, почему direct route плохой;
  • подсвечивать thin liquidity;
  • предупреждать о плохом execution.

3. Treasury liquidity operations

Проект может сам поддерживать ликвидность своих токенов и тогда хочет понимать:

  • когда доливать ликвидность;
  • когда убирать;
  • какой fee tier выбирать;
  • насколько pool health влияет на UX держателей токена.

4. Risk and anomaly monitoring

Можно строить алерты на:

  • резкое падение глубины;
  • необычный outflow LP;
  • сильное расхождение pool price с reference market;
  • всплески арбитражной активности;
  • ухудшение quote-to-fill quality.

Как собрать похожий MVP / prototype

Если цель — не production DEX, а понятный MVP для статьи, демо или внутреннего инструмента, разумный scope такой.

Шаг 1. Выбрать 10–20 ключевых пулов

Например:

  • ETH/USDC;
  • WBTC/USDC;
  • USDC/USDT;
  • несколько ликвидных L2-пулов.

Не нужно сразу покрывать весь рынок.

Шаг 2. Поднять indexer

Минимальные сущности в базе:

  • tokens
  • pools
  • pool_snapshots
  • swaps
  • liquidity_events
  • lp_positions
  • pool_metrics
  • alerts

Indexing-слой должен обновлять:

  • reserves;
  • price estimate;
  • fee accrual;
  • latest volume;
  • LP ownership and pool share.

Шаг 3. Собрать analytics API

MVP API может отвечать на такие вопросы:

  • какой сейчас TVL пула;
  • какой объём был за 24h/7d;
  • какая estimated fee APR;
  • какой price impact на заданный размер swap;
  • как LP-позиция выглядит против hold benchmark.

Шаг 4. Сделать LP dashboard

Минимальный UI:

  • pool overview;
  • current reserves;
  • pool price vs reference;
  • fee income;
  • estimated impermanent loss;
  • historical charts по volume и TVL;
  • warning badges.

Шаг 5. Добавить automation layer

Вот что особенно полезно автоматизировать поверх MVP.

Monitoring

  • резкие отклонения цены от reference market;
  • падение ликвидности ниже порога;
  • всплеск slippage на ключевых размерах сделки;
  • необычный рост failed execution или routing degradation.

Alerts

  • LP position drift;
  • fee yield below threshold;
  • suspected toxic flow;
  • pool imbalance;
  • unusually high arbitrage extraction.

Rebalance helpers

Для активных операторов или DAO можно автоматизировать:

  • предложения по перераспределению ликвидности;
  • отключение risky pools из preferred list;
  • расписание ребалансов;
  • treasury actions при падении depth.

Keeper logic

Если вокруг пула есть собственный продукт, можно запускать keeper jobs, которые:

  • обновляют risk flags;
  • снимают snapshots;
  • пересчитывают KPI;
  • шлют уведомления в Slack/Telegram/ops dashboard.

Что можно автоматизировать поверх liquidity pools

Самый сильный прикладной угол здесь не в том, чтобы ещё раз показать кнопку Add Liquidity, а в том, чтобы превратить сырые onchain события в нормальный operator tooling.

Практичные автоматизации:

  • LP profitability monitor — сравнивает fees против divergence loss;
  • execution quality checker — следит, на каких размерах ордера пул уже токсичен для swap UX;
  • pool health dashboard — TVL, volume, spread-to-market, arbitrage intensity;
  • treasury alerting — уведомляет, если рынок высосал ликвидность из ключевой пары;
  • routing helper — исключает тонкие или деградировавшие пулы из рекомендуемых маршрутов;
  • anomaly detection — ловит подозрительные ценовые прыжки и outlier swaps.

Итог

Liquidity pool — это базовая деталь AMM-DEx, без которой нет ни quote, ни swap, ни LP-yield, ни арбитража.

Если смотреть на него честно, картина такая:

  • trader покупает доступ к ликвидности и платит fee, gas и slippage;
  • LP даёт капитал и получает комиссии, но берёт на себя inventory risk и impermanent loss;
  • арбитражёр синхронизирует цену пула с рынком и забирает часть value за эту работу;
  • протокол получает ликвидную базу, на которой можно строить swap UX, routing, dashboards и automation.

Если совсем коротко:

liquidity pool — это не просто “коробка с токенами”, а рыночный механизм перераспределения цены, риска и комиссии между трейдерами, LP и арбитражёрами.

И именно поэтому поверх пулов так естественно строятся indexers, LP dashboards, routing helpers, alerts, keeper logic и другие automation-layer инструменты. Сами пулы дают исполнение. Продуктовая ценность появляется тогда, когда вы умеете объяснить, измерить и автоматизировать их поведение.