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

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

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 }.

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.