On Ethereum, paying for a transaction is one question: how much gas, at what price. On TRON it is two questions, answered in a fixed order, and the answer is often “nothing.” A transaction draws on two distinct resources — Bandwidth and Energy — each with its own priority ladder of where to pull from, and only when those run dry does the sender burn TRX. Where the cost lands is itself a signal.
This article is about the consumption side: how a transaction is actually paid for once it is submitted, and what that cost — or its absence — tells an investigator. How those resources are obtained by staking is a separate subject, covered in /learn/stake-2/.
Two resources, drawn in order
The most common mistake is to assume a transaction spends its free allowance first. It does not. For Bandwidth, TRON checks the staked pool first, the free allowance second, and burns TRX only as a last resort. TRON’s own documentation is explicit: “if the transaction initiator’s Bandwidth obtained by staking TRX is sufficient, this part of Bandwidth is used for consumption. Otherwise, the free Bandwidth of the transaction initiator is then compared with the transaction consumption. If sufficient, the free Bandwidth is consumed instead. If neither of them is sufficient for the transaction, TRX will be burned.” The reference implementation states the same order as a numbered priority: “1. Staked Bandwidth 2. Free Bandwidth 3. TRX Burning.”
Energy has only two rungs, because there is no free Energy. “First, the Energy obtained by staking TRX will be consumed. If this part of Energy is not enough, the account’s TRX will continue to be burned.”
| Resource | Priority order |
|---|---|
| Bandwidth | Staked → Free (600/day) → Burn TRX |
| Energy | Staked → Burn TRX |
Each rung is all-or-nothing within its pool: a transaction does not top up from free Bandwidth to cover a shortfall in staked Bandwidth — if the staked pool cannot cover the whole transaction, the check moves to the free pool, and so on down. This ordering is why a heavy staker pays zero, a casual user with a small daily allowance pays zero for light activity, and only a wallet that has exhausted both ends up burning TRX.
What sets the cost in the first place
Before the priority ladder decides how a cost is paid, the transaction’s shape decides how much it is.
Bandwidth is byte size. “One byte requires one unit of Bandwidth, so the Bandwidth amount that a transaction needs to consume is equal to the number of transaction bytes.” A transaction’s Bandwidth cost is its serialized size — raw_data, signatures, and result. A bare TRX transfer is small; a contract call carrying ABI-encoded parameters is larger; a multi-signature transaction carrying several signatures is larger still.
Energy is computation. Energy “measures the amount of computation required by the TRON Virtual Machine,” and only smart-contract execution consumes it — the metering is covered in /learn/smart-contracts-and-the-tvm/. A TRX or TRC-10 transfer runs no code and consumes no Energy.
The consequence is that a single contract call is paying down two ladders at once: Bandwidth for its bytes and Energy for its execution, each drawn from its own pool by its own priority order. The two resources are independent — a wallet can have ample Bandwidth and no Energy, and a USDT transfer will sail through on Bandwidth while burning TRX to cover the Energy it lacks.
Falling through to burning TRX
When both staked and free Bandwidth are exhausted, “TRX will be burned to pay for the Bandwidth consumption of the transaction based on the unit price of 0.001 TRX per Bandwidth.” When staked Energy runs out, TRX burns at the Energy unit price — 100 sun (0.0001 TRX) per unit as of June 2026.
Neither rate is a constant. Both are governance parameters with histories. The Bandwidth burn rate of 0.001 TRX was set by TIP-286, which “changed [it] from 0.00014 TRX to 0.001 TRX.” The Energy price has its own change history — proposals such as TIP-483 have moved it by network vote — and the full timestamped series is queryable on-chain through the GetEnergyPrices endpoint. The price in effect is whatever governance last set it to.
[!NOTE] The often-cited “0.1 TRX” figure is not a general per-transaction fee. Per TIP-286, it is specifically the Bandwidth cost of an account-creation transaction when the creator has no Bandwidth — layered on top of the separate 1 TRX creation fee, for 1.1 TRX in total. The general Bandwidth burn rate is 0.001 TRX per unit. Activation economics are their own subject — see /learn/account-activation/.
Because cost is derived from byte size and a per-unit price rather than a live auction, a transaction’s burned-TRX cost can be reconstructed from first principles: its size in bytes, times the rate in effect at its timestamp. Quoting a single “a transfer costs about X TRX” figure is less useful than knowing the formula, because the true cost depends on the transaction’s exact size and the parameter values of the day.
Why this is not Ethereum gas
The contrast with Ethereum is structural, not cosmetic. Ethereum bundles everything into one fee: “Gas refers to the unit that measures the amount of computational effort required to execute specific operations,” paid “in Ethereum’s native currency, ether,” priced “in gwei.” Crucially, Ethereum’s base fee floats — “every block has a base fee which acts as a reserve price,” adjusting block to block with demand, and it is burned.
TRON does three things differently. It splits cost into two non-fungible resources rather than one fungible unit. It prices them at governance-set rates that change only by vote, not at a per-block market rate. And it gives every account a free Bandwidth tier, so routine activity can be genuinely free. There is, as the companion TVM article puts it, no fluctuating gas auction — “the price is set by network governance and changes only when governance changes it.”
Reading cost on-chain
Two practical readings fall out of all this.
Historical cost is deterministic. Because TRON’s prices are governance-fixed and timestamped, the TRX a past transaction burned can be reconstructed exactly: the parameter in effect at that block was a known, published value. There is no equivalent on Ethereum, where the realized fee depended on the live auction at the moment of inclusion. On TRON, cost is a function of public parameters, not market luck.
A zero-fee transaction is not “cheap” — it is provisioned. A wallet that pays no TRX is not benefiting from low gas; it is drawing on staked, delegated, or free resources. That is an attribution signal in its own right. A wallet whose Energy is consistently covered without its own stake is being fueled by someone — the delegation relationship that /learn/fueling/ treats as an ownership signal. The absence of a fee, on TRON, is information.
Sources
- TRON Developer Hub — Resource Model — the consumption priority order for Bandwidth (staked → free → burn) and Energy (staked → burn), Bandwidth as byte size, the 600 free daily Bandwidth, and the 0.001 TRX / 100 sun burn rates.
- java-tron documentation — Resource — the numbered consumption priority confirming staked Bandwidth is drawn before free Bandwidth.
- TIP-286 — Account-creation and bandwidth fees — the governance origin of the 0.001 TRX Bandwidth burn rate and the 0.1 TRX account-creation Bandwidth cost layered on the 1 TRX creation fee.
- TIP-483 — Energy unit price adjustment — an example of the Energy price being changed by network governance, evidence the price is a mutable parameter.
- TRON Developer Hub — GetEnergyPrices — the on-chain endpoint returning the full timestamped history of the Energy unit price.
- Ethereum.org — Gas and Fees — Ethereum’s single demand-priced gas fee, denominated in gwei and paid in ETH, with a per-block base fee that is burned.