ENЛичный кабинет

Почему перевод USDT падает с ошибкой «out of energy»

Это самый непонятный сбой в TRON: перевод виден в обозревателе с пометкой failed, получателю ничего не пришло — а TRX с кошелька всё равно ушли. Ничего не сломалось. Сеть сделала ровно то, что задумано.

Что означает ошибка

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

Дальше контракт исполняется. Если он исчерпает лимит, не завершившись, исполнение останавливается и все изменения состояния откатываются. В обозревателе транзакция записывается с результатом OUT_OF_ENERGY. USDT никуда не ушли.

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

Почему деньги всё-таки списали

Здесь и возникает недоумение: в банке всё наоборот. В TRON вы платите не за результат, а за вычисление. Валидаторы исполнили ваш вызов, потратили на это ресурсы и вернуть их не могут.

Из этого же следует, что неудачный перевод может обойтись дороже удачного: неудачная попытка сожгла всё доступное и не доставила ничего. Слепой повтор сожжёт всё второй раз.

Четыре причины, по убыванию частоты

  1. Получатель никогда не держал USDT. Это примерно удваивает потребность в энергии — около 130 285 вместо 64 285, — потому что контракту приходится выделять новую ячейку хранилища. Если вы взяли энергию под обычный перевод, вам не хватает половины.
  2. Арендованная энергия истекла. Аренда идёт фиксированный срок. Оплатили час, а отправили через полтора — делегирование уже снято, и адрес вернулся к тому, что у него есть своего.
  3. Энергию раньше израсходовало что-то другое. Другая транзакция в том же окне, approve, обмен: энергия — общий пул адреса, а не резерв под конкретную транзакцию.
  4. Энергия есть, а TRX нет. Bandwidth считается отдельно. Переводу нужно около 345 Bandwidth при бесплатном лимите 600 в сутки, и при нехватке сеть хочет за него TRX.

Как разобраться за две минуты

  1. Откройте неудачную транзакцию в TronScan и посмотрите поле Energy Usage. Оно показывает, сколько израсходовано до отказа, — это ваш нижний предел, реальная потребность выше.
  2. Откройте адрес получателя и проверьте, есть ли на нём USDT. Если баланс нулевой или токена в списке нет вообще — причина первая.
  3. Откройте свой адрес и посмотрите панель Resources: доступные Energy и Bandwidth. Сравните с тем, что требовалось транзакции.
  4. Симулируйте перевод вызовом triggerconstantcontract к контракту USDT с теми же отправителем и получателем. Возвращённое energy_used — точная цифра именно для этой пары адресов.

Симуляцию стоит делать перед любой партией выплат. Она превращает догадку в число и ничего не стоит, потому что в сеть не отправляется.

Ошибки, которые выглядят так же, но это не они

TronScan показывает несколько вариантов отказа, и лечатся они по-разному. Прочитать не тот — потерять полдня.

РезультатЧто произошлоЧто делать
OUT_OF_ENERGYВызов исполнялся и исчерпал лимит энергии, не завершившисьУвеличить энергию; проверить историю USDT у получателя
REVERTКонтракт отработал штатно, но отказал в операции — обычно не хватает баланса токена или нет разрешенияДело не в энергии; проверьте баланс USDT и approve
OUT_OF_TIMEИсполнение превысило лимит времени ноды, обычно под нагрузкой сетиПовторить; если повторяется — сам вызов слишком тяжёлый
Ошибка Bandwidth до исполненияТранзакцию отклонили по размеру ещё до запуска кодаПополнить TRX: суточный бесплатный лимит израсходован
Адрес не активированАдрес назначения никогда ничего не получалСначала отправить 1 TRX либо принять комиссию за активацию

Чаще всего за проблему с энергией принимают именно REVERT. Если видите его, добавление энергии не изменит ничего: контракт отказал по своим причинам, а покупка ресурсов лишь удорожает следующий отказ.

Что делать прямо сейчас

  • Берите энергию под дорогой сценарий — около 131 000, — а не под обычный. Запас стоит недорого и убирает весь класс ошибки.
  • Перед отправкой убедитесь, что делегирование действительно на вашем адресе, а не только что вы за него заплатили.
  • Держите небольшой запас TRX, 5–10, чтобы Bandwidth и активация адреса никогда не блокировали отправку.
  • Отправляйте сразу после аренды. Срок аренды начинается в момент делегирования, а не когда вы дошли до подписи.

Не повторяйте ту же транзакцию просто так. Если с ресурсами ничего не изменилось, она упадёт так же и сожжёт комиссию ещё раз.

Как больше не наступать

Для разовых переводов достаточно привычки: проверить баланс USDT у получателя, взять энергию под ответ, отправить.

Для всего автоматического проверка встраивается в процесс. Симулировать вызов, прочитать energy_used, арендовать столько плюс запас, убедиться, что делегирование активно, и только потом отправлять. Четыре шага — и OUT_OF_ENERGY перестаёт быть категорией инцидентов.

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