Розробка DEX на TON

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Розробка DEX на TON
Складний
від 2 тижнів до 3 місяців
Часті запитання

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

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1286
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1198
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    902
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1122
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    589
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    859

Розробка DEX на TON

TON — це не EVM-сумісний чейн. Це означає, що весь накопичений досвід з Solidity, Hardhat, OpenZeppelin потрібно відкласти. Контракти на TON пишуться на FunC або новішому Tact, архітектура storage принципово інша, та паттерни DeFi, які працюють на Ethereum, тут вимагають переосмислення. Команди з EVM-фоном, які недооцінюють цю різницю, зазвичай переписують контракти двічі.

Асинхронна модель TON — головне відмінність

На Ethereum вивізит swap() на роутері — це синхронна цепочка: роутер викликає пул, пул оновлює резерви, повертає результат. Все в одній транзакції.

На TON кожен вивізит між контрактами — окреме повідомлення. Роутер відправляє internal message у пул, пул обробляє його в окремій транзакції, відправляє відповідне повідомлення роутеру. Це дві транзакції, рознесені в часі. Атомарності в EVM-сенсі немає.

Для DEX це означає:

  • Своп не атомарен: між відправкою вхідних токенів та отриманням вихідних проходить кілька секунд
  • Reentrancy в EVM-сенсі неможлива, але race conditions між повідомленнями реальні
  • Откат усієї цепочки при помилці вимагає явної обробки: bounce-повідомлення для повернення токенів

Bounce messages — обов'язковий паттерн

Якщо пул не може виконати своп (наприклад, slippage перевищений), він має відправити bounce-повідомлення з поверненням токенів. Якщо контракт не обробляє bounced messages — токени втрачаються назавжди.

() on_bounce(slice in_msg_body) impure {
    int op = in_msg_body~load_uint(32);
    if (op == op::transfer_notification) {
        ;; Отримали bounce при transfer — повертаємо токени відправнику
        send_tokens(original_sender, amount, jetton_wallet_addr);
    }
}

Архітектура DEX на TON: AMM через Jetton

TON не має native ERC-20. Замість цього — Jetton standard (TEP-74): кожен користувач має окремий jetton wallet контракт. Для свопу користувач відправляє transfer на свій jetton wallet з payload, який містить дані свопа. Jetton wallet відправляє transfer_notification у пул.

Архітектура пулу для 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

П'ять контрактів, п'ять транзакцій на один своп. Це нормально для TON, але вимагає акуратного управління комісіями: кожен крок споживає TON на gas. Користувач повинен приложити достатньо TON (зазвичай 0.1–0.3 TON) для оплати всієї цепочки.

Ключові протоколи як референс

Ston.fi — перший крупний AMM на TON, працює з 2022. Стандартна x*y=k формула, але адаптована для асинхронної моделі. Код відкритий та є де-факто референсною реалізацією для TON DEX.

DeDust — використовує власну Vault архітектуру: центральний Vault контракт для кожного пулу замість jetton wallet підходу. Газо-ефективніше, але менш сумісно зі стандартним Jetton flow.

Tonswap — працює через TON DNS та Telegram-інтеграцію, орієнтований на Telegram Mini Apps.

Concentrated Liquidity на TON: інженерна задача

Реалізація Uniswap V3-style concentrated liquidity на TON — значно складніше, ніж на EVM. Причина: операції з tick-масивом вимагають ітерації, яка на TON обмежена обчислювальними лімітами на транзакцію (gas на TON називається compute fee та обмежений).

На EVM Uniswap V3 використовує bitmap для швидкого пошуку найближчого ініціалізованого tick. TON аналог — hashtable у storage, але кожен доступ до ячейки коштує дорожче через Cell-based storage структуру.

Практичне рішення для MVP: спрощена версія concentrated liquidity з обмеженим числом діапазонів (до 20-50 на пул) — достатньо для більшості use cases, без екстремальної оптимізації tick traversal.

Розробка на FunC vs Tact

FunC — низькорівневий язик, нагадує C. Повний контроль над stack та cell операціями. Обов'язковий для розуміння, як TON зберігає дані.

Tact — високорівневий язик з типізацією, struct-ами та більш читаємим синтаксисом. Компілюється в FunC. Для нових проектів рекомендуємо Tact — менше помилок з cell/slice парсингом.

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);
        // Відправляємо output tokens користувачу
        self.sendTokens(msg.recipient, amountOut, msg.tokenOut);
    }
}

Тестування та інструменти

Blueprint — офіційний фреймворк для розробки та тестування TON контрактів (аналог Hardhat для TON). Підтримує sandbox для локального тестування без реальної ноди.

Sandbox@ton/sandbox) — in-process TON VM для unit тестів. Критично для тестування bounce message handling та багатокрокових транзакційних цепочок.

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

TON DEX практично завжди інтегрована з Telegram через TON Connect протокол. Користувачі підключають Tonkeeper, MyTonWallet або Telegram Wallet. Інтерфейс будується як Telegram Mini App з @tonconnect/ui-react бібліотекою.

Особливість: у Telegram Mini App немає window.ethereum. Весь web3-стек специфічний для TON: @ton/ton для RPC, @ton/core для типів, TON Connect для wallet підключення.

Процес розробки

Аналітика (2–3 дні). Визначаємо тип AMM (x*y=k, stable swap, concentrated), список пулів для запуску, економічну модель fee.

Проектування контрактів (3–5 днів). Схема повідомлень між контрактами, bounce handling, fee accumulation, LP token (Jetton).

Розробка (4–8 тижнів). Pool контракт, Router, LP Jetton minter, тести в Blueprint sandbox.

Фронтенд та TON Connect (2–3 тижні). Swap UI, управління ліквідністю, аналітика.

Деплой та testnet. Testnet (TON testnet) → mainnet. TON має окремену testnet з faucet для TON та тестових Jettonів.

Орієнтири по строкам

Базовий AMM x*y=k з одним пулом та minimal UI — 6–8 тижнів. Повнофункціональний DEX з роутером для мультихопів, аналітикою, Telegram Mini App — 3–4 місяці. Concentrated liquidity з менеджментом позицій — додає ще 4–6 тижнів.