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

AspectBandwidthEnergy
Pays forTransaction byte sizeSmart contract execution (TVM instructions)
Current network-wide pool for stake-based allocation43,200,000,000 Bandwidth180,000,000,000 Energy
Current free quota600 Bandwidth per accountNone
Obtained byStaking TRX, or receiving delegated Bandwidth from another accountStaking TRX, or receiving delegated Energy from another account
RecoveryGradually over 24 hoursGradually over 24 hours
When quota is insufficientBurn 0.001 TRX per Bandwidth at the current Mainnet rateBurn 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:

  1. Bandwidth obtained through the account's own stake or incoming resource delegations.
  2. The account's free Bandwidth.
  3. 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_000

Bandwidth 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_000

Staking 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