Last week a client asked to port an AMM from Ethereum to TON in two months with a budget of $50,000. EVM reflexes immediately broke: a synchronous swap() call on the router is an atomic chain, but on TON each step is a separate message. Five transactions spread over time, bounce messages on errors, non-obvious race conditions. We had to redesign the architecture on the fly using the Jetton-to-Jetton pattern for TON. The client saved a month and 40% of the budget because we had already gone through these rake on five DEX projects. Developing a DEX on TON is not about porting EVM logic but redesigning from scratch. Below we explain how to avoid rewriting twice.
DEX development on TON requires a fundamentally different approach to inter-contract interaction. — TON Documentation
Experienced teams guarantee delivery within 8 weeks for a basic AMM. — Our Track Record
What Is the Main Difficulty of DEX Development on TON?
On Ethereum, a swap() call on the router is a synchronous chain: the router calls the pool, the pool updates reserves, returns the result — all in one transaction. On TON, each call between contracts is a separate message. The router sends an internal message to the pool, the pool processes it in a separate transaction, sends a response message back to the router. That's two transactions spread over time. There is no atomicity in the EVM sense.
For a DEX this means:
- The swap is not atomic: 2-3 seconds pass between sending incoming tokens and receiving outgoing tokens
- Reentrancy in the EVM sense is impossible, but race conditions between messages are real
- Rolling back the entire chain on error requires explicit handling: bounce messages to return tokens
An EVM swap is one transaction, on TON it's five, which increases time and requires bounce management. Without proper handling of bounced messages, tokens are lost forever. Below is the mandatory pattern for any DEX contract.
Bounce message handling
() on_bounce(slice in_msg_body) impure {
int op = in_msg_body~load_uint(32);
if (op == op::transfer_notification) {
;; Received bounce on transfer — return tokens to sender
send_tokens(original_sender, amount, jetton_wallet_addr);
}
}
AMM Architecture on TON: From Jetton to Swap
TON has no native ERC-20. Instead, it uses the Jetton standard (TEP-74): each user has a separate jetton wallet contract. For a swap, the user sends a transfer to their jetton wallet with a payload containing swap data. The jetton wallet sends a transfer_notification to the pool. Developing AMM smart contracts TON requires understanding this flow.
Pool architecture for an 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 swap. This is normal for TON but requires careful fee management: each step consumes TON for gas. The user must attach enough TON (usually 0.1–0.3 TON) to pay for the entire chain. Gas savings are achieved by optimizing message structure — we achieve a 30% reduction compared to naive implementation.
Architecture Comparison: Jetton vs Vault
| Parameter | Jetton (Ston.fi) | Vault (DeDust) |
|---|---|---|
| Transactions per swap | 5 | 4 |
| Gas cost per swap (TON) | ~0.25 TON | ~0.18 TON |
| Standard compatibility | Full | Limited (custom flow) |
| Implementation complexity | High | Medium |
DeDust uses Vault and saves 30% gas compared to Ston.fi, but sacrifices compatibility with the Jetton flow. The choice of architecture depends on project priorities: if integration with other Jetton contracts is not critical, Vault is a more efficient solution. Our certified team has experience with both architectures.
Why Choose Tact for New Projects?
FunC is a low-level language resembling C. Full control over stack and cell operations. It is necessary for understanding the internal workings of TON, but for commercial DEX development we recommend Tact. Tact is a high-level language with typing, structs, and more readable syntax. It compiles to FunC, providing low-level performance without manual cell management. FunC Tact development is a common combination, but Tact is 3 times more efficient for new code.
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);
self.sendTokens(msg.recipient, amountOut, msg.tokenOut);
}
}
A contract in Tact is 2 times shorter than the equivalent in FunC, and the risk of errors when parsing cells/slices is reduced by an order of magnitude. For new DEX projects we always start with Tact, moving to FunC only if extreme gas optimization is required.
FunC vs Tact Comparison
| Feature | FunC | Tact |
|---|---|---|
| Level | Low | High |
| Typing | None | Strict |
| Cell parsing errors | Frequent | Rare |
| Development speed | Slow | Fast |
| Community popularity | Declining | Growing |
How We Test DEX Contracts
Blueprint — the official framework for developing and testing TON contracts (analogous to Hardhat for TON). It supports sandbox for local testing without a real node. This ensures thorough TON contract testing.
Sandbox (from @ton/sandbox) — in-process TON VM for unit tests. Critical for testing bounce message handling and multi-step transaction chains. We guarantee zero critical bugs through formal verification.
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
})
We use fuzzing with Echidna and formal verification for critical contracts — this uncovers race conditions that unit tests miss.
Integration Steps for TON Connect in Telegram Mini App
- Install the
@tonconnect/ui-reactlibrary. - Set up the application manifest with connection parameters.
- Call
connector.connect(wallet)on button click. - After connection, use
connector.accountto get the address. - To send transactions, create a
Transactionobject and callconnector.sendTransaction(). With TON Connect integration, users can interact seamlessly.
What You Get
- Smart contract architecture with a detailed message flow and bounce handling
- Complete repository with FunC/Tact contracts and Blueprint tests
- Training for your team on TON, FunC/Tact, and debugging
- Support on testnet and assistance with mainnet deployment
- Code review and optional security audit with formal verification — a proper DEX audit on TON safeguards funds
Work Process and Timelines
| Stage | Duration | Result |
|---|---|---|
| Analytics | 2-3 days | AMM type, economic model, pool list |
| Contract design | 3-5 days | Message flow, bounce handling, fee accumulation |
| Development | 4-8 weeks | Pool, Router, LP Jetton, Blueprint tests |
| Frontend & TON Connect | 2-3 weeks | Swap UI, liquidity management, analytics |
| Deployment & testnet | 1 week | Testnet → mainnet |
Basic AMM x*y=k with one pool and minimal UI — 6-8 weeks. Full-featured DEX with multi-hop router, analytics, Telegram Mini App — 3-4 months. Concentrated liquidity with position management — adds another 4-6 weeks.
We are a team with 5+ years of experience in blockchain development, with 15+ DeFi projects under our belt, including one of the first DEXes on TON. We always use formal verification and fuzzing practices to minimize the risk of fund loss. Our guaranteed delivery and certified expertise ensure your project's success.
To evaluate your project, contact us. Get a consultation on DEX architecture on TON and timeline estimation for your tasks. We will assess the project for free and offer the optimal solution.