The origin tracer is paused. The library is open and still growing.What’s paused, and when it returns

← All articles

What a Transaction Actually Costs

Part ofWho 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.

ONE TRANSACTION — CHARGED, SETTLED, READ ON-CHAIN Transaction SUBMITTED Bandwidth CHARGE = BYTE SIZE Energy TVM COMPUTATION ONLY [ EACH FROM ITS OWN POOL ] Resource pools STAKED · ZERO FEE FREE: BANDWIDTH ONLY [ EXHAUSTED ] Burn TRX LAST RESORT KEY [ RECORDED ON-CHAIN ] Cost on-chain BYTES × RATE OF THE DAY NO AUCTION — PUBLIC PARAMETERS SET THE PRICE
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 — staked Bandwidth, then free Bandwidth, then 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.”

CONSUMPTION PRIORITY — CHECKED IN THIS ORDER BANDWIDTH · BYTE SIZE ENERGY · COMPUTATION Staked Bandwidth CHECKED FIRST [ SHORT ] Free Bandwidth 600 / DAY · CHECKED SECOND [ EXHAUSTED ] Staked Energy CHECKED FIRST [ NO FREE RUNG — STRAIGHT TO BURN ] Burn TRX BANDWIDTH · 0.001 TRX / UNIT ENERGY · 100 SUN / UNIT KEY BOTH LADDERS END AT THE SAME LAST RESORT — RATES SET BY GOVERNANCE, NOT AUCTION
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.

ONE CALL — TWO METERS RUNNING AT ONCE Contract call E.G. USDT TRANSFER SERIALIZED BYTES TVM COMPUTATION Bandwidth pool PAYS FOR THE BYTES Energy pool PAYS FOR EXECUTION [ INDEPENDENT POOLS — AMPLE BANDWIDTH CAN SIT BESIDE EMPTY ENERGY ] NEITHER CHARGE OUTRANKS THE OTHER
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. For Bandwidth, TIP-286, a July 2021 proposal, recommended that the unit price “needs to be changed from 0.00014 TRX to 0.001 TRX”; the thread was closed on 26 July 2021 with the note that its voting request was “already approved on Tron Mainnet”, and the on-chain record of that vote (proposal 67) carries the approved value — 1,000 sun, the 0.001 TRX the Developer Hub documents as the burn rate. 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.

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 TVM chapter explains, there is 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

  • TRON Developer Hub — Resource Model — Bandwidth as the byte size of a transaction and the 600 free daily Bandwidth. TRON has since moved the consumption priority order and the burn rates off this page; the live page that now carries them and the archived revision this chapter quotes are both cited below.
  • TRON Developer Hub — Paying for resources & Energy sharing — the live home of the charging order for Bandwidth (staked → free → burn) and Energy (staked → burn), and of the 0.001 TRX / 100 sun burn rates.
  • TRON Developer Hub — Resource Model, archived 2025-06-20 — the revision carrying the Bandwidth and Energy consumption paragraphs, the byte-size rule and the 0.001 TRX burn rate in the wording quoted in the body.
  • java-tron documentation — Resource — the numbered consumption priority confirming staked Bandwidth is drawn before free Bandwidth.
  • TIP-286 — Account-creation and bandwidth fees — the July 2021 proposal that the Bandwidth unit price “needs to be changed from 0.00014 TRX to 0.001 TRX”, and the source of the 0.1 TRX account-creation Bandwidth cost layered on the 1 TRX creation fee. The live page serves the issue body to an automated fetch but renders its comment thread client-side, so the closing comment quoted in the body is cited from the archived revision below.
  • TIP-286 — Account-creation and bandwidth fees, archived 2022-11-17 — the revision carrying the comment thread, including the closing comment of 26 July 2021: “This issue will be closed as the voting request of this proposal is already approved on Tron Mainnet.”
  • TronGrid — wallet/getproposalbyid?id=67 — the on-chain record of the vote that comment points to (Tronscan proposal 67): state APPROVED, parameter 3 (the Bandwidth unit price) set to 1000 sun and parameter 7 (the system-contract account-creation fee) to 1000000 sun, created 23 July 2021 (queried 27 September 2026).
  • 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.