Что проверить в receipt
- Сначала откройте execution receipt: transaction body и успешный broadcast не доказывают, что контракт выполнил перевод.
- При REVERT состояние откатывается, но уже использованная Energy оплачивается. При некоторых runtime errors, включая OUT_OF_ENERGY, расход может дойти до рассчитанного лимита.
- Не повышайте fee_limit вслепую. Сверьте contract, функцию, параметры, ресурсы и точный result; повторяйте только после устранения причины.
TxID появился — перевод ещё не выполнен
Типичная история выглядит так: кошелёк отправил подписанную транзакцию, показал длинный hash и через несколько секунд отметил операцию красным. Пользователь видит txID и решает, что токен уже должен быть у получателя. Но нода сначала принимает корректно оформленную транзакцию, затем сеть включает её в блок, а уже во время выполнения TVM контракт может вернуть ошибку. Один зелёный этап не перекрашивает следующие.
| Слой | Что он подтверждает | Чего он не подтверждает |
|---|---|---|
| Broadcast response | Нода приняла запрос для дальнейшей обработки | Включение в блок, исполнение и финальность |
| Transaction body | Подписанные параметры, contract call и txID | Что вызов завершился успешно |
| Execution receipt | Result, fee, Energy, logs и internal transactions | Что блок уже solidified, если ответ взят с latest FullNode |
| Solidified receipt | Результат в солидифицированном состоянии сети | Экономический смысл операции или личность получателя |
- Слой
- Broadcast response
- Что он подтверждает
- Нода приняла запрос для дальнейшей обработки
- Чего он не подтверждает
- Включение в блок, исполнение и финальность
- Слой
- Transaction body
- Что он подтверждает
- Подписанные параметры, contract call и txID
- Чего он не подтверждает
- Что вызов завершился успешно
- Слой
- Execution receipt
- Что он подтверждает
- Result, fee, Energy, logs и internal transactions
- Чего он не подтверждает
- Что блок уже solidified, если ответ взят с latest FullNode
- Слой
- Solidified receipt
- Что он подтверждает
- Результат в солидифицированном состоянии сети
- Чего он не подтверждает
- Экономический смысл операции или личность получателя
Receipt показывает и ошибку, и цену попытки
Порядок чтения без догадок
- 1Убедитесь, что hash относится к TRON
64 шестнадцатеричных символа встречаются в разных сетях. Нужны источник реквизитов, TRON explorer или документированный TRON API, а не один только формат строки.
- 2Откройте transaction body
Сверьте caller, contract address, function selector, параметры, timestamp и fee_limit. Это помогает понять, что именно кошелёк подписал, но не даёт итог выполнения.
- 3Откройте post-execution receipt
Найдите receipt.result, верхнеуровневый result, resMessage, fee, energy_usage, energy_fee, net_usage и net_fee. Названия полей важнее пересказа интерфейса вроде «сбой сети».
- 4Проверьте logs только после result
Для TRC-20 нужен успешный Transfer event от нужного token contract. Логотип USDT и вызов функции transfer без успешного события не доказывают движение токена.
- 5Зафиксируйте block anchor и время проверки
Latest и solidified state различаются. Для спора или отчёта сохраните hash, block number, result, расход ресурсов и источник, из которого получен receipt.
| Поле | Практический смысл | Частая ошибка |
|---|---|---|
| fee | Суммарно сожжённые TRX в sun по receipt | Принимать fee_limit за фактически списанную сумму |
| energy_usage | Energy, покрытая доступным ресурсом аккаунта | Считать любой расход Energy списанием TRX |
| energy_fee | TRX, сожжённые для покрытия дефицита Energy | Игнорировать стейкнутую или делегированную Energy |
| net_usage / net_fee | Bandwidth usage и TRX burn при его нехватке | Объяснять всю комиссию только Energy |
| receipt.result | Результат исполнения TVM | Смотреть только на наличие body или подписи |
- Поле
- fee
- Практический смысл
- Суммарно сожжённые TRX в sun по receipt
- Частая ошибка
- Принимать fee_limit за фактически списанную сумму
- Поле
- energy_usage
- Практический смысл
- Energy, покрытая доступным ресурсом аккаунта
- Частая ошибка
- Считать любой расход Energy списанием TRX
- Поле
- energy_fee
- Практический смысл
- TRX, сожжённые для покрытия дефицита Energy
- Частая ошибка
- Игнорировать стейкнутую или делегированную Energy
- Поле
- net_usage / net_fee
- Практический смысл
- Bandwidth usage и TRX burn при его нехватке
- Частая ошибка
- Объяснять всю комиссию только Energy
- Поле
- receipt.result
- Практический смысл
- Результат исполнения TVM
- Частая ошибка
- Смотреть только на наличие body или подписи
Если нужен общий навык проверки hash, сначала разберите, как отличать найденную транзакцию от совпадения формата и как фиксировать подтверждения. Здесь мы идём дальше: предполагаем, что сеть уже установлена, и исследуем именно execution receipt.
REVERT и OUT_OF_ENERGY списывают ресурсы по-разному
REVERT означает, что выполнение дошло до условия, которое остановило вызов: например, require не выполнился, контракт был на паузе, баланс оказался недостаточным или параметры не прошли проверку. Изменения state откатываются атомарно. Однако инструкции до точки ошибки уже исполнялись, поэтому использованная Energy учитывается. Неиспользованный остаток allowance при обычном REVERT не биллится.
| Результат | Что происходит со state | Как учитывается Energy | Первое действие |
|---|---|---|---|
| REVERT | Изменения откатываются | Только использованная до ошибки; остаток allowance не биллится | Прочитать reason и проверить preconditions |
| OUT_OF_ENERGY | Изменения откатываются | Может быть учтён весь рассчитанный доступный Energy limit | Не повторять; выяснить estimate, fee_limit и состояние контракта |
| OUT_OF_TIME / invalid opcode | Изменения откатываются | Для ряда runtime exceptions применяется spendAllEnergy | Зафиксировать result и обратиться к разработчику контракта |
| Pre-validation rejection | TVM не запускалась | Energy и Bandwidth не расходуются, запись on-chain не создаётся | Исправить структуру, подпись, срок или другой validation error |
- Результат
- REVERT
- Что происходит со state
- Изменения откатываются
- Как учитывается Energy
- Только использованная до ошибки; остаток allowance не биллится
- Первое действие
- Прочитать reason и проверить preconditions
- Результат
- OUT_OF_ENERGY
- Что происходит со state
- Изменения откатываются
- Как учитывается Energy
- Может быть учтён весь рассчитанный доступный Energy limit
- Первое действие
- Не повторять; выяснить estimate, fee_limit и состояние контракта
- Результат
- OUT_OF_TIME / invalid opcode
- Что происходит со state
- Изменения откатываются
- Как учитывается Energy
- Для ряда runtime exceptions применяется spendAllEnergy
- Первое действие
- Зафиксировать result и обратиться к разработчику контракта
- Результат
- Pre-validation rejection
- Что происходит со state
- TVM не запускалась
- Как учитывается Energy
- Energy и Bandwidth не расходуются, запись on-chain не создаётся
- Первое действие
- Исправить структуру, подпись, срок или другой validation error
fee_limit — потолок риска, а не счёт к оплате
В contract call параметр fee_limit выражен в sun и ограничивает Energy budget, который caller готов покрыть. Сеть сравнивает этот потолок с доступной стейкнутой Energy и TRX balance. Слишком низкий cap способен привести к OUT_OF_ENERGY даже у аккаунта с ресурсами; слишком высокий cap не означает автоматическое списание всей суммы. Он лишь расширяет возможный предел выполнения.
Energy price, Bandwidth price и maximum fee limit — параметры сети, которые могут измениться. На дату проверки их можно получить через GetChainParameters, но статья намеренно не превращает текущие числа в вечный тариф. Для оценки перед новой операцией используйте свежий монитор комиссий и всё равно оставляйте запас на изменение state контракта.
Если не дошёл USDT, ищите Transfer нужного контракта
TRC-20 transfer — вызов смарт-контракта. В body можно увидеть намерение вызвать transfer(address,uint256), но перевод токена подтверждает successful receipt и event от конкретного token contract. Если result неуспешен, state откатывается: получатель не получает USD₮, даже если кошелёк успел нарисовать исходящую операцию и удержал TRX за ресурсы.
| Проверка | Ожидаемый факт | Если не совпало |
|---|---|---|
| Token contract | Полный адрес официального контракта в выбранной сети | Не доверять тикеру; установить, какой токен вызван |
| Recipient parameter | Полный адрес получателя совпадает с исходным реквизитом | Не повторять; заново подтвердить реквизит независимым каналом |
| Amount и decimals | Raw amount корректно переводится в пользовательское число | Проверить единицы, не редактировать hex вручную |
| Receipt result | SUCCESS | Классифицировать REVERT/runtime failure |
| Transfer event | Emitter — тот же token contract, from/to/value ожидаемы | Не считать перевод исполненным |
- Проверка
- Token contract
- Ожидаемый факт
- Полный адрес официального контракта в выбранной сети
- Если не совпало
- Не доверять тикеру; установить, какой токен вызван
- Проверка
- Recipient parameter
- Ожидаемый факт
- Полный адрес получателя совпадает с исходным реквизитом
- Если не совпало
- Не повторять; заново подтвердить реквизит независимым каналом
- Проверка
- Amount и decimals
- Ожидаемый факт
- Raw amount корректно переводится в пользовательское число
- Если не совпало
- Проверить единицы, не редактировать hex вручную
- Проверка
- Receipt result
- Ожидаемый факт
- SUCCESS
- Если не совпало
- Классифицировать REVERT/runtime failure
- Проверка
- Transfer event
- Ожидаемый факт
- Emitter — тот же token contract, from/to/value ожидаемы
- Если не совпало
- Не считать перевод исполненным
Успешный receipt тоже не отвечает на все вопросы: токен мог быть другим, сеть могла не поддерживаться депозитом, а интерфейс получателя — задержать зачисление. Эти ветки разобраны отдельно в диагностике пропавшего USDT.
Перед повторной отправкой устраните причину
Повтор оправдан только после конкретного изменения
- Исправлен recipient или amount, и новый реквизит повторно подтверждён по независимому каналу.
- Пополнен TRX balance или получена Energy, а estimate показывает достаточный budget с понятным запасом.
- Снята пауза контракта, истёкший deadline заменён новым или выполнено другое документированное precondition.
- Исправлена allowance/permission, если contract call действительно требовал это право.
- Разработчик или официальный интерфейс подтвердил, что прежний runtime error устранён, и показал новый ожидаемый вызов.
Перед новой подписью вернитесь к правилам безопасного перевода: заново сверяйте сеть, контракт и получателя, даже если первая попытка была вашей. Ошибка не делает сохранённую транзакцию шаблоном, который можно подтверждать не читая.
Что делать, если попыток уже несколько
- 1Остановите автоповтор
Закройте dapp, отмените повторные подтверждения в очереди интерфейса и не подписывайте новую транзакцию с теми же параметрами до диагностики.
- 2Соберите receipts каждой попытки
Для каждого hash сохраните result, fee, Energy, contract, function, block и timestamp. Не суммируйте fee_limit: складываются только фактические расходы из receipts.
- 3Разделите расход ресурса и потерю токена
При reverted Transfer токен обычно не переместился, но TRX или Energy могли быть израсходованы. Проверьте balance до и после, не полагаясь на push-уведомление.
- 4Передайте поддержку воспроизводимый набор
Сеть, hash, contract, result и время полезнее скриншота «ошибка». Seed, private key, SMS-код и удалённый доступ поддержке не нужны.
| Вопрос | Доказательство | Честный вывод |
|---|---|---|
| Транзакция исполнилась? | Solidified receipt и result | SUCCESS либо конкретный failure result |
| Токен переместился? | Transfer event нужного contract с ожидаемыми from/to/value | Событие найдено или не подтверждено |
| Что было списано? | fee и resource fields | Фактический TRX burn и использованные ресурсы |
| Почему можно повторить? | Изменённое precondition и новый estimate | Причина устранена, но success всё равно не гарантирован |
- Вопрос
- Транзакция исполнилась?
- Доказательство
- Solidified receipt и result
- Честный вывод
- SUCCESS либо конкретный failure result
- Вопрос
- Токен переместился?
- Доказательство
- Transfer event нужного contract с ожидаемыми from/to/value
- Честный вывод
- Событие найдено или не подтверждено
- Вопрос
- Что было списано?
- Доказательство
- fee и resource fields
- Честный вывод
- Фактический TRX burn и использованные ресурсы
- Вопрос
- Почему можно повторить?
- Доказательство
- Изменённое precondition и новый estimate
- Честный вывод
- Причина устранена, но success всё равно не гарантирован
Стоп-сигналы
- Сервис обещает вернуть Energy или комиссию после перевода «страхового депозита».
- Для чтения receipt просят seed-фразу, private key, backup-файл, PIN, OTP или удалённый доступ.
- Совет сводится к максимальному fee_limit без разбора result и contract preconditions.
- Поддержка присылает новый token contract или recipient в личном сообщении и торопит повторить перевод.
- Интерфейс называет наличие txID доказательством успешного USDT Transfer, но не показывает receipt и emitter события.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- TRON Developers — confirmation semantics Проверено 10 августа 2026 г.
- TRON Developers — GetTransactionInfoById Проверено 10 августа 2026 г.
- TRON Developers — VM exception handling Проверено 10 августа 2026 г.
- TRON Developers — FeeLimit and Energy cost Проверено 10 августа 2026 г.
- TRON Developers — GetChainParameters Проверено 10 августа 2026 г.