Как работают DEX-агрегаторы и multi-hop swaps простыми словами: routing, execution quality и MVP для swap helper

После разговора про AMM против order book DEX логично перейти на следующий практический слой — как пользователь вообще получает лучший обмен между десятками пулов, сетей и маршрутов. В реальной жизни своп почти никогда не упирается в одну пару и один контракт. Часто лучший результат получается через несколько пулов, иногда через другой актив-посредник, а иногда через разбиение ордера на части.

Именно здесь появляются DEX-агрегаторы, routers и multi-hop swaps. Для технической аудитории это одна из самых полезных тем в DeFi, потому что она соединяет сразу несколько важных вещей:

механику ликвидности;
ценообразование и проскальзывание;
комиссии и execution quality;
backend-логику quote engine;
monitoring, alerts и automation layer вокруг маршрутизации.

Если смотреть на свежие инженерные обсуждения в HN и вокруг DeFi-инфраструктуры шире, там всё чаще повторяется один мотив: ценность не в том, что кнопка Swap существует, а в том, насколько умно система выбирает путь исполнения. Интерфейс можно скопировать быстро. Хороший routing engine — уже нет.

Что именно разбираем

Сегодня разбираем:

что такое DEX router и DEX aggregator;
зачем нужен multi-hop swap;
как система решает, идти ли напрямую или через промежуточный актив;
как двигаются деньги по маршруту;
кто платит fees и где возникают hidden costs;
почему «лучшая цена» без учёта gas и execution risk часто вообще не лучшая;
как собрать похожий MVP, dashboard или helper-tooling вокруг routing.

Главный вопрос статьи можно сформулировать очень просто: как провести пользователя из токена A в токен B так, чтобы итоговый результат был действительно хорошим, а не только красиво выглядел в quote.

Как это работает простыми словами

Представим, что пользователь хочет обменять токен A на токен D.

Наивный вариант такой:

найти один пул A/D;
отправить туда swap;
получить результат.

Но в реальности прямой пул может быть:

слишком тонким;
с плохой ценой;
с высоким price impact;
с большой комиссией;
просто не самым выгодным по ликвидности в данный момент.

Поэтому router начинает искать альтернативы:

A -> USDC -> D
A -> WETH -> D
A -> USDC -> WETH -> D
split route: 60% через один путь, 40% через другой

То есть агрегатор делает примерно то же, что хороший логистический движок: не просто ищет факт существования дороги, а пытается найти лучший маршрут с учётом стоимости, потерь и ограничений.

Что такое multi-hop swap

Multi-hop swap — это обмен, где для достижения конечного актива используется не одна сделка в одной паре, а последовательность переходов через промежуточные активы.

Пример:

пользователь хочет купить токен ARB за cbBTC;
прямой пул cbBTC/ARB слабый или дорогой;
router выбирает путь cbBTC -> WETH -> USDC -> ARB.

Для пользователя это выглядит как одна операция. Но под капотом это цепочка нескольких свопов.

Почему промежуточный маршрут может быть выгоднее

Потому что ликвидность на популярных промежуточных активах часто глубже:

USDC;
USDT;
WETH;
WBTC;
иногда stables в конкретной сети.

Даже если hops больше, итог может быть лучше за счёт:

меньшего slippage;
лучшей глубины;
более узких fee tiers;
доступа к нескольким пулам вместо одного слабого.

Чем router отличается от aggregator

Эти термины часто используют вперемешку, но полезно развести их по смыслу.

Router

Router — это компонент, который:

принимает входной токен и выходной токен;
знает доступные пулы или venue;
строит маршрут;
исполняет его через набор контрактных вызовов.

Он может быть локальным для одного протокола. Например:

router только внутри Uniswap-like ecosystem;
router только внутри одного DEX;
router только по пулам конкретной сети.

Aggregator

Aggregator стоит уровнем выше.

Он может:

сравнивать несколько DEX;
считать direct route против multi-hop route;
дробить ордер между venue;
учитывать gas cost;
выбирать execution path между разными liquidity sources.

Если упростить:

router — выбирает путь внутри известного пространства;
aggregator — сравнивает несколько пространств и пытается оптимизировать итоговый execution.

Как двигаются деньги по маршруту

Это самый важный практический кусок.

Базовый сценарий

Пользователь хочет обменять 10 ETH в токен TOKENX.

Агрегатор считает, что лучший путь такой:

5 ETH через ETH -> USDC -> TOKENX
3 ETH через ETH -> DAI -> TOKENX
2 ETH напрямую через ETH -> TOKENX

Что происходит дальше:

Пользователь подписывает один swap.
Router или aggregator contract получает входной актив.
Ордер разбивается на несколько execution legs.
Каждый leg проходит через свой набор пулов.
Промежуточные токены переходят между контрактами внутри той же транзакции.
Конечный актив собирается обратно и отправляется пользователю.
Если итог ниже minAmountOut, транзакция должна откатиться.

Кто здесь получает fee

Важный момент: fee flow распределён по нескольким слоям.

Trader платит:

swap fee в каждом пуле;
gas за выполнение маршрута;
иногда aggregator fee или referral fee;
implicit cost из-за slippage и market impact.

LP получают:

комиссию каждого пула, через который прошёл объём.

Aggregator или protocol могут получать:

protocol fee;
routing fee;
spread capture, если модель это допускает.

Block builders / validators / MEV actors могут косвенно забирать value:

если маршрут публичный и исполнение можно ухудшить;
если есть sandwich-риски;
если quote устарел к моменту включения в блок.

Именно поэтому «цена до исполнения» и «реально полученный output» — это не одно и то же.

Откуда берётся лучший маршрут

Идея «лучшего маршрута» кажется простой только снаружи. На практике это оптимизация сразу по нескольким измерениям.

1. Liquidity depth

Нужно понять:

сколько ликвидности реально стоит рядом с текущей ценой;
как быстро растёт price impact;
где есть concentrated liquidity, а где пустота.

2. Pool fee tier

Иногда маршрут через большее число hop’ов выигрывает, а иногда наоборот проигрывает, потому что:

в одном пуле fee 0.01%;
в другом 0.3%;
в третьем 1%;
итоговый gross output без fee кажется хорошим, но после fee путь уже хуже.

3. Gas cost

Каждый дополнительный hop — это:

больше вычислений;
больше контрактных вызовов;
выше gas.

Для небольшого swap это может съесть всю выгоду от supposedly better route.

4. Execution risk

Даже выгодный на бумаге путь может быть плохим, если:

пул слишком быстро меняется;
quote stale;
маршрут зависит от тонкой ликвидности;
вероятность revert высокая;
частичный split route делает транзакцию хрупкой.

5. MEV exposure

Публичный route может стать мишенью для:

sandwich attacks;
backrun арбитража;
ухудшения fill quality между quote и settlement.

6. Token risk и protocol risk

Иногда самый выгодный маршрут проходит через сомнительный токен-мостик или малоизвестный пул. Технически quote хороший, но продуктово это плохой маршрут.

Поэтому зрелый routing engine оптимизирует не просто по maxOutput, а по чему-то вроде:

bestNetExecution = output - gas - executionRiskPenalty - policyPenalty

Почему direct route часто проигрывает

Прямая пара выигрывает только если там действительно достаточная ликвидность и нормальная комиссия.

Пример:

прямой пул A/B даёт 1 000 000 units output;
маршрут A/USDC/B даёт 1 008 000;
но при этом на двух hop’ах суммарный fee выше и gas больше;
после вычета всех издержек итог становится 1 004 500.

Тогда multi-hop всё ещё лучше.

Но бывает и наоборот:

gross quote выше;
gas съедает преимущество;
итоговый net output уже хуже прямого пути.

Именно поэтому в нормальном UX пользователю стоит показывать не только «best quote», но и почему маршрут выбран именно такой.

Какие trade-offs реально важны

1. Лучший price quote vs лучший net execution

Самая частая ошибка — сравнивать только output token amount.

Но пользователь интересуется не abstract quote, а тем, сколько он реально получит после всех потерь.

2. Больше hops = лучше цена, но выше хрупкость

Каждый hop увеличивает:

число зависимостей;
вероятность изменений в состоянии пулов;
gas cost;
поверхность для ошибки.

3. Split routing улучшает execution, но усложняет систему

Разделение ордера по нескольким путям может дать лучший результат, но требует:

точной симуляции;
сложного settlement path;
хорошего fallback behavior.

4. Smart routing повышает UX, но переносит сложность в backend

Пользователь видит одну кнопку. Команда поддержки видит:

quote engine;
indexers;
slippage simulator;
token policy rules;
observability;
incident runbooks.

5. Оптимальный путь зависит от размера ордера

Маршрут для 100 USDC и для 1 000 000 USDC часто должен быть разным.

Для маленького ордера:

можно предпочесть минимальный gas и простоту.

Для крупного ордера:

важнее разбивка объёма;
важнее depth-aware routing;
важнее защита от execution degradation.

Основные компоненты архитектуры

Если строить такой продукт не как игрушку, а как полезный прототип или основу для сервиса, архитектура обычно делится на несколько блоков.

1. Onchain contracts

Минимальный контрактный слой:

router contract;
adapter contracts для разных DEX;
allowance / permit handling;
slippage guard;
deadline checks;
emergency pause / denylist для risky paths.

Если продукт не делает собственное onchain исполнение, а только помогает с quote, контрактная часть может быть тоньше. Но даже тогда нужны понятные execution boundaries.

2. Pool and market indexer

Нужно собирать:

reserves;
liquidity ranges;
fee tiers;
recent swaps;
pool health;
token metadata;
block-by-block state updates для расчётов.

Без свежего индекса router начинает принимать решения на старых данных.

3. Quote engine

Это сердце системы.

Он должен:

строить candidate paths;
симулировать output;
учитывать gas;
фильтровать risky venues;
решать, когда дробить ордер;
выдавать ranked routes.

Полезно держать в нём отдельные модули:

path_generator
pool_scorer
gas_estimator
risk_penalty_engine
split_optimizer
quote_cache

4. Execution service

Даже если quote правильный, нужен слой, который:

подготавливает calldata;
следит за deadline;
проверяет final minAmountOut;
логирует execution report;
отмечает revert reasons;
сравнивает quoted vs realized output.

5. Policy and risk engine

Здесь задаются ограничения:

запрещённые токены;
max hops;
max per-route exposure;
min liquidity threshold;
max allowed price impact;
max stale quote age;
bridge and cross-chain rules, если продукт расширяется дальше спота.

6. Monitoring and analytics

Нужно видеть:

route success rate;
revert rate;
average slippage vs estimate;
gas overhead per route type;
execution quality by venue;
top pools by degradation;
suspicious spikes и anomaly patterns.

Реальные сценарии использования

1. Wallet swap helper

Самый очевидный use-case.

Нужно:

быстро выдать quote;
показать path explanation;
подсветить gas и slippage;
защитить пользователя от плохих маршрутов.

2. Treasury execution assistant

Команда проекта хочет конвертировать часть treasury из одного актива в другой.

Тогда routing system помогает:

разбить объём;
выбрать время исполнения;
избегать тонких пулов;
логировать итоговую execution quality.

3. Arbitrage and market monitoring dashboard

Не обязательно сразу строить swap front-end. Иногда выгоднее собрать инструменты вокруг:

мониторинг расхождения цен;
поиск неэффективных путей;
alerting на ухудшение ликвидности;
сравнительный анализ venue.

4. RFQ / solver-style execution helper

Даже если продукт потом уйдёт в intents или RFQ, routing layer никуда не исчезает. Просто часть маршрута будет считаться offchain solver’ом, а не публичным router’ом.

Риски и ограничения

Slippage risk

Если маршрут проходит через тонкие пулы или несколько узких мест, итоговое исполнение может сильно отличаться от ожиданий.

Quote staleness

На волатильном рынке quote быстро устаревает. Если данные обновляются медленно, агрегатор начинает врать.

Revert risk

Чем сложнее маршрут, тем выше вероятность, что один из шагов не выполнится и вся транзакция откатится.

MEV and sandwich exposure

Если маршрут крупный и публичный, часть value может быть потеряна между quote и settlement.

Toxic route selection

Алгоритм может выбрать mathematically attractive, но продуктово плохой путь:

малоизвестный токен;
странный пул;
протокол с историей инцидентов;
маршрут через слишком много зависимостей.

Operational complexity

Снаружи это «просто swap helper», внутри — полноценная data и execution система.

Как собрать похожий MVP

Если задача — сделать не production-grade aggregator, а убедительный demo или рабочий prototype, разумно идти слоями.

Шаг 1. Ограничить universe

Не надо сразу поддерживать всё.

Нормальный MVP:

одна сеть, например Ethereum или Base;
10–30 whitelisted pools;
2–3 DEX adapters;
фокус на blue-chip токенах;
max 2–3 hops.

Это резко упрощает пространство поиска.

Шаг 2. Собрать indexer

Минимально нужны таблицы:

tokens
pools
pool_reserves
pool_fee_tiers
pool_snapshots
quotes
routes
executions
risk_flags

Источники данных:

onchain RPC;
event logs;
subgraph-like слой или свой lightweight indexer.

Шаг 3. Сделать quote engine

Самый понятный MVP-подход:

Построить граф активов и пулов.
Сгенерировать candidate paths до заданной глубины.
Просимулировать output для каждого path.
Оценить gas.
Отфильтровать risky paths.
Выбрать лучший net route.

Псевдоструктура:

build_graph()
generate_paths(tokenIn, tokenOut, maxHops=3)
simulate_each_path(amountIn)
estimate_gas()
apply_risk_penalties()
rank_by_net_output()
return best_route

Шаг 4. Добавить execution wrapper

Даже demo должен уметь:

подготовить calldata;
выставить minAmountOut;
задать deadline;
логировать результат;
откатываться при плохом исполнении.

Шаг 5. Собрать UI

Минимальный интерфейс:

token in / token out;
amount;
expected output;
route preview;
gas estimate;
price impact;
warnings по risk flags.

Хороший бонус для технической аудитории — раскрываемый блок Why this route:

почему не direct path;
почему выбран именно этот промежуточный актив;
какой venue дал лучший depth;
насколько gas съел выгоду.

Что можно автоматизировать поверх

Вот где тема особенно хорошо ложится на практический Sassoft-угол.

1. Route quality monitoring

Автоматические проверки:

quote vs realized output;
рост revert rate;
маршруты с аномально высоким gas;
деградация конкретных пулов.

2. Alerts на thin liquidity

Если один из ключевых промежуточных пулов просел по глубине, routing quality резко ухудшится. Это надо видеть заранее.

3. Treasury execution policies

Можно автоматизировать guardrails:

не исполнять swap выше определённого price impact;
не ходить через untrusted venues;
ограничивать исполнение по времени или объёму;
делить крупные ордера на серии.

4. Dashboard для операторов

Полезные панели:

top routes by volume;
routes with worst slippage;
gas by route family;
venue reliability;
quote freshness;
execution success heatmap.

5. Anomaly detection

Можно ловить:

резкие изменения reserve;
нетипичные расхождения direct vs multi-hop;
рост failed swaps;
venue-specific degradation;
route instability на одном и том же pair/amount profile.

6. Rebalance и keeper logic

Если рядом есть treasury, vault или execution bot, automation layer может:

выбирать окна для менее токсичного исполнения;
раскидывать большой swap по времени;
переключаться между venue по policy rules;
временно отключать опасные маршруты.

Как выглядит здравый roadmap

Если бы маленькая команда строила такой продукт сегодня, здравый порядок был бы примерно таким:

Phase 1 — visibility

indexer;
route simulator;
dashboard;
historical analytics.

Phase 2 — assisted execution

API с quote;
route explanation;
slippage and gas guardrails;
operator alerts.

Phase 3 — full routing MVP

onchain router / adapters;
split routing;
execution reports;
venue scoring;
policy engine.

Phase 4 — automation layer

treasury workflows;
scheduled swaps;
anomaly detection;
venue disable rules;
rebalancing bots.

Главное, что стоит запомнить

Если убрать шум, картина такая:

DEX router ищет путь обмена между токенами;
aggregator сравнивает несколько liquidity sources и оптимизирует execution;
multi-hop swap нужен потому, что лучший путь часто идёт через промежуточные активы, а не напрямую;
пользователь платит не только явные swap fees, но и gas, slippage и execution risk;
хороший routing engine выбирает не самый красивый quote, а лучший net execution;
для MVP достаточно собрать graph of pools + quote engine + risk filters + execution wrapper + dashboard;
самый ценный automation layer строится вокруг route quality, alerts, treasury policies, anomaly detection и operator tooling.

По сути, DEX-агрегатор — это не «ещё один swap UI», а движок принятия решений под ограничениями ликвидности, комиссий и риска исполнения. И именно поэтому routing — один из самых практичных способов объяснить, как на самом деле работает современный onchain exchange stack.