How long rented TRON energy actually lasts
Ask how long rented TRON energy lasts and the answers cannot all be true: it is gone the moment the transaction confirms; it comes back after an hour; it sits on the wallet for three days; it lasts until the seller decides to take it back. Each is a correct answer to a different question, because three separate clocks run over a rented delegation and only one of them is the one people mean. Here they are apart from each other. The short answer, if you only want one: as long as the delegation sits on the address — for our orders 300 seconds, with all but the last three of them to send in; for most sellers an hour. But a term is only a promise until a lock is behind it, and the lock is the clock that actually answers the question.
Three clocks
The first is commercial: the term the seller sold you, which is a number in a price list and nothing more. The second is on-chain: the lock, which is the only thing in the protocol that stops the seller taking the delegation back early. The third belongs to the resource itself: energy that has been spent recovers over the following day, whoever the account is. They are independent — a seller can sell an hour and lock nothing — and most contradictory answers on the subject are someone reporting one of the three as if it were all three.
The term the seller sold
Terms are a product decision, and the spread is wide. Of the seventeen price lists our own watch read on 7 September 2026, sixteen quoted a one-hour lease and one quoted three days. The prices behind those terms, each stamped with the moment it was read, are on the market page; the lease is the seller's own product description behind them. Ours is 300 seconds, which is short on purpose: a delegation costs nothing to create and nothing to end, so buying an hour of standing energy to spend five seconds of it is buying storage.
What that means for an order is one field. When the energy is confirmed on the sending address, the answer carries send_before: the moment the delivery window closes, three seconds under the lease. Those three seconds are arithmetic and not protection — they make the window end before the lease and nothing else. The network dates the lease from the block that carried the delegation, we date it from the moment we saw that delegation confirmed, and the two instants are a poll apart, so a transfer sent in the last seconds of the window can reach the chain after the energy has gone home and burn TRX for it. Send on the signal rather than on the deadline: send_before is the number to plan around, not the lease and not the wall clock (how a wallet sends on rented energy walks the rest of that flow).
The lock, and what a term does not do
A term in a price list is a promise; the mechanism is lock=true on the delegation. Without it the seller can undelegate at any moment — a right ordinary rental vendors keep, because reclaiming is how they resell. The rows of one mainnet vendor pool, read on 3 September 2026, carried no expiry key at all, and the next day the node built an undelegate against one of its live delegations on request — and a built undelegate is one broadcast away from home.
Where there is a lock, it is exact. The period is counted in blocks of three seconds, it defaults to 86,400 of them — three days — when it is left out, and on mainnet on 3 September 2026 the ceiling stood at 864,000 blocks, or thirty days.
It can be extended and never shortened, and while it holds there is no way out at all: a mainnet node that day refused a one-block period and a four-hour one alike — what a new lock has to clear is not the old lock's length but the time still left on it — and refused the undelegate outright, the locked balance counting for nothing; two runs on the Nile testnet on 4 September 2026 drew the same refusals against locks of our own, then had the undelegate accepted as soon as the expiry passed, at five minutes and at four hours. The post on delegation itself carries the node's answers word for word. So the honest form of the question is how long the energy cannot be taken away from you, and the answer to that one is the lock. A term with no lock behind it lasts as long as the seller's interest in leaving it alone.
The daily cycle underneath
The third clock is the protocol's own. An account's energy limit is an allowance, not a balance: spending energy does not subtract from the limit but raises a used counter against it, and that counter drains back down over the following twenty-four hours. This is where "it comes back after an hour" comes from — it is roughly what a partly spent allowance looks like on an account that staked its own TRX. For a rental it applies in one way that matters, and it is the opposite of the obvious one. The counter belongs to the wallet, not to the delegation, and it does not reset when the delegation goes home: a wallet that has just spent 65,000 units carries them against its limit for the rest of the day. A five-minute term is about a three-hundredth of that recovery day, so almost none of it drains before the next order. That is why a second rental has to clear what the first one spent rather than deliver the same amount again — and why what we read on the address before charging is available energy, limit less used, not the limit. At the other end of the market the cycle is most of what is being sold: a three-day lease on a wallet sending a handful of transfers a day is buying the recovery as much as the delegation.
"Used" is not "gone"
A transfer does not consume the delegation. Energy is spent against the limit; the delegation that raised the limit is a row between two addresses, and nobody spending touches it. It ends when the delegator undelegates, or, with a lock on it, no earlier than the expiry — so a wallet that has just burned through its whole limit still holds the delegation, and a wallet that has spent nothing holds no more of one. Which is why the end of a rental means two different things depending on who is watching: the energy was delivered when it appeared on the address, and whether it was used is a separate fact.
One path we have not measured: what the receiving wallet's own staking does to a delegation standing on it. If it unstakes or delegates onward mid-term, the actuator's code suggests there is something to find, and we have not run it.
What the end of the term looks like on an order
An item that reaches the close of its window unused ends as expired, and that is not a failure. It carries no error, because nothing went wrong: the energy was bought, delegated, confirmed on the address and held there for the whole window, and you did not send. The charge stands in mode A for exactly that reason — what is sold is delivered energy, not your act of sending — and in mode C, where a wallet is charged before any recipient is known, expired is the normal ending rather than an exception.
Mode B is the one case where a closed window is ours and not yours. There the sending is part of the service: if we have not broadcast your signed transaction by send_before, the item closes as failed with broadcast_window_missed and the whole reservation comes back. We do not broadcast late either, and that is deliberate rather than fussy — a transfer relayed after the delegation has gone would burn the TRX we were hired to save. What each of those statuses does to an invoice is on the pricing page, and the short answers are in the FAQ.
When a wallet needs energy all day
None of this is a good shape for a hot wallet. A long lease covering a day of unpredictable sending pays for the idle hours; a short one per transfer means an order per transfer. An Auto-refill rule is the third option: an address and a daily budget, after which every transfer the wallet makes is followed by a top-up back to about 131,000 energy — billed when that energy is visible on the network, not when something reports it. An idle wallet spends nothing, because it needed nothing — the day's budget is reserved rather than charged — and the term stops being something you plan around.
How to read the remaining term yourself
Nothing here has to be taken on trust, because all of it is on the chain. The delegation between the two addresses is a row of its own, and the field that answers this whole post is expire_time_for_energy — a timestamp in milliseconds on the row for that pair. An absent key means no lock, not a lock of zero length, and it is the honest reading of most retail rentals.
The expiry is stamped from the previous block's header rather than the delegation's own, which is why the post on delegation itself says to read that number and never compute it. The other half of the answer is the account itself: the energy limit that rose when the delegation arrived, and the fields that go missing — not to zero, missing — the moment it is taken back.