Прежде чем писать код: как выбирается архитектура стейкинга в TON

Не каждая задача в crypto-разработке начинается с кода. Иногда первый и самый ценный шаг — трезвый архитектурный документ, а не спринт разработки.

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

Три модели — и у каждой свои ограничения, не видные на уровне «сделайте стейкинг»

Single nominator. Модель для держателя значимого капитала, разворачивающего свой validator-узел. Для биржи, которая хочет дать возможность стейкать пользовательские небольшие суммы, это решение не подходит по природе — это инфраструктура казначейства, а не массовый продукт.

Nominator pool. Официальный контракт объединяет вклады нескольких участников, но с ограничениями, критичными для UX: рекомендуемый минимум — 10 000 TON, лимит участников пула, и только полный вывод позиции — частичный не поддерживается. Для пользователя, привыкшего выводить часть суммы в любой момент, это ломает ожидания.

Liquid staking. Пользователь получает pool-jetton — токен, представляющий его долю в пуле, что хорошо ложится на уже существующую инфраструктуру Jetton-балансов. Но добавляет новый класс рисков: контракт и провайдер пула, плавающий курс LST/TON, отложенное исполнение вывода при нехватке ликвидности, потенциальный slashing и зависимость от внешнего DeFi-протокола.

Срок блокировки — не константа, а изменяемый параметр сети

Ни у одной из моделей нет фиксированного «срока заморозки», который можно жёстко зашить в интерфейс. Direct validator и single nominator блокируют средства на полный validation round, длительность которого определяется актуальным сетевым параметром консенсуса. Nominator pool выдаёт средства сразу только при наличии свободной ликвидности пула, иначе создаёт заявку на вывод. Liquid staking может дать мгновенный вывод в пределах свободной ликвидности, а при её нехватке уходит в отложенный расчёт.

Практическое следствие для интерфейса: приложение обязано показывать расчётный срок из актуального состояния провайдера на момент запроса и не имеет права обещать пользователю фиксированное время до подтверждения — потому что это было бы попросту неправдой.