TRON Transaction Failed: Error Codes and Fixes

In short: a TRON transaction failed for one of two reasons. Either the node rejected it before broadcast (no fee, nothing on-chain) or it ran and failed on-chain (fee charged, tokens stay put). On 21.10.2026 a USDT transfer needed about 65,000 energy, or around 131,000 to a new address; most failures come down to that gap.

The good news is that TRON tells you exactly what went wrong, as long as you know where to look. This guide sorts every common error into its group, explains what each one costs you, and gives the fix. If you have just watched a USDT payment fail and you are about to hit Send again, read the first two sections before you do.

Did my transaction fail on-chain or was it never sent?

Start here, because the answer decides whether you lost money.

Rejected before broadcast. Your wallet or the node checked the transaction, found a problem and refused to pass it on. There is no transaction hash on Tronscan, or the hash returns "not found". Nothing was charged. Wallets usually show these as a red pop-up with a code such as BANDWITH_ERROR, TRANSACTION_EXPIRATION_ERROR or a decoded message like "account does not exist".

Failed on-chain. The transaction was included in a block, the TRON Virtual Machine executed it and the execution failed. You get a real hash, Tronscan shows the result as failed, and the fee section lists energy and bandwidth consumed. Codes here are OUT_OF_ENERGY, REVERT and OUT_OF_TIME. Your USDT did not move, but the resources and any burned TRX are gone.

To check, paste the hash or your address into Tronscan and open the transaction. Look at three fields: the result, the energy usage breakdown, and "fee" or "burned TRX". If the result is "SUCCESS" and the recipient still says they have nothing, that is a different problem: see USDT sent but not received.

A quick rule that saves real money: a pre-broadcast rejection is free to retry once you fix it. An on-chain failure costs you every time it repeats, so never retry it blindly.

Which TRON error codes matter, and what does each one cost?

The table groups the errors you will actually meet as a wallet user or a developer. The "cost" column is what you lose on that attempt. The descriptions follow TRON's official pages on smart contract errors and broadcast and RPC errors.

Note the spelling: BANDWITH_ERROR is missing a "D" in the protocol itself.

Why does OUT_OF_ENERGY happen so often with USDT?

USDT on TRON is a smart contract, so every transfer runs code and burns energy. You can learn the mechanics in our guide to TRON energy, but the short version is this: TRON gives you about 600 free bandwidth a day and zero free energy. Energy comes from staking TRX, from renting it, or from burning TRX at the network price.

On 21.10.2026 the live network gave these figures:

Bandwidth comes on top: about 345 bytes, or roughly 0.35 TRX if your free daily bandwidth is already used up.

OUT_OF_ENERGY appears when the energy you hold plus the TRX the wallet is allowed to burn cannot reach that total. Three patterns cause almost all of them:

1. The fee limit was set too low. Some wallets and scripts let you set a fee limit. If it is below the real cost, execution stops midway and the whole allowance is spent. Doubling the required energy for a new address is the classic trap: a limit that comfortably covers a 65,000-energy transfer is far short of 130,000.
2. Partial energy. You staked or rented enough for a normal transfer, then sent to an empty address. The energy you had is consumed first, and the wallet then needs TRX to burn for the rest. If the TRX is not there, the call fails.
3. Not enough TRX for the burn. You have zero energy and only 3 TRX. The wallet may still let you sign, and the chain fails the call.

A failed transfer that hit OUT_OF_ENERGY leaves your USDT where it was, but you lose what was burned. The dedicated guide to the OUT_OF_ENERGY error walks through reading the exact energy numbers on Tronscan and picking the right amount for the retry.

What does "insufficient TRX for fee" or BANDWITH_ERROR mean?

This is the most common pre-broadcast rejection for people coming from Ethereum. On Ethereum you need ETH for gas; on TRON you need either resources or TRX to burn. If you hold 500 USDT and 0 TRX, and no energy, most wallets will either grey out the Send button or return a "not enough TRX" style message. At node level the same situation shows up as BANDWITH_ERROR.

Despite the name, BANDWITH_ERROR is not only about bandwidth. Per TRON's documentation it also fires when you cannot pay for a memo, a multisig signature or the creation of a new account. On 21.10.2026 the memo fee and multisig fee were each 1 TRX, and creating an account by sending TRX to a fresh address cost 1 TRX (plus 0.1 TRX if you lack staked bandwidth for it).

Two quick checks resolve it:

• Is there any TRX at all on the sending address? A small amount covers bandwidth and activation fees, though not a USDT transfer without energy.
• Is today's free bandwidth already used? The free 600 points refill over 24 hours, and a transaction can only use free bandwidth if the remainder covers the full size. The TRON bandwidth guide explains why 600 points does not mean "two free transfers".

If you cannot or do not want to buy TRX right now, insufficient TRX for fee covers the routes: getting a small amount of TRX, renting energy so you do not need to burn, or swapping part of your USDT.

What does REVERT mean, and is it my fault?

REVERT means the contract itself said no. The code checked a condition, the condition failed, and the contract aborted on purpose. You pay for the energy used up to that point, which is usually a fraction of a full transfer, plus bandwidth.

For USDT, typical reasons are:

• Amount larger than balance. Some wallets catch this, some scripts do not.
• The sending address is blacklisted. Tether can freeze addresses on its TRC20 contract. A frozen address cannot send, and every attempt reverts.
• Calling the wrong contract. A fake "USDT" token with a different contract address may have its own rules, including refusing transfers. The real USDT TRC20 contract is TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, the one Tether lists for TRON.

With dApps (DEX swaps, staking contracts, games) REVERT often means slippage was exceeded, a deadline passed or the contract is paused. The dApp's interface usually translates the reason; if it does not, Tronscan sometimes shows a decoded revert message under the transaction details.

Do not keep retrying a REVERT. The chain is telling you the conditions are wrong, and each attempt costs energy.

What do expired, TAPOS and duplicate errors mean?

These three are timing and bookkeeping problems, mostly seen by developers, payment scripts and people using hardware wallets slowly.

Transaction expired. Every TRON transaction carries an expiry time. The default is 60 seconds after it is built; the protocol allows up to 24 hours. If you build the transaction, then take two minutes to confirm on a Ledger, the node may reject it with TRANSACTION_EXPIRATION_ERROR. Nothing is charged. Build a new one and sign promptly.

TAPOS_ERROR. Each transaction references a recent block to prove it was built on the current chain. If that block is unknown to the node (stale data, a node that is out of sync, or a reference to a block that was forked away), you get this error. Rebuild the transaction against a recent block from a synced node.

DUP_TRANSACTION_ERROR. The node already has this exact transaction, either pending or in a block. This is a warning, not a failure: your first attempt may have gone through. Look up the hash before you build a replacement, or you risk paying twice.

Why does a new address cause "account does not exist" or a double fee?

TRON accounts must be activated before they exist on-chain. Activation happens when the address first receives TRX, a TRC10 token, or (in most cases) a TRC20 transfer. Until then, some operations fail validation with "account does not exist".

You usually see this when:

• You try to send from a freshly generated address that has received nothing yet.
• A wallet requires the recipient to be active before it allows certain actions. MetaMask's TRON help page, for example, tells users to send TRX first to activate a new account, and Ledger's support asks for a small TRX deposit before tokens show up.

Sending USDT to a brand-new address is a separate cost issue rather than an error. It roughly doubles the energy, from about 65,000 to about 131,000 on 21.10.2026. If you prepared energy for the cheaper case, the transfer either burns the difference in TRX or fails with OUT_OF_ENERGY.

How do I fix a failed TRON transaction step by step?

1. Find the hash. In your wallet's history, copy the transaction ID. No hash means it never left the wallet: read the error message and go to the matching row in the table above.
2. Open it on Tronscan. Note the result, energy used, bandwidth used and TRX burned.
3. Match the result to the cause. OUT_OF_ENERGY: resources too low. REVERT: contract condition. Expired or TAPOS: rebuild. Validation errors: account or balance problem.
4. Check the recipient. Does it already hold USDT? If not, plan for about 131,000 energy, not 65,000.
5. Fix the resource gap. Either keep enough TRX to burn (about 6.5 TRX or 13 TRX in the cases above, plus bandwidth), stake TRX, or rent energy for the transfer. Our energy rental page delivers energy to your address so the transfer runs without burning TRX; you do not hand over keys or a seed phrase.
6. Send once. Confirm the energy has arrived on the address (Tronscan shows it in the account's resources), then send.

If you are a developer, log the full receipt from gettransactioninfobyid for every failed payout. It includes the result code and fee, which makes support tickets and accounting much easier.

How do I stop TRON transactions failing in the future?

Most failures are preventable with four habits.

• Always keep a small TRX buffer. Even with rented or staked energy, bandwidth, memo fees and activation fees are paid in TRX. A few TRX on every sending address prevents most pre-broadcast rejections.
• Size energy for the recipient, not for the average. New addresses need roughly double. If you pay many first-time recipients, plan for the higher figure.
• Do not lowball the fee limit. If you set it yourself, set it above the real cost. A limit that is too low turns a successful transfer into a paid failure.
• Check the contract address. Only one USDT contract on TRON is real. Adding a token by search instead of by contract is how fake balances and stuck transfers start.

The transaction structure page in TRON's developer docs explains expiry, reference blocks and fee limits in more depth if you build transactions yourself.