Blog · 2 November 2026

Five minutes or an hour: choosing a TRON energy lease

We sell TRON energy on two leases, 300 seconds and 3,600 seconds. Both deliver the same energy for the same transfer, and both are priced per unit of energy for the whole lease. The hour leaves that energy on the address longer. Five minutes suits software that sends on the signal, and the extra time is worth paying for when a person or a long batch stands between the energy arriving and the transfer going out.

A lease is an amount of energy and a term

An order names the transfer and, if it wants something other than the default five minutes, a duration_s. The energy follows from the transfer: about 65,000 units when the recipient already holds USDT, about 131,000 when it holds none. The lease does not change that amount. The price follows from the lease: current_price_sun is what one unit costs for the whole term, so the hour's price is the price of a unit held for an hour, with nothing to multiply by twelve.

On the hour lease, an order for one transfer buys energy for one transfer and an hour to send it in. A transfer spends the same units at minute two as at minute fifty, and spent energy barely comes back while the lease runs: an account's used energy drains back over the following day, and an hour is about a twenty-fourth of that day. How long rented energy lasts goes through that daily cycle and the other two clocks on a delegation.

The window is the lease less three seconds

Once the energy is confirmed on the sending address, the order carries send_before. On the five-minute lease that is 297 seconds after confirmation, on the hour 3,597. The three seconds are the same on every lease, and all they do is make the window close before the lease does. The network starts the lease at the block that carried the delegation, we start the window when we see that delegation confirmed, and the gap between the two is usually longer than three seconds. A transfer sent at the very end of either window can land after the energy has gone home and burn the full fee in TRX.

That gap is the same size on both leases. On five minutes it comes out of 297 seconds, on the hour out of 3,597, and the rule stays the same: send on the order.ready webhook or on the first poll that shows send_before, and keep well clear of the deadline.

A batch shares one deadline. It runs from the last delegation confirmed in the order, and it can be no later than the first successful purchase allows, since energy cannot start before it was bought. We buy at about a second a position, and positions we reach with less than thirty seconds of window left are not bought: they close failed with purchase_failed, and their reservation comes back. On the five-minute lease that cuts a large batch off at roughly its 269th transfer. On the hour, a full batch of 500 fits with most of the window to spare.

What an hour buys

The plainest use is a set of transfers you will send within the hour, though not all at once. A payout run that goes out as approvals arrive, or a queue your own code drains at its own pace, can be ordered as one batch on the hour lease. The energy for every transfer lands on the sending wallet together, and each transfer goes out when it is ready. Order only what you will send. A position whose window closes unused ends expired and is charged, because the energy was delivered and held for the whole window.

The hour also covers a send that waits on a person. In mode A you sign and broadcast the transfer yourself, and the order never sees how it was signed: a hardware wallet and a second approver both fit. Five minutes leaves little room for an approver, and an hour leaves plenty. Mode B cannot carry the second approver, because it accepts one owner signature on Permission_id 0 and refuses multisignature.

Mode B needs the hour least, even for a transaction signed well ahead of time. There you hand us a signed transfer, and we broadcast it in the same pass that marks the energy ready, so a single transfer gains nothing from a longer window. The window is also capped by the transaction's own expiry, less thirty seconds. The hour therefore helps a mode B order only when the batch takes longer than five minutes to buy and its transactions were signed to live longer than that. They can be: we accept an expiry up to 23 hours 59 minutes after the transaction reaches us. What a TRON energy API actually does walks through mode B from the request up.

An order for a volume (energy_units) above 131,000 units has to take the hour. Such a position is bought in pieces from several sellers, and each piece's lease runs from its own delegation, so on five minutes the first piece would start to expire while the last was still arriving. A shorter lease is refused with 400 invalid_request, details.reason bulk_needs_longer_lease.

What the hour cost against five minutes

Most of the market sells the hour. Of the seventeen price lists our watch read on 7 September 2026, sixteen quoted one hour. Each of our two leases has its own price, recomputed against the market, so neither is derived from the other. GET /v1/tariff/history charts one lease per request, and with range=30d it returns 720 hourly points of what we sold at. We read both series on 27 October 2026 and compared them hour by hour.

The hour lease cost more on most hours and less on some, and across the month the two came out close. The premium moved from week to week, and in one of the four weeks the hour came out cheaper. Most of that month was sold under the earlier daily schedule of prices, and one price per lease replaced it on 26 October. The last row starts at 00:00 UTC on that day, so its first hours may still carry the schedule, and two days are too few to say whether the gap will hold.

The history records what we sold at and promises nothing about the next hour. Today's prices for both leases are on the pricing page, and products[] of GET /v1/tariff returns the same figures. When TRON energy is cheapest reads the same history across the hours of the day.

Choosing a lease

Choose by the longest your send can take after the energy lands. If it is seconds, take five minutes. If it is longer, take the hour, and order only the transfers you will make inside it.

Have your code read the leases from products[] each time. Products go on and off sale without a release: the one-day lease went off sale on 25 October 2026, and an order or an estimate naming a lease that is not on sale gets 400 invalid_request, with the leases that are in details.allowed. The lease is part of the order's body, so a retry under the same idempotency key with a different duration_s is refused with 409 idempotency_conflict and creates nothing.

A wallet that sends all day fits neither lease, and nothing longer than an hour is on sale. An Auto-refill rule is built for it: you give an address and a daily budget, and the wallet is topped back up after every transfer it makes.

What we did not measure

We have not measured how long our own customers' hour-lease orders wait between delivery and the send, so nothing here says how much of the hour a typical order uses. The gap between the network's start of a lease and ours is worked out from how the window is computed, and we have not timed it on its own. The price comparison covers one month, nearly all of it under the earlier daily schedule.

Price the same batch on both leases before you pick one, with nothing reserved: POST /v1/estimate takes duration_s →