Разработка системы сравнения цен на DEX
Приходит задача: найти лучший курс для свапа 50 ETH в USDC. Uniswap v3 даёт одну цену, Curve — другую, Balancer — третью. Разница в 0.3% на 50 ETH — это уже 150 долларов только на одной транзакции. При торговле объёмами от 100k USD разрыв между DEX достигает 1-2%, и каждый свап без агрегации — прямые потери.
Задача системы сравнения цен — дать пользователю или алгоритму актуальную картину по всем релевантным DEX за одно обращение, с учётом slippage, gas cost и split routing.
Где обычно ломается наивная реализация
On-chain вызовы в реальном времени — медленно и дорого
Первый подход, который приходит в голову: вызывать quoteExactInputSingle на Uniswap v3 Quoter, get_dy на Curve, queryBatchSwap на Balancer — и сравнивать. Проблема в том, что это симуляция on-chain выполнения через eth_call. На mainnet с 8-12 DEX и 3-4 вариантами маршрутов получается 30+ RPC-вызовов на каждый запрос пользователя. При 200ms на вызов — 6 секунд ожидания. За это время цена уже изменилась.
Конкретный кейс из практики: агрегатор с наивным last-write-wins кешем терял актуальность котировок за 3-5 блоков. Пользователь видел цену X, нажимал свап, получал revert из-за slippage, платил газ впустую. Конверсия падала на 40%.
Stale data и блочный drift
Цена в пуле Uniswap v3 меняется с каждым свапом. Если кеш обновляется раз в 12 секунд (1 блок на Ethereum), между обновлениями может пройти несколько крупных сделок. Особенно критично для пулов с низкой ликвидностью — там сдвиг цены на 1-2% за блок не редкость.
Curve использует другую модель ценообразования — StableSwap invariant. Формула A * n^n * sum(x_i) + D = A * D * n^n + D^(n+1) / (n^n * prod(x_i)) чувствительна к балансам пула, которые меняются по-своему. Нельзя применять одну и ту же логику расчёта slippage для Uniswap v3 concentrated liquidity и Curve stable pools.
Архитектура системы
Два слоя данных: off-chain индексация + on-chain верификация
Рабочая схема: The Graph субграфы для индексации состояния пулов — ликвидность, текущие цены, объёмы. Данные обновляются покблочно и доступны через GraphQL без RPC-нагрузки. Для Uniswap v3 — официальный subgraph с pools, ticks, positions. Для Curve — собственный субграф или парсинг событий TokenExchange.
On-chain верификация нужна только в момент непосредственного исполнения: финальный quoteExactInput перед транзакцией пользователя с актуальным block state.
| Источник | Latency | Точность | Нагрузка на RPC |
|---|---|---|---|
| The Graph subgraph | 2-5 сек (1 блок) | Высокая | Минимальная |
| Multicall + Quoter | 200-500 мс | Точная | Высокая |
| DEX SDK (off-chain math) | <10 мс | Расчётная | Нет |
| WebSocket событий | Real-time | Событийная | Средняя |
Off-chain math для скорости
Uniswap v3 предоставляет @uniswap/v3-sdk и @uniswap/smart-order-router — полный расчёт маршрута с split routing происходит локально, без RPC, на основе загруженного состояния пулов. Аналогично для Curve — Python SDK или TypeScript-порт формулы StableSwap позволяет вычислить get_dy локально.
Такой подход снижает latency до 10-50 мс и убирает зависимость от RPC-провайдера на горячем пути.
WebSocket для стриминга
Для интерфейсов с realtime-обновлением цен — WebSocket подписка через ethers.js provider.on('block', ...) или viem watchBlocks. При каждом новом блоке пересчитываем котировки только для активных торговых пар в UI, а не всего маркетплейса.
Процесс работы
Аналитика (1-2 дня). Определяем список DEX под конкретный чейн, нужные торговые пары, требуемую latency. Ethereum mainnet, Polygon, Arbitrum, Base — у каждого свои активные DEX и своя структура ликвидности.
Разработка backend (3-5 дней). Сервис индексации с The Graph + Multicall, кеш состояния пулов, REST/WebSocket API. Стек: Node.js + TypeScript, viem для on-chain взаимодействий, Redis для кеша.
Разработка расчётного модуля (2-3 дня). Off-chain math для каждого подключённого DEX, split routing алгоритм, учёт gas cost при сравнении.
Frontend интеграция (1-2 дня). wagmi хуки для получения котировок, отображение сравнения, интеграция с транзакционным флоу.
Тестирование. Fork-тесты на Hardhat/Foundry с реальным mainnet-состоянием — проверяем точность расчётов против реальных on-chain результатов.
Ориентиры по срокам
Базовая система сравнения для 3-5 DEX на одном чейне — 3-5 дней. Полноценный агрегатор с multi-chain, split routing и realtime UI — от 2 недель. Сроки зависят от количества подключаемых DEX и требований к latency.
Стоимость рассчитывается после уточнения чейнов, DEX и требований к производительности.