How TRON energy delegation works
TRON energy delegation is one transaction and two account fields. An address that has staked TRX for energy calls delegateResource naming a receiver, and from that block on, that receiver can spend energy it never staked for, while the staker still holds every TRX it froze. Nothing is transferred, nothing is approved on the receiving side, no key changes hands. It is the mechanism the whole energy rental market stands on, and what follows is read out of java-tron's own actuators and out of live reads of mainnet and two transactional runs on the Nile testnet on 3 and 4 September 2026.
What crosses, and what stays
The staked TRX never leaves the owner's account: delegating moves it between two buckets inside that account, out of the balance frozen for energy and into a delegated-for-energy one. TRON Power — the voting weight — is the sum of both buckets, so lending costs a staker no votes and no voting rewards. A mainnet staker read on 3 September 2026 shows it better than the source does: it was casting 3,080,000 votes while holding less than half that much undelegated, the rest lent out, and the node's own TRON Power figure for it was the two buckets added together.
The receiver gets the other half of the bargain: energy, and nothing else. The field a delegation writes on the receiving account is not a term of TRON Power, so borrowed energy carries no ballot with it — the receiver in that same read had no TRON Power figure at all, and neither did ours on Nile.
What the receiving account shows
Two numbers move. acquired_delegated_frozenV2_balance_for_energy rises by the delegated amount, and the account's energy limit rises with it — by the delegated TRX times the network's TotalEnergyLimit divided by its TotalEnergyWeight, truncated. On 3 September 2026 a mainnet receiver holding 31246 TRX of delegations from two delegators showed an energy limit of 299,638, which is that arithmetic exactly at the ratio the network carried that evening: 180,000,000,000 over 18,770,236,993.
Which is where buyers of energy are surprised: a delegation is denominated in TRX, not in energy. The denominator is the network's total staked weight, it moves every block, and a figure measured elsewhere does not travel — the same stake was worth about 7.7 times as much energy on Nile that week as on mainnet.
The lock, and the four refusals
By default a delegation can be pulled back at any moment. lock=true on the delegate call is what prevents that, and it is the only thing that does. It takes one parameter, lock_period, counted in blocks of three seconds — a field that reads like a duration and is a count, so asking for 300 of them because you wanted 300 seconds buys fifteen minutes, silently. Left at zero or omitted it means 86,400 blocks: three days. The upper bound is a chain parameter, and on mainnet on 3 September 2026 it stood at 864,000 blocks, or thirty days.
A lock can be extended and never shortened. A second delegation to the same receiver is accepted only if its period is at least the time still to run, and it then resets the expiry of the whole accumulated balance rather than just the new part — so topping up a locked delegation re-locks everything underneath it. Everything else the network refuses. These four came back from a mainnet node on 3 September 2026, aimed at a pair with a live twenty-four-hour lock; the node runs the actuator's own validation while building either call, so all four are the actuator's own answers and nothing was signed or sent:
- a one-block lock on top of the live one —
The lock period for ENERGY this time cannot be less than the remaining time[86241000ms] of the last lock period for ENERGY!, which names what is left to run, in milliseconds; - a four-hour lock on top of the same one — the identical refusal. Longer than a fresh lock is not the test; longer than what remains is;
- a lock one block past the ceiling —
The lock period of delegate resource cannot be less than 0 and cannot exceed 864000!; - the undelegate itself —
insufficient delegateFrozenBalance(Energy), request=1000000, unlock_balance=0. Not "less than you asked for": while the lock holds, locked balance counts as nothing at all.
A validated build is not a block, so the same was done with a lock of our own. Two runs on Nile on 4 September 2026 took out a lock, asked to undelegate at once, waited the lock out and asked again: refused both times with that last sentence character for character, accepted both times once the expiry had passed — at five minutes and at four hours. The long run also settled what the unit counts: between the two transactions the header clock advanced 4,801 three-second slots while the block height advanced 4,785, so sixteen slots produced no block and the lock still ran its four hours. lock_period counts slots of the block clock, not blocks that get produced.
Ending one, and seeing that it ended
The delegator calls undelegateResource, and with no lock in the way it is done in a block. Neither call carries a fee beyond bandwidth — both actuators price themselves at zero — which is why energy can be sold in units of minutes at all. Against a live lock there is no cancel and no fee that buys a way out; delegating again with lock=false is not one either, since that writes a separate row and leaves the locked one standing.
The lock is visible in exactly one place: the delegation row for the pair, where expire_time_for_energy is a timestamp in milliseconds. An absent key means no lock — what an ordinary rental vendor's delegation looks like, and the rows of one mainnet pool, read on 3 September 2026, carried no expiry key at all. Read that number rather than working it out: the actuator stamps it from the previous block's header, so a calculation from the delegation's own block is one block out, and one from the transaction's timestamp is out by a different amount every time. Both Nile runs matched the stored value to the millisecond under the first rule and neither of the others.
When a delegation ends, the receiver's two fields do not go to zero — they vanish from the answer, and the delegation row comes back empty. Anything polling an account has to treat missing as zero, or it will go on showing energy that returned to its owner minutes ago.
Why the receiving wallet signs nothing
All of this happens on the delegator's side: the receiver is named in the transaction, one field is written on its account, and there is nothing to accept, approve or connect — which is also why a delegation cannot reach what that wallet holds. Two requirements point the other way: the address has to exist as an account already, and it must not be a contract, which the actuator refuses outright. That is what makes energy rentable by API at all (what energy is, and where it comes from).
What renting builds on top
A seller of energy is an account with a stake and a delegation habit: it delegates to your sending wallet for a term, you spend the energy on a USDT transfer, and it takes the delegation back. Terms differ from seller to seller; ours is 300 seconds, because a transfer takes seconds. An order answers with send_before — the moment the delivery window closes, three seconds under that term — and that field, not the wall clock, is the one to plan around.
All of it is visible while the term runs, which is the useful part of renting on a public chain: the delegate transaction on the sending wallet, the energy limit that rose on it, and the row between the two addresses on any explorer that reads the delegation state. The energy is either on the address or it is not, and the charge is for the first of those (what that costs right now). A wallet that sends all day is the same mechanism on a schedule: an Auto-refill rule tops it back up after every transfer instead of asking you to order one.
Two things we have not measured, and both belong in the open. One is what the receiving account's own staking activity does to a delegation standing on it: if a receiver unstakes or delegates onward mid-term, the actuator's code suggests there is something to find, and we have not run it. The other is a top-up: the source and TIP-542 both say an accepted second delegation re-locks the whole balance underneath it, and we have not put one through.