Розробка 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. Між запитом та деплоєм транзакції у mempool — 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 атака неминуча: бот бачить транзакцію в mempool, тисне ціну вперед, ваш своп проходить по гіршій ціні, бот откатує. Контрмири: amountOutMin за замовчуванням = 99% від котировки (1% slippage), опціональна інтеграція з Flashbots Protect або MEV Blocker для приватного mempool маршрутизації.

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

Аналітика (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 тижні. Вартість рассчитується після уточнення списку протоколів та чейнів.