TRON Stake 2.0: staking, delegating and reclaiming energy

Energy on TRON comes from staked TRX. Under Stake 2.0 an address stakes TRX for energy, and can delegate the energy that stake produces to another address and reclaim it later; the receiver spends it as if it were its own. This page is the reference for those calls — what they take, what they refuse, and what the chain does not do for you.

The four calls

Call	What it does	Key arguments
`freezeBalanceV2`	Stakes TRX for energy (or bandwidth). Usable from the next block	`amount` in SUN, `resource`
`delegateResource`	Gives the energy of part of your stake to another address	`amount` in SUN, `receiverAddress`, `resource`, `lock`, `lockPeriod` in blocks
`undelegateResource`	Takes a delegation back; partial amounts allowed	`amount` in SUN, `receiverAddress`, `resource`
`unfreezeBalanceV2`	Starts unstaking; the TRX is withdrawable after 14 days	`amount` in SUN, `resource`

Delegations are counted in SUN of stake, not in energy. The energy a stake produces is

EnergyLimit = staked SUN / 1,000,000 × TotalEnergyLimit / TotalEnergyWeight

and both network totals move with every block, so the same SUN buys slightly different energy over time. Delegate SUN, and read the receiver’s energy back to confirm it.

Energy recovers over 24 hours

EnergyUsed decays linearly to zero over 24 hours from the last use; there is no midnight reset. An address with an energy limit L can spend L energy per day at any pace, until its usage reaches the limit; past that a transaction either burns TRX or fails with OUT_OF_ENERGY.

Delegating

lock = false means no lock, whatever lockPeriod says.
lock = true with lockPeriod 0 or missing locks for 86,400 blocks — 3 days (one block is 3 seconds). Always pass lockPeriod explicitly.
The longest lock is 864,000 blocks — 30 days.
Delegating again to the same receiver with a lock extends it: the expiry of all locked balance of that resource between the two addresses moves to now plus the new period. A new period shorter than the time left is refused.
Locked and unlocked delegations between the same two addresses are kept apart; an unlocked one can always be reclaimed.
Energy delegated to an address cannot be delegated onward. Only an address’s own stake can be delegated.
There is no limit on the number of receivers in the protocol.

Validation errors

Message contains	Cause
`delegateBalance must be greater than or equal to 1 TRX`	Delegations start at 1 TRX of stake
`delegateBalance must be less than or equal to available FreezeEnergyV2 balance`	More than the free part of your own stake
`receiverAddress must not be the same as ownerAddress`	Delegating to yourself
`Account … does not exist`	The receiver is not activated
`Do not allow delegate resources to contract addresses`	The receiver is a contract
`The lock period of delegate resource cannot be less than 0 and cannot exceed 864000!`	`lockPeriod` out of range
`The lock period for ENERGY this time cannot be less than the remaining time`	A shorter lock over an existing one

Reclaiming

You can reclaim the unlocked part of a delegation, and the locked part once its lock has expired. A lock has no early exit: no fee buys it out. Reclaiming more than that is refused with insufficient delegateFrozenBalance.

Reclaiming also moves usage. The energy the receiver spent from your stake comes back onto your meter, up to what the reclaimed stake produces in a day and in proportion to your share of the receiver’s energy:

transferUsage = min(reclaimed SUN / 1,000,000 × TotalEnergyCurrentLimit / TotalEnergyWeight,
                    receiver.energyUsage × reclaimed SUN / receiver's total stake for energy)

So a delegation nobody used costs nothing to take back; one that was used leaves your stake recovering for up to a day.

Unstaking

unfreezeBalanceV2 starts a 14-day wait (chain parameter getUnfreezeDelayDays).
At most 32 unstakes can be pending per address; batch them.
Delegated stake cannot be unstaked until it is reclaimed.
withdrawExpireUnfreeze collects matured unstakes; cancelUnfreezeBalanceV2 cancels all pending ones and stakes them again at once.

Reading the state

Most TronWeb read helpers default to { confirmed: true }, which asks the solidity node — about a minute behind the head of the chain (54 seconds when we measured). For anything that decides the next delegation, pass { confirmed: false }.

Read	Returns
`getAccountResources(address)`	`EnergyLimit`, `EnergyUsed`, `NetLimit`, `NetUsed`, the network totals
`getCanDelegatedMaxSize(address, 'ENERGY')`	SUN that can be delegated now, net of your own usage
`getDelegatedResourceV2(from, to)`	The delegations between two addresses, locked and unlocked, with expiry
`getDelegatedResourceAccountIndexV2(address)`	Every address delegated to or from
`getAvailableUnfreezeCount(address)`	Unstake slots left of 32

What TRON does not do

No automatic reclaim. A delegation stays until its owner sends undelegateResource; the proposal to add one (TIP-632) is a draft.
No nonce. Two transactions from one address can land in either order.
A duplicate broadcast is harmless. A transaction’s id is the hash of its contents, so sending the same signed bytes twice is refused as dup trans, not executed twice.

Sources: TIP-467 (Stake 2.0), TIP-542 (resource delegation lock period), java-tron DelegateResourceActuator, UnDelegateResourceActuator and UnfreezeBalanceV2Actuator, TronWeb TransactionBuilder. Checked 2026-09-11 and 2026-10-01.