Jetton v2 в TON: что изменилось в стандарте джеттонов (TEP-74 → Jetton 2.0)

В экосистеме TON фунгибельные токены называются джеттонами (Jetton) и формально описаны стандартом TEP-74. Архитектура классическая для TON: Jetton Master (Minter) хранит метаданные/эмиссию, а для каждого владельца создаётся отдельный Jetton Wallet-контракт, где учитывается баланс и исполняются переводы. Осенью 2025 года сообществу представлен Jetton v2 (Jetton 2.0) — обновление референс-реализации, сохраняющее интерфейс TEP-74, но заметно оптимизирующее газ и пропускную способность за счёт перевода кода jetton-wallet в library-cell и связанных улучшений пайплайна.

Jetton V2 в Ton

Что вам это даёт:

  • Меньше комиссий и веса сообщений. Код кошелька хранится как библиотечная ячейка (library cell), а не инлайн — сокращаются storage/forwarding-fee и размер StateInit при пересылках.
  • Стабильнее под нагрузкой. Снижается вероятность «захлёбывания» при internal_transfer и массовых рассылках/эйрдропах; обработка кошельков становится предсказуемее.
  • Совместимость на уровне API. Для кошельков/бирж это те же вызовы TEP-74 (transfer/burn/metadata), но быстрее и дешевле.

Ниже — детальное руководство по Jetton v2: чем он отличается от «v1» (референс-TЕP-74), как устроена библиотечная раскладка кода, как работать с Mintless Jetton (TEP-176/177), на что смотрят биржи/кошельки и где подстерегают граничные случаи.

База: как устроены джеттоны в TON

Архитектура.

  • Jetton Master (Minter) — мастер-контракт: хранит общее состояние (total supply, ссылку/ячейку метаданных), управляет эмиссией и расчётом адресов кошельков.
  • Jetton Wallet — отдельный кошелёк для каждого владельца: хранит баланс, принимает/шлёт internal_transfer, рассылает нотификации, обрабатывает on_bounce.
  • Метаданные — по стандарту TEP-64 (on-chain / semi-chain / off-chain). Для приложений критично корректно парсить name/symbol/decimals/image и пр.

Сообщения и обработчики (минимум):

  • transfer → отправка из кошелька владельца; может нести forward_payload для получателя.
  • internal_transfer → внутренняя доставка между кошельками; при неуспехе возможен bounce и возврат средств через on_bounce.
  • burn → сжигание с уведомлением мастеру.
  • get_wallet_data / get_wallet_address → чтение баланса/адреса кошелька.

Десятичность. У джеттонов разная decimals (например, jUSDT — 6, большинство — 9), это важно для фронтендов/SDK.

См. также: Транзакция, Кошелёк, Безопасность.

Что приносит Jetton v2 (Jetton 2.0)

1) Library-cell для кода Jetton Wallet. Главное изменение — код кошелька вынесен в библиотечную ячейку сети (library cell), а в конкретных кошельках хранится ссылка-хэш. Это:

  • Сильно уменьшает размер StateInit и объём пересылаемых данных при создании/взаимодействиях.
  • Сокращает forwarding fee на маршруте internal_transfer (типичный выигрыш по документации — в ~3–4 раза для кейсов с init_code).
  • Упрощает массовые рассылки/аирдропы и работу под пиковыми нагрузками.

2) Гарантии исполнения и «правильное» развертывание. Референс подчёркивает: гарантии исполнения v2 корректны, только если кошелёк развёрнут как library. Если вы используете форк «без библиотеки», нужно пересчитать газ-константы и принять риски более тяжёлых сообщений. В репозитории описан стандартный Librarian-контракт для публикации библиотеки и проверки валидности развертывания.

3) Экономика хранения библиотеки. Библиотека публикуется на длительный срок (в референсе типовое значение — порядка «десятков лет»), за что вносится депозит TON. Важно мониторить срок хранения: если библиотека истечёт и не будет продлена, кошельки потеряют доступ к коду и перестанут обрабатывать сообщения. В проде держите процедуру продления и аварийный план.

4) Производительность под нагрузкой. На практике Jetton v2 даёт существенный прирост скорости обработки при перегрузках сети (в публичных анонсах — «до ×3 быстрее» при конгестии) и снижение совокупных комиссий; для пользователей UX не меняется — те же переводы, но быстрее/дешевле.

5) Совместимость. Интерфейсы TEP-74 и парсинг TEP-64 сохранены. Это означает, что кошельки/биржи/сканеры не обязаны менять API — важно лишь обновить Heuristics по проверке кошельков (см. ниже).

Как это работает технически

Развёртывание библиотеки кода кошелька

  • Публикуете код jetton-wallet как library cell через librarian (спец-контракт + скрипт).
  • В Jetton Master передаёте library-ссылку на код кошелька вместо «сырых» байтов.
  • Все создаваемые Jetton Wallet будут ссылаться на эту библиотеку.

Плюсы для сообщений/физики TON

  • Кошелёк при internal_transfer не тащит за собой «тонны» init-кода, что уменьшает вес и forwarding fee.
  • Меньше шанс, что сообщение «не пролезет» в слот из-за размера/квот.
  • Лёгче масштабировать массовые операции (аирдропы, пулы ликвидности, премии и т. п.).

Проверки на стороне сервисов

  • При индексации кошельков проверяйте соответствие minter/wallet (из get_wallet_data) и валидность ссылки на библиотеку.
  • Держите «белый список» хэшей библиотек для популярных джеттонов, чтобы отсекать фишинговые «лжекошельки».

Mintless Jetton (TEP-176/177) и Jetton v2

Mintless Jetton — расширение TEP-74, позволяющее делать огромные меркл-аирдропы без «персональных минтов». Идея:

  • В Jetton Master хранится меркл-корень распределения.
  • Пользовательский кошелёк подтверждает доказательство при первой исходящей операции с токеном → фактический *mint по требованию* (нет отдельного шага «claim»).
  • Это резко снижает нагрузку и стоимость распределений на миллионы адресов.

Где тут v2. Библиотечный кошелёк Jetton v2 органично сочетается с mintless-подходом: меньше веса сообщений/переинициализаций → дешевле и надёжнее массовые первичные движения. Для интеграции:

  • Протокол/бот раздачи должен отдавать правильный Merkle-proof;
  • Кошелёк поддерживает добавление доказательства в тело transfer (или спец-операцию расширения);
  • Индексаторы учитывают «виртуальные балансы» до первого движения.

Миграция и апгрейды

Можно ли «перевести» существующий джеттон на v2? Да, если в вашем минтере предусмотрен апгрейд (часто есть админ-операция upgrade/смена кода), вы можете:

  • обновить минтер до версии, где wallet-code — library;
  • убедиться, что адреса кошельков не меняются (детерминизм адреса сохраняется);
  • откатить/перевыпустить метаданные (если меняли формат хранения);
  • пройти тестнет: проверка checkWalletLib, нагрузка ботов, сценарии on_bounce.

Операционная гигиена

  • Для админ-ключей используйте мультисиг (гардианы/аппаратные) — компрометация = риск «окирпичивания» минтера.
  • Любой upgrade сначала — в тестнете: неверный код/слепки данных могут сломать контракт.
  • Документируйте внешние зависимости (адрес librarian, срок хранения, хэш библиотеки) и публикуйте для сообществ/бирж.

Лучшие практики для dApp, бирж и кошельков

Выплаты/аирдропы

  • Для массовых раздач используйте Mintless (TEP-176/177) или «бандлы» с минимальным forward_ton_amount.
  • Симулируйте on_bounce и сценарии «частичного исполнения»: при неуспехе средства должны вернуться отправителю.

UX и Decimal-гигиена

  • Не «хардкодьте» 9 знаков — читайте decimals из метаданных: популярные стейблы (jUSDT/jUSDC) — 6.
  • Показывайте пользователю разложение комиссий: базовая + forwarding + storage (и экономию от v2).

Индексаторы/бэкенды

  • Проверяйте привязку wallet → minter и валидность библиотеки (сверка по get_lib).
  • Для mintless поддерживайте виртуальные балансы до первого движения и «одиночное» доказательство per адрес.
  • Не ждите «лишних подтверждений» — в TON финализация быстрая; лишний wait ухудшает UX.

Безопасность

  • on_bounce должно корректно откатывать списание отправителя при неуспешном internal_transfer.
  • Ограничивайте forward_ton_amount и фильтруйте forward_payload у получателя.
  • Держите allow-list библиотек и минтеров (по хешам/адресам) — снижает фишинг в интерфейсе.

Сообщения и полезные детали Jetton v2

Transfer → Internal transfer → Notification

  • Инициатор отправляет transfer из своего Jetton Wallet.
  • Кошелёк отправителя инициирует internal_transfer на кошелёк получателя.
  • Получатель (если задан forward_ton_amount) шлёт уведомление в конечный адрес/контракт (dApp), передавая forward_payload (например, ID ордера).
  • При ошибке доставка «отскакивает» bounce в кошелёк отправителя, который через on_bounce возвращает списанную сумму.

Library-кошелёк и экономия

  • Для многих сценариев с init_code forwarding fee падает с ~0.011 TON до ~0.003 TON (оценка из доков по library-cells), что критично для мелких платежей/микротраснзакций.
  • В массовых use-case (игры, аирдропы) это десятки процентов экономии.

Смена кода/данных минтера

  • В v2 предусмотрены административные операции: смена кода/данных минтера, задокументирован «риск окерпичивания» при неверных слепках — обязательно тестируйте.

Частые ошибки разработчиков (и как их избежать)

  • Неучтённый decimals. У jUSDT — 6, у TON и большинства джеттонов — 9. Всегда умножайте amount на 10^decimals.
  • Игнорирование on_bounce. Неполное зачисление без возврата отправителю — распространённый баг; в референсе показан корректный паттерн.
  • Непроверенная библиотека. Развёрнули кошелёк без library-ссылки → потеряли выигрыш v2 и рискуете нестабильностью.
  • Хардкод адресов/хэшей. Используйте методы чтения из минтера/кошелька, а не «магические строки».
  • Ожидание «ещё N блоков». В TON финализация после 1 блока; «дополнительные ожидания» ухудшают UX и усложняют ретраи.

Инструменты и SDK

  • Blueprint / Sandbox — шаблоны сборки, тесты и скрипты деплоя референс-джеттона.
  • Tact Cookbook — примеры Jetton Master/Wallet, приёмы Tact-разработки.
  • TON Connect — готовые UI-компоненты и SDK для отправки transfer/работы с джеттонами из фронтенда (React/UI).
  • tonlib/ton4j/tonutils — бэкенд-SDK (Rust/Java/Python) с поддержкой чтения джеттонов и их кошельков.

Вопросы и ответы (FAQ)

Нужно ли «перевыпускать» токен под v2? Нет. Jetton v2 — это обновление реализации, совместимое с TEP-74. Вы переводите минтер/кошельки на библиотечную схему и получаете экономию газа и стабильность. Адреса держателей/балансы сохраняются.

Становится ли v2 «обязательным» стандартом? Формальный стандарт (TEP-74) остаётся прежним. V2 — референс-реализация и набор практик (library-cell и др.), которые экосистема рекомендует для производительности.

Что если библиотека «протухнет»? Если не продлите хранение library-cell, кошельки потеряют доступ к коду и перестанут принимать сообщения. Держите депозит/мониторинг и процедуру продления.

Совместим ли v2 с Mintless Jetton? Да. Mintless — это расширение TEP-74 (TEP-176/177). V2 снижает издержки и делает такие аирдропы более предсказуемыми.

Правда ли, что v2 «в 3 раза быстрее»? В публичных анонсах фигурирует «до ×3 быстрее при перегрузке». В конкретном dApp профит зависит от нагрузки и паттернов сообщений; стабильный выигрыш даёт именно library-wallet.

Чек-лист внедрения Jetton v2

* Перейдите на library-cell для кода Jetton Wallet (деплой через librarian), сохраните хэш/адрес в реестрах. * Прогоните тестнет и скрипт 

checkWalletLib

, нагрузочные сценарии transfer/internal_transfer/on_bounce. * Обновите индексаторы: верификация связки wallet→minter, валидность библиотеки (get_lib). * Для массовых рассылок — рассмотрите Mintless (TEP-176/177). * Обновите фронтенд: корректный учёт decimals, подсказки по комиссиям (база/forward/storage), «экономия v2». * Оформите операционный регламент: мультисиг-админ, периодическое продление library, процедуру отката.

Связанные материалы

Task Runner