Rented energy does not have to go to the wallet that paid for it. On TronSave you set a receiver address, and the delegation lands there — which is how exchanges cover hot wallets, payroll services cover payout addresses, and agencies cover client wallets from one account. But two kinds of address are rejected outright, and one of them surprises almost everyone: you cannot delegate energy to a smart contract.
The receiver is just a field
Every buy order has a target address for the resources. Leave it as your own wallet and the energy comes to you; paste someone else’s and it goes to them. You pay, they get the energy, and nothing about the transaction requires their involvement or permission.
That is the mechanism behind most of the volume on the platform. A withdrawal pipeline rents energy to the hot wallet that will sign the transfers. A service covering customers rents to each customer’s address. None of it needs the receiver to hold an account, sign anything, or know TronSave exists.
The interface validates the address live as you type, showing a green check when it can receive, and an X with the reason when it cannot. There is a QR scanner next to the field for when you are working from a phone or a printed address.
Two addresses that get rejected
| State | What it means | Fix |
|---|---|---|
| Not activated on-chain | The address exists as a string but has never been activated as a TRON account. | Activate it — see below. |
| Contract address | The address belongs to a smart contract, which cannot receive a delegation. | Use the wallet that will call the contract. |
| Invalid address | Not a valid TRON address at all. | Check for a truncated or mistyped paste. |
Why an unactivated address cannot receive energy
A TRON address is not an account until something activates it. Until then there is no account record on-chain to attach delegated resources to, so the delegation has nowhere to land. This is the single most common failure when someone bulk-loads a list of freshly generated addresses — they look like valid addresses because they are, but none of them exist yet as accounts.
The Bulk Buy tool handles this directly: it flags inactive rows and offers an Activate Addresses action that activates the selected wallets for roughly 1.1 TRX each. Budget for that line item when you are onboarding a batch of new addresses — for a thousand fresh wallets it is a real number, and it is separate from the energy itself. Our guide to activating a TRON wallet covers what activation is and why TRON charges for it.
Why a contract address cannot receive energy
This is the one that trips up developers, because the instinct is reasonable: my contract is expensive to call, so my contract needs energy. TronSave rejects it plainly — contract address, cannot receive delegation — and the field’s own tooltip says the target “cannot be a contract address.”
The resolution is a shift in where you think the cost lands. Energy for a contract call is consumed from the account that signs and sends the transaction, not from the contract being called. So when your service calls a contract, rent the energy to the wallet doing the calling. The contract never needs any.
Put concretely: to send USDT you rent to the sending wallet, not to the USDT contract. To call your own dApp you rent to each user’s wallet, or to whichever hot wallet signs on their behalf. If you find yourself wanting to fund a contract with energy, the address you actually want is one step upstream. See what a smart contract call costs in energy for sizing that amount.
Buying for many receivers at once
One receiver per order works fine until you have fifty. Bulk Buy takes a pasted list or a CSV and applies one amount and duration across every address, with per-address status so you can see exactly which succeeded.
It also does the validation work up front, sorting your list into the same categories above plus duplicates — so a list with a repeated address, a contract, and three unactivated wallets tells you that before you pay rather than after. Clean the list, activate what needs activating, then buy.
Multisig and paying from elsewhere
Two related distinctions are worth separating, because they are easy to conflate:
- Who receives the energy — the receiver address, covered above.
- Who pays — either your prepaid internal balance, which deducts TRX instantly with no gas, or an on-chain payment from your connected wallet.
The on-chain payment path supports multisig, and there is a dedicated field for a multisign account address. That matters for treasuries and exchanges where no single key can move funds: the payment can require its usual co-signatures while the energy still lands on whichever operational wallet needs it.
If you are ordering through the API, the same separation appears as distinct parameters for the receiver and the requesting account, so a backend service can place orders on behalf of addresses it does not control. The SDKs expose both.
A short checklist before a batch
- Confirm every receiver is a wallet, not a contract.
- Check for unactivated addresses and activate them (~1.1 TRX each).
- De-duplicate the list — paying twice for one address is silent waste.
- Decide the payment source: internal balance for speed, on-chain if multisig is required.
- Size the energy per receiver, not per order.
FAQ
Can I buy TRON energy for someone else’s wallet?
Yes. Set their address as the receiver. They do not need a TronSave account and do not have to approve anything — the delegation simply arrives.
Why does my receiver address show a red X?
Three possibilities: the account is not activated on-chain, the address belongs to a smart contract, or it is not a valid TRON address. Hovering the marker tells you which.
My contract needs energy. Where do I send it?
To the wallet that signs the call. Energy is consumed from the calling account, so the contract itself never holds a delegation.
How much does activating an address cost?
Roughly 1.1 TRX per wallet through the Bulk Buy activation action. It is a one-time cost per address and separate from the energy you rent.
Can I pay from a multisig wallet?
Yes — the on-chain payment path supports multisign, with a field for the multisign account address. The receiver of the energy is set independently.
Does the receiver keep the energy permanently?
No. Rented energy is delegated for the duration you chose and returns to the provider afterwards. Anything unused is simply not consumed.
Bottom line
The receiver field is what makes TronSave work for anyone operating more than one wallet — you fund the addresses that do the signing, from one account, in one order. Just remember the two rules the interface enforces: the receiver must be an activated account, and it must be a wallet rather than a contract. Both failures are visible before you pay, provided you look at the marker next to the address.
Covering more than one wallet? Paste your list into Bulk Buy on TronSave — it validates every address and flags contracts, duplicates and inactive accounts before you pay.
TronSave publishes this blog and operates the marketplace described here. The ~1.1 TRX activation cost and the receiver validation rules reflect the product at the time of writing and can change. This is not financial advice.
