При спробі портувати 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:
- Гаманець користувача → Jetton Wallet: transfer з forward payload
- Jetton Wallet → Router: transfer_notification
- Router → Pool: swap
- Pool → Jetton Wallet (output token): internal_transfer
- 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<_={}&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 | DeDust |
|---|---|---|
| Архітектура | Router-based (Jetton Wallet → Router → Pool) | Vault-based (Vault → Pool) |
| Slippage protection | minAskAmount в payload | minAskAmount в vault |
| Ціна за резервами | GET /pools/ | Pool.getEstimatedSwapOut |
| Комісія (комісія пулу + роутер) | 0.4% | 0.3–0.5% |
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 + моніторинг. Запуск з малим капіталом, поступове масштабування.
Орієнтири за строками
| Тип бота | Термін (тижні) |
|---|---|
| DCA / grid бот (одна пара) | 1–1.5 |
| Арбітражний бот (моніторинг кількох пар) | 2–3 |
Вартість розраховується індивідуально залежно від складності стратегії та кількості інтеграцій. Наш досвід: 7+ років у блокчейн-розробці, 15+ крипто-проектів. Якщо вам потрібна консультація з архітектури — зв'яжіться з нами для детального обговорення вашого завдання. Замовте розробку бота — отримайте готове рішення під вашу стратегію.
Типові помилки при розробці TON бота:
- Не враховувати bounced messages — замовник втрачає токени.
- Використовувати один гаманець для всіх стратегій — змішування коштів збільшує ризик.
- Ігнорувати rate limits RPC — бот зависає при частих запитах.
Цікавить TON-бот? Зв'яжіться з нами для оцінки вашого проекту. Ми проаналізуємо стратегію, підберемо стек і запропонуємо строки.