Інтеграція бота з SushiSwap SDK
SushiSwap розгорнут на 30+ чейнах, і це головна причина, чому торговельні боти використовують саме SushiSwap SDK замість прямих викликів контрактів. Вручну підтримувати актуальні адреси роутерів для Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain та ще двадцяти мереж — окремої роботи, яку SDK бере на себе.
Але SDK має свої особливості, які не очевидні без досвіду роботи з ним.
Що важливо знати перед інтеграцією
Версії та архітектура SDK
SushiSwap SDK v3 (@sushiswap/sdk) та новіший @sushiswap/router — це різні пакети з різними API. @sushiswap/router — поточний стандарт, який підтримує SushiSwap v3 (concentrated liquidity), v2 та маршрутизацію через кілька протоколів одночасно.
Старий @sushiswap/sdk працює тільки з v2-пулами та застарів для більшості задач. Видили ботів, які роками працювали на старому SDK, не підозрюючи, що втрачають 20-30% маршрутів через відсутність v3-пулів у розрахунку.
Отримання котирування та slippage
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. Бот, який передає нульовий або застарілий gasPrice, отримує маршрут, оптимальний за кількістю вихідних токенів, але не за net profit.
Для торговельного бота правильна формула: netProfit = outputAmount - inputAmount - gasCost. gasPrice повинен братися з mempool, а не кешуватися.
Мультичейн конфігурація
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%), інакше транзакція може виконатися зі збитком при русі ринку між симуляцією та включенням у блок.
Моніторинг пулів через The Graph
SushiSwap має субграфи для кожного чейна. Для бота, який моніторить liquidity events або відслідковує зміни цін у пулах, запити через The Graph ефективніші, ніж прямі on-chain виклики:
query PoolReserves {
pairs(where: { id_in: ["0x..."] }) {
reserve0
reserve1
token0Price
volumeUSD
}
}
Для realtime мониторингу — WebSocket підписка на події Sync (v2) або Swap (v3) через ethers.js напрямку, оскільки The Graph має затримку кілька секунд.
Орієнтири за часовими рамками
Інтеграція торговельного бота з SushiSwap SDK для одного чейна — 3-5 днів. Мультичейн система з маршрутизацією через кілька версій протоколу та мониторингом пулів — до тижня. Включаючи тести на testnet та документацію по конфігурації.