What a delegation actually transfers
Under TRON's Stake 2.0 mechanism, an address that has staked TRX can delegate the resulting Energy or Bandwidth to another address. The staked TRX never moves. What is delegated is the right to consume a resource, and nothing else.
- The provider does not receive your keys, and delegation grants no authority over your balances.
- There is no approval, no allowance and no signature from you involved — a delegation is made by the provider on their own side.
- You continue to build, sign and broadcast your own transactions. The provider is not a party to them.
- When the term expires the delegation is withdrawn automatically. Nothing of yours is touched at any point.
This is a structural property of the protocol, not a promise from a company. There is no version of resource delegation that can move tokens out of the receiving address.
Verifying it in TronScan
Do not take anyone's word for what landed on your address, including ours. Check it.
- Open your address in TronScan and go to the Resources panel. Delegated Energy is listed separately from Energy you own, with the amount and the address it came from.
- Open the delegation transaction itself. The contract type reads DelegateResourceContract, and the only fields are the resource, the amount, the receiver and the lock period.
- Confirm the receiver is your address, character for character, and that the amount matches what you paid for.
- Note the expiry. A delegation that has lapsed looks identical to one that never arrived, and the difference matters when a transfer fails.
If you want to be thorough, check your token balances before and after. They will not have changed, because a delegation contract has no mechanism to change them.
The real risks, which are different
Renting is structurally safe. That does not make every provider worth using, and the genuine risks are commercial rather than cryptographic.
| Risk | What it looks like | How to limit it |
|---|---|---|
| Paying and receiving nothing | The payment lands, the delegation never does | Use a provider that shows on-chain confirmation per order; start with a small order |
| Delegation expires before you send | You paid for an hour, you signed ninety minutes later | Broadcast promptly; re-check resources immediately before signing |
| Paying from an exchange | Resources land on the exchange's address, not yours | Pay from a wallet you control, or specify the receiver explicitly |
| Typing the address wrong | Resources go to a stranger and cannot be recalled | Copy and paste, then verify the last six characters |
Notice that none of these involve anyone gaining access to your funds. They are ways of losing the money you paid for the rental, which is a much smaller and more recoverable category of problem.
Red flags
One rule filters out essentially every scam in this space:
- Anyone who asks for your seed phrase or private key is stealing from you. Delegation requires neither, so there is no legitimate reason to ask.
- Anyone who asks you to “connect” a wallet and sign an approval for a resource rental is not renting you a resource. Delegation needs no signature from the receiver.
- Anyone who asks you to send USDT to “verify” or “unlock” an address is running a well-known scam.
- A provider that cannot show you the on-chain delegation for an order has nothing to show you.
The correct amount of information to give a resource provider is a TRON address. That is the entire list.
What to check before your first larger order
- Place the smallest order the provider offers and follow it through to the on-chain delegation.
- Confirm the price you were quoted is the price you were charged.
- Check that the rental duration matches what was advertised, by reading the expiry on-chain rather than in the interface.
- Send one real transfer using the delegated Energy and confirm it succeeded before scaling up.
Four steps, one small payment, and the question is settled with evidence instead of trust.