Energy vs bandwidth on TRON
TRON meters two resources rather than charging one fee, and a payout desk meets them in wildly unequal proportions. Energy vs bandwidth is not a choice between two ways of paying — every transaction spends some of both. It is worth knowing which of them you will run out of, because only one is ever the reason a USDT transfer costs 6.5 TRX.
What each one meters
Bandwidth is charged for the transaction itself: its size in bytes, once it is signed and broadcast. Energy is charged for what the transaction makes the network compute — the instructions of a smart contract, executed on every node that validates it. A plain TRX transfer moves a number between two accounts and runs no contract code, so it spends bandwidth and no energy at all. A USDT transfer is a call into the USDT contract, so it spends both, and it is not close to even (the two meters, in more detail).
The split is not about size. A transaction can be long and compute almost nothing, or short and compute a great deal. Bytes are one meter and instructions are another, and neither is a proxy for the other.
What one USDT transfer takes of each
Energy: about 65,000 units when the recipient already holds USDT, about 131,000 when the address has never held it and the transfer has to create its token account first (why there are two figures).
Bandwidth: a few hundred points. The one real USDT transfer we sent and measured on mainnet on 2 September 2026 spent 345 points against 130,285 units of energy, on one receipt. What is worth noticing is the scale rather than the exact figure: the same transaction is metered in the tens of thousands on one meter and in the hundreds on the other.
The free daily allowance, and why energy has none
Every account gets some bandwidth for nothing, every day. The chain parameter that sets it, getFreeNetLimit, read 600 points on mainnet on 7 September 2026, and the same 600 stood in a live account record we captured on 2 September. Against a transaction of a few hundred points that is roughly one contract call a day covered, with the second one already paying.
Energy has no such grant. There is no free daily energy for an account at any volume — the only ways to have any are to stake for it or to be delegated some, and an account with neither pays for every unit of every transfer it sends. That single asymmetry is most of what separates the two meters in practice.
What the network charges when each runs out
Neither shortfall stops the transaction. Both are taken out of the sender's TRX at a protocol rate, and the transfer confirms as if nothing had happened — which is exactly why the cost is so often noticed late.
Energy burns at 100 sun per unit. At about 65,000 units that is the familiar 6.5 TRX, and 13.1 TRX when the recipient has never held USDT.
Bandwidth burns at ten times that rate for each point — one point of bandwidth costs what ten units of energy cost, on the parameters we read on 7 September 2026. That sounds worse than it is until the quantities go in: at 345 points the burn comes to 0.345 TRX, against 13.1 TRX for the energy of that same transfer. Ten times the rate, under a thirty-eighth of the bill, because the meter reads three hundred on one side and a hundred and thirty thousand on the other.
Which one a payout desk actually runs out of
Energy, every time. Ten transfers a day is 650,000 units of energy to find from somewhere, and a few thousand points of bandwidth, of which the free allowance covers the day's first transaction and nothing after it — the grant is spent whole per transaction, not point by point. Scale that to a few hundred transfers and the bandwidth side is still arithmetic on hundreds of points per transaction while the energy side is arithmetic on hundreds of thousands of units. A desk that has solved energy has solved its resource problem; a desk that has solved bandwidth has solved a rounding item.
That asymmetry is why the rental market that exists is an energy market.
How you get more of either
On paper the mechanisms are symmetric. You can stake TRX for energy or stake TRX for bandwidth — the same freeze, pointed at a different meter. An account that has staked can delegate either resource to another account for a period, and delegating hands over the resource and nothing else: no keys, no approvals, no access to funds.
In practice the market is one-sided. Energy is rented by the minute by a whole industry. Bandwidth is barely rented at all: the largest on-chain rental contract we have measured has its bandwidth side switched off, a flag we read on 2 September 2026, and our own market feed quotes no bandwidth products either — a rate per point of bandwidth is not a cheap energy price, however alike the two look in a column (what the feed does quote).
| Energy | Bandwidth | |
|---|---|---|
| Meters | contract computation | transaction size in bytes |
| A USDT transfer takes | about 65,000 units, or 131,000 to a new recipient | a few hundred points |
| Free daily allowance | none, at any volume | 600 points an account |
| When it runs out | TRX burned per unit | TRX burned per point, ten times the rate |
| Staking gives it | yes | yes |
| Can be delegated | yes | yes |
| Rented on a market | by the minute | barely at all |
What an order delivers, and what it leaves alone
An order here delivers energy, and that is the whole of it: energy on the sending wallet, for a window long enough to send inside (what a transfer costs right now). Nothing in it touches bandwidth, and nothing needs to — the free points cover the day's first transaction, and after that the network takes its few hundred points out of TRX at a price that stays a rounding item beside the energy it sits next to.
The one place that free allowance is load-bearing is the wallet holding no TRX at all. Energy delegated to it covers the contract call, and the free daily bandwidth covers the bytes, so the transfer goes out of an empty account — for the first transaction of the day. The second one needs a little TRX in the account for the bytes, and no amount of energy will stand in for it (the rest of that arrangement).