Bandwidth and Energy
TRON's two metering resources — Bandwidth for transaction byte size and Energy for smart contract execution — and how to obtain each.
TRON meters on-chain operations through two system resources. Bandwidth generally covers the byte size of a transaction stored on-chain, so it scales with how big the transaction is. Energy covers smart contract execution, so it scales with how much computation a contract performs. Both can be obtained by staking TRX and recover continuously over a rolling 24-hour window. Bandwidth also has a per-account free quota; Energy does not.
Prerequisites
Quick comparison
| Aspect | Bandwidth | Energy |
|---|---|---|
| Pays for | Transaction byte size | Smart contract execution (TVM instructions) |
| Current network-wide pool for stake-based allocation | 43,200,000,000 Bandwidth | 180,000,000,000 Energy |
| Current free quota | 600 Bandwidth per account | None |
| Obtained by | Staking TRX, or receiving delegated Bandwidth from another account | Staking TRX, or receiving delegated Energy from another account |
| Recovery | Gradually over 24 hours | Gradually over 24 hours |
| When quota is insufficient | Burn 0.001 TRX per Bandwidth at the current Mainnet rate | Burn 0.0001 TRX per Energy at the current Mainnet rate, subject to fee_limit |
Bandwidth sources are not combined for a transaction. For an ordinary transaction, staked or delegated Bandwidth must cover the full byte cost; otherwise the network tries the free quota. If neither quota can cover the full transaction, TRX is burned for the entire Bandwidth cost. Energy is settled differently: available Energy can cover part of the execution and TRX is burned for the caller-side remainder. See Paying for resources & Energy sharing.
The network-wide Bandwidth and Energy amounts allocated to stakers, the per-account free Bandwidth quota, and the resource prices are chain parameters. Their corresponding keys are getTotalNetLimit, getTotalEnergyCurrentLimit, getFreeNetLimit, getTransactionFee, and getEnergyFee. Query wallet/getchainparameters for current values.
Bandwidth
Transactions submitted on-chain generally consume Bandwidth; read-only queries do not consume on-chain Bandwidth. Under the current rules, a node clears the transaction's ret field and uses the serialized Protobuf Transaction size as the base Bandwidth cost. If the contract type is not ShieldedTransferContract, the node adds a fixed 64 Bandwidth result allowance. This is a fixed allowance rather than the result's actual serialized size. Additional signatures and longer contract parameters generally increase the transaction size and therefore its Bandwidth cost.
Payment sources at a glance
The Bandwidth required by a transaction is normally paid in the following order:
- Bandwidth obtained through the account's own stake or incoming resource delegations.
- The account's free Bandwidth.
- A TRX burn.
For the conditions governing each quota, the full-coverage rule, burn rates, account-creation charges, and TRC-10 issuer sponsorship, see Paying for resources & Energy sharing.
The current getFreeNetLimit value gives each activated externally owned account up to 600 free Bandwidth. Free Bandwidth can be used only when both the account's remaining free quota and the network-wide shared free-Bandwidth quota can cover the transaction in full.
In the current protocol implementation, the network-wide shared free-Bandwidth limit, publicNetLimit, is 14,400,000,000 Bandwidth. Both the account quota and the network-wide quota recover gradually over time; if no more free Bandwidth is consumed, they recover fully after 24 hours.
Accounts can also stake TRX for Bandwidth. The current network-wide pool for stake-based allocation is 43,200,000,000 Bandwidth and is distributed in proportion to stake:
Bandwidth obtained through staking
= (TRX the account stakes for Bandwidth / total TRX staked for Bandwidth network-wide)
× 43_200_000_000Bandwidth delegated to an account by another account can also be used to pay for transactions.
Energy
Smart contract execution on TRON consumes Energy. Each TRON Virtual Machine (TVM) instruction has a fixed Energy cost, and a contract call's total Energy consumption equals the sum of those costs. Unlike Bandwidth, Energy has no free quota. The caller can cover its share with staked or delegated Energy and then the TRX-burn fallback; depending on the contract settings, the deployer may contribute staked or delegated Energy as well.
The current network-wide Energy pool for stake-based allocation is 180,000,000,000 and is distributed proportionally to stake. This value is controlled by getTotalEnergyCurrentLimit (and related adaptive-Energy parameters); query wallet/getchainparameters before relying on it:
Energy obtained
= (your TRX staked for Energy / total TRX staked for Energy network-wide)
× 180_000_000_000Staking TRX for resources
Send a FreezeBalanceV2Contract transaction to stake TRX for either resource. Build the unsigned transaction with the wallet/freezebalancev2 HTTP API:
BASE_URL=https://api.shasta.trongrid.io # example — replace with any TRON node (TronGrid, third-party, or self-hosted)
curl -X POST ${BASE_URL}/wallet/freezebalancev2 \
-H "Content-Type: application/json" \
-d '{
"owner_address": "TBRmnXKMEVfQ8XeQA2NroC9cGi77TvPbNb",
"frozen_balance": 1000000,
"resource": "BANDWIDTH",
"visible": true
}'The fields:
owner_address— the staking account, in Base58Check (visible: true) or hex.frozen_balance— amount in sun (1,000,000 sun = 1 TRX).resource—"BANDWIDTH"or"ENERGY". Set to"ENERGY"to stake for Energy instead.
The response is an unsigned transaction. Sign it with the owner's private key and broadcast via wallet/broadcasttransaction. For the end-to-end build / sign / broadcast pattern, see the Stake & Delegate Resources recipe.
Staking is reversible. To recover the underlying TRX, send UnfreezeBalanceV2Contract to begin the waiting period defined by getUnfreezeDelayDays, then WithdrawExpireUnfreezeContract to claim the unstaked TRX. For the full lifecycle, see Staking on the TRON network.
Delegating resources
An account can delegate its earned Bandwidth or Energy to another account through DelegateResourceContract. The receiving account uses the delegated resource directly without staking itself. Delegation is reversible and supports an optional lock period for added safety. CEXs and DApp operators commonly use this mechanism to absorb resource costs on behalf of their users from a single staking pool.
In practice, Energy delegation is more common than Bandwidth delegation: the current free Bandwidth quota covers many everyday transfers, while Energy has no free tier and contract calls can quickly exhaust an account's available resources.
Recovery cycle
Bandwidth and Energy usage decay over a rolling 24-hour window. If no additional resource is consumed, an amount used at one time is fully recovered after 24 hours. New consumption is combined with the unrecovered usage and recalculates the recovery schedule, so the available amount depends on the account's activity throughout the window.
Related resources
- Resource Model — Three-resource overview, including TRON Power
- Paying for resources & Energy sharing — Burn rates, charging order, deployer Energy sharing,
fee_limit, dynamic Energy - Staking on the TRON network — Stake, unstake, withdraw, delegate
wallet/getaccountresource— Query an account's Bandwidth, Energy, and TP
Updated 6 days ago