Ми інтегруємо торгових ботів з STON.fi SDK для автоматизованої торгівлі на DEX у блокчейні TON. TON принципово відрізняється від EVM: асинхронна модель повідомлень, actor model та свої fee-механіки. Наш досвід у блокчейн-розробці (5+ років, понад 10 проєктів на TON) дозволяє врахувати всі нюанси та побудувати надійного бота під ключ.
Чому TON складніший за EVM для бота?
Асинхронна модель транзакцій
В Ethereum транзакція або виконалася, або ревертнулася — все синхронно в одному блоці. В TON контракти спілкуються через асинхронні повідомлення. Відправивши swap-повідомлення на STON.fi router, ви не знаєте результат негайно. Потрібно слухати вхідні повідомлення на адресу гаманця (transfer notification від jetton) або polling стану через TON API.
Це означає: бот повинен мати state machine для кожної операції. Відправили swap → чекаємо підтвердження → якщо нема за N секунд → retry або алерт. Проста send-and-forget логіка призводить до втрати транзакцій.
Кожне повідомлення в TON кодується як Bag of Cells (BoC). Для парсингу вхідних сповіщень потрібно декодувати BoC та витягувати поля, такі як jetton amount та sender. STON.fi SDK надає типи для цього, але інтеграція вимагає налаштування TON listener.
Офіційна документація STON.fi SDK рекомендує використовувати queryId для відстеження операцій — він включається у відповідні повідомлення та дозволяє зіставити запит з результатом.
Як інтегрувати бота з STON.fi SDK?
Встановлення та конфігурація
import { DEX, pTON } from "@ston-fi/sdk"; import TonWeb from "tonweb"; const tonweb = new TonWeb( new TonWeb.HttpProvider("https://toncenter.com/api/v2/jsonRPC", { apiKey: process.env.TONCENTER_API_KEY }) ); const router = tonweb.open( new DEX.v1.Router("EQB3ncyBUTjZUA5EnFKR5_EnOMI9V1tTEAAPaiU71gc4TiUt") ); STON.fi SDK v2 підтримує DEX v1 та v2 пули. Для нового коду використовуємо v2 router — він підтримує складніші routing сценарії та кращу інтеграцію з API.
Отримання котирувань
const pool = await router.getPool({ token0: "EQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM9c", // TON token1: USDT_JETTON_ADDRESS }); const data = await pool.getData(); // data.reserve0, data.reserve1 — поточні резерви // Розраховуємо очікуваний output через AMM формулу SDK надає getExpectedOutputs() для розрахунку слиппеджу. Важно: котирування швидко застарівають на активному ринку. Для торгового бота — кешувати не довше 5-10 секунд.
Виконання свопу
const swapTxParams = await router.buildSwapTonToJettonTxParams({ userWalletAddress: wallet.address, proxyTon: new pTON.v1(), offerAmount: new TonWeb.utils.BN("1000000000"), // 1 TON в nanotons askJettonAddress: USDT_JETTON_ADDRESS, minAskAmount: expectedOutput.mul(99).div(100), // 1% slippage tolerance queryId: Date.now() // унікальний id для tracking }); await wallet.sendTransfer({ secretKey: keyPair.secretKey, toAddress: swapTxParams.to, amount: swapTxParams.gasAmount, seqno: await wallet.getSeqno(), payload: swapTxParams.payload }); queryId — критично важливий параметр для tracking. Він включається в повідомлення відповіді та дозволяє зіставити swap-запит з результатом в асинхронній моделі.
| Аспект | EVM | TON |
|---|---|---|
| Модель | Синхронна (все в одному блоці) | Асинхронна (повідомлення) |
| Відстеження | tx receipt | state machine + polling |
| Газ | upfront, реверт при нестачі | forward fees по ланцюжку |
| SLIPPAGE | менш критичний | критичний через затримки |
Як побудувати архітектуру торгового бота під TON?
Price monitor: періодичний polling цін через STON.fi API (https://api.ston.fi/v1/pools) або прямі on-chain запити. API зручніше — повертає нормалізовані дані по всіх пулах. On-chain надійніше при ненадійному API.
Strategy engine: логіка торгових рішень. Для арбітражного бота — порівняння цін STON.fi з іншими TON DEX (DeDust). Для трендового бота — технічні індикатори на історичних цінах з API.
Transaction manager: черга транзакцій з retry логікою. TON вимагає правильного seqno для гаманця — паралельне відправлення призводить до помилок. Транзакції відправляємо послідовно або через окремі sub-wallets.
Result tracker: polling останніх транзакцій гаманця через TON API для підтвердження виконання свопів. https://toncenter.com/api/v2/getTransactions?address=...
Управління газом на TON
TON використовує модель газу, відмінну від Ethereum. Для jetton-swap потрібно відправити достатньо TON для оплати forward fees по ланцюжку повідомлень: router → jetton wallet → user wallet. STON.fi SDK повертає правильний gasAmount в buildSwapTxParams — не занижуйте його «заради економії». Якщо газу не вистачить — повідомлення просто не дійде, і кошти можуть зависнути на проміжному контракті. Оптимізація газу дозволяє зекономити до 30% на комісіях, а фіксована вартість розробки виключає перевитрату бюджету.
Що входить в нашу роботу?
| Етап | Термін | Результат |
|---|---|---|
| Аналіз вимог та стратегії | 1 день | Технічне завдання |
| Проектування архітектури | 1-2 дні | Документ архітектури |
| Розробка інтеграції SDK та логіки | 2-4 дні | Робочий бот з моніторингом |
| Тестування (unit, integration, fuzzing) | 1-2 дні | Звіт про тестування |
| Розгортання та навчання команди | 1 день | Доступи, документація, інструкції |
Всі роботи виконуються під ключ з гарантією 30 днів на виявлені баги. Ми використовуємо формальну верифікацію критичних контрактів.
Наш досвід та гарантії
- Досвід у Web3-розробці з 2019 року, понад 10 проєктів на TON/STON.fi
- Гарантія безпеки: код перевіряється Slither, Mythril та Echidna
- Сертифіковані інженери (Ethereum, Solana, TON)
- Економія на комісіях до 30% за рахунок оптимізації газу
Зв'яжіться з нами для оцінки вашого проєкту. Ми запропонуємо оптимальне рішення під ключ за 1-2 тижні. Отримайте консультацію з інтеграції вже сьогодні.
Ссылки: