First, decide which kind of failure this is
Everything downstream depends on one question: is the transaction on-chain at all?
- If you have a transaction hash, paste it into TronScan. A page loads and the Status field names the failure. Go to the on-chain section below.
- If you have no hash, or the explorer does not recognise it, the transaction never reached the network. Go to the never-broadcast section.
- If the explorer shows SUCCESS with a TRC-20 transfer attached, the transfer worked and the problem is on the receiving side. Go to the last section.
It is on-chain and marked failed
| Result | Cause | Fee taken? |
|---|---|---|
| OUT_OF_ENERGY | The call exhausted its Energy limit partway through | Yes |
| REVERT | The contract refused — usually insufficient USDT balance, or a missing allowance for a contract spending on your behalf | Yes |
| OUT_OF_TIME | Execution exceeded the node's time budget, typically under network load | Yes |
| Blacklisted address | Tether can freeze addresses at the contract level; transfers to or from one are refused | Yes |
All four charge you. That is not a bug — the network performed the computation you asked for, and it cannot un-perform it. Retrying without changing anything burns the fee a second time.
OUT_OF_ENERGY is by far the most common of these and has its own deep dive. REVERT is the one most often misdiagnosed as an Energy problem: adding Energy changes nothing, because the contract refused on its own terms.
It never reached the network
These fail before any code runs, so nothing is charged — which is at least a small consolation.
| Cause | How to recognise it | Fix |
|---|---|---|
| No Bandwidth and no TRX | The wallet rejects the transaction on size before execution | Hold a few TRX; the 600 free daily points are spent |
| Destination never activated | The explorer says the account does not exist | Send 1 TRX first, or accept the activation fee |
| fee_limit set too low | The wallet warns, or the call stops exactly at the limit | Raise it — an unused limit costs nothing |
| Wrong network entirely | You sent TRC-20 to an ERC-20 or BEP-20 deposit address | Contact the recipient immediately; recovery depends entirely on them |
The wrong-network case is the only genuinely serious one on this page. Nothing about TRON can help — the funds are on TRON at an address whose owner may or may not control the TRON keys for it. Exchanges sometimes recover these for a fee, and sometimes cannot.
It succeeded but the recipient says nothing arrived
If the explorer shows SUCCESS with a TRC-20 transfer naming the right address and amount, the network did its job. The remaining causes are all on the receiving side.
- The wallet is not displaying the token. Many wallets hide TRC-20 tokens until they are added manually — the balance is there, the interface is not showing it.
- The recipient is looking at the wrong address, or the wrong network within the same wallet.
- It went to an exchange deposit address that requires a minimum, or that credits on a delay.
- There is a typo one character deep in the address, and it went to a real but different account. Compare the address in the explorer against the one you intended, character by character.
Send the recipient the transaction hash rather than a description. It settles the question immediately and without a conversation.
The two-minute diagnosis
- Open the hash in TronScan and read Status.
- If it failed, read the result string and match it against the tables above.
- Check the recipient's address page: does it hold USDT, and is it activated? Those two facts explain most Energy-related failures before you look at anything else.
- Check your own Resources panel for available Energy and Bandwidth — the available figure, not the total.
- Before retrying, change something. A retry with identical resources produces an identical failure and an identical fee.
Preventing most of them
- Size Energy for the recipient rather than the amount, and assume the expensive case for anyone new.
- Keep 5 to 10 TRX on any sending wallet. It covers Bandwidth, activation and rounding.
- Check the recipient address is activated and holds USDT before a first payment, not after.
- For automated sending, simulate each call and size from the result instead of a hardcoded constant.
Four habits remove roughly everything on this page except the wrong-network case, and that one is prevented by checking the network before you paste the address rather than after.