TRON transaction errors: causes and fixes

OUT_OF_ENERGY means the transfer needed more energy than the sender had, and the fee limit or the TRX balance could not pay for the rest, so the network stopped it and kept the TRX already burned. The USDT did not move.Read the fix →

Rented energy only helps if it is on the sending address, large enough for this transfer, and still within its rental window. A transfer that fails or burns TRX after a rental almost always misses one of the three.Read the fix →

REVERT means the smart contract itself refused the call. For a USDT transfer the usual reasons are a balance lower than the amount sent, or an address frozen by the issuer; energy does not change either.Read the fix →

BANDWITH_ERROR — spelled that way by TRON nodes — means the sending address had no free bandwidth left and no TRX to pay for it, so the transaction was never broadcast. Every activated address gets 600 free bandwidth points a day; a USDT transfer spends about 345.Read the fix →

CONTRACT_VALIDATE_ERROR means the network checked the transaction before running it and refused it: the most common reasons are too little TRX for the amount and fees, an address that is not activated, or a fee limit outside the allowed range.Read the fix →

A new TRON address exists only after it receives its first TRX: that transfer activates it, and the sender pays about 1.1 TRX for creating the account. Until then the address can receive tokens but cannot send anything.Read the fix →

OUT_OF_TIME means the smart contract call took longer than the network allows for one transaction, so it was stopped. It is rare for a USDT transfer and usually points to a heavy contract.Read the fix →

SIGERROR means the node checked the signature and it does not prove the sending address authorised the transaction: most often it was signed with a different private key, or the address uses multi-signature permissions that this signature does not satisfy.Read the fix →

Every TRON transaction carries an expiration time set when it is built; a node refuses it once that time has passed. TronWeb sets it about a minute ahead by default, so a transaction signed and broadcast later — after a slow approval, a queue or a retry from storage — expires.Read the fix →

Each TRON transaction names a recent reference block (ref_block_bytes and ref_block_hash). TAPOS_ERROR means the node cannot find that block on its chain: it is too old, or the transaction was built against another network — a Nile testnet transaction sent to mainnet, for example.Read the fix →

DUP_TRANSACTION_ERROR means the node already has this exact signed transaction. A transaction's id is the hash of its contents, so broadcasting the same bytes twice cannot execute twice — the second attempt is refused.Read the fix →