The five fields that matter
| Field | What it tells you |
|---|---|
| Status / Result | SUCCESS, or the specific failure — OUT_OF_ENERGY, REVERT, OUT_OF_TIME |
| Energy Usage Total | How much Energy the call actually consumed, and where it came from |
| Bandwidth / Net Usage | Bytes charged, and whether they came from the free allowance or burned TRX |
| Fee | TRX actually burned. Non-zero on a failed transaction is normal, not a bug |
| TRC-20 Transfers / Token Transfer | Whether tokens actually moved. Empty on a failure, populated on success |
The last one is the single most useful field for answering “did the money arrive?”. The transaction existing is not the same as the transfer happening — a failed call is recorded on-chain with no token transfer attached to it.
Reading a successful transfer
On a healthy USDT transfer you should see Status SUCCESS, a TRC-20 Transfers section naming the sender, recipient and amount, and an Energy Usage figure in the region of 64,000 or 130,000 depending on the recipient.
The Energy Usage breakdown is worth reading closely, because it tells you where the resource came from. If it shows Energy consumed from your own balance, your stake or rental covered it. If it shows a fee in TRX, the network burned your TRX to make up the shortfall — which means you paid the expensive rate without noticing.
That last case is the most common form of silent overpayment. The transfer works, nothing looks wrong, and the difference only shows up in the TRX balance over time.
Reading a failure
When the status is not SUCCESS, the result string tells you which fix applies. They are genuinely different problems.
| Result | Read it as | Fix |
|---|---|---|
| OUT_OF_ENERGY | The call ran and ran out of Energy partway | More Energy; check the recipient's USDT history |
| REVERT | The contract executed and refused — usually insufficient balance or missing allowance | Not an Energy problem; check the token balance |
| OUT_OF_TIME | Execution exceeded the node's time budget under load | Retry; if persistent, the call is too heavy |
| Account does not exist | The destination address was never activated | Send 1 TRX first, or accept the activation fee |
For a REVERT, look for the revert reason if the explorer surfaces one. Contracts often encode a readable message, and it usually names the exact condition that was not met.
fee_limit is not the fee
The fee_limit field is a ceiling you set before signing — the most you are willing to spend on execution. It is not what you were charged.
Comparing fee_limit against Energy Usage tells you whether a failure was self-inflicted. If usage reached the limit exactly, your limit was too low and the call was cut short. If usage stopped well below it, the limit was not the constraint and the cause is elsewhere.
Checking an address rather than a transaction
- Open the address page and read the Resources panel: Energy and Bandwidth, available over total, with delegated amounts listed separately from owned ones.
- Check the token list to see whether the address holds USDT at all. A missing token is what makes a transfer to that address expensive.
- Look at the creation date to confirm the address is activated. No date means no account.
- Scan recent transactions for other calls in the same window — Energy is a shared pool, and something else may have drained it.
Delegated resources appear in the same figures as owned ones, so an address looks funded right up to the moment a rental expires. When debugging a timing issue, check when the delegation was made and how long it ran.
What to send when you ask for help
Whether you are writing to a resource provider, an exchange or a counterparty, one piece of information does almost all the work.
- The transaction hash. It is public, it is unambiguous, and it lets anyone reconstruct exactly what happened without a conversation.
- Not a screenshot of your wallet — it shows what your wallet believes, not what the chain recorded.
- Not the amount and the time — there may be several transactions matching that description.