При попытке портировать 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-бот? Свяжитесь с нами для оценки вашего проекта. Мы проанализируем стратегию, подберём стек и предложим сроки.