TRON Contract Call Resources: Trace the Charge Order

A TRON contract call draws Energy for TVM execution and Bandwidth for the serialized transaction, with each resource settled from separate account pools. The decisive condition is the contract’s consume_user_resource_percent, because it sets the caller’s Energy share before the network falls back to the deployer or the caller’s TRX balance.

Bandwidth and Energy pay separate parts of the call

Bandwidth covers the transaction’s on-chain byte size; Energy covers the instructions executed by the contract. They are charged independently, so enough Energy does not prevent a Bandwidth shortfall, and spare Bandwidth cannot pay for execution. TRON Energy has no free daily quota; Bandwidth currently has a free account quota set by getFreeNetLimit, typically 600 units per rolling 24-hour window.

Think of the transaction as a parcel sent to a workshop: Bandwidth pays to carry the parcel, while Energy pays for the work done inside. For a USDT TRC-20 transfer, the contract’s code path determines the Energy consumed; the sender’s available Bandwidth and Energy, plus any applicable TRX balance, determine how those costs are covered.

The caller’s share is charged before the deployer’s subsidy

For Energy, the network first charges the caller up to the share set by consume_user_resource_percent, using the caller’s available staked or delegated Energy. The setting ranges from 0—the deployer is responsible for the full Energy cost—to 100—the caller is responsible for all of it. Many contracts use 100; a lower setting can subsidize callers, but only while the deployer has enough eligible Energy.

The deployer’s contribution is constrained by its available Energy and the contract’s origin_energy_limit. If that pool cannot cover its configured share, the uncovered amount can fall back to the caller, subject to the caller’s own Energy capacity and fee_limit. A zero fee_limit leaves the caller unable to cover Energy, so a call can fail even when the caller holds TRX if the deployer cannot fund the whole execution.

When the caller must cover Energy beyond its staked or delegated balance, TRX is burned at the current getEnergyFee rate, typically 100 sun per Energy. The caller’s fee_limit is denominated in sun and caps the caller’s Energy budget, including Energy supplied by the caller’s resources; it is not a fixed fee and does not cap the deployer’s stake. Query wallet/getchainparameters for the live burn rate and maximum fee limit, since chain parameters can change.

Estimate the call, then read its receipt

Before broadcasting, simulate the same contract method and inputs with wallet/triggerconstantcontract; its energy_used is a useful estimate, not a reservation. wallet/estimateenergy can be more accurate for some edge cases, but availability depends on node configuration. Leave headroom in fee_limit: changed contract state, a different execution branch, or dynamic Energy penalties can make the mined call consume more than the simulation suggested.

If the transaction is pending, the simulation’s resource snapshot may already be stale: another transaction can use the account’s available Energy before this one executes. Once included, inspect wallet/gettransactioninfobyid or, for solidified data, walletsolidity/gettransactioninfobyid; the receipt’s energy_usage, origin_energy_usage, energy_usage_total, energy_fee, and net_usage help distinguish caller Energy, deployer Energy, burned TRX, and Bandwidth.

Match the failure to the resource that ran short

OUT_OF_ENERGY means execution hit the available Energy budget, often because fee_limit was too low or the deployer subsidy was exhausted. Re-estimate with production-shaped inputs, check the contract’s share and origin limit, then raise the caller’s limit only if the expected maximum burn is acceptable. A normal REVERT signals a contract condition or invalid input instead; increasing fee_limit will not fix that logic failure, and Energy already consumed is still charged.

For a transaction whose cost is the issue, the linked TRON Energy can be rented to cover Energy instead of relying entirely on TRX burn. tronenergy.dev is a service for renting TRON Energy for USDT TRC-20 transfers and other TRON transactions. The official TRON Developer Hub documents the resource order and estimation endpoints; use the actual receipt to settle what happened on-chain.

Before retrying, check:

• Whether the transaction is pending or has a confirmed failure.
• The caller’s available Energy and Bandwidth, plus consume_user_resource_percent and origin_energy_limit.
• The simulation estimate, fee_limit in sun, and receipt fields after inclusion.