Разработка API DEX-агрегатора

Разработка API DEX-агрегатора

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

Где ломается routing-логика на практике

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 на основе исторической волатильности пары.

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

Uniswap v3 имеет пулы с разными fee tier: 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 дополнительные $2.4 газа превращают выгоду в убыток. API должен считать net output с учётом стоимости газа и возвращать маршрут, оптимальный по итоговой сумме, а не только по цене свапа.

Как мы строим DEX-агрегатор API

Архитектура routing engine

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

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

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

Контрактная часть: smart order router

API возвращает не просто маршрут, а calldata для исполнения. Для мультихоп свапов через разные протоколы — собственный router-контракт, который батчит вызовы и обеспечивает атомарность. Если один шаг в цепочке ревертится — откатывается всё.

Контракт написан на Solidity 0.8.x с использованием delegatecall для вызовов адаптеров под каждый протокол. Адаптеры изолированы — добавление нового DEX не трогает основной router. Тесты через Foundry с fork mainnet: реальные пулы, реальные резервы, edge cases при низкой ликвидности.

Защита от MEV и sandwich атак

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

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

Аналитика (1 день): список целевых DEX, чейны (Ethereum, Arbitrum, Base, BSC), требования к latency.

Разработка routing engine (2–3 дня): граф ликвидности, алгоритм поиска пути, кэш резервов.

Разработка router-контракта (1–2 дня): мультихоп адаптеры, тесты на fork.

REST/RPC API (1 день): endpoint /quote, /swap, rate limiting, документация.

Тестирование и оптимизация (1 день): нагрузочные тесты, latency профилирование.

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