DeFi на TON: обзор

DeFi (децентрализованные финансы) на TON — это быстрорастущий сектор с уникальными возможностями: мгновенные транзакции, интеграция с Telegram и доступ к сотням миллионов пользователей. Понимание DeFi-ландшафта TON необходимо для разработчиков, которые хотят создавать финансовые приложения или интегрировать существующие DeFi-протоколы. В отличие от DeFi на Ethereum, асинхронная модель TON требует принципиально иных подходов к проектированию финансовых протоколов.

В модулях M01—M02 мы изучили архитектуру TON и модель акторов, а в M05 разобрали шардированные токены (Jetton 2.0). Теперь применим эти знания к реальным DeFi-протоколам — и увидим, как шардинг меняет правила игры.

DeFi на шардированном блокчейне

На Ethereum DeFi-протоколы опираются на атомарные транзакции: один вызов может обратиться к DEX, получить токены, использовать их как залог в lending-протоколе и вернуть прибыль — всё в одной транзакции. Это называется composability (компонуемость).

TON работает по-другому. Каждый контракт — это независимый актор, и взаимодействие между контрактами происходит через асинхронные сообщения:

Ethereum (синхронно):
User -> DEX.swap() -> Lending.deposit() -> всё в 1 транзакции

TON (асинхронно):
User -> msg1 -> DEX Router -> msg2 -> Pool -> msg3 -> Jetton Wallet -> ...
       каждая стрелка = отдельная транзакция

Это означает:

• Нет атомарной компонуемости — нельзя объединить несколько протоколов в одну транзакцию
• Каждое взаимодействие = цепочка сообщений — swap на DEX требует 4—6 отдельных транзакций
• Результат не мгновенный — между отправкой запроса и получением токенов проходит несколько блоков

Jetton-based экономика

Все токены на TON — это Jetton (стандарт TEP-74). Это означает, что DeFi-протоколы работают не с абстрактными “токенами”, а с конкретной шардированной архитектурой Jetton Wallet контрактов:

• У каждого пользователя свой Jetton Wallet — отдельный контракт, хранящий баланс
• Перевод токенов — это цепочка сообщений между Jetton Wallet контрактами
• DeFi-протокол тоже имеет свои Jetton Wallet контракты для каждого токена

Знание архитектуры Jetton из M05 критически важно для понимания DeFi на TON.

Асинхронные операции: что может пойти не так

Проектирование DeFi на TON требует учёта:

1. Bounce-обработка — контракты должны корректно обрабатывать отскочившие сообщения и возвращать средства
2. Slippage protection — между отправкой запроса и исполнением цена может измениться
3. Таймауты — если сообщение не обработано за определённое время, контракт должен вернуть средства
4. Газ в цепочке — каждое сообщение требует газа, и отправитель должен приложить достаточно TON для всей цепочки

Экосистема DeFi на TON

Основные категории DeFi-протоколов:

В следующих уроках мы подробно разберём каждую категорию:

• Урок 02 — DEX: архитектура STONfi и DeDust, механика AMM на шардированном блокчейне
• Урок 03 — Lending: протокол EVAA, модель supply/borrow, ликвидации
• Урок 04 — Стейкинг и экономика валидаторов, номинаторские пулы (устаревшие)
• Урок 05 — Liquid staking: Tonstakers (tsTON), Bemo (stTON), DeFi-композиция

Ключевые принципы DeFi на TON

Перед изучением конкретных протоколов запомните три принципа:

1. Всё асинхронно Нет синхронных вызовов между контрактами. Каждая DeFi-операция — это цепочка сообщений, растянутая на несколько блоков.

2. Всё шардировано Контракты пользователей и протоколов распределены по шардчейнам. Pool не хранит все балансы в одном месте — у каждого пользователя свои Jetton Wallet контракты.

3. Газ оплачивает инициатор Пользователь, начинающий операцию, должен приложить достаточно TON для оплаты всей цепочки сообщений. Неиспользованный газ возвращается через excesses сообщение.

Частые ошибки

1. Копируют DeFi-паттерны из Ethereum напрямую (Uniswap, Aave) без адаптации к асинхронной модели TON, что приводит к race conditions и потере средств.
2. Не учитывают, что атомарные flash-кредиты невозможны на TON из-за асинхронности: каждое сообщение между контрактами обрабатывается в отдельной транзакции.
3. Игнорируют TVL и ликвидность конкретных пулов перед интеграцией: низкая ликвидность ведёт к высокому slippage.
4. Не закладывают обработку проскальзывания (slippage protection): без min_amount_out пользователь может получить значительно меньше ожидаемого.