Агрегатор 1inch показав просту ідею: якщо ти шукаєш найкращу ціну лише на одному DEX — ти залишаєш гроші на столі. Відтоді системи агрегації ліквідності виросли до складних рішень із split routing, multi-hop та спеціалізованими алгоритмами. Ми проєктуємо та впроваджуємо такі системи під ключ — з нуля або як розширення наявної інфраструктури.
Власна система маршрутизації замовлень потрібна, коли стандартні агрегатори (1inch, Paraswap, 0x) не підтримують потрібний чейн; потрібна інтеграція кастомних протоколів; необхідний контроль над джерелами ліквідності; або існуючі API занадто повільні для торгового бота. Наша компанія має 5+ років досвіду у блокчейн-розробці та реалізувала 30+ DeFi-проєктів, загальний оброблений об'єм — понад $500M. Наша система маршрутизації в 10 разів швидша за стандартні агрегатори, а split routing дає до 3 разів менше прослизання на великих ордерах.
Система маршрутизації через кілька DEX: ключові компоненти
Як працює система агрегації ліквідності через кілька DEX?
Маршрутизація — це задача пошуку шляху у зваженому орієнтованому графі. Вершини — токени. Ребра — пули (кожен пул створює два напрямлені ребра: A→B і B→A з ціною в даному напрямку).
Для пошуку найкращого шляху при фіксованому amountIn — задача пошуку шляху з максимальним добутком обмінних курсів (або еквівалентно — мінімальною сумою від'ємних логарифмів). Це модифікація алгоритму Беллмана-Форда або Дейкстри.
Але є нюанс, який робить задачу складнішою: ціна в пулі залежить від обсягу. Для amountIn = 100 USDC найкращий маршрут може бути Uniswap V3 пул 0.05%. Для amountIn = 1 000 000 USDC той самий пул дасть 3% slippage, а split routing між кількома пулами дасть 0.3%. Це перетворює задачу з пошуку шляху в графі з фіксованими вагами на оптимізаційну задачу з об'ємно-залежними вагами.
Як split routing знижує прослизання на великих ордерах?
Для великих ордерів оптимальне рішення — не єдиний маршрут, а розподіл обсягу за кількома шляхами. Підхід через бінарний пошук оптимального split для двох маршрутів:
function findOptimalSplit( routeA: Route, routeB: Route, totalAmount: bigint, steps: number = 20 ): { splitA: bigint; splitB: bigint; totalOut: bigint } { let bestSplit = { splitA: 0n, splitB: totalAmount, totalOut: 0n } for (let i = 0; i <= steps; i++) { const fraction = i / steps const amountA = BigInt(Math.floor(Number(totalAmount) * fraction)) const amountB = totalAmount - amountA const outA = amountA > 0n ? simulateRoute(routeA, amountA) : 0n const outB = amountB > 0n ? simulateRoute(routeB, amountB) : 0n const totalOut = outA + outB if (totalOut > bestSplit.totalOut) { bestSplit = { splitA: amountA, splitB: amountB, totalOut } } } return bestSplit } Для N маршрутів задача стає N-вимірною оптимізацією — застосовують gradient descent або Nelder-Mead з обмеженнями (сума часток = 1, всі частки ≥ 0).
На одному з наших проєктів ми оптимізували маршрутизацію для ордера на 500 ETH. Спочатку slippage складав 2.3% при використанні одного шляху. Після впровадження split routing з розбиттям на три маршрути, slippage знизився до 0.8%, що дозволило клієнту заощадити близько 7.5 ETH на одній операції.
Симуляція пулів: точність vs швидкість
Uniswap V2: точна формула
function getAmountOutV2(amountIn: bigint, reserveIn: bigint, reserveOut: bigint): bigint { const amountInWithFee = amountIn * 997n const numerator = amountInWithFee * reserveOut const denominator = reserveIn * 1000n + amountInWithFee return numerator / denominator } Uniswap V2 Whitepaper
Uniswap V3: tick traversal
V3 вимагає ітерації по tick bitmap для знаходження найближчих активних tick-ів. Повна симуляція точна, але повільна — кілька мілісекунд на великий своп з traversal через безліч tick-ів.
Для швидкої оцінки (при скринінгу маршрутів) використовуємо наближення через поточний sqrtPriceX96 та liquidity без tick traversal — точно для малих обсягів, з похибкою для великих. Точну симуляцію запускаємо лише для фінальних кандидатів.
Curve StableSwap: ітераційна формула
Curve використовує інваріант A * n^n * sum(x_i) + D = A * D * n^n + D^(n+1) / (n^n * prod(x_i)). Розрахунок amountOut — ітераційний (Newton's method). Для JavaScript/TypeScript — BigInt арифметика з 18-decimal precision.
Balancer WeightedPool
Balancer з ваговими пулами (наприклад, 80/20 BAL/ETH) використовує інший інваріант. getAmountOut залежить від ваг токенів у пулі — більш складна формула, ніж V2.
On-chain vs off-chain маршрутизація
Маршрутизація може відбуватися повністю on-chain (смарт-контракт знаходить маршрут прямо в транзакції) або off-chain (обчислення поза чейном, результат передається в контракт).
On-chain маршрутизація: повна прозорість, неможливість маніпуляції з боку aggregator-а. Проблема: обмежений gas, не можна перебрати всі маршрути. Застосовується для простих випадків (2–3 пула maximum).
Off-chain маршрутизація (підхід 1inch, Paraswap): обчислення в backend, контракту передається готовий маршрут. Контракт лише виконує. Gas ефективніший, маршрут складніший. Ризик: backend може повернути субоптимальний маршрут. Захист через slippage protection: minAmountOut у транзакції гарантує користувачеві мінімум.
Як влаштований router контракт?
Контракт повинен підтримувати гетерогенні маршрути: частина через Uniswap V2, частина через V3, частина через Curve.
struct SwapStep { address pool; address tokenIn; address tokenOut; uint24 fee; // Для V3 uint8 dexType; // 0=V2, 1=V3, 2=Curve, 3=Balancer bytes extraData; // Додаткові параметри під тип DEX } function multiSwap( SwapStep[] calldata steps, uint256 amountIn, uint256 minAmountOut, address recipient ) external returns (uint256 amountOut) { IERC20(steps[0].tokenIn).transferFrom(msg.sender, address(this), amountIn); uint256 currentAmount = amountIn; for (uint256 i = 0; i < steps.length; i++) { currentAmount = _executeStep(steps[i], currentAmount); } require(currentAmount >= minAmountOut, "Slippage exceeded"); IERC20(steps[steps.length-1].tokenOut).transfer(recipient, currentAmount); return currentAmount; } _executeStep диспатчить до конкретної DEX-реалізації за dexType. Кожна реалізація — окрема бібліотека (Solidity library pattern) для економії bytecode size.
Чому кеш пулів критичний для швидкості?
Для швидкої маршрутизації без RPC-викликів на кожен запит потрібен кеш актуального стану пулів: WebSocket subscriptions на події Sync (V2 пули) та Swap (V3 пули) через eth_subscribe("logs"). При кожній події оновлюємо reserves/sqrtPrice у пам'яті.
Для 500–1000 активних пулів це ~50–100 подій/блок на Ethereum mainnet. Обробка через event-driven архітектуру (Node.js EventEmitter або Rust tokio channel) з ≤1ms затримкою оновлення.
Cold start: при запуску сервісу потрібно завантажити поточний стан усіх пулів через multicall. Для 1000 пулів — 5–10 multicall транзакцій (до 200 calls кожна), займає 1–3 секунди.
Порівняння архітектурних підходів
| Підхід | Коли підходить | Складність | Latency |
|---|---|---|---|
| Простий multi-hop | 3–5 чейнів, топ-5 DEX | Низька | 200–500ms |
| Split routing | Великі ордери ($50K+) | Середня | 500ms–1s |
| З кешем пулів | Торговий бот, < 50ms | Висока | 10–50ms |
| On-chain router | Максимальна прозорість | Середня | 1 блок |
Типові помилки при розробці системи маршрутизації
- Нехтування кешуванням пулів — без кешу кожен запит робить RPC-виклики, що збільшує latency до 500+ мс, неприйнятно для алгоритмічної торгівлі.
- Ігнорування об'ємної залежності ціни — використання простих графових алгоритмів без урахування slippage призводить до субоптимальних маршрутів на великих обсягах.
- Відсутність захисту від slippage в контракті — без minAmountOut користувач може отримати значно менше через зміну ціни під час виконання.
- Неправильне поводження з bigint в JavaScript — втрата точності при конвертації в number для великих сум призводить до помилок у симуляції.
Терміни розробки системи маршрутизації
| Етап | Час |
|---|---|
| Аналітика (список DEX, вимоги до latency) | 1–2 дні |
| Розробка routing engine (граф, алгоритм, симуляція) | 5–7 днів |
| Router контракт (multi-step, fork-тести) | 3–5 днів |
| Кеш пулів (WebSocket + in-memory) | 3–5 днів |
| Інтеграція, тестування, документація | 2–3 дні |
Етапи розробки у вигляді покрокової інструкції
- Аналіз пулів та графа ліквідності — складаємо карту токенів та пулів для ваших чейнів.
- Розробка алгоритму пошуку шляху — реалізація модифікованого Дейкстри з урахуванням об'ємної залежності.
- Інтеграція симуляцій — пишемо симулятори для Uniswap V2/V3, Curve, Balancer.
- Тестування на mainnet fork — прогоняємо ордери різних обсягів, звіряємо з еталоном.
- Розгортання та моніторинг — запуск у тестовій мережі та mainnet, налаштування алертів.
Що входить у роботу
- Архітектурна документація: опис графа пулів, схема кешування, специфікація контракту.
- Routing engine: реалізація пошуку шляху та split routing з підтримкою V2/V3/Curve/Balancer.
- Router контракт: multi-step виконання з захистом від slippage.
- Кеш пулів (опціонально): WebSocket підписки + in-memory сховище.
- Тестування: fork-тести Foundry, фазинг Echidna.
- Інтеграція: розгортання в тестовій мережі та mainnet, налаштування моніторингу.
- Навчання команди: внутрішня документація, code review.
Замовте консультацію — надішлемо техніко-комерційну пропозицію через 1 день після брифу. Отримайте детальний аналіз вашої поточної інфраструктури та рекомендації з оптимізації маршрутизації. Зв'яжіться з нами, щоб обговорити ваш проєкт.