How the TRON energy rental market works, from one hour of mainnet data

Between 13:02 and 14:02 Stockholm time on 3 November 2026, TRON mainnet produced 1,200 blocks with 636,736 transactions. 178,526 of them (28.0%) were energy delegations or their returns. Only plain TRX transfers were more common. Of the delegations we could pair with a return inside the hour, half came back within 72 seconds.

Most of that traffic is the TRON energy rental market. Providers that stake TRX lend its energy to an address for a few seconds to a few days, and the renter pays less than the network would burn for the same energy. This guide shows what the market looks like on chain, how a rental works at the protocol level, how prices relate to the burn cost, and what can go wrong for an operator that depends on it. If you are new to energy itself, start with what TRON energy is.

What one hour of rentals looks like

We read every block from 87,677,911 to 87,679,110 with wallet/getblockbynum on the Dwellir TRON endpoint, one request at a time, and grouped the transactions by contract type.

Of the 103,857 delegations, 90,509 delegated energy and 13,348 delegated bandwidth. Every one of them succeeded. Counting bandwidth, resource delegations and returns made up 32.2% of all transactions. New stakes were rare: 71 in the hour. The market moves existing stake between addresses, over and over.

The counts cover top-level transactions only. A smart contract that delegates through the TVM, as some rental protocols do, appears as an internal transaction and is not in this table. Not every delegation is a paid rental either: a company that shares its treasury stake with its own hot wallets uses the same transaction. The size and timing patterns below show that most of the traffic behaves like per-transfer rental.

Delegations are sized for one transfer

TRON delegations move TRX stake, not energy units. At 9.7383 energy per staked TRX per day, we converted each delegation's balance into the energy it carries:

The median delegation was 13,288 TRX, which carries 129,403 energy at the ratio we measured. That is 882 energy short of a USDT transfer to an empty wallet. Covering the gap by burning costs about 0.09 TRX. Providers size delegations from the ratio at the moment they send them, and the ratio moves. The pattern is plain: most delegations carry the energy for one USDT transfer.

Most rentals last about a minute

We paired each energy delegation with the next return by the same owner to the same receiver inside the hour. 71,663 of the 90,509 delegations (79.2%) found a pair:

This pairing is a heuristic. An owner can hold several delegations to one receiver, and in 4,045 pairs the returned amount differed from the delegated one. The other 20.8% found no return inside the hour, and the one-hour window biases the figures toward short delegations. Read them as the shape of the per-transfer market, not as exact rental terms.

The receiver called the USDT contract within 20 blocks (60 seconds) of the delegation in 56,372 cases (62.3%). And the market reaches most USDT senders: 54,835 of the 65,717 addresses (83.4%) that sent a USDT transaction in the hour also received an energy delegation in the same hour.

Renters almost never burn TRX

To see whether rentals work, we read the receipts of the last 200 blocks (87,678,911 to 87,679,110, 13:52 to 14:02 Stockholm time) with wallet/gettransactioninfobyblocknum. They held 22,924 USDT transfer calls. We split them by whether the sender received an energy delegation in the same block as its transfer or in the 20 blocks before it:

The percentages are of successful transfers: 11 and 27 transfers failed in the two groups. The second group includes senders that stake their own TRX or hold longer delegations, so most of it also burned nothing. The 24.1% that burned for all their energy paid 6.43 TRX or 13.03 TRX per transfer.

Many lenders, no single gatekeeper

1,587 addresses sent energy delegations. The top 5 sent 14.7% and the top 10 sent 25.4%. 169 addresses with 100 or more delegations each sent 84.4% of all delegations, which points to automated provider accounts. The receivers were spread wide: 57,389 addresses, of which 46,420 received a single delegation.

Payment rarely moves on the same path. In only 35 cases did the receiver send TRX to the delegator in the 40 blocks before the delegation. Providers collect through platform deposit addresses, prepaid balances or API accounts, so the payment and the delegation do not link on chain.

How a rental works at the protocol level

A rental is two ordinary Stake 2.0 transactions around your own:

1. The provider has TRX staked for energy with wallet/freezebalancev2.
2. The provider calls wallet/delegateresource with your address as receiver_address, resource: ENERGY and a balance in sun. Your EnergyLimit rises at once.
3. You send your transaction. It uses the delegated energy as if you had staked it.
4. The provider calls wallet/undelegateresource and takes the stake back.

Step 4 explains the one-minute rentals. When the provider takes the stake back, java-tron moves the energy you used from your account to the provider's (UnDelegateResourceActuator.java, owner credit). That usage then recovers on the provider's account over 24 hours, and it counts against what the provider can delegate next (DelegateResourceActuator.java). A provider cannot lend the same energy twice. It can lend it, take the stake back the moment you are done, and re-lend the unused part to the next customer.

For you, the renter, the early return costs nothing. The energy you needed is already spent.

The lock decides who carries the timing risk

A delegation can set lock: true with a lock_period in blocks of 3 seconds. Until the period ends, the provider cannot take it back. The maximum is 864,000 blocks (30 days), and a lock with no period defaults to 3 days (DelegateResourceActuator.java).

In the sample, 86,843 of 90,509 energy delegations (95.9%) had no lock. The locked ones clustered at a few periods. The table lists the six largest:

An unlocked delegation protects the provider. It can reclaim the stake at any moment, including before your transaction lands. A locked delegation protects you for its period. For a payout that must not burn TRX, ask the provider for a lock that covers your signing and broadcast time. Reading EnergyLimit with wallet/getaccountresource right before you broadcast confirms the energy arrived, but only a lock keeps it there until your transaction lands.

What rented energy costs

Three numbers bound the price of energy on TRON:

• The burn price is the practical ceiling. A renter who can burn TRX has no reason to pay more than getEnergyFee: 100 sun per energy, or 6.4285 TRX for a USDT transfer to a holder. The protocol does not cap rental prices; providers set them off chain.
• The provider's capacity is the stake. A provider earns from a staked TRX only while it is lent out. JustLend DAO's rental pool reported 28.1% utilization at 14:14 Stockholm time, with 1,403,987,468 TRX delegated through it.
• The 24-hour recovery sets the unit. Energy you use is gone from the provider's capacity for up to 24 hours, however short your rental.

A worked example from on-chain rates

JustLend DAO publishes its rental rate in its EnergyRental contract at TU2MJ5Veik1LRAgjeSzEdvmDYx7mefJZvd. We read _rentalRate(0, 1) for energy with wallet/triggerconstantcontract at 14:14 Stockholm time. It returned 6,330,650,569, a rate per second scaled by 10^18:

6,330,650,569 / 10^18 x 86,400 s = 0.000547 TRX per delegated TRX per day
0.000547 TRX / 9.7383 energy     = 56.2 sun per energy per day

JustLend's public API (openapi.just.network/lend/strx) agreed within 0.3% at the same minute: priceFor10KEnergByRent 0.5632 TRX against priceFor10KEnergByBurn 1.0000 TRX, which is 10,000 energy at the 100-sun burn price.

Renting 64,285 energy means delegating 6,601 TRX. JustLend bills rent for the hours you keep it, and keeps a security deposit of one day's rent. Its rental terms deduct 0.75 days of that deposit when the energy is used up. For one transfer in a one-hour rental:

That is 55.5% below the burn price, from the contract's rate and JustLend's documented rules. It is a calculation, not a quoted order: the rate moves with pool utilization, and the order also locks a refundable liquidation reserve of at least 20 TRX (minFee).

Marketplaces that sell per-transfer energy through an API quote their own prices per order. The on-chain data cannot show those prices, because the payment does not travel with the delegation. Compare quotes against two fixed references: the burn price of 100 sun per energy, and your own cost to stake.

Stake, rent or burn for a payment operator

For an operator, the choice comes down to volume, timing and how much TRX you can lock for 14 days. At today's parameters, for USDT transfers to holders:

• Burn when volume is low or unpredictable. It needs no counterparty.
• Stake when the balance sheet already holds the TRX and volume is steady. Staked TRX keeps its voting power, and the marginal cost per transfer is 0 TRX.
• Rent when you need capacity you cannot or will not lock for 14 days. At 100,000 transfers a day, staking would take 3.6% of all TRX staked for energy today.

Most large operators combine them: a stake that covers the base load, rentals for the peaks, and a TRX balance that lets any transfer fall back to burning.

Risks when you depend on rented energy

• Early reclaim. An unlocked delegation can end before your transaction confirms. The transfer then burns TRX up to fee_limit, or fails with OUT_OF_ENERGY.
• Wrong recipient type. A rental sized for 64,285 energy fails to cover a transfer to a wallet without USDT, which needs 130,285. Size for the worst case, or estimate per transfer with wallet/estimateenergy.
• Counterparty risk. You pay before the provider delegates. Delivery time and refunds depend on the provider, not the protocol.
• Parameter changes. getEnergyFee, the USDT contract's energy_factor and TotalEnergyWeight move the burn ceiling and the value of a staked TRX. The burn price fell from 210 to 100 sun on 29 August 2025, which lowered the ceiling for every rental price.
• RPC load. Each rented transfer adds reads: wallet/getaccountresource before broadcast, and a receipt check after. Plan the request budget with the transfers.

Watch the market from your own node connection

Everything in this guide comes from standard TRON HTTP API calls: wallet/getblockbynum for delegations, wallet/getaccountresource for an address's energy, wallet/getchainparameters for the burn price and wallet/triggerconstantcontract for on-chain rates. A rental-aware payment service makes these calls on every transfer, so they belong on an endpoint with headroom.

Dwellir serves the TRON HTTP API and JSON-RPC on the TRON network page, with each method documented in the TRON docs. To size an endpoint for payment traffic, contact the Dwellir team.