We integrate trading bots with the STON.fi SDK for automated trading on the DEX in the TON blockchain. TON is fundamentally different from EVM: it has an asynchronous message model, an actor model, and unique fee mechanics. Our experience in blockchain development (5+ years, over 10 projects on TON) allows us to account for all the nuances and build a reliable turnkey bot.
Why TON Is Harder Than EVM for a Bot
Asynchronous Transaction Model
In Ethereum, a transaction either executes or reverts — everything is synchronous within one block. In TON, contracts communicate via asynchronous messages. After sending a swap message to the STON.fi router, you don't know the result immediately. You need to listen for incoming messages on the wallet address (transfer notification from jetton) or poll state via the TON API.
This means the bot must have a state machine for each operation. Send a swap → wait for confirmation → if none within N seconds → retry or alert. A simple send-and-forget logic leads to lost transactions.
Each message in TON is encoded as a Bag of Cells (BoC). Parsing incoming notifications requires decoding the BoC and extracting fields such as jetton amount and sender. The STON.fi SDK provides types for this, but integration requires setting up a TON listener.
The official STON.fi SDK documentation recommends using queryId to track operations — it is included in response messages and allows you to match a request with a result.
How to Integrate a Bot with the STON.fi SDK
Installation and Configuration
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") ); The STON.fi SDK v2 supports DEX v1 and v2 pools. For new code we use the v2 router — it supports more complex routing scenarios and better API integration.
Getting Quotes
const pool = await router.getPool({ token0: "EQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM9c", // TON token1: USDT_JETTON_ADDRESS }); const data = await pool.getData(); // data.reserve0, data.reserve1 — current reserves // Calculate expected output via AMM formula The SDK provides getExpectedOutputs() for slippage calculation. Important: quotes become stale quickly in an active market. For a trading bot, cache for no longer than 5–10 seconds.
Executing a Swap
const swapTxParams = await router.buildSwapTonToJettonTxParams({ userWalletAddress: wallet.address, proxyTon: new pTON.v1(), offerAmount: new TonWeb.utils.BN("1000000000"), // 1 TON in nanotons askJettonAddress: USDT_JETTON_ADDRESS, minAskAmount: expectedOutput.mul(99).div(100), // 1% slippage tolerance queryId: Date.now() // unique ID for tracking }); await wallet.sendTransfer({ secretKey: keyPair.secretKey, toAddress: swapTxParams.to, amount: swapTxParams.gasAmount, seqno: await wallet.getSeqno(), payload: swapTxParams.payload }); queryId is a critical parameter for tracking. It is included in response messages and allows you to match the swap request with the result in the asynchronous model.
| Aspect | EVM | TON |
|---|---|---|
| Model | Synchronous (everything in one block) | Asynchronous (messages) |
| Tracking | tx receipt | state machine + polling |
| Gas | upfront, revert if insufficient | forward fees along the chain |
| SLIPPAGE | less critical | critical due to delays |
How to Build a Trading Bot Architecture for TON
Price monitor: periodic polling of prices via the STON.fi API (https://api.ston.fi/v1/pools) or direct on-chain requests. The API is more convenient — it returns normalized data for all pools. On-chain is more reliable when the API is unreliable.
Strategy engine: logic for trading decisions. For an arbitrage bot — compare STON.fi prices with other TON DEXs (DeDust). For a trend-following bot — technical indicators on historical prices from the API.
Transaction manager: a queue of transactions with retry logic. TON requires a correct seqno for the wallet — parallel sending leads to errors. We send transactions sequentially or via separate sub-wallets.
Result tracker: polling the wallet's latest transactions via the TON API to confirm swap execution. https://toncenter.com/api/v2/getTransactions?address=...
Gas Management on TON
TON uses a gas model different from Ethereum. For a jetton swap, you need to send enough TON to pay forward fees along the message chain: router → jetton wallet → user wallet. The STON.fi SDK returns the correct gasAmount in buildSwapTxParams — do not reduce it "to save". If gas is insufficient, the message simply won't reach its destination, and funds may get stuck at an intermediate contract. Optimizing gas can save up to 30% on commissions, and fixed development cost prevents budget overruns.
What Our Work Includes
| Stage | Duration | Result |
|---|---|---|
| Requirements & strategy analysis | 1 day | Technical specification |
| Architecture design | 1–2 days | Architecture document |
| SDK integration & logic development | 2–4 days | Working bot with monitoring |
| Testing (unit, integration, fuzzing) | 1–2 days | Test report |
| Deployment & team training | 1 day | Access, documentation, instructions |
All work is carried out turnkey with a 30-day warranty on any bugs found. We use formal verification for critical contracts.
Our Experience and Guarantees
- Web3 development experience since 2019, over 10 projects on TON/STON.fi
- Security guarantee: code is checked with Slither, Mythril, and Echidna
- Certified engineers (Ethereum, Solana, TON)
- Up to 30% savings on commissions through gas optimization
Contact us for an assessment of your project. We'll propose an optimal turnkey solution in 1–2 weeks. Get a consultation on integration today.
Links: