Розробка бота для TON DEX (StonFi, DeDust)

При спробі портувати Ethereum-бота на TON розробники стикаються з фундаментальною відмінністю — асинхронною моделлю виконання. Замість однієї атомарної транзакції на Ethereum, TON виконує ланцюжок internal messages, де кожен крок може бути bounced. Без правильної архітектури бот втрачає кошти або зависає в невизначеному стані. Наш підхід: будуємо бота з нуля, використовуючи state machine для відстеження кожної pending swap транзакції з урахуванням bounced messages та timeout-ів. Отримайте консультацію з архітектури вашого TON DEX бота — зв'яжіться з нами для оцінки проекту.

«У TON кожен ланцюжок повідомлень може бути перерваний bounced-повідомленням — це задокументовано в архітектурі віртуальної машини TVM» (TON Documentation, див. Wikipedia: TON).

Асинхронність TON: чому звичайні патерни не працюють

Як транзакції в TON відрізняються від EVM?

На Ethereum swap — один виклик, один receipt, один status: success або reverted. У TON один запит користувача породжує ланцюжок internal messages між контрактами. Swap на StonFi v2:

1. Гаманець користувача → Jetton Wallet: transfer з forward payload
2. Jetton Wallet → Router: transfer_notification
3. Router → Pool: swap
4. Pool → Jetton Wallet (output token): internal_transfer
5. Jetton Wallet → гаманець користувача: transfer_notification

Кожен крок — окрема транзакція з окремим хешем. Успіх першої транзакції не гарантує успіх всього ланцюжка. Якщо крок 3 або 4 провалиться — на кроках 5-6 прийде bounced message і вихідні токени повернуться.

Бот повинен: відправити крок 1, запам'ятати вихідний message hash, відстежувати дерево транзакцій по in_msg_hash, чекати або успішного кроку 5, або bounced message з поверненням.

TON API для моніторингу транзакцій

TON Center API v2: GET /v2/transactions?address={}&limit=20&lt_={}&hash={} — отримуємо транзакції адреси. Для відстеження конкретного ланцюжка використовуємо lt (logical time) та hash для пагінації.

Зручніший варіант для ботів: TON API getBlockTransactions + WebSocket через TON Access. При отриманні кожного блоку — перевіряємо транзакції своєї адреси. Latency 1-3 секунди після фіналізації блоку (TON фіналізує за 5-6 секунд).

Бібліотеки: @ton/ton (TypeScript, офіційна) або tonutils-go (Go). Для Python — pytoniq-core.

Як бот взаємодіє з StonFi та DeDust?

StonFi v2: роутер та message payload

StonFi v2 swap payload для jetton → jetton:

import { StonApiClient } from '@ston-fi/api';
import { DEX } from '@ston-fi/sdk';

const client = new StonApiClient();
const dex = client.openDex(DEX.v2);

const txParams = await dex.getSwapJettonToJettonTxParams({
  userWalletAddress: walletAddress,
  offerJettonAddress: USDT_ADDRESS,
  askJettonAddress: STON_ADDRESS,
  offerAmount: toNano('100'),
  minAskAmount: toNano('95'),
});

await wallet.sendTransaction(txParams);

minAskAmount — це on-chain slippage protection. Якщо пул не може дати мінімальну суму — транзакція bounced, токени повертаються. Бот повинен обчислювати minAskAmount на основі поточної ціни пулу мінус допустимий slippage.

DeDust: vault-based архітектура

DeDust відрізняється архітектурою: замість прямої відправки в pool — через vault. Кожен токен має свій vault контракт. Swap починається з depositing в vault з attached swap params в payload:

import { Asset, Factory, MAINNET_FACTORY_ADDR, Pool, VaultJetton } from '@dedust/sdk';

const factory = client.open(Factory.createFromAddress(MAINNET_FACTORY_ADDR));
const tonVault = client.open(await factory.getNativeVault());

await tonVault.sendSwap(wallet.getSender(), {
  poolAddress: pool.address,
  amount: toNano('1'),
  gasAmount: toNano('0.25'),
});

DeDust підтримує як Uniswap v2-стиль (volatile pools), так і Curve-стиль (stable pools). Для стейблкоїн пар — stable pool з меншим slippage.

Отримання поточної ціни без swap

Для StonFi: GET https://api.ston.fi/v1/pools/{poolAddress} повертає token0_address, token1_address, reserve0, reserve1. Ціна = reserve1 / reserve0 з урахуванням decimals.

Для DeDust: виклик Pool.getEstimatedSwapOut — view функція, повертає amountOut для заданого amountIn. Це точніше, ніж розрахунок за резервами, особливо для stable пулів.

StonFi v2 swap дешевший за DeDust приблизно на 0.1% для великих сум завдяки відсутності подвійного vault, але DeDust дає точніші розрахунки для stable пулів.

Як бот обробляє bounced-повідомлення?

Зазначимо: коли TON бот відправляє swap, він запам'ятовує хеш вихідного повідомлення та запускає таймер. Якщо через 10-15 секунд (3-4 блоки) не приходить ні успішної фінальної транзакції, ні bounced — бот переходить у стан error. При отриманні bounced перевіряється код помилки: якщо це revert через провину пулу (занадто висока ціна), бот відправляє повторну угоду з новим параметром minAskAmount. Всі bounce-транзакції логуються для подальшого аналізу.

Що входить у розробку

• Архітектура бота з урахуванням асинхронності TON: state machine для pending swaps.
• Інтеграція з StonFi та/або DeDust API: отримання цін, побудова транзакцій.
• Обробка bounced messages та timeout-ів: повтор або логування.
• Реалізація стратегії (арбітраж, grid, DCA) за вашим вибором.
• Моніторинг та сповіщення (Telegram, Prometheus метрики).
• Документація та код, готовий до деплою.

Які торгові стратегії реалізовані на TON DEX?

Arbitrage StonFi ↔ DeDust. Одна й та сама пара jetton/TON торгується на обох DEX. Цінова розбіжність >0.5% (вище комісії + газ) — можливість арбітражу. Атомарності немає (немає flash loans у тому ж сенсі), тому арбітраж двоетапний: swap на DEX1, потім swap на DEX2. Ризик: за час виконання першого свопу другий пул змінить ціну.

Grid trading. Купівля jetton при зниженні ціни нижче grid level, продаж при підвищенні. Проста стратегія, працює на бічному ринку. Для TON пар з достатньою ліквідністю ($500K+ TVL) — практично.

DCA (Dollar Cost Averaging). Автоматична купівля фіксованого обсягу TON→Jetton за розкладом. Реалізується через cron job + TON wallet SDK. Мінімальна складність, гарне введення в TON bot розробку.

Інфраструктура

Гаманець. Для бота потрібен hot wallet — TON гаманець v4 або v5. Seed phrase зберігається в зашифрованому вигляді (AES-256), ніколи в plaintext. Ліміт коштів на hot wallet — тільки операційний запас, основні кошти окремо.

Нода або RPC. Публічний TON Center безкоштовний, але rate-limited (1 req/sec). Для активної торгівлі — TON Center Pro ($49/місяць, 25 req/sec) або власна lite-server нода.

Моніторинг. Telegram bot для сповіщень про угоди. Prometheus метрики: trades_per_hour, profit_per_day, error_rate.

Процес роботи

Етап 1: Аналіз та прототип (3–5 днів). Підключення до TON, читання цін з StonFi/DeDust API, симуляція стратегії на історичних даних.

Етап 2: Розробка бота (1–2 тижні). Transaction builder, state machine для відстеження pending swaps, error handling для bounced messages.

Етап 3: Тестування на TON testnet (3–5 днів). TON має повноцінний testnet з testnet StonFi deployment.

Етап 4: Production деплой. VPS + моніторинг. Запуск з малим капіталом, поступове масштабування.

Орієнтири за строками

Вартість розраховується індивідуально залежно від складності стратегії та кількості інтеграцій. Наш досвід: 7+ років у блокчейн-розробці, 15+ крипто-проектів. Якщо вам потрібна консультація з архітектури — зв'яжіться з нами для детального обговорення вашого завдання. Замовте розробку бота — отримайте готове рішення під вашу стратегію.

Типові помилки при розробці TON бота:

• Не враховувати bounced messages — замовник втрачає токени.
• Використовувати один гаманець для всіх стратегій — змішування коштів збільшує ризик.
• Ігнорувати rate limits RPC — бот зависає при частих запитах.

Цікавить TON-бот? Зв'яжіться з нами для оцінки вашого проекту. Ми проаналізуємо стратегію, підберемо стек і запропонуємо строки.