TRON Energy for a contract call comes from staked TRX, delegated resources, or burning TRX at 100 sun per unit. For one-off TRC-20 transfer energy, use TRON Energy to rent Energy for the sending account instead of locking TRX in Stake 2.0. Estimate the call, check Bandwidth, and set fee_limit before signing.
What Does Energy Actually Cover?
Energy pays for TRON Virtual Machine instructions during contract execution; Bandwidth pays for the transaction’s on-chain bytes. A plain TRX transfer needs Bandwidth but no Energy, whereas a USDT TRC-20 transfer invokes a contract and uses both. Energy has no free allowance; the current free Bandwidth allowance is 600 units per account over a rolling 24 hours.
The network uses the caller’s available Energy before burning TRX for a shortfall. A contract may assign part of its Energy cost to its deployer through consume_user_resource_percent, subject to the deployer’s origin_energy_limit and available Energy. Check that setting before assuming the deployer will cover any of your call.
Available TRON Energy belongs to the account making the contract call. If your wallet sends USDT from address A to address B, delegate or rent Energy to A, not B or the USDT contract. Delegation changes A’s resource balance; it does not move tokens.
How Much Energy Will This Transaction Need?
Estimate the call using the sender, contract, function and arguments you intend to submit. A wallet may show an estimate; an app or script can read energy_used from wallet/triggerconstantcontract, or energy_required from wallet/estimateenergy where the node supports it. Estimate shortly before broadcasting because contract state and dynamic pricing can change the result.
TRON energy for USDT transfers depends heavily on the recipient’s current USDT balance. As illustrative figures, sending to an address that already holds USDT uses roughly 64,000 Energy, while sending to a zero-USDT balance uses roughly 130,000. Writing a previously empty balance slot accounts for much of the gap; the token balance matters even when the TRON account is active.
At 100 sun per Energy, those examples would burn about 6.4 or 13 TRX if the caller had no Energy, plus any Bandwidth charge. With 50,000 Energy available against a 130,000-unit estimate, the 80,000-unit shortfall would burn about 8 TRX. Query getEnergyFee and getTransactionFee through wallet/getchainparameters for the live rates.
Which Route Should You Use?
Compare the cost of your Energy shortfall with the cost and duration of obtaining resources. Burning TRX can suit a small, occasional call; repeated transfers can justify a reusable staked allocation. Renting gives you delegated quota for a call without locking your own TRX.
- Burn TRX: Keep enough spendable TRX for the Energy gap and any Bandwidth burn.
- Rent Energy: Obtain delegated quota for the sending address before the call, with room above the estimate.
- Stake TRX: Stake for ENERGY under Stake 2.0 and use or delegate the resulting quota; used Energy recovers over 24 hours, while unstaking currently requires a 14-day wait on Mainnet.
Staking does not produce a fixed number of Energy units per TRX. Your quota depends on your share of the network’s Energy stake, so compare what a rental costs with the TRX burn avoided on the calls you expect to make.
Send It in Five Steps
Use the sender’s live resource balance and a fresh estimate to size the transaction before broadcasting. The sequence also applies to approvals, swaps and other contract calls, though each function can consume a different amount.
- Confirm the transaction. Identify the signing address, intended TRC-20 contract, recipient and amount. Check the contract and recipient independently because a wrong or reverted call can still consume Energy.
- Estimate this call. Simulate its exact function and arguments, then check the sender’s available Energy and Bandwidth in the wallet or through wallet/getaccountresource. Subtract available Energy from the caller’s estimated requirement and leave room for a changed balance or dynamic surcharge.
- Fund the shortfall. For Energy for TRC-20 transfers needed now, arrange a rental to the signing address, stake TRX for ENERGY, or retain enough TRX for the burn. If renting, wait until the account’s resource balance shows the delegation and send while that quota is available.
- Set the transaction budget. Set fee_limit in sun for the caller’s full estimated Energy requirement plus headroom, even when some Energy is already available. In the 130,000-unit example, 13,000,000 sun covers the bare estimate at 100 sun per unit; a 15,000,000-sun limit permits 150,000 units. It is a ceiling, not an up-front charge, and does not cover Bandwidth.
- Sign, broadcast and inspect the receipt. Confirm that execution succeeded, then compare energy_usage_total, energy_fee and net_fee with your estimate. A broadcast acknowledgment alone does not establish that the transfer happened.
What If the Cost Changes or the Call Fails?
A changed recipient balance, a different contract branch or an updated energy_factor can invalidate a saved estimate. The Dynamic Energy Model raises the effective cost of heavily used contracts; its surcharge can change between estimates and execution. Re-estimate before a batch or leave headroom for that change.
OUT_OF_ENERGY can mean too little available Energy and TRX, or a fee_limit below the caller’s full requirement. Check both the resources and the cap before retrying: raising fee_limit cannot create resources, while renting more Energy cannot fix a low cap. A failed execution may still consume Energy, so inspect its receipt first.
Exhausted Bandwidth can separately burn TRX for transaction bytes, currently at 1,000 sun per byte. Keep a small spendable TRX balance for that charge; holding USDT and delegated Energy alone may not cover it.
Rent when the avoided TRX burn exceeds the rental charge for your call window, stake when repeated use justifies the unstaking delay, and otherwise pay the burn.