Откуда берётся цена на DEX простыми словами: AMM, арбитраж, oracles и MVP для price intelligence

После материалов про order book DEX и DEX-агрегаторы логично разобрать фундаментальный вопрос, который стоит под любой кнопкой Swap: откуда вообще на DEX берётся цена. Пользователь видит курс, например 1 ETH = 3,120 USDC, но за этой цифрой нет единого центрального источника истины. Есть пулы, арбитражёры, внешние рынки, slippage, газ, latency и иногда оракулы — и всё это вместе собирает то, что на фронте выглядит как «текущая цена».

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

  • кто именно выставляет цену;
  • почему quote и execution price — разные вещи;
  • как двигаются деньги между трейдерами, LP и арбитражёрами;
  • где возникают fees и risk transfer;
  • какой MVP можно собрать, если нужен свой swap-helper, quote-monitoring сервис или price dashboard.

Если смотреть на инженерные обсуждения шире, там постоянно повторяется один и тот же паттерн: интерфейс часто показывает одно число, но реальная система живёт на нескольких слоях истины сразу. Для DEX это особенно заметно. Цена на экране — это не закон природы, а итог работы market structure.

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

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

  • откуда на DEX берётся цена в AMM-модели;
  • почему пул сам по себе не «знает справедливую цену»;
  • как арбитраж выравнивает DEX относительно других рынков;
  • где в DEX важны oracles, а где они не нужны напрямую для swap;
  • как двигаются деньги и кто получает fees;
  • какие реальные trade-offs есть между speed, decentralization, price accuracy и capital efficiency;
  • как собрать похожий MVP: от indexer и quote engine до monitoring, alerts и automation layer.

Главная идея простая: цена на DEX не приходит сверху, она постоянно собирается из ликвидности, сделок и арбитража.

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

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

Внутри него лежат два актива:

  • ETH;
  • USDC.

Когда трейдер покупает ETH за USDC:

  • он приносит USDC в пул;
  • забирает ETH из пула;
  • соотношение активов меняется;
  • вместе с ним меняется и цена следующей сделки.

То есть в AMM цена рождается не из чьего-то ручного приказа «ETH теперь стоит вот столько», а из текущего состояния ликвидности в пуле.

Но здесь есть важная оговорка.

Сам пул не знает, что происходит на Binance, Coinbase, Hyperliquid или в соседнем пуле на другой сети. Он знает только:

  • сколько у него сейчас резервов;
  • какую кривую использует контракт;
  • сколько комиссии надо взять за swap.

Поэтому честнее говорить так:

  • AMM вычисляет локальную цену внутри своей ликвидности;
  • рынок через арбитраж подтягивает эту локальную цену к внешней реальности.

Именно этот стык и есть настоящая price discovery-механика DEX.

Цена в AMM: не oracle, а функция состояния пула

В простейшем AMM цена выводится из соотношения резервов.

Если в пуле стало:

  • больше USDC;
  • меньше ETH,

то ETH внутри этого пула становится дороже для следующего покупателя.

Если наоборот:

  • кто-то массово продаёт ETH в пул;
  • ETH в пуле становится больше;
  • USDC становится меньше,

то локальная цена ETH в этом пуле падает.

Полезная ментальная модель такая:

пул не публикует цену — он публикует функцию обмена.

Цена — это производная от вопроса: сколько токена B я получу, если отдам токен A прямо сейчас на конкретном объёме.

Отсюда сразу следуют две важные вещи.

1. На DEX нет одной универсальной цены

Есть:

  • mid price или spot-like price в конкретном пуле;
  • effective execution price на конкретном размере ордера;
  • quoted output после fee;
  • realised output после майнинга транзакции.

Это разные числа.

2. Размер сделки сам влияет на цену

На маленьком объёме ты видишь почти одну цену. На большом — уже другую.

Поэтому разговор «какой курс на DEX» без размера сделки обычно неполный.

Почему пул сам по себе не держит “рыночную” цену

Допустим, внешний рынок считает, что 1 ETH = 3,100 USDC, а в конкретном пуле из-за серии сделок и перекоса резервов получается 1 ETH = 3,060 USDC.

Пул не проснётся и не исправит себя автоматически. Он не смотрит новости, не читает биржевой фид и не знает, где «правильно». Он просто исполняет формулу.

Что происходит дальше:

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

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

Как арбитраж двигает деньги

Это центральный кусок всей DEX-механики.

Сценарий

Допустим:

  • в CEX или на других DEX ETH торгуется по 3,100 USDC;
  • в нашем пуле ETH можно купить эквивалентно по 3,060 USDC.

Арбитражёр:

  1. покупает ETH в дешёвом пуле;
  2. выводит или хеджирует позицию против внешнего рынка;
  3. продаёт ETH дороже в другом venue;
  4. оставляет себе spread после gas и fees.

Что при этом происходит экономически:

  • LP отдают немного «дешёвый» ETH и получают комиссию, но часть ценового отклонения фактически уходит арбитражёру;
  • арбитражёр получает прибыль за выравнивание цены;
  • рынок получает более актуальную цену в пуле;
  • следующий обычный трейдер видит уже более реалистичный курс.

Именно поэтому LP-доходность нельзя оценивать только по gross fees. Часть value в AMM регулярно перетекает арбитражёрам как цена за синхронизацию с рынком.

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

Это хороший способ объяснить механику без абстракций.

Trader

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

  • swap fee;
  • gas;
  • slippage;
  • иногда hidden execution cost, если quote устарел или маршрут плохой.

В обмен он получает:

  • мгновенную доступную ликвидность;
  • permissionless execution;
  • возможность сделать swap без классического market maker за столом.

LP

LP получает:

  • swap fees;
  • иногда incentives или protocol rewards.

Но несёт:

  • inventory risk;
  • impermanent loss / divergence loss;
  • риск, что хорошие трейды заберут арбитражёры быстрее, чем комиссия это компенсирует;
  • smart contract risk.

Arbitrageur / Solver / Searcher

Он получает:

  • spread между venue;
  • value от быстрого выравнивания цены;
  • иногда MEV-возможности, если execution публичный и есть latency.

Но несёт:

  • gas risk;
  • failed transaction risk;
  • конкуренцию со стороны других арбитражёров;
  • bridge / settlement risk, если арбитраж межсетевой.

Protocol

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

  • protocol fee;
  • flow data;
  • объём и продуктовую ценность сети интеграций.

Где тут slippage и почему quote не равен итоговой цене

Даже если пул уже близок к рынку, у пользователя нет гарантии, что он получит ровно показанный курс.

Причины:

1. Размер ордера

Чем больше ордер, тем сильнее он двигает кривую внутри пула.

2. Время между quote и исполнением

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

3. Публичное исполнение и MEV

Если сделка видна заранее, её могут sandwich-ить или просто исполнить после изменения состояния ликвидности.

4. Нетто-стоимость маршрута

На бумаге путь может выглядеть выгоднее, но после gas, fees и latency уже нет.

Поэтому цена на DEX — это всегда цена с контекстом исполнения.

Где в этой схеме нужны oracles

Это место часто путают.

Для обычного AMM swap внешний oracle не всегда нужен напрямую, потому что пул сам умеет считать output из своей ликвидности. Но это не означает, что oracles не важны.

Они критичны рядом с обменом в нескольких сценариях.

1. Защитные проверки и sanity bounds

Приложение или контракт может сверять:

  • не слишком ли пул отклонился от reference market;
  • не пытаются ли провести swap по явно плохой цене;
  • не сломан ли какой-то route.

2. Lending, margin и collateral logic

Если DEX — это часть более сложного протокола, например perpetual venue или money market, то ликвидации и collateral ratios обычно уже нельзя безопасно строить только на сырых spot price из одного пула.

3. TWAP и anti-manipulation logic

Вместо мгновенной spot-цены система может использовать:

  • TWAP;
  • median между несколькими источниками;
  • bounded deviation checks.

4. Analytics, dashboards и treasury automation

Если ты строишь продукт вокруг DEX-активности, тебе часто нужна не только onchain quote-цена, но и более устойчивая reference price для:

  • PnL;
  • inventory valuation;
  • alerting;
  • risk triggers;
  • operator dashboards.

Итого:

  • swap внутри AMM может жить без внешнего oracle;
  • серьёзный продукт вокруг DEX почти всегда использует oracle или reference price layer где-то рядом.

Откуда берётся “справедливая цена” на практике

На практике она не живёт в одном контракте.

Обычно есть несколько слоёв:

Локальная onchain цена

То, что прямо сейчас получается в конкретном пуле или маршруте.

Cross-venue reference

То, что видно при сравнении нескольких DEX и иногда CEX.

Time-smoothed reference

TWAP, EMA, median или другой сглаженный ориентир.

Execution-aware price

Цена с учётом:

  • размера ордера;
  • gas;
  • route quality;
  • expected slippage;
  • вероятности плохого исполнения.

Для пользователя может быть полезнее именно последний слой, а не абстрактный spot.

Реальные trade-offs

1. Permissionless liquidity против чистоты price discovery

AMM легко запустить и интегрировать, но цену в нём постоянно приходится синхронизировать через арбитраж.

2. Простота UX против честности отображения

Показать один красивый курс просто. Честно показать диапазон, route quality и execution risk — сложнее, но полезнее.

3. Глубина ликвидности против capital efficiency

Чем лучше ликвидность вокруг текущей цены, тем меньше slippage. Но за это кто-то держит капитал и несёт риск.

4. Быстрая onchain composability против MEV exposure

Открытая и composable execution-модель удобна для интеграций, но делает пользователя уязвимее к front-running и sandwich-risk.

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

Если задача — сделать price intelligence слой вокруг DEX, не нужен full-scale Uniswap с нуля. Достаточно собрать MVP, который хорошо показывает механику.

1. Onchain data ingestion

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

  • события swap;
  • состояния резервов пулов;
  • fee tiers;
  • liquidity changes;
  • block timestamps и номера блоков.

Это можно делать через:

  • subgraph-подобный индексер;
  • прямой RPC ingestion;
  • batch jobs в Postgres / ClickHouse.

2. Quote engine

Компонент, который умеет ответить:

  • сколько output даст пул прямо сейчас;
  • как меняется цена на разном размере сделки;
  • какой route между A и B сейчас лучший;
  • насколько quote отклоняется от reference market.

Для MVP достаточно:

  • 10–50 ключевых пулов;
  • расчёта direct route;
  • нескольких basic multi-hop путей;
  • fee-aware net quote.

3. Reference price layer

Нужен отдельный слой, который строит reference price из:

  • нескольких onchain venue;
  • при необходимости централизованных бирж как внешнего ориентира;
  • TWAP / median logic.

Это позволяет показывать:

  • deviation по каждому пулу;
  • подозрительные скачки;
  • вероятные арбитражные окна.

4. Risk checks

MVP стоит сразу снабдить проверками:

  • max deviation vs reference;
  • min liquidity threshold;
  • max slippage threshold;
  • stale quote detection;
  • block delay / RPC lag alerts.

5. UI и dashboard

Хороший минимальный интерфейс:

  • пара активов A/B;
  • best route;
  • quoted output;
  • expected slippage;
  • deviation vs reference;
  • recent pool events;
  • gas-adjusted net output.

6. Automation layer

Вот где появляется настоящая продуктовая ценность.

Поверх MVP можно автоматизировать:

  • alerts, если пул сильно ушёл от рынка;
  • поиск подозрительных ценовых выбросов;
  • уведомления о деградации route quality;
  • keeper-логику для внутренних treasury swaps;
  • авто-переключение между preferred venue;
  • отчёты по lost execution quality.

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

Если смотреть на DEX как на инфраструктуру, а не только как на сайт для swap, то automation layer особенно полезен в пяти сценариях.

1. Monitoring цены и liquidity health

Следить за:

  • резким падением глубины;
  • большим отклонением от reference;
  • всплесками fee-paid vs output deterioration.

2. Treasury execution helpers

Для команды или DAO полезно иметь сервис, который не просто делает swap, а:

  • проверяет deviation;
  • ждёт более нормального окна исполнения;
  • выбирает venue по policy rules.

3. LP operations

Если у тебя есть свои LP-позиции, price intelligence нужен для понимания:

  • когда арбитраж слишком активно вымывает value;
  • где fee income уже не покрывает risk;
  • когда диапазон ликвидности надо перестраивать.

4. Alerting по MEV-risk

Если execution регулярно ухудшается по сравнению с quote, это может быть сигналом:

  • плохого маршрута;
  • слишком широкого slippage tolerance;
  • exposure к sandwich-атакам.

5. Operator dashboard

Для живой команды полезен экран, где видно:

  • reference price;
  • onchain pool price;
  • deviation;
  • latest swaps;
  • quote-to-fill difference;
  • объём арбитражной активности.

Где этот подход реально полезен

Такой материал не только для «крипто-энтузиастов». Он прикладной для:

  • команд, которые строят swap UX;
  • treasury-операторов и DAO;
  • аналитиков execution quality;
  • разработчиков дашбордов и monitoring-инструментов;
  • команд, которые хотят сделать routing helper, quote API или alerting layer.

Потому что DEX сегодня — это уже не просто смарт-контракт с кнопкой обмена. Это рыночная инфраструктура, где цена — результат исполнения, ликвидности и арбитража, а не одна цифра из воздуха.

Итог

Цена на DEX берётся не из магического источника и не только из формулы AMM.

Она складывается из нескольких сил сразу:

  • локальной ликвидности в пуле;
  • размера сделки;
  • действий арбитражёров;
  • сравнений с другими venue;
  • иногда oracle/reference layer;
  • качества execution в конкретный момент времени.

Если объяснять это совсем коротко, то:

AMM считает локальную цену, рынок через арбитраж делает её похожей на глобальную, а хороший продукт сверху превращает это в понятный и безопасный execution для пользователя.

Именно поэтому вокруг DEX почти неизбежно появляются indexers, quote engines, dashboards, alerts и automation workflows. Без них у вас есть только пул. С ними появляется полноценный product layer.