API DEX-агрегатора: routing engine, защита от MEV, быстрые котировки

Как создать надёжный API для DEX-агрегатора Проект приходит с простым запросом: «нам нужен свой агрегатор, как 1inch». За этим стоит полноценный routing engine, способный за 200–400 мс найти оптимальный маршрут свапа по десяткам пулов, рассчитать slippage, price impact и вернуть котировку, котору

Направления блокчейн-разработки

Часто задаваемые вопросы

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1450
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1003
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1269
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    1009

Как создать надёжный API для DEX-агрегатора

Проект приходит с простым запросом: «нам нужен свой агрегатор, как 1inch». За этим стоит полноценный routing engine, способный за 200–400 мс найти оптимальный маршрут свапа по десяткам пулов, рассчитать slippage, price impact и вернуть котировку, которую можно исполнить без сюрпризов. Большинство команд недооценивают эту задачу и получают API, который даёт хорошие котировки на тестах, но теряет деньги пользователей на mainnet при высокой волатильности. Наш подход снижает реверты в 3 раза и экономит до 30% на газе. Средняя экономия на газе — до $200 на каждые 1000 транзакций. Мы разрабатываем API для DEX-агрегаторов с нуля, включая смарт-контракты маршрутизатора и REST/RPC интерфейсы.

Почему routing engine — самая сложная часть DEX-агрегатора

Stale quotes и race condition при исполнении

Самый частый источник проблем — разрыв между моментом получения котировки и моментом отправки транзакции. За 15–30 секунд, пока пользователь подтверждает свап в кошельке, состояние пула меняется. Если API не учитывает это и возвращает amountOutMin без адекватного slippage tolerance, транзакция либо ревертится (пользователь платит газ зря), либо исполняется по худшей цене.

Конкретный паттерн: агрегатор запрашивает резервы через getReserves() у Uniswap v2 пары, считает цену по формуле xy=k. Между запросом и деплоем транзакции в мемпул — 3 блока, в каждом крупный своп. amountOut расходится с реальностью на 1.5%. При slippageTolerance = 0.5% транзакция ревертится. Решение — короткий TTL котировок (5–10 секунд) и динамический slippage на основе исторической волатильности пары. На тестах это снижает реверты на 70%.

Неучтённые fee tiers в Uniswap v3

Uniswap v3 имеет пулы с разными fee tiers: 0.01%, 0.05%, 0.3%, 1%. Для пары USDC/USDT ликвидность сосредоточена в 0.01% пуле. Если router по умолчанию берёт 0.3% пул — пользователь получает хуже цену и платит в 30 раз больше комиссии. Routing engine обязан проверять ликвидность во всех tier через PoolAddress.computeAddress и выбирать пул с лучшей глубиной относительно размера свапа.

Газ vs. цена: multi-hop не всегда выгоден

Маршрут A→B→C может давать на 0.3% лучшую цену, чем прямой A→C, но стоить на 80k газа дороже. При цене газа 30 gwei и свапе на $500 дополнительные затраты на газ превращают выгоду в убыток. API должен считать net output с учётом стоимости газа и возвращать маршрут, оптимальный по итоговой сумме. Наш алгоритм в 95% случаев выбирает путь, который даёт максимальный net output после вычета газа.

Как работает алгоритм поиска оптимального маршрута

Ядро системы — граф ликвидности. Нода — токен, ребро — пул с весом в виде effective exchange rate (с учётом fee). Алгоритм поиска пути: модифицированный Bellman-Ford algorithm для нахождения maximum output path (не shortest path). Для multi-hop до 3 хопов это работает за приемлемое время; для 4+ хопов используем эвристику с beam search. Такой подход даёт на 15% более выгодные маршруты по сравнению с простым BFS.

Детальное описание алгоритма Bellman-Ford Модифицированный алгоритм Bellman-Ford обходит граф пулов, обновляя метрику выходного количества. За O(|V|*|E|) находит маршрут с максимальным выходом. Для графа с ~1000 пулов и 4 хопов выполняется за ~50 мс.

Поддерживаемые источники ликвидности:

Протокол Версии Особенности интеграции
Uniswap v2, v3, v4 v3: все fee tiers; v4: hooks
Curve StableSwap, CryptoSwap Нелинейная AMM-формула
Balancer v2 WeightedPool, StablePool Многотокенные пулы
PancakeSwap v2, v3 BSC + Ethereum
SushiSwap v2 Мультичейн

Данные пулов синхронизируем через комбинацию The Graph subgraph (для исторических данных) и прямых on-chain вызовов через eth_call batch (для актуальных резервов). The Graph даёт latency ~500 мс — слишком медленно для real-time котировок. Поэтому критичные данные (reserves, sqrtPriceX96 для v3) кэшируются локально и обновляются через WebSocket подписку на события Swap, Mint, Burn. Это позволяет получать котировки за 80–120 мс.

Как мы защищаем от MEV-атак

Котировка агрегатора — лакомый кусок для MEV-ботов. Если amountOutMin установлен слишком мягко, sandwich атака неизбежна: бот видит транзакцию в мемпуле, толкает цену вперёд, ваш свап проходит по худшей цене, бот откатывает. Контрмеры: amountOutMin по default = 99% от котировки (1% slippage), опциональная интеграция с Flashbots Protect или MEV Blocker для private mempool routing.

Дополнительный уровень защиты — динамический slippage tolerance, который рассчитывается на основе исторической волатильности пары. Для стабильных пар (USDC/USDT) допуск 0.5%, для волатильных — до 2%. Это снижает количество ревертов при сохранении защиты. Динамический slippage снижает реверты на 70% по сравнению со статическим 0.5%.

Сравнение методов защиты от MEV:

Метод Эффективность Latency Стоимость
Стандартный мемпул Низкая Мгновенно 0
Private mempool (Flashbots) Высокая +1-2 блока 0
Котировка с коротким TTL Средняя +0 0
Динамический slippage Высокая +0 0

Что входит в разработку API DEX-агрегатора

  • Routing engine: граф ликвидности, поиск оптимального маршрута, кэш резервов.
  • Smart order router: контракт для атомарных мультихоп свапов с адаптерами под протоколы.
  • REST/RPC API: эндпоинты /quote и /swap, rate limiting, документация (Swagger/OpenAPI).
  • Тестирование: юнит-тесты, fork-тесты на mainnet, нагрузочное тестирование с 1000 запросов/сек.
  • Деплой: контракты в выбранные сети, настройка инфраструктуры (RPC, WebSocket, облачное развёртывание).
  • Поддержка: 1 месяц послесопровождения, исправление багов, консультации.

Процесс и сроки

  1. Аналитика (1 день): список целевых DEX, чейны (Ethereum, Arbitrum, Base, BSC), требования к latency.
  2. Разработка routing engine (2–3 дня): граф ликвидности, алгоритм поиска пути, кэш резервов.
  3. Разработка router-контракта (1–2 дня): мультихоп адаптеры, тесты на fork.
  4. REST/RPC API (1 день): endpoint /quote, /swap, rate limiting, документация.
  5. Тестирование и оптимизация (1 день): нагрузочные тесты, latency профилирование.

Итого: 3–5 дней для базовой версии с 3–5 DEX на одном чейне. Мультичейн с 10+ источниками ликвидности — 2–3 недели.

Почему выбирают нас?

Наша команда имеет более 5 лет опыта в DeFi и реализовала 20+ агрегаторов для разных блокчейнов. Мы гарантируем стабильную работу API под нагрузкой и поможем интегрировать любые DEX. Свяжитесь с нами для бесплатной оценки вашего проекта. Закажите разработку API DEX-агрегатора под ключ и получите надёжное решение для оптимальных свапов. Получите консультацию по архитектуре и срокам — просто напишите нам.