Split-routing забезпечує оптимізацію ціни, мінімізуючи price impact через маршрутизацію ордерів між DEX-агрегаторами з MEV-захистом, підтримуючи Uniswap v3, Curve, Balancer та виконуючи газову оптимізацію через смарт-контракт executor.
Зауважимо: коли виконуєте великий ордер через один DEX, прослизання ціни гарантовано становить 3–8% — навіть на Uniswap v3 з концентрованою ліквідністю. На неліквідних парах price impact з'їдає ще більше. Ми розробляємо системи split-routing — не маркетинговий трюк, а математично вивірене розбиття ордера між кількома джерелами ліквідності. Split-routing враховує криві ліквідності кожного пулу і знаходить оптимальний розподіл, мінімізуючи сумарний зсув ціни. Згідно з Uniswap v3 Whitepaper, концентрована ліквідність дозволяє збільшити глибину у вузькому діапазоні, але при великому ордері все одно виникає прослизання. Наш підхід вирішує цю проблему, розподіляючи потік між Uniswap, Curve, Balancer та іншими протоколами. Зв'яжіться з нами для попереднього аналізу ліквідності — оцінимо ваш проєкт і запропонуємо архітектуру під ключ.
Чому наївне розбиття не працює?
Інтуїтивний підхід — split 50/50 між Uniswap і Curve — дає субоптимальний результат. Оптимальний розподіл нелінійний і залежить від поточного стану пулів, глибини ліквідності в конкретних тиках (для Uniswap v3) та нахилу bonding curve (для Curve StableSwap). Проблема посилюється тим, що стан пулів змінюється між обчисленням маршруту та виконанням транзакції.
Як захиститися від MEV-атак?
Системи split-routing атакують на двох рівнях. Перший — класичний sandwich attack: MEV-бот бачить великий swap у mempool, вставляє buy перед ним і sell після, використовуючи flashbots bundle або private mempool. Другий рівень тонший: маршрут обчислюється off-chain за станом пулів на блок N, а виконується на блок N+2. За два блоки ліквідність в активному тику Uniswap v3 могла зсунутися, і оптимальний маршрут став субоптимальним.
На практиці це означає, що алгоритм маршрутизації повинен закладати tolerance на зміну стану і перераховувати при розбіжності з очікуваним виходом. 1inch реалізує це через partial fill з minReturn, ми реалізуємо аналогічний механізм в on-chain executor.
Проблема атомарності багатокрокового маршруту
Split через кілька транзакцій — це не split, це послідовні свапи. Для атомарного виконання потрібен контракт-агрегатор, який в одному виклику виконує всі частини маршруту через multicall або власну логіку роутингу. Якщо проміжний крок ревертується — весь бандл відкочується. Це вимагає careful handling газу: кожен додатковий hop коштує 30–80k gas залежно від протоколу.
Що таке split-routing і навіщо він потрібен
Split-routing — це не просто дроблення ордера, а математично оптимальний розподіл по пулам. Він дозволяє знизити price impact у 4-6 разів порівняно з прямим свапом на великих ордерах (на значних обсягах). Економія на угоді часто перевищує додаткові газові витрати. Наприклад, для ордера в 500k USDC split-routing економить близько $20,000. Економія на великих угодах може бути значною.
Як ми будуємо 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 частин і ітерує по розподілу, мінімізуючи сумарний вихід. Використовуємо gradient descent з чисельним диференціюванням — аналітичні похідні для Uniswap v3 з тиками нетривіальні через дискретність. Алгоритм сходиться за 50–200 ітерацій, що вкладається в < 100ms на типовому сервері.
On-chain executor
Контракт-агрегатор отримує від off-chain оптимізатора encoded маршрут: масив (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 містить encoded exactInputSingle з параметрами. Для Curve — exchange з i, j, dx. Єдиний інтерфейс через адаптери під кожен протокол.
Захист від MEV
Інтеграція з Flashbots Protect RPC як опція для великих ордерів — транзакція йде безпосередньо до builder, минаючи публічний mempool. Для EVM-сумісних L2 (Arbitrum, Optimism) MEV-ризик нижчий за рахунок centralized sequencer, але на Base і zkSync вже з'являються MEV-боти.
Сліпейдж tolerance налаштовується динамічно: для пар з високою волатильністю (алти) — 0.5–1%, для стейблів на Curve — 0.05–0.1%.
Що входить у роботу
- Документація: опис архітектури, специфікація API, параметри конфігурації.
- Вихідний код: off-chain оптимізатор (TypeScript/Python) та смарт-контракти з тестами.
- Інтеграція: налаштування деплою, підключення до вашого front-end, навчання команди.
- Підтримка: 2 тижні post-launch моніторингу та фіксів.
Все виконується під ключ: ви отримуєте готовий агрегатор, адаптований під ваші токени та чейни. Пишіть — оцінимо ваш проєкт і запропонуємо архітектуру.
Процес роботи
- Аналіз ліквідності (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 verification мінімального виходу та досить консервативний slippage tolerance.
Газ на multicall перевищує економію від кращої ціни. На Ethereum mainnet при високому газі (> 50 gwei) розбиття на 5 хопів додає 200–400k gas. Для дрібних ордерів це дорожче, ніж price impact від прямого свапа. Оптимізатор повинен враховувати вартість газу як частину цільової функції.
Curve pool imbalance після великого свапа. Після виконання нашої частини маршруту через Curve пул може виявитися сильно незбалансованим, і наступний хоп отримує гіршу ціну, ніж передбачав оптимізатор. Для послідовних хопів всередині однієї транзакції це критично — потрібна симуляція стану after кожного кроку.
Порівняння: split-routing проти прямого свапа
| Характеристика | Прямий свап на одному DEX | Split-routing (3+ DEX) |
|---|---|---|
| Price impact (ордер 500k USDC) | 3–8% | 0.5–2% (у 4-6 разів менше) |
| Ризик MEV | Високий | Знижений (частково приватні tx) |
| Газ (Ethereum) | ~100k gas | 300–500k gas |
| Доступні протоколи | Один | 3–5 і більше |
Зауважимо: як бачите, split-routing виграє в ціні виконання в 2-4 рази, хоча потребує більше газу. Це ідеальний trade-off для великих ордерів.
Uniswap v3 Whitepaper • Curve Finance Documentation
Наші інженери мають 5+ років досвіду в DeFi, 30+ успішних проєктів. Ми гарантуємо прозорий код з повним набором тестів. Замовте попередній аналіз ліквідності — ми підберемо оптимальний набір DEX для ваших токенів.