Три независимых результата одного Jetton-перевода

  • forward_ton_amount=0 по TEP-74 означает, что transfer_notification отправляться не должно.
  • При ненулевом forward amount trace должен дойти от recipient Jetton wallet до owner address, но нехватка TON или ошибка фазы могут оборвать ветку.
  • Сервис не должен кредитовать депозит по одному opcode: sender notification надо связать с allowlisted master и ожидаемым wallet.
Три слоя, которые нельзя склеивать
СлойПроверяемый фактНе следует автоматически
Jetton stateinternal_transfer обработан recipient Jetton wallet; balance изменилсяOwner получил notification
NotificationСообщение 0x7362d09c дошло на destinationSender доверен и amount можно кредитовать
СервисInvoice/memo сопоставлен и internal ledger обновлёнOn-chain перевод можно повторить
Три слоя, которые нельзя склеивать
Слой
Jetton state
Проверяемый факт
internal_transfer обработан recipient Jetton wallet; balance изменился
Не следует автоматически
Owner получил notification
Слой
Notification
Проверяемый факт
Сообщение 0x7362d09c дошло на destination
Не следует автоматически
Sender доверен и amount можно кредитовать
Слой
Сервис
Проверяемый факт
Invoice/memo сопоставлен и internal ledger обновлён
Не следует автоматически
On-chain перевод можно повторить

Сначала определите, должно ли уведомление существовать

В теле transfer поле forward_ton_amount задаётся в nanotons. TEP-74 требует: если значение больше нуля, recipient Jetton wallet отправляет destination сообщение transfer_notification с этой TON-value; если равно нулю, уведомление отправляться не должно. Официальный payment guide рекомендует для совместимых депозитов как минимум 1 nanogram. Это минимальный триггер сообщения, а не обещание достаточного общего attached value для всех комиссий и deploy.

Если перевод готовил кошелёк или dApp, извлеките исходный BOC и декодируйте transfer#0f8a7ea5: query_id, raw amount, destination, response_destination, forward_ton_amount и forward_payload. Не восстанавливайте эти поля по комментарию интерфейса. Форматы адресов TON нужны, чтобы привести raw и user-friendly записи к одному account ID, но bounceable-строка не подтверждает тело сообщения.

Trace должен связать три разных аккаунта

Найдите в trace транзакцию sender Jetton wallet, её internal_transfer к wallet получателя и следующую транзакцию recipient Jetton wallet. Затем ищите отдельный out message на owner destination. В нём первые 32 бита body должны быть 0x7362d09c; query_id, amount, предыдущий owner в поле sender и forward_payload сверяются с исходным transfer. Одна верхняя transaction не описывает судьбу всех зависимых сообщений.

Для каждого узла прочитайте compute/action, aborted, bounce и фактически созданные out_msgs. Фазы TON-транзакции показывают, где ветка оборвалась: sender wallet мог не создать internal_transfer, recipient wallet мог изменить balance, но не профинансировать notification, либо сообщение могло уйти и завершиться на destination иначе. Bounce — отдельная ветка и не обещание полного возврата комиссий.

Decision tool для пропавшего notification
НаблюдениеКлассификацияДействие
forward_ton_amount=0, recipient balance выросNotification по стандарту не ожидалсяНе повторять; для сервиса собрать on-chain evidence и его правила recovery
forward amount >0, notification есть и sender доверенOn-chain notification найденПроверить amount/payload и отдельное internal credit
forward amount >0, ветка не созданаОшибка до notificationЗафиксировать phase codes и balances; не угадывать refund
opcode совпал, sender неизвестенНедоверенное сообщениеНе кредитовать; восстановить master → wallet relation
trace ещё pending или неполонРезультат неизвестенДождаться finalized/исторического trace и сверить второй источник
Decision tool для пропавшего notification
Наблюдение
forward_ton_amount=0, recipient balance вырос
Классификация
Notification по стандарту не ожидался
Действие
Не повторять; для сервиса собрать on-chain evidence и его правила recovery
Наблюдение
forward amount >0, notification есть и sender доверен
Классификация
On-chain notification найден
Действие
Проверить amount/payload и отдельное internal credit
Наблюдение
forward amount >0, ветка не создана
Классификация
Ошибка до notification
Действие
Зафиксировать phase codes и balances; не угадывать refund
Наблюдение
opcode совпал, sender неизвестен
Классификация
Недоверенное сообщение
Действие
Не кредитовать; восстановить master → wallet relation
Наблюдение
trace ещё pending или неполон
Классификация
Результат неизвестен
Действие
Дождаться finalized/исторического trace и сверить второй источник

Правильный opcode не аутентифицирует Jetton

Любой контракт может прислать body с 0x7362d09c. Источник in_msg должен быть ожидаемым Jetton wallet владельца-получателя, вычисленным для allowlisted master. Полную проверку пары Jetton master и Jetton wallet выполните как prerequisite; здесь она не повторяется. Только после этого raw amount, sender и payload становятся кандидатами на бизнес-обработку.

Recovery packet без повторного перевода

  1. 1
    Закрепите идентификаторы

    Сохраните network, external message hash, trace ID, account addresses, LT и время.

  2. 2
    Декодируйте transfer

    Зафиксируйте все TEP-74 fields и приложенную TON-value, не только Jetton amount.

  3. 3
    Пройдите message tree

    Свяжите sender wallet, internal_transfer, recipient wallet и notification либо точку её отсутствия.

  4. 4
    Сверьте state

    Снимите до/после balance обоих Jetton wallets и transaction phase results.

  5. 5
    Аутентифицируйте sender

    Докажите allowlisted master → expected recipient wallet до credit.

  6. 6
    Эскалируйте один кейс

    Передайте сервису raw evidence, invoice/payload и ожидаемый completion state; не отправляйте второй transfer.

Stop-сигналы

  • поддержка просит повторить перевод, не установив state первого;
  • notification принимают только по opcode без проверки in_msg.source;
  • название и symbol токена используют вместо allowlisted master;
  • forward_ton_amount путают с количеством Jetton или всей fee;
  • одно action-событие эксплорера заменяет полный message trace;
  • отсутствие notification объявляют доказательством полного возврата sender.

Результат закрыт, когда документированы token balance delta, ожидаемость и подлинность notification, а для биржи — отдельный статус internal credit. Если trace расходится между индексаторами, не делайте безопасный повтор: перечитайте finalized messages и state, передайте один evidence packet оператору и подпишите новую операцию только после однозначного решения по первой.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

  1. TEP-74 — Fungible tokens (Jettons) standard TON Blockchain · Проверено 23 августа 2026 г. в 19:59 GMT+5
  2. TON Docs — Jetton payments processing TON Docs · Проверено 23 августа 2026 г. в 19:59 GMT+5
  3. TON Docs — Traces TON Docs · Проверено 23 августа 2026 г. в 19:59 GMT+5
  4. TON Docs — Messages and transactions TON Docs · Проверено 23 августа 2026 г. в 19:59 GMT+5
Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.