Everything about the decision to rent TRX energy is simple until you have more than one address. Then a property that is invisible at single-wallet scale becomes the dominant cost: energy lands on the address the provider delegates to, it cannot be pooled, and it cannot be split. Fifty payout wallets are fifty separate purchasing decisions, and most desks make that decision once, identically, for all of them.
That uniform decision is where the money goes. This article sets out a per-address allocation rule with a computable break-even, then prices the cost that almost nobody includes in a fleet model: bandwidth.
The short version
Allocate per address, by expected transfer count, against a hard threshold. A 30-day rental at 500 sun costs 32.5 TRX for one transfer’s worth of capacity; burning the same transfer costs 6.43 TRX. So a wallet must send at least five to six transfers inside the term for a standing rental to beat simply burning TRX. Below that, renting that address is a straight loss — and in a fleet of fifty wallets, a third of them usually sit below it.
The second finding is larger and less discussed. Bandwidth is also per address, it is not rentable, and at fleet scale it costs more than the energy markup on most wallets. For a desk running 310 transfers a day across fifty addresses, bandwidth burns about 77 TRX a day — roughly $736 a month — and that figure does not appear in any energy quote.
Why one order cannot cover a fleet
A rental is a delegation. The provider stakes TRX, the resulting energy allowance is delegated to one address, and that address spends it. Three consequences follow directly, and each one breaks a common assumption:
- Allowance is not transferable at will. Moving energy from the address that holds it to the address that needs it requires a separate on-chain delegation. It is not a database edit; it is a transaction.
- Allowance is not divisible at purchase. Buying 3.25M energy does not give you fifty 65,000 allocations unless the provider delegates fifty times, which most will not do in a single order.
- Allowance refills per address, over 24 hours. Spend it and it comes back slowly, on that address only. A wallet’s daily capacity is therefore its delegation size, not its monthly budget divided by thirty.
So when you rent TRX energy for a fleet, you are not buying a pool. You are buying N independent capacities, and the sizing question has to be answered N times. The alternative — one large delegation to a treasury, then onward delegation — is a real option, and it is covered below, but it moves the cost rather than removing it.
The threshold: five to six transfers per term
For any address where you would rent TRX energy, the comparison that decides it is standing rental versus burning, and it is arithmetic rather than judgement.
break-even transfers = (capacity × sun price) ÷ (capacity × 100 sun)
The capacity cancels, which is the useful part: the break-even depends only on the term price, not on the size of the allocation. At a 30-day price of 500 sun, break-even is 500 ÷ 100 = 5 transfers. At a 7-day price of 150 sun, it is 1.5 transfers. At an hourly price of 50 sun, it is half a transfer — meaning a single hourly rental always beats burning, which is why one-off senders should never hold a standing balance at all.
| Term | Listed price | Cost of one 65,000 allocation | Break-even vs burning | Use it when the address sends… |
|---|---|---|---|---|
| 1 hour | 50 sun | 3.25 TRX | 0.5 transfers | any single transfer |
| 1 day | 65 sun | 4.23 TRX | 0.66 transfers | 1–2 transfers in 24h |
| 7 days | 150 sun | 9.75 TRX | 1.5 transfers | 2–5 transfers a week |
| 30 days | 500 sun | 32.50 TRX | 5.05 transfers | 6 or more a month |
That table is the allocation rule. Sort your addresses by monthly transfer count, then assign each one the shortest term whose break-even it clears. Wallets under six transfers a month should not be on a 30-day rental; wallets doing twenty a day should not be on hourly orders.
The failure this prevents is not exotic. A desk that rents 65,000 energy for thirty days on all fifty addresses pays 1,625 TRX a month and delivers, at best, fifty transfers a day from it. If eighteen of those wallets send fewer than six transfers a month, roughly 585 TRX a month is spent on capacity that expires unused — about 36% of the bill, for nothing.
The opposite error is just as common and more damaging: fifty identical allocations means the twelve busy wallets are also capped at one transfer a day, so their extra transfers burn TRX at 6.43 each. Uniform allocation is wrong at both ends simultaneously, which is why it survives — the errors partially offset in the total and the invoice looks plausible.
Two architectures, and when each wins
Architecture A: per-address rental. Each wallet gets its own delegation, sized to its own burst — the default way to rent TRX energy. Simple to operate, easy to attribute cost, and no on-chain delegation steps. It wins when wallet volumes are roughly equal and stable.
Architecture B: treasury stake plus delegation. Stake once from a treasury address, then delegate energy outward to the signing addresses as needed, re-delegating as volumes shift. Reclaiming a delegation does not require the 14-day unstaking period, because the TRX never leaves the stake — which makes this far more flexible than it sounds.
The trade is operational. Architecture B adds a delegation transaction per reallocation, each consuming bandwidth, and it centralises key risk on a treasury address that now holds both the stake and the authority to move it. It wins when wallet volumes are uneven and shifting — which, in practice, is most fleets. If you are deciding between staking and renting at all, the gating questions are in the four gates before the cost maths; this section assumes you have already cleared them.
Bandwidth: the fleet cost nobody quotes
Energy is the expensive resource, so it gets all the attention, and most desks that rent TRX energy budget for it and stop there. Bandwidth is the boring one, and at fleet scale it quietly becomes the second-largest line.
A TRC20 transfer consumes about 345 bytes. Each address receives 600 free bytes a day — roughly 1.7 transfers. Past that, bandwidth burns at 1,000 sun per byte, which is 0.345 TRX per transfer.
Now scale it. Fifty addresses, 310 transfers a day between them:
| Item | Calculation | Result |
|---|---|---|
| Bandwidth consumed | 310 transfers × 345 bytes | 106,950 bytes/day |
| Free allowance | 50 addresses × 600 bytes | 30,000 bytes/day |
| Burned | 76,950 bytes × 1,000 sun | 76.95 TRX/day |
| Monthly | × 30 | 2,309 TRX ≈ $736 |
For comparison, the energy bill for those same 310 transfers at 1.51 TRX each is about 14,000 TRX a month. Bandwidth is 16% of energy — not dominant, but far too large to leave out of a fleet model, and completely absent from every rental quote in the market.
It is also the highest-return staking decision available. Staking for bandwidth yields 1.62 bytes per TRX per day; burning those bytes costs 1,000 sun each. So each TRX staked for bandwidth avoids 1.62 × 1,000 sun = 0.00162 TRX per day, which annualises to roughly 59%. Staking for energy, by contrast, returns something closer to 8% on the same basis. Bandwidth staking is about seven times more efficient per TRX locked, and it is the one line item most desks have never looked at.
The catch is the 14-day lock, and the fact that each address needs its own bandwidth — you cannot share one address’s allowance with forty others. Stake on the signing addresses, or stake centrally and delegate bandwidth outward exactly as you would energy.
The fresh-wallet case: double energy, and it lands on your busiest wallets
A transfer to a recipient holding no USDT costs 130,285 energy instead of 64,285 — 2.03×. New wallets are therefore the most expensive transfers in the fleet, and they cluster: onboarding campaigns, new counterparties, first payouts.
Two implications for allocation. First, when you rent TRX energy per address, capacity sized on the standard number is half the real requirement during an onboarding push, which is exactly when a missed transfer is most visible. Second, because the multiplier is per transfer and not per address, a wallet doing five new-recipient transfers needs 5 × 130,285 = 651,425 energy capacity, not 5 × 64,285.
A workable compromise: size standing rental for your funded-recipient base, and hold a burn reserve for new-recipient traffic, since that arrival pattern is bursty and unpredictable per address. The reserve sizing logic is in the parameter reference sheet, updated with current values.
What the fleet needs that a single wallet does not
Four things, and each of them assumes you rent TRX energy per wallet rather than in bulk. A bulk buyer has none of these problems and none of these controls.
- An address registry with intended capacity per address. Without it, you cannot detect drift, and drift is the normal state of a fleet — volumes move between wallets and nobody re-sizes.
- Per-address monitoring on the resource panel. Order pages report intent. A wallet with a green order and empty resources will fail its next transfer, and in a fleet of fifty you will not notice until a counterparty does.
- Separate owner and active keys per signing address. One compromised hot wallet should not imply a compromised fleet; the permission structure that makes this true is the subject of the signing rule that prevents most losses.
- A re-sizing cadence. Monthly, against actual transfer counts. The break-even table above is only useful if someone re-runs it; the cost of a fleet is that yesterday’s correct allocation is next quarter’s overpayment.
The rule, compressed
Energy is per address, so the rule for how to rent TRX energy across a fleet is per-address by construction. Count each wallet’s transfers for the coming term and assign the shortest term whose break-even it clears — one transfer clears an hour, two clear a day, six clear a month. Anything below the threshold is cheaper burned. Then add 0.345 TRX per transfer for bandwidth past the free allowance, and treat bandwidth staking as a separate decision with a much better return than energy staking.
Run that once and the fleet stops being a single purchasing decision — and the question stops being whether to rent TRX energy at all. It becomes fifty small ones with a rule behind them — which is the only form in which it can be managed at all.
All figures dated 2026-11-09, priced at 100 sun per energy unit, 1,000 sun per byte, and TRX near $0.319. The allocation logic does not depend on those values, but every break-even in the tables does, so reprice them before you rent TRX energy on a new term. Both sun-denominated parameters are set by network governance and have changed before; re-verify them before reusing any of this arithmetic. For the full purchasing sequence around a rental, start with the guide to renting TRX energy, and for the ordering checks that prevent the avoidable failures, the 12-point pre-flight checklist.