TRON OUT_OF_ENERGY: Why a USDT Transfer Failed and Burned TRX

A TRON transaction with the result OUT_OF_ENERGY ran out of resources halfway through executing the USDT contract. The transfer itself was rolled back, so your USDT is still in your wallet — but the energy already consumed was paid for by burning TRX, and that TRX is gone. The fix is to resend with enough TRX on the address (or with staked or rented energy) and a fee limit high enough for the transfer you are making.

How energy is priced and why USDT costs more to a fresh address is explained in why a USDT TRC20 transfer costs what it does. This guide is about the failure: reading it, understanding what you paid for, and not repeating it.

What the explorer is telling you

Open the hash on Tronscan. A failed transfer shows a red result such as FAILED – OUT OF ENERGY and, in the resources block, energy consumed together with TRX burned. The TRC20 transfer section is empty or marked as failed: no tokens moved. Your wallet's history may still list the attempt with a red icon. If you are not sure the hash is a TRON one, the transaction hash identifier lists the possible chains.

Why it runs out of energy

Every TRC20 call has two limits. The first is the energy the contract needs: a USDT transfer to an address that already holds USDT uses around 65,000 energy, to an address that has never held USDT roughly twice that, because the contract writes a new storage slot. The second is the fee limit, the maximum TRX the transaction is allowed to burn for energy when you have none staked. If the energy needed costs more than the fee limit, or more TRX than you hold, execution stops when the allowance is exhausted.

With the energy price read from the network in October 2026 (100 sun per unit, 1 TRX = 1,000,000 sun), 65,000 energy costs about 6.5 TRX and 130,000 energy about 13 TRX. A wallet or script that sets a fee limit of 5 TRX, or an address that holds only 5 TRX, will fail on both — and burn what it managed to spend. The USDT TRC20 fee calculator recomputes these numbers for your case.

Common causes

• Not enough TRX on the sending address. The most frequent cause with self-custody wallets: you hold USDT and 3–5 TRX.
• A fee limit set too low by hand or by an old script. Some API integrations hard-code a small fee limit that worked before the energy price changed.
• Rented energy that expired or was smaller than needed. Energy rental covers a fixed amount for a period; a transfer to a new holder can need more than you rented.
• Sending to a contract with heavy logic. Transfers into some smart contracts cost far more than a plain transfer.

How to resend without failing again

1. Check the recipient: if it has never held USDT, budget for the higher energy figure.
2. Top up TRX on the sending address to at least the cost of the transfer plus a margin — 15 TRX for a transfer to an existing holder and 30 TRX to a new one is a comfortable buffer at current prices.
3. If your wallet shows a fee limit field, set it above the expected cost; the unused part of the limit is not burned.
4. Send once, wait for the result on Tronscan (a few seconds), and only then retry if needed.

Bandwidth is the second resource. Every transaction needs a few hundred bytes of bandwidth, and each address gets a free daily allowance (600 points at the time of writing). If you have used it up, the bandwidth part is also paid by burning a small amount of TRX. It rarely causes a failure on its own, but it adds to the TRX you need on the address.

Energy staking and rental

If you send USDT often, staking TRX for energy (Stake 2.0) or renting energy from a provider lowers the cost per transfer. Staked TRX can be unstaked after a 14-day waiting period. Whether it pays off depends on how many transfers you make a month; for occasional transfers, simply keeping enough TRX is easier.

When the failure happened during a swap

If you were sending USDT TRC20 to a KOT.CASH order and the transfer failed, nothing arrived at the deposit address and the order is still waiting for payment. Resend the full amount while the order countdown is still running; if it has expired, create a new order rather than paying the old address. Payouts from the service side do not fail this way: the provider pays its own energy.