Інтеграція бота з Jupiter SDK (Solana)

Інтеграція бота з Jupiter SDK (Solana)

Jupiter — це де-факто стандарт агрегації ліквідності на Solana: маршрутизує через Orca, Raydium, Meteora, Phoenix і десятки інших AMM/CLMM в одній транзакції. Для торгового бота це означає доступ до найкращих цін без необхідності самому реалізовувати інтеграцію з кожною біржею. Але «просто використовувати Jupiter SDK» — це не так просто, як виглядає з документації.

Що реально важливо при інтеграції

V6 API vs UltraAPI — різні моделі виконання

Jupiter V6 API (/quote + /swap) — класичний підхід: отримати котировку, побудувати транзакцію, відправити самостійно. Повний контроль над транзакцією, можна додати свої інструкції до/після swap.

Jupiter Ultra API (2024) — нова модель: /order і /execute. Тут Jupiter сам управляє виконанням і MEV-захистом через власний transaction sender. Менше контролю, але краща fill rate в умовах конкуренції.

Для бота з кастомною логікою (наприклад, арбітраж або складні стратегії з кількома свапами в одній транзакції) — потрібен V6 API з ручною збіркою транзакцій. Для простого автоматичного трейдингу Ultra API простіше та ефективніше.

Десеріалізація й розмір транзакції

Транзакції в Solana обмежені 1232 байтами. Jupiter маршрути через кілька пулів швидко наближаються до цього ліміту. Versioned Transactions (Transaction v0) з Address Lookup Tables (ALT) — обов'язкова вимога для складних маршрутів. Jupiter V6 API повертає swapTransaction уже як versioned транзакцію з ALT, але якщо додаєш свої інструкції — кожен аккаунт в інструкції додає 32 байти, якщо він не в ALT.

Практична проблема: додавання однієї кастомної інструкції з 5 аккаунтами до складного 3-hop маршруту дало transaction too large. Рішення — створити власний ALT з аккаунтами, які часто використовуються, і передати його в addressLookupTableAccounts при десеріалізації.

Slippage, price impact і stale quotes

Котировка від Jupiter актуальна секунди — на Solana блоки кожні 400ms. При високій волатильності ціна змінюється раніше, ніж бот встигає відправити транзакцію.

Правильна схема: slippageBps в запросі /quote — максимально допустиме відхилення. Для волатильних пар ставимо 50-100bps, для стейблкоин пар 10-20bps. Але при автоматичній торгівлі потрібен динамічний slippage: вичислювати priceImpactPct з відповіді і встановлювати slippage як max(minSlippage, priceImpactPct * 1.5).

Проблема stale quotes: якщо між /quote і /swap пройшло >2 секунди при активному ринку — висока вероятність SlippageToleranceExceeded помилки. Стратегія retry: при цій помилці одразу перезапросити котировку, не збільшувати slippage автоматично — це захист від ситуації, коли ринок йде в одну сторону і бот гонится за ціною з кожним retry.

Архітектура інтеграції

Структура бота

MarketDataService (WebSocket RPC subscriptions)
    ↓
StrategyEngine (логіка входу/виходу)
    ↓
JupiterQuoteService (/quote API з кешем)
    ↓
TransactionBuilder (додавання кастомних інструкцій)
    ↓
TransactionSender (retry логіка, priority fees)
    ↓
PositionTracker (мониторинг відкритих позицій)

Priority fees на Solana

Після введення локального fee market на Solana (2023) приоритетні транзакції вимагають ComputeBudgetProgram.setComputeUnitPrice. Без цього транзакція може не попасти в ближайші блоки при навантаженні на мережу.

Правильний розрахунок: запитати getRecentPrioritizationFees для аккаунтів, з якими працює транзакція (пули Jupiter маршруту), брати 75-й перцентиль за останні 20 слотів. Це дає competitive fee без переплати.

ComputeBudgetProgram.setComputeUnitLimit — теж важливий. Jupiter swap через 3 пула споживає ~200k-400k compute units. Встановити ліміт чуть вище симульованого значення: це знизить базову вартість транзакції.

Робота з WebSocket RPC

Для бота потрібна підписка на зміни аккаунтів через accountSubscribe. Це дає обновлення в реальному часі без polling. На Helius RPC або QuickNode Solana — latency 50-100ms до підтвердження. Власна нода — 20-50ms.

Важливий нюанс: accountSubscribe повертає дані аккаунту, але для Raydium/Orca пулів потрібно їх десеріалізувати через відповідні crate (Rust) або бібліотеки (JS). Для Jupiter-specific даних це не потрібно — достатньо відстежувати зміну й перезапитувати котировку.

Управління keypair та транзакціями

Ніколи не зберігаємо private key в коді або змінних оточення в откритому вигляді. Для боевого бота — AWS KMS або HashiCorp Vault для підписання. Для упрощеної версії — зашифрований keystore файл з паролем з env.

Parallelism: Solana дозволяє кілька транзакцій в flight одночасно, якщо вони не затрагують одні аккаунти. Для multi-pair бота — пул keypair-ів для паралельних позицій.

Стек

TypeScript + @jup-ag/api (офіційний SDK v6) + @solana/web3.js v1.x (або новий @solana/kit). Для десеріалізації даних пулів — @orca-so/whirlpools-sdk, @raydium-io/raydium-sdk-v2. Redis для кеша котировок і state позицій.

Орієнтири по термінам

Базова інтеграція з Jupiter V6 і автоматичним свапом по сигналу — 3-5 днів. Повноцінний бот з dynamic slippage, priority fee розрахунком, retry логікою й position tracking — 1-2 тижні.

Вартість рахується після аналізу стратегії та вимог до виконання.