Торговый бот теряет до 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 и документацию. Свяжитесь с нами для оценки вашего проекта — мы подготовим коммерческое предложение с учётом вашей стратегии. Получите консультацию, чтобы узнать, как оптимизировать вашего бота под текущую архитектуру.