OUT_OF_ENERGY on TRON: Why It Happens and How to Fix It

In short: an out of energy error on TRON means a smart contract call, usually a USDT transfer, used up its energy budget before finishing. The call reverts, the USDT stays put, but the TRX burned is not refunded. On 21.10.2026 a USDT transfer needs about 65,000–131,000 energy; budgeting for the higher figure fixes most cases.

What does OUT_OF_ENERGY actually mean?

Every TRC20 transfer runs code inside the TRON Virtual Machine, and every instruction costs energy. Before the call starts, the network works out how much energy it is allowed to use. If execution needs more than that, the TVM stops, the state changes are rolled back, and the transaction receipt records OUT_OF_ENERGY.

TRON's documentation on paying for resources puts it plainly: the caller covers energy with staked or delegated energy first and then a TRX burn, the total is capped by the budget derived from fee_limit, and if usage would exceed that budget the transaction reverts with OUT_OF_ENERGY. Energy already consumed is still charged.

The important part is the ordering. The transaction is not rejected at the door. It is accepted into a block, it runs, it fails halfway, and you pay for the half it ran. That is what distinguishes it from most other TRON errors listed in our transaction errors reference.

Why did my transaction run out of energy?

The energy budget is roughly: energy you have available, plus the energy that the network is allowed to buy by burning your TRX. That second part is limited twice, by the fee_limit set on the transaction and by how much TRX is actually on the address. Failures come from one of these being too small for what the call needs.

The second-to-last row is a classic. The USDT contract charges about 64,285 energy (21.10.2026) to send to an address that already holds USDT, but about 130,285 to an address that has never held it, because a new balance slot has to be written. Our breakdown of energy for a USDT transfer explains how those figures are made up, including the dynamic energy surcharge.

How do I confirm it was OUT_OF_ENERGY and not something else?

Paste the transaction hash into Tronscan and look at three things:

1. Result. A failed call shows a failure status with the reason OUT_OF_ENERGY. Other reasons, such as REVERT, point to a different problem in the contract logic.
2. Energy usage and fee. The details panel shows how much energy was consumed, how much came from your staked or delegated energy, and how much TRX was burned.
3. Token transfers. A reverted call has no TRC20 transfer event. Your USDT balance is unchanged.

If the result is SUCCESS and the recipient still has not received the funds, you are dealing with a different issue entirely: see USDT sent but not received.

Is the TRX burned on a failed transaction lost?

Yes. Consumed energy is charged whether the call succeeds or not, and the TRX burned to pay for it does not come back. It is a network-level rule, so neither your wallet nor any energy service can reverse it.

A concrete example. You send USDT to a first-time holder with 6 TRX on your address and no energy. The call needs around 130,000 energy, which would cost about 13 TRX to burn at 100 SUN per unit. The network burns what it can within the budget, the call runs out partway through, and it reverts. Your 6 TRX are largely gone, the USDT has not moved, and you still need to fund the full transfer for the retry.

That is why topping up "just enough" is a false economy. The cheapest attempt is the one that succeeds first time.

How do I fix OUT_OF_ENERGY and retry safely?

1. Check the recipient. Look up their address on Tronscan. If they have never held USDT, plan for the higher figure, about 131,000 energy.
2. Get enough energy or TRX in place. Either rent energy for the full requirement and wait until it shows on your address, or hold enough TRX to burn for it plus a buffer. If you have neither, our guide on insufficient TRX for the fee lists the quickest ways to cover it.
3. Raise fee_limit if you control it. Developers using TronWeb or a custom wallet should set fee_limit comfortably above the expected burn. It is a ceiling, not a charge: you only pay for energy actually used.
4. Check bandwidth too. A USDT transfer is about 345 bytes. If your 600 free daily bandwidth is used up, that costs around 0.35 TRX, which must also be available.
5. Retry once the resources show on the address. Refresh the wallet or Tronscan and confirm the energy figure before signing.

How do I prevent OUT_OF_ENERGY in the future?

• Budget for new holders by default. If you pay many different people, assume the higher energy figure unless you know the recipient already holds USDT.
• Keep a TRX buffer even when renting energy, so a small shortfall is burned instead of failing the call.
• Wait for delegation before signing. Rented energy only helps once it appears on your address.
• Monitor for parameter changes. Energy price and the dynamic multiplier for popular contracts are set by the network and can change. Re-check numbers periodically against TRON's resource model.
• Automate if you send often. Businesses that move USDT all day typically keep energy topped up automatically so there is always enough for a new-holder transfer.

One failed transaction is annoying. A payout script that fails on every new recipient is expensive. Most OUT_OF_ENERGY cases disappear once the budget is sized for the worst realistic case, not the average one.