← All articles

What a Transaction Actually Costs

Part of Who Controls a TRON Wallet? A Complete Guide to TRON Address Attribution

Key takeaways

  • TRON splits transaction cost into two resources — Bandwidth and Energy — each paid from its own pool in a fixed priority order; TRX only burns as a last resort.
  • The rates are governance parameters rather than a live auction, so the cost a past transaction burned can be reconstructed exactly from its byte size and the price of that day.
  • A zero-fee transaction is provisioned by someone — who paid for the resources is itself an attribution signal.

On Ethereum, paying for a transaction is one question: how much gas, at what price. On TRON it’s 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 ladder of where to pull from, and only when those run dry does the sender burn TRX.

This is the consumption side: how a transaction gets paid for once it’s submitted, and what that cost — or its absence — tells an investigator. How those resources are obtained by staking is covered separately in Stake 2.0.

SUBMIT CHARGE FALL THROUGH POOLS READ ON-CHAIN Transaction SUBMITTED Bandwidth BYTE SIZE Energy TVM ONLY Staked / Free PAID = ZERO FEE Burn TRX LAST RESORT Cost RECONSTRUCTABLE PAY SHORT EXHAUSTED
One transaction, end to end: charged, settled against its pools, then readable on-chain.

Two resources, drawn in order

A transaction doesn’t spend its free allowance first — that’s the common mistake. For Bandwidth, TRON checks the staked pool first, the free allowance second, and burns TRX only when both come up short. The docs are 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 lists the same order as a numbered priority: “1. Staked Bandwidth 2. Free Bandwidth 3. TRX Burning.”

Energy has only two rungs, because there’s 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.”

BANDWIDTH · BYTE SIZE ENERGY · COMPUTATION Staked Bandwidth CHECKED FIRST Free Bandwidth 600 / DAY Burn TRX 0.001 TRX / UNIT Staked Energy CHECKED FIRST Burn TRX 100 SUN / UNIT SHORT SHORT NO FREE RUNG
Two resources, two ladders. Energy has no free tier.

Each rung is all-or-nothing within its pool. A transaction doesn’t top up from free Bandwidth to cover a shortfall in the staked pool — if staked can’t cover the whole transaction, the check moves down to free, then to burn. That 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

The transaction’s shape decides how much it owes before the ladder decides how that gets paid.

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.” So Bandwidth cost is 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 — metering is covered in Smart Contracts and the TVM. A TRX or TRC-10 transfer runs no code and consumes no Energy.

A single contract call therefore pays down two ladders at once: Bandwidth for its bytes, Energy for its execution, each drawn from its own pool by its own order. The two are independent. A wallet can hold ample Bandwidth and no Energy, so a USDT transfer sails through on Bandwidth while burning TRX to cover the Energy it lacks.

Contract call e.g. USDT transfer SERIALIZED SIZE TVM COMPUTATION Bandwidth pool PAYS FOR BYTES Energy pool PAYS FOR EXECUTION
One contract call, two independent meters running at once.

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 0.001 TRX Bandwidth rate was set by TIP-286, which “changed [it] from 0.00014 TRX to 0.001 TRX.” The Energy price has moved by network vote too — proposals such as TIP-483 have adjusted it — and the full timestamped series is queryable on-chain through the GetEnergyPrices endpoint. Whatever governance last set is the price in effect.

[!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 Account Activation.

Because cost comes from byte size times 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. A single “a transfer costs about X TRX” figure tells you less than the formula does — the true cost depends on the transaction’s exact size and the parameter values of the day.

Why this isn’t Ethereum gas

The contrast is structural. 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.” Its 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 instead of one fungible unit. It prices them at governance-set rates that change only by vote, never at a per-block market rate. And it gives every account a free Bandwidth tier, so routine activity can be genuinely free. As the companion TVM article puts it, there’s no fluctuating gas auction — “the price is set by network governance and changes only when governance changes it.”

On TRON, cost is a function of public parameters, not market luck.

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. Ethereum has no equivalent: there the realized fee depended on the live auction at the moment of inclusion.

A zero-fee transaction is provisioned. A wallet that pays no TRX isn’t benefiting from low gas; it’s drawing on staked, delegated, or free resources, and that’s 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 treated as an ownership signal in Who Pays the Fees?. On TRON, the absence of a fee is information.

Sources