Bot Integration with SushiSwap SDK

SushiSwap SDK Bot Integration

SushiSwap is deployed on 30+ chains, and this is the main reason why trading bots use SushiSwap SDK instead of direct contract calls. Manually maintaining current router addresses for Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain and twenty more networks is separate work that the SDK handles.

But SDK has its own quirks that aren't obvious without experience working with it.

What's Important to Know Before Integration

SDK Versions and Architecture

SushiSwap SDK v3 (@sushiswap/sdk) and newer @sushiswap/router are different packages with different APIs. @sushiswap/router is the current standard, supporting SushiSwap v3 (concentrated liquidity), v2 and routing through multiple protocols simultaneously.

The old @sushiswap/sdk works only with v2 pools and is obsolete for most tasks. We've seen bots running on old SDK for years, unaware they're missing 20-30% of routes due to v3 pools not being in calculations.

Getting Quotes and 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 returns optimal route accounting for gas. Important nuance: gas cost is only included in the calculation if current gasPrice is passed. A bot passing zero or stale gasPrice gets a route optimal by token output amount, but not by net profit.

For a trading bot, the correct formula is: netProfit = outputAmount - inputAmount - gasCost. gasPrice should be taken from mempool, not cached.

Multi-Chain Configuration

SDK automatically resolves contract addresses by chainId. But for custom configurations (own node, custom RPC), you must pass providers map explicitly:

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),
}

Using public RPCs (Infura, Alchemy free tier) leads to rate limiting with intensive monitoring. For production bot — own node or paid tier with guaranteed throughput.

Executing Swap via Router

SushiSwap v3 router on Arbitrum — 0x...RouteProcessor3. SDK generates calldata for processRoute() automatically:

const { routeProcessorAddr, routeCode } = trade
const tx = await routeProcessor.processRoute(
  fromToken.address,
  amountIn,
  toToken.address,
  minAmountOut,  // amountOut * (1 - slippage)
  recipient,
  routeCode,
)

minAmountOut protects from slippage. For arbitrage bot, slippage tolerance should be minimal (0.1-0.3%), otherwise transaction can execute at a loss if market moves between simulation and block inclusion.

Monitoring Pools via The Graph

SushiSwap has subgraphs for each chain. For a bot monitoring liquidity events or tracking price changes in pools, queries via The Graph are more efficient than direct on-chain calls:

query PoolReserves {
  pairs(where: { id_in: ["0x..."] }) {
    reserve0
    reserve1
    token0Price
    volumeUSD
  }
}

For realtime monitoring — WebSocket subscription to Sync events (v2) or Swap events (v3) via ethers.js directly, as The Graph has several-second delay.

Timeline Estimates

Trading bot integration with SushiSwap SDK for one chain — 3-5 days. Multi-chain system with routing through multiple protocol versions and pool monitoring — up to a week. Including testnet tests and configuration documentation.