Створення торгового бота на Uniswap: архітектура та gas-оптимізація
При створенні торгового бота на Uniswap розробник стикається з несумісністю поколінь SDK. V2 використовує пари з reserve0/reserve1, v3 — пули з sqrtPriceX96 та tickCurrent. Помилка у виборі версії або змішування концепцій — головна причина ревертів та невірних розрахунків. Наприклад, один із клієнтів втратив значну суму через неправильний розрахунок amountOut при арбітражі між v2 та v3 пулами. Такі ситуації вирішуються коректною архітектурою. Наша команда з 10+ блокчейн-інженерів допомагає уникнути цих пасток та побудувати надійне рішення під ключ.
Як вибрати версію SDK для торгового бота?
У v2 SDK пул — це просто Pair з двома токенами та reserve0/reserve1. Ціна обчислюється тривіально, але відсутня concentrated liquidity — ефективність капіталу низька. У v3 SDK пул — це Pool з sqrtPriceX96 у Q64.96-форматі, liquidity та tickCurrent. Розрахунок amountOut для великого свопу вимагає ітерації по tick-масиву. Саме це робить @uniswap/v3-sdk через утиліти SwapMath та TickMath (згідно з офіційною документацією Uniswap v3 SDK).
Типова помилка: брати sqrtPriceX96 та liquidity з одного eth_call, а ticks — з іншого. Між викликами пул може змінити стан, що дає невірний amountOut. Ми вирішуємо це через Multicall: отримуємо slot0, liquidity та потрібні ticks в одній атомарній транзакції. Такий підхід знижує ймовірність помилок до мінімуму.
import { Pool, Route, Trade, SwapQuoter } from '@uniswap/v3-sdk' import { Token, CurrencyAmount, TradeType, Percent } from '@uniswap/sdk-core' import { ethers } from 'ethers' const poolContract = new ethers.Contract(poolAddress, IUniswapV3PoolABI, provider) // Атомарний multicall для стану пула const [slot0, liquidity] = await Promise.all([ poolContract.slot0(), poolContract.liquidity() ]) const pool = new Pool( tokenA, tokenB, fee, slot0.sqrtPriceX96.toString(), liquidity.toString(), slot0.tick ) Як налаштувати маршрутизацію та gas?
AlphaRouter робить десятки RPC-викликів для оцінки маршрутів — для бота це дорого та повільно. Ми або кешуємо маршрути заздалегідь, або реалізуємо власний легкий router для топ-10 торгових пар, оновлюючи кеш кожні 30 секунд. Це скорочує затримки та економить газ.
Permit2 та управління approvals
З версії Uniswap Universal Router перехід на Permit2 — стандарт. Замість прямого token.approve(router, amount) потрібно підписувати PermitSingle через EIP-712 та передавати підпис у swap-транзакцію. SDK надає AllowanceTransfer.getPermitData() для генерації даних підпису. Це підвищує безпеку та знижує кількість on-chain транзакцій.
Slippage та deadline
const slippageTolerance = new Percent(50, 10_000) // 0.5% const deadline = Math.floor(Date.now() / 1000) + 60 * 20 // 20 хвилин const { calldata, value } = SwapRouter.swapCallParameters(trade, { slippageTolerance, deadline: deadline.toString(), recipient: walletAddress }) Для арбітражних ботів встановлюємо slippage 0.1% та deadline 1–2 хвилини, інакше атакуючий може вставити сендвіч. Правильна оцінка газу знижує комісії на 30–40%, що для активного бота економить сотні доларів на місяць.
Нові можливості Uniswap v4: Hooks
Uniswap v4 (після запуску mainnet) вводить архітектуру Hooks — довільна логіка до/після свопу. Для ботів це важливо: хук може змінити effective amount out або заблокувати своп за певних умов. SDK v4 надає V4Router з підтримкою PoolKey нового формату.
| Параметр | Uniswap v3 | Uniswap v4 |
|---|---|---|
| Пул | Pool (sqrtPriceX96) | PoolKey + Hooks |
| Маршрутизація | V3Router | V4Router |
| Ticks | TickMath | TickMath з hook-контекстом |
Чому варто використовувати Multicall для отримання стану пула?
Race condition між RPC-викликами — часта причина невірних розрахунків. Multicall об'єднує кілька запитів в одну транзакцію, гарантуючи консистентність даних. Це особливо критично для пулів з високою волатильністю. На практиці використання Multicall підвищує точність симуляцій та знижує кількість ревертів.
Стек та рекомендовані залежності
| Пакет | Версія | Призначення |
|---|---|---|
@uniswap/v3-sdk |
^3.x | Розрахунки V3 пулів |
@uniswap/sdk-core |
^5.x | Token, CurrencyAmount |
@uniswap/smart-order-router |
^3.x | AlphaRouter |
viem |
^2.x | RPC, типобезпека |
ethers |
^6.x | Підписання, відправка |
Ми віддаємо перевагу viem для read-only операцій та ethers.js для підписання транзакцій.
Процес роботи
- Аналітика: визначаємо цільові пари, тип бота, вимоги до latency. Проводимо дослідження ліквідності та історичних даних. (1 день)
- Розробка: інтеграція SDK, маршрутизатор, gas management, backtest на історичних даних через Foundry fork. (3–5 днів)
- Тестування та деплой: спочатку Sepolia, потім mainnet з обмеженими сумами. Проганяємо 100+ сценаріїв, включаючи екстремальні коливання ціни та перевантаження мережі.
Що входить у результат
- Код з коментарями російською/англійською
- Скрипти деплою та автотестів
- Документація зі встановлення та запуску
- Навчання команди замовника (1 година онлайн)
- Підтримка протягом 30 днів після здачі
Чому обирають нас?
5+ років досвіду в блокчейн-розробці, 50+ проектів у DeFi, команда з 10+ сертифікованих інженерів. Проводимо формальну верифікацію критичних ділянок коду, надаємо звіт про перевірку та рекомендації. Хочете отримати надійного торгового бота з мінімальними комісіями? Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Замовте інтеграцію сьогодні та отримайте 30-денну підтримку.