Торговий бот втрачає до 30% маршрутів, якщо використовує прямий виклик контрактів SushiSwap замість SDK. Різниця — SDK автоматично підставляє актуальні адреси роутерів на 30+ чейнах і будує маршрути через v3-пули, які старий код просто ігнорує. Ми у своїй практиці часто зустрічаємо проекти, де інтеграція виконана в обхід SDK, і це обертається втратами ліквідності та зниженням прибутку. Один з клієнтів з арбітражним ботом на Arbitrum після переходу на @sushiswap/router збільшив кількість успішних маршрутів на 24% і скоротив gas-витрати на 18% за рахунок динамічного gasPrice.
Ми — команда з багаторічним досвідом у блокчейн-розробці. За цей час реалізували понад 40 інтеграцій торгових ботів на SushiSwap та інших DEX. У цій статті ділимося ключовими аспектами, які потрібно врахувати при підключенні бота до SushiSwap SDK.
Яку версію SushiSwap SDK обрати для торгового бота?
SushiSwap SDK v3 (@sushiswap/sdk) і новіший @sushiswap/router — це різні пакети з різними API. @sushiswap/router — поточний стандарт, що підтримує SushiSwap v3 (concentrated liquidity), v2 і маршрутизацію через кілька протоколів одночасно. Старий @sushiswap/sdk працює тільки з v2-пулами — він застарів для більшості завдань. Бачили ботів, які роками працювали на старому SDK, не підозрюючи, що втрачають 20-30% маршрутів через відсутність v3-пулів.
| Версія | Підтримка v2 | Підтримка v3 | Мультичейн | Статус |
|---|---|---|---|---|
@sushiswap/sdk |
Так | Ні | Так | Застаріла |
@sushiswap/router |
Так | Так | Так | Актуальна |
Чому передача актуального gasPrice критична для net profit?
import { Router } from '@sushiswap/router' import { ChainId } from '@sushiswap/chain' const trade = await Router.getBestRoute({ chainId: ChainId.ARBITRUM, fromToken: WETH, toToken: USDC, amount: parseUnits('1', 18), gasPrice: await provider.getGasPrice(), }) getBestRoute повертає оптимальний маршрут з урахуванням газу. Якщо передано нульовий або застарілий gasPrice, маршрут оптимізується тільки за вихідною кількістю токенів, ігноруючи net profit. Формула для торгового бота: netProfit = outputAmount - inputAmount - gasCost. gasPrice має братися з mempool, а не кешуватися. В одному проекті ми знизили gas-витрати на 18% після впровадження динамічного gasPrice.
Як моніторинг пулів через The Graph допомагає боту?
SushiSwap має субграфи для кожного чейну. Для бота, що моніторить liquidity events або відстежує зміни цін, запити через The Graph ефективніші за прямі on-chain виклики. Однак у The Graph є затримка в кілька секунд, тому для realtime підходить WebSocket-підписка на події Sync (v2) або Swap (v3) через ethers.js. Порівняння методів:
| Метод | Затримка | Навантаження на RPC | Підходить для |
|---|---|---|---|
| The Graph | 2-10 секунд | Низька | Нечасті оновлення цін |
| WebSocket (ethers.js) | 100-500 мс | Середня | Арбітраж, HFT |
| On-chain (polling) | 1-12 секунд | Висока | Резервний варіант |
Які ризики при використанні застарілої версії SDK?
Старий @sushiswap/sdk не підтримує v3-маршрути, що веде до втрати 20-30% доступної ліквідності. Крім того, він може не підтримувати нові чейни або EIP, викликаючи помилки транзакцій. Наприклад, після переходу на EIP-1559 код без оновлення SDK не зможе коректно виставити maxPriorityFeePerGas, що призведе до зависання транзакцій. Регулярно оновлюйте SDK до останньої версії — команда SushiSwap додає підтримку нових мереж і виправляє баги.
Мультичейн конфігурація
SDK автоматично резолвить адреси контрактів за chainId, але для кастомних конфігурацій (власна нода, кастомний RPC) потрібно передавати providers map явно:
import { providers } from 'ethers' const providerMap = { [ChainId.ETHEREUM]: new providers.JsonRpcProvider(ETH_RPC), [ChainId.ARBITRUM]: new providers.JsonRpcProvider(ARB_RPC), [ChainId.POLYGON]: new providers.JsonRpcProvider(POLY_RPC), } Використання публічних RPC (Infura, Alchemy free tier) призводить до rate limiting при інтенсивному моніторингу. Для production-бота ми рекомендуємо власну ноду або платний tier з гарантованим throughput.
Виконання свапу через роутер
SushiSwap v3 роутер на Arbitrum — 0x...RouteProcessor3. SDK генерує calldata для processRoute() автоматично:
const { routeProcessorAddr, routeCode } = trade const tx = await routeProcessor.processRoute( fromToken.address, amountIn, toToken.address, minAmountOut, // amountOut * (1 - slippage) recipient, routeCode, ) minAmountOut — захист від slippage. Для арбітражного бота slippage tolerance має бути мінімальним (0.1-0.3%), інакше транзакція може виконатися у збиток при русі ринку між симуляцією та включенням у блок.
Що входить у нашу роботу
- Аналіз поточної архітектури бота та стратегії торгівлі.
- Проектування маршрутизації з урахуванням мультичейн та multiversion.
- Написання коду з використанням
@sushiswap/router, налаштування RPC, gas-менеджменту. - Тестування на testnet з імітацією пікових навантажень.
- Деплой на mainnet з поступовим нарощуванням обсягів.
- Моніторинг та алертинг — інтеграція з Tenderly або своїм бекендом.
- Документація з конфігурації та експлуатації.
- Підтримка протягом місяця після запуску.
Орієнтири за термінами
Інтеграція торгового бота з SushiSwap SDK — від 3 до 5 днів для одного чейну. Мультичейн система з маршрутизацією через кілька версій протоколу та моніторингом пулів — до тижня. Включає тести на testnet та документацію. Зв'яжіться з нами для оцінки вашого проекту — ми підготуємо комерційну пропозицію з урахуванням вашої стратегії. Отримайте консультацію, щоб дізнатися, як оптимізувати вашого бота під поточну архітектуру.