Not enough energy or bandwidth to send USDT on TRON

The warning appears and your balance hasn't moved an inch. The USDT is right there, the same number as a minute ago, and the send button does nothing. All you get is one line: not enough energy. Or not enough bandwidth. Some wallets hand you both words at once. The first thought is almost always the same one — I have the money, so what else does this chain want?

It wants resources. On TRON, the tokens you hold and your ability to broadcast a transaction are two separate accounts, and no amount of USDT settles the second one. This piece walks the step: what each of the two resources covers, why a TRC20 transfer draws on both, where that unsent transfer currently stands, what to do (and specifically not do) when the receiving side is an exchange, and the two routes TRON's own documentation gives you for topping resources up.

Bandwidth and energy are two different tanks

TRON's developer documentation splits them cleanly. Bandwidth "covers the byte size of transactions stored on-chain; larger transactions consume more." Energy "covers the computation the TVM performs when executing a smart contract." One pays for the space your transaction takes up; the other pays for the work a contract does.

Where they differ most is in how you get them, and that difference is what strands people. Bandwidth comes with a free allowance — the docs currently put getFreeNetLimit at 600, described as up to 600 free bandwidth per account over a rolling 24-hour window (go by what TRON's docs state at the time; checked 2026-09). Energy has no equivalent. The docs list its source as staking TRX, flagged in plain words: no free quota.

Why holding USDT doesn't help

USDT on TRON isn't a native coin. It's a number in a contract's ledger. Sending it means broadcasting a transaction that calls that contract and asks it to move the number from your name to someone else's. The documentation is explicit that every transaction except queries consumes bandwidth equal to its on-chain byte count, and that smart contract calls additionally consume energy.

So your transfer draws from both tanks — and neither can be paid in USDT. A ledger entry isn't fuel for the chain that stores it. That's the whole reason a fat balance and a dead send button coexist so comfortably.

One variant catches people off guard: the same amount goes through to a wallet you use all the time, then fails when you paste in the fresh deposit address an exchange just gave you. The address isn't broken. Crediting an address that has never held that token before makes the contract write a new storage entry, and writing storage inside a contract is one of the operations the docs name as consuming energy. By that mechanism the same transfer tends to cost more when the destination is new. How much more depends on the contract and the chain parameters of the moment — your wallet's pre-send estimate and the explorer's record beat any number printed in an article.

Where that failed transfer actually sits

Our habit here is to place the money on the route before doing anything else, and this case is no exception. When resources fall short, the transaction can end in one of two ways, and TRON's page on feeLimit keeps them apart:

• Rejected during validation. It never entered the TVM at all, so there was no contract execution for energy to pay for. It never became an execution on the chain.
• Entered the TVM, then hit the ceiling. In TRON's own words: if execution has not completed when the caller's required energy reaches that limit, the transaction fails with OUT_OF_ENERGY.

For your wallet both endings mean one thing: the tokens never reached the other address. The USDT is still yours. Nothing is half-sent, and nothing is sitting somewhere waiting to be released.

To tell which ending you got, take the transaction hash to a TRON block explorer and read the status row. If it doesn't say confirmed or success, treat the transfer as something that never happened and make every later decision on that basis. Where the hash hides in your wallet and which rows on an explorer page carry the verdict are covered in finding the TxID and reading the explorer.

Worth separating from two neighbouring problems: a transaction that made it on-chain and is merely gathering confirmations is the stuck-pending case; confirmations complete with nothing credited is a different article again. An energy shortfall happens before either — it never even reached a successful broadcast.

Sending to an exchange? Don't file a recovery request

This is the part we most wanted to write down. The moment the send fails, plenty of people open the exchange's "deposit not credited" help page and start filling in a self-service recovery form. Close it.

Binance's help page on self-service recovery of missing deposits lists eligibility up front: the transaction has to be marked "confirmed/success" on the blockchain, and it has to be "depositing into your account." A transfer that died for lack of resources fails the first condition outright — there's no successful token transfer to the deposit address on-chain, which means there's no deposit on the exchange's side either. Filing anyway just creates work for you and for support.

The same page rules out several other situations, worth knowing so you don't knock on the wrong door later: withdrawal transactions, cases where you are the sender, and applications submitted on behalf of others are all listed as ineligible. And when a transfer is eligible, the guidance is to wait before applying — in Binance's words, if your transaction is eligible for self-service recovery and your funds still haven't arrived after 1 hour, fill in the application. Go by whatever that help page states at the time you read it.

Every retry costs you, including the failed ones

The instinctive response to a failed send is another send, and then another. On this chain that instinct is expensive. The documentation states that energy consumed — whether it came out of your stake or was burned from your TRX — is never refunded, even if the transaction reverts later or fails on a different check. The FAQ page adds the finer version: only the energy used before the error is charged, and the unused allowance isn't billed.

Which means every retry that makes it into the TVM before dying spends real resources. Only the ones rejected during validation cost nothing — and you have no way of knowing which kind you're about to trigger before you tap.

So reverse the order: get the resources in place first, then send the second time. Hammering the button five times tends to end with five resource charges and USDT that hasn't moved a millimetre.

Two official ways to get resources

For an ordinary user, TRON's documentation points in exactly two directions:

• Stake TRX. An account can obtain resources in advance by staking TRX, parking bandwidth and energy under your own name so each transaction doesn't have to pay cash at the door.
• Keep enough TRX sitting in the address. When stake and the free quota can't cover an operation's cost, the network burns TRX from the sender's balance at the rate the chain parameters set for each resource — a rate the documentation can change, so read it off the official page at the time (checked 2026-09). Less setup, but you pay per transaction.

How much TRX to keep there? We don't print a figure. Chain parameters get adjusted and a contract's energy draw varies with what it has to do, so any hard number eventually becomes a trap. Use your wallet's estimate at send time and what the explorer records afterwards. As for third-party energy rental and fee-delegation services: we don't cover them and don't recommend them. Two routes appear in the documentation, and those are the two we write about.

There's also an exit people forget. If the point of this transfer was to get USDT into an exchange, the chain itself is a choice. TRON is cheap on the condition that you've stocked resources first; if you hold no TRX right now and don't feel like buying some just to move funds, another network may be the faster fix. What the routes cost and how fast they settle is in USDT across networks, compared, and the table in the complete network guide is there if you'd rather just follow one. Check the destination network's minimum deposit before you switch, so that saving a fee doesn't walk you into a different line.

Questions that keep coming back

Does topping up TRX fix a bandwidth error too?
Yes — same mechanism. When resources run short the network burns TRX from your balance to cover the cost, and that applies to bandwidth as much as to energy. The difference is that bandwidth has a free daily allowance to fall back on and energy doesn't.

If I move all my USDT out, does this stop happening?
No. Resource costs never come out of USDT, so the token balance is irrelevant to this step. Moving the USDT out is itself a transfer that needs resources you don't yet have.

Did the failed attempt eat some of my USDT?
The transfer didn't succeed, so no token movement was recorded and the ledger entry is untouched. What was actually spent is the resource or TRX consumed before the failure. The typical picture: USDT unchanged, TRX slightly lower.

Should I contact exchange support first?
Until there's a successful record on-chain there's nothing for support to look up — no transaction, no deposit, no case. Get the send to succeed, then talk about crediting.

Sources: TRON developer docs · resource model, TRON developer docs · setting feeLimit, Binance help centre · self-service deposit recovery, TRON developer docs · FAQ. Checked 2026-09-22. Chain parameters, free allowances and eligibility rules all change — go by those pages as they stand when you read them.