TRON Resource Delegation Under the Hood: How It Actually Works

The Resource Model Before You Can Understand Delegation

TRON doesn't charge gas in the Ethereum sense. Instead, every account has two resource pools: energy and bandwidth. Energy is consumed by smart contract execution. Bandwidth is consumed by every transaction, whether or not it touches a contract. When your account runs out of either, the network burns TRX from your balance to cover the deficit. That burn is what makes things expensive.

Resources are generated in two ways. First, by staking TRX: lock TRX and the network credits your account with a proportional share of the global energy or bandwidth pool, refreshed every 24 hours. Second, by receiving a delegation: another account stakes TRX and assigns the resulting resources to your address. Your account uses the delegated resources exactly as if you had staked yourself. From the VM's perspective, there's no distinction.

This is the foundation everything else sits on. Delegation is not a payment channel or a wrapper. It's a direct assignment of on-chain resource entitlements from one account to another.

What Stake 2.0 Changed About Delegation

The original staking model (Stake 1.0) required you to choose at stake time whether your TRX would produce energy or bandwidth, and you could only unfreeze the full amount at once after a 3-day lock. Delegation existed, but it was blunt. You staked TRX, it generated one resource type, and you optionally pointed that resource at another address.

Stake 2.0, activated on the mainnet in mid-2023, restructured this significantly. The key changes relevant to delegation:

• Proportional resource splitting: A single staked TRX position can have its generated resources split and delegated to multiple addresses simultaneously. You're not sending TRX anywhere, you're routing the resource output.
• Unstaking in tranches: You can unstake partial amounts without touching the rest of the staked position. This lets resource providers manage liquidity without disrupting active delegations.
• 14-day unstaking delay: After calling unstake, the TRX enters a withdrawal queue. It's locked for approximately 14 days before you can call withdrawExpireUnfreeze to reclaim it. During that window, any delegation that relied on that TRX is cancelled immediately, not after 14 days. The delegation ends when you initiate the unstake, not when you receive the TRX.
• No more resource type switching lock: In 1.0, switching from energy to bandwidth required a full unstake and re-stake cycle. In 2.0, you can re-delegate the resource output of the same staked position to a different resource type without unstaking, though this still requires a separate on-chain transaction.

The practical implication for anyone receiving delegated energy: your resource balance can drop to zero mid-day if the delegator initiates an unstake. There's no grace period at the receiving end.

The On-Chain Mechanics of a Delegation Transaction

When a delegator calls delegateResource, the transaction records three things: the delegator's address, the receiver's address, and the amount of energy (or bandwidth) being delegated. The network then adjusts the resource limits shown in the receiver's account state accordingly.

Internally, TRON nodes track delegated resources separately from self-owned resources. If you query an account via wallet/getaccount on the HTTP API, you'll see fields like delegated_frozenV2_balance_for_energy and acquired_delegated_frozenV2_balance_for_energy. The first is what you've sent out. The second is what you've received. Neither moves TRX. The actual TRX stays in the delegator's staked balance.

Resource consumption during a transaction works like this: the VM checks the executing account's available energy (self-staked plus received delegations). If sufficient, it deducts from that pool in order: received delegations are consumed first, then self-staked. If the pool is exhausted, TRX is burned from the account's free balance at the current network rate. The rate isn't fixed. It's calculated dynamically based on total network energy and the current burn price set by on-chain parameters.

How Energy Recovers After Use

Energy isn't a one-time credit. Used energy recovers linearly over a 24-hour window. If your account has a maximum energy limit of 100,000 and you use 65,000 executing a contract, you'll be back to full after 24 hours. At the halfway point (12 hours), you'll have approximately 32,500 available again.

This recovery applies to both self-staked and delegated energy. The recovery rate is tied to the account's maximum, not to some fixed global clock. So two accounts with different energy limits recover at different absolute rates, even though both refill completely in 24 hours.

For high-frequency operations, this 24-hour cycle is the binding constraint. A single delegation sized for one transfer per day won't cover ten transfers per day, even if the total energy looks sufficient on paper. You need to account for recovery cadence, not just total capacity.

Revoking and Reassigning Delegations

Delegation is not permanent. A delegator can call unDelegateResource at any time to pull resources back. The effect is immediate: the receiver's available energy drops by the revoked amount on the next block. There's no cooldown on the receiver's side and no compensation mechanism at the protocol level.

Reassigning a delegation, sending the same resource output to a different receiver, requires two transactions: revoke from the current receiver, then delegate to the new one. These are separate on-chain operations and consume bandwidth themselves. In Stake 2.0 you can batch these more efficiently than before, but they're still not atomic from a single transaction standpoint.

One edge case worth knowing: if a delegator's staked TRX generates, say, 200,000 energy, and they've delegated 150,000 to address A, they can delegate the remaining 50,000 to address B without touching A's delegation. The constraint is that total delegated energy cannot exceed total generated energy. Trying to over-delegate will fail at the transaction level.

What This Means for Rented Energy

Energy rental services like tronenergyrent.com operate entirely within this delegation model. When you rent energy, the provider stakes TRX, generates energy, and calls delegateResource targeting your address. From your account's perspective, you receive acquired_delegated_frozenV2_balance_for_energy exactly as described above. You don't hold TRX. You hold a temporary resource allocation.

The rental duration corresponds to how long the provider keeps that delegation active. A 1-day rental at current prices costs 8.19 TRX per 65,000 energy (enough to cover one standard TRC-20 USDT transfer requiring ~65,000 energy and ~345 bandwidth). A 30-day rental runs 175.50 TRX for the same energy block. You can check exact costs for your specific transfer volume with the calculator.

The reason short-duration rentals cost more per day is purely mechanical: the provider has to manage the unstaking queue and re-delegation overhead for frequent cycles. The 14-day withdrawal delay means capital is tied up regardless of how short the rental is.

Bandwidth Delegation Follows the Same Model

Everything described above applies equally to bandwidth, with one difference in default behavior. Every account gets 600 free bandwidth per day from the network, regardless of staking. This free allocation covers basic TRX transfers but won't cover the bandwidth portion of high-frequency TRC-20 transfers. Staking or receiving delegated bandwidth increases your limit above that 600 baseline.

When you delegate bandwidth to an account, you're adding to their capacity on top of any free allocation they already have. The consumption order is: free bandwidth first, then delegated bandwidth, then self-staked bandwidth, then TRX burn. This ordering matters if you're trying to calculate exactly when burn will kick in for a given account.

Reading Delegation State from the API

If you're building tooling or monitoring a delegation, the relevant API calls are:

• wallet/getaccount: returns full account state including delegated and received resource fields
• wallet/getdelegatedresourcev2: returns the specific delegation record between two addresses, including the exact energy amount and lock expiration if any lock was set
• wallet/getcanwithdrawunfreezeamount: lets a delegator check how much of their queued unstake is already withdrawable

The getdelegatedresourcev2 endpoint is particularly useful for verifying that a delegation is active and sized correctly before executing transactions that depend on it. Don't assume a delegation is in place because it was set up yesterday. Always confirm on-chain state before relying on it.