How to rent TRON energy safely
A rental needs one thing from you: the address the energy should land on. Search for how to rent TRON energy safely and you get two kinds of page — sellers, and warnings about sellers — and neither settles it, because the useful test is not whether a seller looks trustworthy but what the transaction actually requires. Everything else a seller asks for is asking for something other than energy.
What a real rental asks for: an address
Energy moves by delegation, and a delegation is signed by the account holding the staked TRX, not by the account receiving the energy. The receiving side is passive: the network raises its energy limit and that is the whole of the event (how energy works). So the complete list of what a legitimate seller needs from you is the address the energy should land on.
Nothing to sign. No wallet connection. No token approval. No seed phrase. No "activation" payment to unlock the delivery. The one requirement on the address itself is that it exists on chain: energy cannot be delegated to an account that has never been activated, which in our API is a refusal — 422 invalid_address with details.reason set to inactive_wallet — rather than a charge for a delivery that could not have happened.
What the delegation looks like from your side
Delivery does not have to be taken on trust. TRON records a delegation against the receiving account as well as against the delegator's — the field names still carry the V2 of the staking model that introduced it — so the buyer can read the result without asking the seller anything.
Two fields say it, and each comes from its own call. acquired_delegated_frozenV2_balance_for_energy, which getaccount returns, is the staked sun delegated to your account; and on a wallet that has staked nothing of its own, the EnergyLimit of getaccountresource is what that comes to in energy — the acquired amount times the network's own ratio of total energy limit to total staked weight. Where the wallet stakes too, the delegated part is the rise in EnergyLimit rather than the whole of it. The sun is what a delegation fixes; the energy is not, because that ratio moves with the whole network's stake, block by block.
Read against a mainnet receiver on 3 September 2026, the arithmetic came out to the unit: energy acquired from two delegators, and an EnergyLimit of 299,638. The same record carried no tronPowerLimit at all — a receiver gains no voting weight from a delegation, which is one more way of saying that what crosses is energy and nothing else.
The term is in the same place. getdelegatedresourcev2 shows a locked delegation with an expire_time_for_energy on its row; without a lock there is no such key, and the delegator can take the energy back with one call. An energy vendor's pool read on 4 September 2026 showed exactly that — a live delegation with no expiry on the row, and the node building an undelegate transaction against it on request. Not dishonesty: a different good, and the record is the only place that says which of the two you bought.
The red flags, and what each one is after
- "Connect your wallet." A delegation needs no connection and no session: the delegator signs it alone, and your account appears in it as a string. What a connect flow actually buys the other side is the ability to put a transaction in front of you for signature, and the two worth putting there are a transfer and an approval.
- "Approve USDT so the energy can be delivered." An approval is a call on the token contract granting a spender the right to move your USDT, up to the allowance you set and for as long as it stands. It has no part in a delegation whatsoever — energy arrives on an account that has never signed anything. This is not a warning sign near the scam; it is the scam.
- "Send TRX to this address and get free energy." A payment with no order behind it: no identifier to quote, no record of what was bought, nobody holding an obligation. A rental has an order that either delivered or did not, and an undelivered one gives the money back without being asked.
- A bot that wants a private key or a seed phrase — to "verify", "activate" or "link" the wallet. No step of any rental has a place for one. Whoever holds the key holds the funds, and that is the end of the conversation.
- A seller that wants the transfer routed through it. "Send us the USDT and we forward it once the energy lands" is custody, not energy. Handing a transfer over is a real arrangement — it is mode B here — but what is handed over is a transaction you signed yourself, naming the recipient and the amount, which cannot be altered by a byte without breaking the signature.
What to check after paying
Two facts, both readable from the chain rather than from the seller. First the energy: the receiving account's energy limit either rose or it did not, and that delivery is the entire thing being sold. Second the term, which is how long it stays. A delegation without a lock is revocable at any moment; a locked one cannot even be shortened by the delegator, and the network refuses the attempt by naming the milliseconds still to run.
Ours is a short lease deliberately: the order carries send_before, 297 seconds from the last confirmed delegation, and an estimate echoes back the lease it priced as duration_s. A short window is what makes energy cheap enough to rent by the transfer at all.
What a seller can promise, and what it cannot
An honest seller promises the delivery of energy. It cannot promise that your transfer will succeed, because the reasons a USDT transfer fails are properties of the addresses rather than of the energy: a recipient frozen in the token contract, a sender that does not hold what it is trying to move, a contract that reverts (what a payout desk actually meets).
Our statuses are written to keep the two apart. completed means the energy was delivered, and in mode A it can arrive before you have sent anything. expired means it was delivered, held for the whole window and not used — charged, because it was delivered. failed means it was not delivered through our fault, and then nothing is charged. Which of those releases money is the whole of the refund policy, and a seller unwilling to state the same split in advance is worth one more question before money moves.
Prepaid credits, and what a failed delivery does
Money here is prepaid service credits, denominated in TRX. Creating an order reserves the price; the charge lands when the energy is visible on chain, not when a supplier says it was sent. A delivery that fails releases the reservation in full, automatically, with no ticket to open, and a mixed batch settles line by line as partially_completed — charged for the positions that arrived, released for the rest (how that reads on an invoice).
Questions we actually get
Can a delegation drain the wallet it lands on?
No — and you do not have to take that on trust: the receiving account gains acquired_delegated_frozenV2_balance_for_energy and grants nothing back, which is the whole of what the record shows.
Do I need TRX on the wallet to receive energy?
No, and a delegation does not touch the balance in either direction. The wallet does have to exist on chain: an address that has never been activated is not an account yet, and there is nothing to delegate to.
How do I tell whether a quoted price is real?
Read it from an endpoint rather than from a page written months ago. Ours is on the pricing page, live at every load; the market page shows what the vendors we watch publish for themselves, each reading stamped with the moment it was taken. A price nobody can fetch is a claim rather than a quote (more of what integrators ask).