Send a little TRX to the sending address, and once it arrives, send the USDT. When a wallet says there isn't enough TRX or energy, what is holding you back is the fee: sending TRC20 USDT on TRON is a call to the USDT contract, which consumes bandwidth and energy, and both are charged to the address that starts the transfer. If that address doesn't have enough resources of its own, TRX in it is burned instead, and no amount of USDT can stand in for that TRX.

Energy comes with no free allowance. TRON's developer documentation, Paying for resources & Energy sharing, gives the order: the caller's staked or delegated energy is used first, and TRX is burned for the rest, currently at 0.0001 TRX per unit of energy. If the address holds no TRX at all and has no staked or delegated energy, there is nothing to pay the energy cost with, so the transfer can't go out. The documentation gives only the unit price and the method of charging, not a fixed figure for how much one transfer burns, and a heavily used contract may need different amounts of energy at different times.

Withdrawing USDT from an exchange vs. sending it from your own wallet: who pays for energy

Exchange withdrawalNo TRX needed

The on-chain transfer is sent from the exchange's address
Energy and bandwidth come out of the exchange's side
You pay the fee shown on the withdrawal page

Sending from your own walletKeep TRX ready

Your address starts the transaction
Energy and bandwidth are charged to you
Any shortfall burns TRX in your address

Bandwidth, energy and burned TRX are all charged to whoever starts the transaction; the receiving side pays no resources. If the USDT in your wallet was withdrawn from an exchange, the withdrawal went through without a hitch, and the first time you try to send it on you get blocked, this is the reason: the address starting the transfer is now your own.

Sending USDT on Ethereum means keeping ETH ready for gas, as explained in What Is a Gas Fee — Why It Keeps Changing, and How to Pay Less. TRON splits that cost into two resources, bandwidth and energy, and when you have neither, you top up with TRX.

What TRON bandwidth and energy each pay for, and how much is free each day

The two resources are tracked separately and charged in different ways.

ResourceWhat it pays forFree allowanceWhen your own runs short
BandwidthEvery transaction except queries, by the number of bytes it takes up600 per account per day, which can be changed by proposalBurn TRX: transaction bytes × 1,000 sun (0.001 TRX per unit)
EnergyThe computation used to deploy or run a smart contractNoneBurn TRX for the shortfall: 0.0001 TRX (100 sun) per unit

Bandwidth is charged in three steps: first bandwidth from staked TRX, then the daily free bandwidth, and TRX is burned only when neither is enough. Each step has to cover the whole transaction by itself, because the network does not combine them; if neither can, TRX is burned for the full bandwidth cost.

Energy has one step fewer. Available energy is used first, whether you staked for it yourself or another account delegated it to you, and only the shortfall burns TRX. Both burn rates in the table are chain parameters and can be changed by proposal.

Energy payment order section of TRON's developer documentation: the deployer's share depends on the deployer's limit and available staked or delegated Energy, the caller covers the remainder with staked or delegated Energy first and then a TRX burn, and the caller's total is capped by the budget from fee_limit
A contract deployer's chosen share of energy comes only from the deployer's staked or delegated energy under TRON's October 2026 rules; the caller covers the rest with available energy first and then by burning TRX, and fee_limit caps only the caller's total.

Why TRX went down even though the USDT never left

When a contract runs, energy is worked out instruction by instruction and deducted as execution goes along. If execution stops partway, what happens to the energy already deducted depends on why it stopped:

  • Going past fee_limit: fee_limit is the most TRX the caller is willing to pay for this contract execution. If usage exceeds it, the execution fails and the energy already used is not refunded; TRON's documentation labels this failure OUT_OF_ENERGY.
  • The contract reverts itself (REVERT): only the energy for the instructions already executed is charged.
  • A contract bug or an execution timeout: all the energy available to the transaction is deducted as a penalty, and the part paid for by burning TRX is capped by fee_limit.

In none of these cases is the burned TRX returned, and because the contract execution failed, the USDT transfer did not happen either. Look up the transaction's TxID in a block explorer, check whether it failed or succeeded and how much USDT and TRX the address has left, and then decide whether to send again.

Top up enough TRX before you resend. If you still can't find the result of the previous transfer, hold off on sending another one.

Sending TRX to a new, unactivated address: the sender pays to create the account

When the receiving address hasn't been activated yet, creating the account is charged separately. TRON's developer documentation (Accounts and keys) puts the account creation fee on the sender, and on Mainnet it is currently 1 TRX.

A transaction that creates a new account also follows its own bandwidth rule: it can't use free bandwidth. The network first tries the sender's bandwidth from staking or incoming delegation; if that can't cover the full amount, none of it is used, and a fixed 0.1 TRX is burned on top of the account creation fee.

When you top up a brand-new wallet that hasn't been activated, withdrawing from an exchange makes the exchange's address the sender. Sending from another wallet of yours makes that wallet pay to create the account, so keep extra TRX there for it. Both amounts are chain parameters, and what applies is whatever the chain is set to at the time you send.

Besides topping up TRX, staking or delegation can also get you energy

Topping up TRX is the simplest fix. Energy only burns TRX for the shortfall, and whatever isn't burned stays in the address, so leave a little extra when you top up: under the documentation's dynamic energy model, a heavily used contract that consumes too much energy in one maintenance period (currently 6 hours) costs more energy to call with the same transaction in the next period.

If you often send from the same address, you can also stake TRX for energy. TRX staked for energy receives energy in proportion to its share of all TRX staked for energy across the network. When others stake more, your share shrinks, so a given stake doesn't buy a fixed amount.

Another account can also delegate to you energy it got from staking and hasn't used. Energy comes from your own stake, from someone else's delegation, or from burning TRX on the spot, and none of these needs your recovery phrase or private key; for someone to delegate energy to you, giving them your receiving address is enough. Close any page that offers “free energy” and asks you to enter your recovery phrase or private key.

Which TRON resources come back, and which can be taken away

Can I get back the TRX burned on a failed transfer?

No. Whether usage went past fee_limit, the contract reverted itself, or the contract hit a bug or timed out, burned TRX is not returned, and the USDT transfer did not go through either. First use the transaction's TxID in a block explorer to confirm whether it failed or succeeded and how much USDT and TRX are left in the address; if you are going to resend, top up enough TRX first.

How long do energy and bandwidth take to recover once used?

Energy, free bandwidth and bandwidth from staking all recover gradually within 24 hours of being used, rather than refilling all at once at a set hour. If you can't wait for that and need to send now, you can still burn TRX to pay for whatever is missing.

Can energy someone delegated to me be taken back?

Yes, when they cancel the delegation. If no lock period was chosen when delegating, they can cancel at any time; if one was chosen, they can only cancel once it ends, and if they delegate to the same address again during that time, the waiting period starts over. Also, the receiver has to be an activated external account; contract addresses can't receive delegated resources.