DEX Development on TON
TON is not EVM-compatible chain. This means all accumulated experience with Solidity, Hardhat, OpenZeppelin must be set aside. Contracts on TON written in FunC or newer Tact, storage architecture fundamentally different, and DeFi patterns that work on Ethereum here require rethinking. Teams coming with EVM background and underestimating this difference usually rewrite contracts twice.
TON's asynchronous model — main difference
On Ethereum swap() call on router — synchronous chain: router calls pool, pool updates reserves, returns result. All in one transaction.
On TON each call between contracts — separate message. Router sends internal message to pool, pool processes it in separate transaction, sends response message back to router. Two transactions, separated in time. No atomicity in EVM sense.
For DEX this means:
- Swap is not atomic: between sending input tokens and receiving output passes several seconds
- Reentrancy in EVM sense impossible, but race conditions between messages real
- Rollback of entire chain on error requires explicit handling: bounce messages for token return
Bounce messages — mandatory pattern
If pool cannot execute swap (e.g., slippage exceeded), it must send bounce message with token return. If contract doesn't handle bounced messages — tokens lost forever.
() on_bounce(slice in_msg_body) impure {
int op = in_msg_body~load_uint(32);
if (op == op::transfer_notification) {
;; Got bounce on transfer — return tokens to sender
send_tokens(original_sender, amount, jetton_wallet_addr);
}
}
DEX architecture on TON: AMM through Jetton
TON has no native ERC-20. Instead — Jetton standard (TEP-74): each user has separate jetton wallet contract. For swap user sends transfer to their jetton wallet with payload containing swap data. Jetton wallet sends transfer_notification to pool.
Pool architecture for AMM:
User Jetton Wallet A
→ transfer(amount, pool_address, forward_payload=swap_data)
→ Pool Jetton Wallet A (transfer_notification)
→ Pool Contract (swap message)
→ Pool Jetton Wallet B (transfer)
→ User Jetton Wallet B
Five contracts, five transactions per one swap. Normal for TON, but requires careful fee management: each step consumes TON for gas. User must attach enough TON (usually 0.1–0.3 TON) for entire chain payment.
Key protocols as reference
Ston.fi — first major AMM on TON, operating since 2022. Standard x*y=k formula, but adapted for asynchronous model. Code open and is de-facto reference implementation for TON DEX.
DeDust — uses proprietary Vault architecture: central Vault contract for each pool instead of jetton wallet approach. More gas-efficient, but less compatible with standard Jetton flow.
Tonswap — works through TON DNS and Telegram integration, oriented toward Telegram Mini Apps.
Concentrated Liquidity on TON: engineering challenge
Implementing Uniswap V3-style concentrated liquidity on TON — significantly harder than on EVM. Reason: operations with tick array require iteration, which on TON limited by computational limits per transaction (gas on TON called compute fee and limited).
On EVM Uniswap V3 uses bitmap for fast nearest initialized tick search. TON analogue — hashtable in storage, but each cell access costs more due to Cell-based storage structure.
Practical solution for MVP: simplified concentrated liquidity version with limited ranges (up to 20-50 per pool) — sufficient for most use cases, without extreme tick traversal optimization.
Development on FunC vs Tact
FunC — low-level language, reminds C. Full control over stack and cell operations. Mandatory for understanding how TON stores data.
Tact — high-level language with typing, structs and more readable syntax. Compiles to FunC. For new projects recommend Tact — fewer errors with cell/slice parsing.
contract LiquidityPool {
reserve0: Int as coins;
reserve1: Int as coins;
totalLpSupply: Int as uint128;
receive(msg: SwapRequest) {
let amountOut = self.calculateAmountOut(msg.tokenIn, msg.amountIn);
require(amountOut >= msg.minAmountOut, "Slippage exceeded");
self.updateReserves(msg.tokenIn, msg.amountIn, amountOut);
// Send output tokens to user
self.sendTokens(msg.recipient, amountOut, msg.tokenOut);
}
}
Testing and tools
Blueprint — official framework for developing and testing TON contracts (Hardhat analogue for TON). Supports sandbox for local testing without real node.
Sandbox (from @ton/sandbox) — in-process TON VM for unit tests. Critical for testing bounce message handling and multi-step transaction chains.
import { Blockchain } from '@ton/sandbox'
import { LiquidityPool } from '../build/LiquidityPool'
const blockchain = await Blockchain.create()
const pool = blockchain.openContract(await LiquidityPool.fromInit(token0, token1))
const swapResult = await pool.sendSwap(user.getSender(), {
tokenIn: token0Address,
amountIn: toNano('100'),
minAmountOut: toNano('95')
})
expect(swapResult.transactions).toHaveTransaction({
to: pool.address,
success: true
})
Telegram Mini Apps integration
TON DEX practically always integrated with Telegram via TON Connect protocol. Users connect Tonkeeper, MyTonWallet or Telegram Wallet. Interface built as Telegram Mini App with @tonconnect/ui-react library.
Specificity: in Telegram Mini App no window.ethereum. Entire web3-stack specific for TON: @ton/ton for RPC, @ton/core for types, TON Connect for wallet connection.
Development process
Analytics (2–3 days). Determine AMM type (x*y=k, stable swap, concentrated), pool list for launch, fee economic model.
Contract design (3–5 days). Message scheme between contracts, bounce handling, fee accumulation, LP token (Jetton).
Development (4–8 weeks). Pool contract, Router, LP Jetton minter, tests in Blueprint sandbox.
Frontend and TON Connect (2–3 weeks). Swap UI, liquidity management, analytics.
Deploy and testnet. Testnet (TON testnet) → mainnet. TON has separate testnet with faucet for TON and test Jettons.
Timeline estimates
Basic AMM x*y=k with one pool and minimal UI — 6–8 weeks. Full DEX with router for multi-hop, analytics, Telegram Mini App — 3–4 months. Concentrated liquidity with position management — adds another 4–6 weeks.