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

При попытке портировать Ethereum-бота на TON разработчики сталкиваются с фундаментальным отличием — асинхронной моделью исполнения. Вместо одной атомарной транзакции на Ethereum, TON выполняет цепочку internal messages, где каждый шаг может быть bounced. Без правильной архитектуры бот теряет средств

Направления блокчейн-разработки

Часто задаваемые вопросы

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1451
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1005
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1270
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    1011

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