Tronscan

Tronscan: Bandwidth and Energy Choices for TRX Staking

Tronscan lets you stake TRX for Bandwidth or Energy through its Stake 2.0 resource tools. Bandwidth covers transaction size; Energy covers smart contract execution. A basic TRX transfer consumes Bandwidth, while a TRC-20 transfer also consumes Energy. Choose the resource that addresses your account's actual shortfall. Staking can reduce the TRX burned for resource charges, although available capacity and contract budgets still affect execution. The choice also commits TRX that won't remain immediately spendable.

Last updated 13 Oct, 2026

Usable resources include recovered and delegated capacity, so an account's total stake alone doesn't determine the next transaction's resource shortfall.

Staked TRX, Transaction Bytes, and Contract Execution

Bandwidth and Energy cover different costs within a TRON smart contract transaction, while a Stake 2.0 stake allocates TRX to one selected resource. Each allocation contributes capacity for its particular cost. The transaction's type determines whether contract computation adds an Energy requirement to its Bandwidth requirement.

Bandwidth for Transaction Size

On-chain transactions consume Bandwidth according to their byte size. An account can obtain capacity from its free Bandwidth quota, staking, or resource delegation. For standard Bandwidth payments, the network first tries staked or delegated capacity, then free quota. Each pool must cover the full requirement; if neither can, TRX is burned for the entire Bandwidth charge. Free quota use also requires enough capacity in the shared network quota. Direct TRX transfers to unactivated addresses follow separate account-creation charging rules and cannot use free Bandwidth. The free quota and the network's total staked Bandwidth allocation come from chain parameters, so neither establishes a permanent number of free transfers. Transactions of different sizes consume different amounts.

Energy for Contract Computation

Energy meters the computation that smart contracts perform. TRC-20 transfers and token approvals invoke contract methods, which adds an execution cost to the transaction's byte cost. Energy has no free quota. Staked or delegated Energy can meet that cost; otherwise, the network can burn TRX within the applicable transaction budget. Choosing Energy therefore addresses contract work, even when the intended action appears as a token transfer.

Allocation and Immediately Usable Capacity

Stake 2.0 allocates Bandwidth or Energy according to your share of all TRX staked for that resource across the network. Resource capacity grows with that share. A fixed TRX stake doesn't establish a permanent resource output, because the total stake for the same resource can change.

Bandwidth and Energy have separate allocation pools. Dividing a stake between them supplies both kinds of capacity, with each portion contributing to its respective pool. The same TRX amount doesn't represent comparable quantities of Bandwidth and Energy: they meter different things and have different network totals.

Staked Bandwidth and Energy recover gradually over a 24-hour window after consumption.

Allocated capacity and immediately usable capacity differ whenever an account has consumed resources that haven't recovered yet. Repeated contract calls can exhaust available Energy before recovery finishes. That can trigger further TRX burning even though the stake hasn't changed. Current consumption and recovery therefore matter alongside the allocation that staking supplies.

The Resource Selection in Stake 2.0

The Stake 2.0 resource selector specifies whether a staking transaction allocates TRX to Bandwidth or Energy; the connected wallet handles authorization for the selected account. The resource portfolio appears under Resources, and Get Energy opens the Energy staking form. Account permissions govern who can authorize staking. A successful, confirmed stake establishes the allocation. A wallet connection or signature alone doesn't establish that the transaction succeeded.

Contract Budgets and TRX Burning

The caller's Energy budget combines usable Energy with TRX that can burn for Energy, subject to the caller's configured fee_limit . Staking changes the resource capacity available to meet execution costs. The transaction's budget imposes a separate constraint.

The Caller-Side Energy Limit

TRON converts the fee_limit amount in sun into a caller-side Energy budget. That budget constrains staked Energy and Energy funded by burning TRX. Enough liquid TRX alone doesn't ensure that a contract call can complete. A contract's deployer can cover part of a call's Energy, subject to its configured share, per-call limit, and available staked or delegated Energy. The caller covers the remainder, so its requirement can differ from the transaction's total Energy use. Transaction details distinguish caller consumption, contract owner consumption, and total consumption. A failed call can still consume resources that the network used to validate and execute it.

Consumption and Monetary Charges

Transaction details report resource consumption separately from fees. Bandwidth usage records bytes, while the Bandwidth and Energy fee fields record charges in sun. One TRX equals 1 000 000 sun. Resource usage alone therefore doesn't establish the amount of TRX burned. Comparing the usage and fee fields for the same transaction connects the staking choice to its monetary effect, while preserving the units of each field.

TRON Power Alongside the Resource Choice

Mainnet's current resource model grants one TRON Power (TP) per TRX staked for either Bandwidth or Energy. That ratio concerns voting weight. It doesn't describe the quantity of either transaction resource that the account receives. Choosing Energy supplies the same TP per staked TRX as choosing Bandwidth under this model.

Staking supplies voting rights. Voting for Super Representatives is the separate action that uses those rights to earn voting rewards.

The link between resource staking and TP applies while getAllowNewResourceModel remains disabled. If that parameter enables the new model, new Bandwidth or Energy stakes no longer grant TP. New voting power then requires separate staking with the TRON_POWER resource type. Resource selection and voting-power acquisition would consequently become separate staking decisions.

Delegation, Reclamation, and Resource Ownership

Delegation lets an account share unused staked Bandwidth or Energy with another externally owned account, separating the account that commits TRX from the account that uses the capacity. Received resources contribute to the recipient's available capacity.

Capacity at a Different Address

Energy delegated by another account can cover contract costs without an Energy stake owned by the receiving account. Delegated Bandwidth can cover transaction-size costs. These allocations change the recipient's resource shortfall, so a comparison based only on its own staked TRX can overlook capacity that already supports its transactions. A corresponding portion of the delegator's stake backs the delegation. The receiving address gets resource capacity, while the TRX remains staked in the delegating account.

Locks and Reclaimed Capacity

Reclamation becomes available when a delegation isn't locked or its configured lock period has expired. The duration belongs to that delegation's settings, so a single lock duration doesn't describe every delegation. A locked allocation limits when the delegator can regain its capacity and release the TRX that backs it.

Reclaiming resources returns their capacity after on-chain confirmation. It doesn't necessarily make all that capacity immediately usable. The protocol retains usage accounting, and consumed resources recover over time. Reclamation changes the account that holds the capacity without resetting all prior consumption.

Unstaking and Available TRX

Stake 2.0 keeps unstaked TRX pending until the selected network's waiting period ends, after which withdrawal moves matured amounts into the spendable balance. Starting an unstake doesn't release liquid TRX immediately. Partial unstaking is supported, so an account can release part of its stake while retaining the remainder.

View full-size image

Mainnet's waiting period is currently 14 days. The getUnfreezeDelayDays chain parameter controls that period, and governance can change it. Testnets can use different delays. TRX that backs delegated resources must first be undelegated before unstaking. If a lock prevents reclamation, that lock also postpones when the backing TRX can enter the unstaking process.

Withdrawing matured TRX doesn't always require a separate transaction. Initiating a new unstake also withdraws earlier amounts that have already cleared the pending period. On Mainnet, cancelling all pending unstakes re-stakes those amounts; the same cancellation transaction withdraws any matured amounts instead. Staking keeps the committed TRX unavailable for spending until withdrawal, with the waiting time changing if the selected network changes its delay parameter.