Guide

How to Check a TRON Energy Delegation and Its Lock Period

By: TronBid Team3 min read3

Verify the delegation transaction, resource type, receiving address and lock expiry. Distinguish a rental payment from delivered usable Energy.

A locked green Energy bridge connects a staking vault to a TRON wallet while TRX remains in the vault.

To confirm that Energy was delegated, inspect the resource operation and the recipient's current account state. A successful rental payment alone does not prove delivery. The payment, delegation, resource usage and eventual return are separate records.

Find the delegation transaction

Open the rental or marketplace order and look for the resource transaction ID. Do not use the incoming payment TXID as proof of delegation. The operation should describe resource delegation, not merely a TRX transfer or USDT contract call.

Use the transaction inspection guide to verify the record in TRONSCAN. If the service has not yet provided a resource transaction, check the order status before assuming the resources are available.

Match owner, recipient and resource

Check the resource owner, receiving address and whether the operation concerns ENERGY or BANDWIDTH. The receiving address should match the account intended to use that resource.

For a standard USDT transfer, Energy normally belongs at the sending address, not the token recipient. A delegation to a different account may be valid on-chain but still fail to solve your own transfer's shortage.

Understand the amount shown on-chain

TRON delegation transactions express the delegated balance in stake-equivalent SUN, not directly as the number of Energy units shown in a rental package. The network's stake-to-resource relationship determines the associated resource capacity.

Do not compare a transaction's raw balance with the package's Energy figure as though they were the same unit. TRON's delegation documentation describes the balance and resource fields. Use the service's delivered amount and the account resource state alongside the raw transaction.

Read the lock correctly

The lock flag and lock period govern when resources may be reclaimed. A lock period in the transaction is measured in blocks, not seconds. An omitted period with locking enabled must not be interpreted as zero duration.

For an illustration based on approximately three-second blocks, 300 blocks is about 15 minutes. This is a unit conversion, not a promise that every rental uses that lock. Check the actual record and displayed expiry. A later delegation to the same recipient can affect an existing lock.

Separate lock expiry from resource return

Reaching the end of a lock makes reclamation possible under the relevant rules; it does not by itself prove that an undelegation transaction has already occurred. The service's rental term and return process should be checked separately.

Used resource recovery is another distinct concept. The 24-hour recovery guide explains why a locked delegation can remain active while the recipient has already consumed much of its available Energy.

Check what the recipient can use now

Refresh the exact receiving account and inspect available resources after delivery. Concurrent transfers can reduce the remaining amount, so the current balance may be lower than the original package.

If the owner, recipient or resource type does not match, save the order number and TXID for support. If they match but a USDT transfer still fails, use the Energy failure checklist rather than assuming another identical rental is the answer. For cost planning before the next order, see the rental-cost guide.

Frequently Asked Questions

No. Check the delegation operation and the target account's current resource state separately.

The transaction balance is expressed as stake-equivalent SUN, while the package displays resource units. They are different quantities.

No. Expiry and actual reclamation are separate facts. Check current delegation state and any return transaction.