Розробка системи split-routing для оптимізації ціни

Розробка системи split-routing для оптимізації ціни

Ордер на 500K USDC через один DEX — це гарантований проскальз на 3-8% в залежності від глибини пулу. На Uniswap v3 з концентрованою ліквідністю ситуація краща, але на неліквідних парах impact цени все ж таки з'їдає значну частину угоди. Split-routing — це не маркетинг, це математика: оптимальний розподіл ордера між кількома джерелами ліквідності знижує сумарний price impact завдяки роботі на різних ділянках кривих.

Чому наївне розділення не працює

Інтуїтивний підхід — розділення 50/50 між Uniswap та Curve — дає субоптимальний результат. Оптимальний розподіл нелінійний і залежить від поточного стану пулів, глибини ліквідності в конкретних тіках (для Uniswap v3) та нахилу bonding curve (для Curve StableSwap). Проблему посилює те, що стан пулів змінюється між обчисленням маршруту та виконанням транзакції.

Front-running через MEV та застарілість маршруту

Системи split-routing атакують на двох рівнях. Перший — класичний sandwich attack: MEV-бот бачить великий swap у mempool, вставляє покупку перед ним та продаж після, використовуючи flashbots bundle або приватний mempool. Другий рівень тонший: маршрут обчислюється off-chain за станом пулів на блоку N, а виконується на блоку N+2. За два блоки ліквідність у активному тіку Uniswap v3 могла зміститися, і оптимальний маршрут став субоптимальним.

На практиці це означає, що алгоритм маршрутизації повинен закладати допуск на зміну стану та перерахувати при розходженні з очікуваним виходом. 1inch реалізує це через «partial fill» з minReturn, ми реалізуємо аналогічний механізм у on-chain executor.

Проблема атомарності багатокрокового маршруту

Split через кілька транзакцій — це не split, це послідовні свапи. Для атомарного виконання потрібен контракт-агрегатор, який в одному виклику виконує всі частини маршруту через multicall або власну логіку маршрутизації. Якщо проміжний крок ревертується — весь бандл відкатується. Це вимагає обережного поводження з газом: кожен додатковий hop коштує 30-80k газу в залежності від протоколу.

Як ми будуємо split-routing

Алгоритм оптимізації маршруту

Ядро системи — off-chain оптимізатор, який вирішує задачу мінімізації сумарного price impact. Для кожного DEX ми отримуємо криву «об'єм → ціна виконання»:

• Uniswap v2/v3, PancakeSwap: через quoter контракт або симуляцію через eth_call з fork стану
• Curve: аналітична формула StableSwap/Cryptoswap
• Balancer: формула WeightedPool або StablePool через querySwap
• DODO: PMM (Proactive Market Maker) — нелінійна крива з параметрами з оракула

Оптимізатор ділить ордер на N частин та ітерує по розподілу, мінімізуючи сумарний вихід. Використовуємо градієнтний спуск з числовим диференціюванням — аналітичні похідні для Uniswap v3 з тіками нетривіальні через дискретність. Алгоритм сходиться за 50-200 ітерацій, що укладається в < 100ms на типовому сервері.

On-chain executor

Контракт-агрегатор отримує від off-chain оптимізатора закодований маршрут: масив (address pool, bytes calldata swapData, uint256 portion). Executor ітерує по масиву, викликаючи кожен пул з розрахованою часткою вхідного токену. На виході перевіряє actualOutput >= minOutput через require, інакше revert.

struct SwapStep {
    address pool;
    address tokenIn;
    address tokenOut;
    uint256 amountIn;
    bytes data; // ABI-encoded call to pool
}

Для Uniswap v3 data містить закодований exactInputSingle з параметрами. Для Curve — exchange з i, j, dx. Єдиний інтерфейс через адаптери під кожен протокол.

Захист від MEV

Інтеграція з Flashbots Protect RPC як опція для крупних ордерів — транзакція йде напрямки до builder, обминаючи публічний mempool. Для EVM-сумісних L2 (Arbitrum, Optimism) MEV-ризик нижче завдяки централізованому sequencer, але на Base та zkSync уже з'являються MEV-боти.

Допуск slippage налаштовується динамічно: для пар з високою волатильністю (альти) — 0.5-1%, для стейблів на Curve — 0.05-0.1%.

Процес роботи

Аналіз ліквідності (3-5 днів). Профілюємо пулы на цільових чейнах: глибина ліквідності, типові об'єми, розподіл по тіках для v3. Визначаємо список DEX для інтеграції.

Розробка оптимізатора (1-2 тижні). Off-chain сервіс на TypeScript/Python. Тестуємо на історичних даних через The Graph — наскільки оптимальний маршрут переважає прямий своп за вихідною ціною.

Smart contract executor (1 тиждень). Розробка та тести у Foundry з fork-тестами на mainnet. Перевіряємо всі граничні випадки: нульовий вихід, revert у проміжному пулу, reentrancy через callback.

Інтеграція та деплой. API для front-end, документація за параметрами, деплой на testnet → mainnet через Gnosis Safe мультисиг.

Орієнтири за строками

Базова система з 3-5 DEX на одному чейні — 3-4 тижні. Мультичейн агрегатор з кросс-L2 маршрутизацією через bridge — від 2 місяців. Строки залежать від кількості інтегрованих протоколів та вимог до оновлення маршрутів у реальному часі.

Типові грабли при розробці

Stale quotes у production. Алгоритм обчислює маршрут за станом блоку N, транзакція майниться на N+3. Пул встиг зміститися. Рішення — on-chain верифікація мінімального виходу та досить консервативна slippage tolerance.

Газ на multicall перевищує економію від кращої ціни. На Ethereum mainnet при високому газі (> 50 gwei) розділення на 5 хопів додає 200-400k газу. Для дрібних ордерів це дорожче, ніж price impact від прямого свапу. Оптимізатор повинен враховувати вартість газу як частину цільової функції.

Curve pool imbalance після крупного свапу. Після виконання нашої частини маршруту через Curve пул може виявитися сильно незбалансованим, і наступний хоп отримує гіршу ціну, ніж передбачав оптимізатор. Для послідовних хопів всередину однієї транзакції це критично — потрібна симуляція стану после кожного кроку.