Разработка системы сравнения котировок DEX: off-chain математика и realtime API
Приходит задача: найти лучший курс для свапа 50 ETH в USDC. Uniswap v3 даёт одну цену, Curve — другую, Balancer — третью. Разница в 0.3% на 50 ETH — это уже 150 долларов только на одной транзакции. Мы предлагаем профессиональную разработку системы сравнения цен на DEX, которая экономит до 2% на каждой сделке. Опыт нашей команды — более 5 лет в блокчейн-разработке, свыше 100 реализованных проектов. Система интегрируется с любым чейном и DEX, гарантируя актуальность котировок в реальном времени. Закажите разработку и получите консультацию по архитектуре. Ключевая задача агрегатора котировок — минимизировать latency и обеспечить точность расчётов, чтобы пользователь видел реальную цену с учётом комиссий и проскальзывания. Наша система решает эту задачу за счёт гибридной архитектуры.
Проблемы наивной реализации агрегатора котировок
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.
Типичная ошибка при агрегации — игнорирование проскальзывания, особенно для крупных ордеров. Без учёта глубины пула пользователь может получить цену, которая недостижима на момент свапа. Наша система всегда рассчитывает slippage для каждого DEX индивидуально.
Архитектура системы сравнения котировок
Два слоя данных: off-chain индексация + on-chain верификация
Рабочая схема: The Graph subgraphs для индексации состояния пулов — ликвидность, текущие цены, объёмы. Данные обновляются поблочно и доступны через 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 математика быстрее on-chain?
Uniswap v3 предоставляет @uniswap/v3-sdk и @uniswap/smart-order-router — полный расчёт маршрута с split routing происходит локально, без RPC, на основе загруженного состояния пулов. Аналогично для Curve — Python SDK или TypeScript-порт формулы StableSwap позволяет вычислить get_dy локально. Согласно официальной документации Uniswap v3, off-chain расчёты обеспечивают точность до 0.01%.
Такой подход снижает latency до 10-50 мс и убирает зависимость от RPC-провайдера на горячем пути.
Как обеспечить realtime обновление?
Для интерфейсов с realtime-обновлением цен — WebSocket подписка через ethers.js provider.on('block', ...) или viem watchBlocks. При каждом новом блоке пересчитываем котировки только для активных торговых пар в UI, а не всего маркетплейса. Это сокращает нагрузку на сервер и ускоряет отображение.
Учёт газа при агрегации
Gas cost может изменить привлекательность маршрута. Если один DEX даёт лучшую цену, но исполнение стоит 500k газа, а другой — чуть хуже, но 200k газа, второй может быть выгоднее. Мы используем eth_gasPrice и исторические данные для оценки стоимости газа, включая EIP-1559 parameters. В расчётном модуле сравнивается net output после вычета газа.
Пример: при цене газа 50 Gwei, разница в 300k газа = 0.015 ETH (≈$30). На сделке в 10 ETH это 0.3% — значимо.
Как off-chain индексация ускоряет сравнение котировок?
The Graph subgraph позволяет получать состояние тысяч пулов за один GraphQL-запрос, без последовательных RPC-вызовов. Данные обновляются каждые 2-5 секунд (в зависимости от скорости блока). Этого достаточно для большинства трейдеров, так как цена не успевает измениться критически за 2-5 секунд. Для сверхбыстрых операций (например, MEV) можно добавить WebSocket-подписку на события пула.
Подключаемые DEX и индивидуальный расчёт slippage
Мы подключаем любые DEX на Ethereum, Polygon, Arbitrum, Optimism, Base. В базовой версии — Uniswap v3, Curve, Balancer. Slippage рассчитывается индивидуально: для Uniswap v3 — tick-based модель с учётом tick spacing и ликвидности диапазона; для Curve — StableSwap formula; для Balancer — weighted pool formula. Для каждого DEX мы используем соответствующий SDK и верифицируем расчёты fork-тестами.
Что входит в разработку системы сравнения цен?
- Аналитика (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 результатов.
- Документация и передача. Предоставляем полную техническую документацию, доступы к инфраструктуре, обучение вашей команды. Оказываем поддержку в течение месяца после запуска.
Сравнение подходов к агрегации
| Параметр | Наивный подход | Наш подход |
|---|---|---|
| Latency | 6 секунд | 10-50 мс |
| Точность | С низким кешем | До 0.01% |
| Зависимость от RPC | Высокая | Минимальная |
| Стоимость газа | Высокая | Экономия до 30% |
Наша система обновляет котировки в 10 раз быстрее наивного подхода за счёт off-chain индексации и локальных расчётов. Экономия на газе при тестировании составила до 30% за счёт минимизации on-chain вызовов. Сравните с конкурентами, которые используют только on-chain запросы — наша система показывает меньшую задержку и ниже стоимость транзакций. Средняя экономия на сделке объёмом 10 ETH достигает 0.1 ETH, а для сделки в 100 ETH — превышает 1 ETH.
Пример расчёта экономии
Трейдер хочет обменять 50 ETH на USDC. Лучшая цена на Uniswap v3: 3400.50 USDC за ETH, на Curve: 3400.20, на Balancer: 3400.40. С учётом газа и проскальзывания выгоднее всего Uniswap. Наша система показывает итоговую разницу в 0.15 ETH.Ориентиры по срокам
Базовая система сравнения для 3-5 DEX на одном чейне — 3-5 дней. Полноценный агрегатор с multi-chain, split routing и realtime UI — от 2 недель. Сроки зависят от количества подключаемых DEX и требований к latency.
Обращайтесь к нам для детального обсуждения вашей задачи. Закажите разработку и получите консультацию по архитектуре.