Ми інтегруємо торговельних ботів з Jupiter SDK для оптимальних свопів на Solana. Jupiter — це де-факто стандарт агрегації ліквідності: він маршрутизує через Orca, Raydium, Meteora, Phoenix та десятки інших AMM/CLMM в одній транзакції. Для бота це означає доступ до найкращих цін без необхідності самому реалізовувати інтеграцію з кожною біржею. Але «просто використовувати Jupiter SDK» — це не так просто, як здається з документації. Наша команда з 10+ річним досвідом блокчейн-розробки та 50+ проектами на Solana гарантує надійну інтеграцію під ключ.
Чому важливо правильно обрати API Jupiter?
Різниця між V6 API та Ultra API не завжди очевидна, але критична для бота.
V6 API vs UltraAPI — дві моделі виконання. V6 (/quote + /swap) дає повний контроль: ви отримуєте котирування, будуєте транзакцію та відправляєте її самі. Можна додати свої інструкції до та після swap. Ultra API (/order + /execute) — Jupiter керує виконанням та MEV-захистом через власний transaction sender. Менше контролю, але вищий fill rate.
Для бота з кастомною логікою (арбітраж, складні стратегії з кількома свопами) обирайте V6. Для простого автотрейдингу Ultra простіше та ефективніше.
| Характеристика | V6 API | Ultra API |
|---|---|---|
| Рівень контролю | Повний | Частковий |
| MEV-захист | Ручний | Вбудований |
| Підходить для | Складні стратегії | Проста автоматизація |
| Fill rate | Середній | Високий |
Як впоратися з обмеженням розміру транзакції?
Транзакції Solana обмежені 1232 байтами. Jupiter маршрути через декілька пулів швидко вибирають ліміт. Versioned Transactions (v0) з Address Lookup Tables (ALT) — обов'язкові. V6 повертає swapTransaction вже з ALT, але додавання кастомних інструкцій збільшує розмір. Практична проблема: одна інструкція з 5 акаунтами на складному 3-hop маршруті дала "transaction too large". Рішення — створити свій ALT для часто використовуваних акаунтів та передати його в addressLookupTableAccounts.
Як налаштувати slippage, price impact та stale quotes?
Котирування Jupiter актуальне секунди — на Solana блоки кожні 400ms. При високій волатильності ціна змінюється до відправки транзакції. Правильна схема: slippageBps в запиті /quote — максимум. Для волатильних пар ставимо 50-100bps, для стейблкоінів 10-20bps. Але для автоматичної торгівлі потрібен динамічний slippage: max(minSlippage, priceImpactPct * 1.5). Stale quotes: якщо між /quote та /swap пройшло >2 секунд при активному ринку — висока ймовірність помилки. Стратегія retry: при помилці SlippageToleranceExceeded негайно перезапитати котирування, не збільшуючи slippage (захист від "погоні за ціною").
Архітектура інтеграції
MarketDataService (WebSocket RPC subscriptions) ↓ StrategyEngine (логіка входу/виходу) ↓ JupiterQuoteService (/quote API з кешем) ↓ TransactionBuilder (додавання кастомних інструкцій) ↓ TransactionSender (retry logic, priority fees) ↓ PositionTracker (моніторинг відкритих позицій) Priority fees на Solana
Після введення локального fee market пріоритетні транзакції вимагають ComputeBudgetProgram.setComputeUnitPrice. Без цього транзакція може не потрапити в блок при навантаженні. Правильний розрахунок: запитувати getRecentPrioritizationFees для акаунтів пулів з маршруту, брати 75-й перцентиль за останні 20 слотів. Це дає competitive fee без переплати. ComputeUnitLimit встановлюйте трохи вище симульованого значення — це знизить базову вартість.
Робота з WebSocket RPC
Підписка на зміни акаунтів пулів через accountSubscribe — реальний час без polling. На Helius RPC або QuickNode — latency 50-100ms до підтвердження. Власна нода — 20-50ms. Важливий нюанс: для Raydium/Orca пулів десеріалізуйте дані через відповідні SDK; Jupiter-specific дані відстежувати не потрібно — достатньо перезапитати котирування при зміні.
Управління keypair
Ніколи не зберігаємо private key в коді або змінних середовища відкрито. Для бойового бота — AWS KMS або HashiCorp Vault. Для спрощеної версії — зашифрований keystore з паролем з env. Parallelism: Solana дозволяє декілька транзакцій в flight для різних акаунтів — використовуйте пул keypair для паралельних позицій.
Стек
TypeScript + @jup-ag/api v6 + @solana/web3.js v1.x. Для десеріалізації пулів — @orca-so/whirlpools-sdk, @raydium-io/raydium-sdk-v2. Redis для кешу.
| Компонент | Рішення | Latency |
|---|---|---|
| RPC | Helius / QuickNode / власна нода | 50-200ms |
| Котирування | Jupiter V6 /quote API | 100-300ms |
| Пріоритет | getRecentPrioritizationFees | перерахунок кожні 5 блоків |
| Підписки | accountSubscribe WebSocket | realtime |
| Підпис | AWS KMS / local keystore | 10-50ms |
Що входить в роботу
- Інтеграція обраного API (V6 або Ultra)
- Налаштування динамічного slippage та retry logic
- Оптимізація priority fees
- Підключення WebSocket підписок для реального часу
- Документація інтеграції
- Тестування на devnet та mainnet
- Підтримка після запуску (1 місяць)
Орієнтири за термінами
Базова інтеграція з V6 та автоматичним свопом за сигналом — 3-5 днів. Повноцінний бот з динамічним slippage, priority fee розрахунком, retry та position tracking — 1-2 тижні. Вартість розраховується після аналізу стратегії та вимог. Економія на газі за рахунок правильного ComputeUnitLimit може досягати 30%.
Зв'яжіться з нами, щоб обговорити інтеграцію вашого бота. Отримайте консультацію щодо вибору архітектури.
Джерело: Jupiter V6 API documentation