Case Studies: STON.fi v2 и DeDust v2

К 2026 оба крупнейших DEX на TON прошли существенную архитектурную ревизию. Обе системы пришли к vault-based дизайну, но с разными нюансами реализации и наборами поддерживаемых пулов.

STON.fi v2: архитектура

STON.fi v2 ввёл vault-based дизайн (раньше vault считался “фишкой DeDust”), расширенный набор pool types и обновлённый routing.

Design Decisions (v2)

Решение	Выбор v2	Rationale
AMM formulas	CPMM + CPI (CP с concentrated liquidity) + WStable (weighted stable)	Многообразие use-cases — от volatile до peg-pairs
Контейнер ликвидности	Vault per token (single contract на актив)	Меньше Jetton Wallet’ов, общий accounting через factories
LP positions	Single-sided deposits supported (через vault)	Снижает порог входа для LP
Router	Обновлённый Router v2 + off-chain pathfinding	Multi-hop, RFQ-style маршрутизация
Fee	Per-pool fee (0.01% / 0.05% / 0.3% и пр.)	Tier зависит от типа pool’а

Pool types (v2)

Pool type	Формула	Use case
CPMM	x · y = k	Volatile pairs (TON/JET)
CPI	CP с concentrated liquidity	Узкие диапазоны, высокая capital efficiency
WStable	Stableswap (плоская зона) с весами и amplification A	Stable + слегка дивергирующие активы

Architecture Layers (v2)

STON.fi v2 Architecture:

User Layer:
  └── Telegram Mini App / Web dApp

SDK Layer:
  └── @ston-fi/sdk v2 (TypeScript)
  └── Routing, gas estimation, message building, single-sided deposits

Contract Layer:
  ├── Router v2: creates pools, маршрутизация multi-hop
  ├── Vault[]: один на актив (Jetton или native TON)
  ├── Pool[]: per-pair логика (CPMM / CPI / WStable)
  └── LP positions: per-provider (Jetton-style, sharded)

Infrastructure:
  ├── Indexer: track swaps, LP events, fees
  └── API: price feeds, pool stats, routing

DeDust v2: архитектура

DeDust v2 продолжил vault-based линию и в ноябре 2025 перешёл на CPMM v2 как default для всех новых пулов.

Design Differences (v2 vs v2)

Аспект	STON.fi v2	DeDust v2
Контейнер ликвидности	Vault per token + Pool per pair	Vault per token + Pool per pair (factories per type)
Native TON	Прямое обращение через native vault	Через wTON / native vault (в зависимости от pool)
Pool types	CPMM, CPI, WStable	CPMM v2 (с 17 ноября 2025), Stable, Volatile, Boosted
LP positions	Sharded LP (Jetton-style) + single-sided deposits	Не Jetton-LP в CPMM v2: позиции записаны в state самого pool-контракта (не передаются между кошельками)
Boosts	—	Founder/dev incentives для CPMM v2 (с янв 2026)
Routing	Off-chain pathfinding, on-chain execution	Off-chain pathfinding, on-chain execution

Vault pattern (общий принцип у обоих)

Vault-based DEX (STON.fi v2 / DeDust v2):

Vault_USDT: holds all USDT across all pools (один Jetton Wallet)
Vault_TON:  holds all TON across all pools
Pool TON/USDT: accounting only (reserves, fee state, LP shares)
Pool USDT/STON: accounting only

Advantage:
  - Один Jetton Wallet на токен (vs N pools = N wallets)
  - Дешёвле gas на multi-hop swap (меньше cross-shard hops)
  - Чище shared liquidity между pool types

Trade-off:
  - Сложнее message flow (vault ↔ pool authentication)
  - Vault — concentration риск на актив (security/audit focus)

STON.fi v2 vs DeDust v2 vault layout

STON.fi v2

DeDust v2

Lessons Learned

1. Simplicity wins for first version, vault wins on scale

STON.fi v1 стартовал с простого x×y=k и pool-per-pair (каждый pool — свой Jetton Wallet). DeDust сразу заложил vault. К v2 оба пришли к одной и той же базе — vault per token + pools-as-accounting — потому что на росте liquidity дублирование Jetton-кошельков на каждый pool становится дорогим (gas + cross-shard hops). Урок: для первой версии — простой direct pool, на scale — обязательный переход на vault.

2. Async requires careful state management

Оба DEX столкнулись с edge cases в async message flows:

Что если Pool получил Token A, но Token B message потерялся?
Что если Pool обработал swap, но send output token failed (bounce)?
Timeout mechanisms и refund flows — критически важны

3. Gas estimation is UX

Оба DEX инвестировали в precise gas estimation:

SDK рассчитывает optimal gas для каждого типа операции
Excess возвращается пользователю
dApp показывает estimated fee перед подтверждением

4. Off-chain routing, on-chain execution

Оптимальный маршрут multi-hop swap рассчитывается off-chain (SDK/API), а выполнение on-chain. On-chain routing слишком дорого (перебор путей = compute gas).

Проверка знанийKnowledge check

ОтветAnswer