Two meters, two bills
| Energy | Bandwidth | |
|---|---|---|
| Pays for | Executing smart contract code | The size of the transaction in bytes |
| Needed by | USDT and every other TRC-20 transfer, swaps, approvals | Every transaction without exception |
| Free allowance | None | 600 points per account per day |
| Burn rate if short | Set by getEnergyFee, ~0.0001 TRX per unit | 0.001 TRX per point |
| Typical USDT transfer | ~64,285, or ~130,285 to a first-time holder | ~345 |
| How to obtain it | Stake TRX, rent it, or let the network burn your TRX | Same three routes, but the daily allowance usually suffices |
Energy: the cost of computation
Energy meters work done by the TRON Virtual Machine. Every opcode a contract executes has a price, and the total is what your transaction consumes.
This is why a USDT transfer is expensive and a TRX transfer is not. Moving TRX is a native balance update the protocol handles directly. Moving USDT means asking a contract to update its own ledger, and you pay for every step of that.
- There is no free Energy allowance. An address that has never staked or rented has zero.
- Energy is a pool belonging to the address, not a reservation attached to a transaction. Anything you sign draws from the same pool.
- Staked and delegated Energy regenerates over roughly 24 hours after use.
Bandwidth: the cost of space
Bandwidth meters bytes. A transaction that serialises to 345 bytes needs 345 Bandwidth, regardless of what it does — a contract call and a plain transfer are billed the same way for size.
Every account gets 600 free Bandwidth every day, which resets on a rolling basis. That covers one TRC-20 transfer comfortably and two not at all, which is why the second transfer of the day is often the one that surprises people.
Bandwidth is cheap in absolute terms — about 0.345 TRX for a transfer if you have to burn for it. It causes trouble not because of the cost but because a wallet holding rented Energy and zero TRX has no way to pay it.
Why one cannot substitute for the other
They are separate meters with separate accounting, and the network checks both. Holding 650,000 Energy does not buy you a single byte of Bandwidth, and a full daily Bandwidth allowance does not execute one line of contract code.
- Plenty of Energy, no Bandwidth and no TRX — the transaction is rejected before it executes.
- Plenty of Bandwidth, no Energy and no TRX — the contract call fails with OUT_OF_ENERGY and the fee is still taken.
- Both short, some TRX — it goes through, and you pay the network's own conversion rate for both, which is the most expensive way to transact.
Worked examples
| Transaction | Energy | Bandwidth | Notes |
|---|---|---|---|
| Send TRX | 0 | ~270 | Free allowance covers it |
| Send USDT to an existing holder | ~64,285 | ~345 | First one of the day is free on Bandwidth |
| Send USDT to a first-time holder | ~130,285 | ~345 | New storage slot doubles the Energy |
| Approve a contract to spend USDT | ~15,000–30,000 | ~350 | Varies with the contract |
| Send to an unactivated address | As above | ~100 | Plus a 1 TRX account creation fee |
How to get each one
The three routes to Energy are not equally available for Bandwidth, and that asymmetry is worth knowing before you plan around it.
| Route | Energy | Bandwidth |
|---|---|---|
| Do nothing | Network burns TRX at the getEnergyFee rate | 600 free points a day, then TRX is burned |
| Stake TRX | Grants Energy in proportion to your stake, regenerating daily | Grants Bandwidth the same way, but the free tier usually makes it unnecessary |
| Rent | The usual choice: large, predictable, worth optimising | Possible, and mostly worth it for high-frequency senders |
In practice almost everyone optimises Energy and ignores Bandwidth, because Energy is the bill that is two orders of magnitude larger. Bandwidth only becomes interesting when you send many transactions per day from one address and the free allowance stops covering them.
Reading your own resources
Both meters are visible on-chain, so you never have to guess what an address holds.
- In TronScan, open the address and look at the Resources panel. It shows Energy and Bandwidth as available over total, and it distinguishes what you own from what has been delegated to you.
- Programmatically, call getaccountresource on any node. It returns EnergyLimit and EnergyUsed, plus freeNetLimit, freeNetUsed, NetLimit and NetUsed. Available Energy is EnergyLimit minus EnergyUsed; available Bandwidth is the free and staked allowances minus their used counters.
- Before a batch, check both numbers rather than one. A wallet that passes the Energy check and fails the Bandwidth check produces exactly the same interruption.
Delegated resources show up in the same panel as your own, so an address can look well funded a minute before a rental expires and empty a minute after. If timing matters, read the numbers immediately before you sign.
How to size both
- Work out Energy from the recipient, not the amount. Existing USDT holder: budget around 65,000. Unknown or first-time recipient: budget around 131,000.
- Assume one free transfer per day on Bandwidth. Beyond that, keep TRX to cover roughly 0.35 TRX per transfer.
- Keep a working float of 5 to 10 TRX in any address that sends regularly. It covers Bandwidth, account activation and rounding, and it removes a whole class of failure.
- For anything automated, simulate each call with triggerconstantcontract and size from the energy_used it returns rather than a constant.
The rule that survives contact with reality: rent or stake for Energy because it is the large, predictable cost, and keep a little TRX for Bandwidth because it is the small, easily forgotten one.