Интеграция бота с Raydium SDK (Solana)

Интеграция бота с Raydium SDK (Solana)

Solana AMM работает принципиально иначе, чем Uniswap на EVM. На Ethereum swap — это один вызов контракта. На Solana — набор инструкций внутри транзакции, каждая из которых взаимодействует с конкретными account'ами. Если при интеграции с Raydium SDK передать неверный account (неправильный pool state PDA или token vault) — транзакция молча ревертится с кодом 0x1 без внятного сообщения. Это первое, с чем сталкиваются при самостоятельной интеграции.

Специфика Raydium AMM v4 и CLMM

Raydium поддерживает два пула: AMM v4 (аналог Uniswap v2, constant product) и CLMM (concentrated liquidity, аналог Uniswap v3). Для торгового бота это разные SDK-пути и разная структура accounts.

AMM v4 swap требует передачи ~10 accounts: pool state, token vaults обоих активов, authority PDA, user token accounts. Все адреса деривируются через findProgramAddressSync с правильными seeds — это не документировано явно, нужно смотреть исходники SDK или reverse-инженерить существующие транзакции через Solana Explorer.

CLMM дополнительно требует tick array accounts — сегментов ценового диапазона. Если текущая цена находится на границе тика, нужно передать соседние tick arrays, иначе транзакция провалится. Raydium CLMM SDK v2 обрабатывает это автоматически через PoolUtils.computeAmountOut, но только если правильно инициализировать PoolInfoLayout.

import { CLMM, PoolUtils } from '@raydium-io/raydium-sdk-v2';

const poolInfo = await CLMM.getPoolInfoFromRpc({
    connection,
    poolId: new PublicKey(POOL_ID),
});

const { amountOut, remainingAccounts } = PoolUtils.computeAmountOut({
    poolInfo,
    tickArrayCache,
    baseMint: new PublicKey(INPUT_MINT),
    epochInfo: await connection.getEpochInfo(),
    amountIn: new BN(swapAmount),
    slippage: 0.005,
});

remainingAccounts — это те самые tick arrays, которые нужно передать в инструкцию. Пропустить этот шаг = гарантированный revert.

Проблемы с latency и приоритетными комиссиями

На Solana нет газовой аукции как на EVM. Вместо этого — compute unit price (priority fee). Транзакция с setComputeUnitPrice(microLamports) получает приоритет в очереди валидатора. Без priority fee в периоды высокой нагрузки (новый мем-токен, торговля на открытии рынка) транзакция может зависнуть на 5-10 секунд или вообще не попасть в блок.

Оптимальная стратегия — динамический расчёт priority fee на основе recent fee statistics:

const recentFees = await connection.getRecentPrioritizationFees({
    lockedWritableAccounts: [poolStatePubkey, userTokenAccount],
});
const p75Fee = recentFees
    .map(f => f.prioritizationFee)
    .sort((a, b) => a - b)[Math.floor(recentFees.length * 0.75)];

const priorityFeeIx = ComputeBudgetProgram.setComputeUnitPrice({
    microLamports: Math.max(p75Fee * 1.2, MIN_PRIORITY_FEE),
});

Ещё один момент — preflight checks. По умолчанию sendTransaction прогоняет симуляцию перед отправкой. Для скоростного бота это лишние ~100ms. Если уверены в корректности транзакции после собственной симуляции — skipPreflight: true и commitment: 'processed' для быстрого подтверждения.

Архитектура бота

Стек: TypeScript, @raydium-io/raydium-sdk-v2, @solana/web3.js, Redis для состояния.

Структура:

• WebSocket подписка на programSubscribe нужного AMM program ID — детектим новые пулы
• Парсинг account data через PoolInfoLayout для получения текущих резервов и цены
• Расчёт swap через SDK, оценка slippage и price impact
• Формирование транзакции с приоритетными fees + versioned transaction (v0) для address lookup tables
• Отправка на несколько RPC одновременно для резервирования

Versioned transactions (v0) важны: Raydium CLMM swap генерирует ~20+ accounts, стандартная legacy транзакция имеет лимит 35 accounts. Address Lookup Tables позволяют сжать адреса и уместить всё в одну транзакцию.

Ориентиры по срокам

Базовая интеграция с AMM v4 Raydium (покупка/продажа по фиксированной паре) — 3-4 дня. Полноценный бот с CLMM поддержкой, динамическим priority fee и мультипул мониторингом — 1-2 недели. Стоимость рассчитывается индивидуально.