Разработка DEX-агрегатора
Разработчик интегрирует swap в dApp, напрямую в один Uniswap v3 пул — и пользователи жалуются на плохие курсы. Причина: для крупных свопов ($50K+) ликвидность одного пула не оптимальна. Разбить на несколько источников (split routing) может дать 0.3-0.8% улучшение цены. На $100K свопе это $300-800 разницы. Именно это делает агрегатор — находит оптимальный маршрут через несколько DEX одновременно.
Техническая сложность: routing algorithm
Граф DEX ликвидности и поиск пути
Routing задача — это нахождение оптимального пути в направленном графе, где:
- Узлы = токены
- Рёбра = пулы (каждый пул создаёт два ребра: token0→token1 и обратно)
- Вес ребра = output amount для заданного input
Для простого свопа A→B нужен кратчайший путь (по максимизации output). Для split routing — нужно разбить input на K частей и найти K путей, которые в сумме дают максимальный output.
Наивный подход — перебор всех путей длиной 1-3 hop, сравнение outputs. Работает при небольшом количестве пулов. При 10,000+ пулов (Uniswap v3 на mainnet имеет >8,000 активных пулов) — нужна оптимизация.
Практический подход:
- Предварительная фильтрация: только пулы с TVL > $100K и объёмом > $10K за 24h
- Bellman-Ford для нахождения всех путей до 3 hop
- Для split routing: симуляция нескольких пропорций (100/0, 80/20, 60/40, 50/50) через каждый маршрут, выбор максимума
Для EVM чейнов с high gas (Ethereum mainnet) 3-way split уже нецелесообразен: экономия от лучшей цены может перекрываться дополнительным газом. На Arbitrum/Optimism (gas ~$0.01-0.05) split routing выгоден даже для маленьких свопов.
Симуляция output off-chain
Ключевое требование: рассчитать amountOut для каждого маршрута быстро и точно без on-chain вызовов (те дорогие и медленные).
Uniswap v2 (x*y=k): аналитическая формула:
amountOut = (amountIn * 997 * reserveOut) / (reserveIn * 1000 + amountIn * 997)
Данные резервов через getReserves() — один RPC вызов на пул.
Uniswap v3 (концентрированная ликвидность): нет аналитической формулы для произвольных сумм. Нужно симулировать тик-за-тиком. QuoterV2.quoteExactInputSingle делает это on-chain, но это RPC вызов с gas симуляцией. Для быстрого routing — использовать off-chain реализацию tick math (@uniswap/v3-sdk) с кешированными данными тиков из subgraph.
Curve: get_dy(i, j, dx) — view функция, статик-колл. Для каждого пула Curve нужен отдельный RPC вызов, но они батчатся через Multicall3.
Staleness данных и решение
Данные резервов и тиков устаревают с каждым блоком. При volatile рынке за 1-2 блока цена может сдвинуться значительно. Стратегии обновления:
-
Подписка на события:
Sync(Uniswap v2),Swap(Uniswap v3/Curve) через WebSocket. При каждом событии обновляем кеш для конкретного пула - Периодический polling: каждые 5-10 секунд для менее ликвидных пулов
- On-demand refresh: при запросе quote — обновить данные для топ-10 пулов маршрута через Multicall
Наш подход: WebSocket events для топ-100 пулов по TVL, polling каждые 15 секунд для остальных.
Архитектура агрегатора
On-chain vs Off-chain routing
Полностью off-chain: routing Engine рассчитывает маршрут, возвращает готовый calldata для swap router. Smart contract — просто executor, никакой логики выбора пути. Это подход 1inch v5 Aggregation Router. Минимальный on-chain gas, но доверие к backend.
Hybrid: routing off-chain, on-chain верификация минимального output. Контракт получает path + amountOutMinimum, исполняет через Uniswap/Curve routers, проверяет require(amountOut >= amountOutMinimum). При несоответствии — revert. Это наш рекомендованный подход.
Aggregator Router контракт
contract AggregatorRouter {
function swap(
SwapParams calldata params
) external payable returns (uint256 amountOut) {
// Для каждого шага маршрута
for (uint i = 0; i < params.steps.length; i++) {
amountOut = _executeStep(params.steps[i], amountOut);
}
require(amountOut >= params.minAmountOut, "Insufficient output");
// Transfer output tokens to recipient
IERC20(params.tokenOut).safeTransfer(params.recipient, amountOut);
}
}
SwapStep содержит: protocol (uniswap_v2/v3/curve/balancer), poolAddress, tokenIn, tokenOut, portion (для split routing — какая доля идёт через этот шаг).
Комиссия агрегатора
Агрегаторы берут fee двумя способами:
- Spread: показывают пользователю quote чуть хуже реального, разницу оставляют. Непрозрачно.
- Explicit fee: берут N bps (basis points) от output. Прозрачно, лучше для репутации.
Типично: 5-30 bps (0.05-0.30%) в зависимости от swap size. Реализуется в контракте как feeAmount = amountOut * feeBps / 10000.
Мультичейн и бриджинг
Расширение агрегатора до cross-chain swap: пользователь отправляет USDC на Ethereum, получает MATIC на Polygon. Под капотом: swap USDC→bridgeToken на Ethereum, bridge через Across/Stargate, swap bridgeToken→MATIC на Polygon.
Интеграция с Across Protocol v3: SpokePool.deposit() с destination calldata для финального swap. Latency bridge: 1-5 минут. Газ: существенно выше одиночного swap, целесообразно от $1000+ суммы.
Стек разработки
Backend routing engine: TypeScript, viem для RPC вызовов, Redis для кеширования данных пулов, WebSocket для event subscriptions. Smart contracts: Solidity 0.8.x + Foundry. Frontend: React + wagmi + токен импорт через Uniswap Token Lists стандарт.
Для subgraph данных (TVL, volume, тики Uniswap v3): The Graph hosted service или собственный subgraph на Graph Node.
Процесс работы
Routing engine (1-2 недели). Граф пулов, алгоритм поиска маршрута, симуляция outputs, кеширование.
Smart contract (1 неделя). Aggregator router + тесты fork mainnet.
API и frontend (1-2 недели). Quote API, swap UI с отображением маршрута.
Тестирование. Сравнение quotes с 1inch/Paraswap как эталоном.
Ориентиры по срокам
Агрегатор для 2-3 DEX в одном чейне: 2-3 недели. Мультичейн агрегатор с cross-chain swap и собственным subgraph: 2-3 месяца.