# TRON Stake 2.0: staking, delegating and reclaiming energy

Source: https://tenergy.me/docs/stake-2-delegation
Last updated: 2026-10-01

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.