Tron Fees: Bandwidth, Energy and fee_limit

A Tron fee is the resource cost of a transaction, paid in bandwidth for its size and in energy for smart contract execution. If your account has too little of a resource, the network burns TRX to cover the gap. This article explains the payment order, the fee_limit that caps a contract call and the dynamic energy model that changes costs.

Why do Tron fees exist?

Every transaction except a query consumes bandwidth, so each transaction has a price in a limited resource. The TRON resource model defines bandwidth as the byte size of a transaction. Energy measures the computation in the TRON Virtual Machine and applies only when a contract is deployed or called.

Accounts get resources by staking TRX or by receiving delegated resources. Every account also gets a free bandwidth allowance of 600 per day. Anything beyond that is paid in burned TRX. The rates and allowances are network parameters that governance proposals can change, so read current values from the chain instead of hard-coding them. The Chaingateway endpoint GET /api/v2/tron/chainparameters returns them.

In what order are fees paid?

The network deducts staked resources first and burns TRX last. The order differs slightly for bandwidth and energy.

Energy has no free allowance, so a contract call from an account without staked energy always burns TRX. Transactions that create a new account follow different rules. They skip the free allowance and burn 0.1 TRX if staked bandwidth does not cover them. A TRC10 token transfer can also be paid by the token issuer’s prepaid bandwidth.

A worked example: a transaction of 265 bytes needs 265 bandwidth. The size includes the signature, the protobuf framing and a 64-byte result allowance, as java-tron and the protobuf encoding rules define them. If the sender has no staked bandwidth and has already used the free 600, burning costs 265 × 1,000 sun, which is 0.265 TRX. The TRON fee guide shows how to get the byte size.

How do I read an account’s remaining resources?

Query the node’s wallet/getaccountresource endpoint and subtract used from limit. The resource model document gives these formulas. Absent fields count as 0.

Remaining free bandwidth   = freeNetLimit - freeNetUsed
Remaining staked bandwidth = NetLimit - NetUsed
Remaining energy           = EnergyLimit - EnergyUsed

Resources recover over 24 hours after use. A wallet that sends a few transfers per day can therefore stay inside its free bandwidth, while any contract call needs staked or delegated energy to avoid burning TRX. Check the balance before each batch of sends instead of assuming the previous state.

What is fee_limit?

The fee_limit is the maximum amount of TRX, in sun, that a contract call may burn. It protects you from unexpectedly high energy use. The resource model document describes it as a value between 0 and 15,000,000,000 sun, which is 15,000 TRX. The upper bound is itself a network parameter. The Chaingateway chain parameters response lists it as getMaxFeeLimit.

The document walks through an estimate. A contract needed about 20,000 energy at most. At 100 sun per unit, that is 2,000,000 sun, or 2 TRX. If the contract’s developer has committed to covering 90 percent of the energy, the caller’s share is 200,000 sun, and that is the fee_limit to set.

To get the energy estimate, call the node’s estimateenergy method before you send the call. The node must run with vm.estimateEnergy=true.

What does a failed transaction cost?

The cost of a failed contract call depends on how it failed. If the contract stops with a REVERT, you pay only for the instructions that ran before it. If it crashes because of a bug or a timeout, the network deducts all the energy allowed for the transaction. That total includes your staked energy, the developer’s share and burned TRX up to the fee_limit.

This is why a low fee_limit is not just a spending cap. If the limit is below what the call needs, the execution fails, and the energy used so far is not refunded.

Why does the energy cost of a contract change?

Popular contracts can cost more energy because of the dynamic energy model. The resource model document describes it as a balancing mechanism. If a contract’s base energy use exceeds a threshold within a maintenance period, calls to it cost more in the next period. The current maintenance period is 6 hours.

Each contract has an energy_factor, which starts at 0. The energy a call costs is the base energy multiplied by 1 + energy_factor. On mainnet, the document lists an increase_factor of 0.2 and a max_factor of 3.4. A contract at the maximum therefore costs 4.4 times its base energy. The factor decreases again when the contract’s usage falls to or below the threshold. You can read a contract’s current factor with the getcontractinfo node call.

For payments, this means that an energy estimate from last week can be too low today. Estimate before each send, or add a margin to the fee_limit. For a USDT example and the recipient-dependent difference in energy, see the TRON fee guide.