The most common request after a first cost model is “show me a real bill”. Fair. A formula is easy to agree with and hard to trust. So this is a full month, torn down line by line, with every input stated before the arithmetic starts.
One disclosure up front, because it matters: the company below is a model, not a named client. The volume and mix are representative of a mid-sized payout operator, the parameters are current chain values with dates, and every step is reproducible with your own numbers substituted. Treat it as a worked template for teams that buy trx energy at scale — not as a benchmark survey.
The scenario, stated exactly
| Input | Value | Basis |
|---|---|---|
| Transfers delivered per day | 5,000 | stated assumption |
| Days in month | 30 | stated assumption |
| Recipients already holding USDT | 78% | stated assumption |
| Recipients with zero USDT balance | 22% | stated assumption |
| Failed attempts (retried) | 1.8% | stated assumption |
| Energy purchased but expired unused | 6% | stated assumption |
| Energy price (burn) | 100 sun | chain parameter, current |
| Rental quote | 62 sun | model input, spot market |
| Bandwidth price | 1,000 sun per byte | chain parameter, current |
| Bytes per TRC-20 transfer | 345 | measured |
| Energy: recipient holds USDT | 64,285 | measured receipt |
| Energy: recipient balance zero | 130,285 | measured receipt |
| TRX/USD | $0.3175 | market rate, 2026-11-07 |
Nothing else is assumed. If one of these differs in your operation, every line below scales linearly except the ones that depend on mix, and those are shown separately so you can re-weight them.
Line 1 — energy for recipients that hold USDT
78% of 150,000 delivered transfers is 117,000 transfers at 64,285 energy each.
117,000 × 64,285 = 7,521,345,000 energy
This is the largest single line, and the one that decides how much TRX energy you need to buy each month.
At a 62 sun rental quote: 7,521,345,000 × 62 = 466,323,390,000 sun, or 466,323 TRX.
Line 2 — the empty-wallet tail
22% of 150,000 is 33,000 transfers at 130,285 energy, because a zero balance means the contract writes a new slot.
33,000 × 130,285 = 4,299,405,000 energy, or 266,563 TRX at 62 sun.
This is the line that surprises people. The tail is 22% of the volume and 36% of the energy cost. Any model that averages the two requirements into one number — 97,285, say — is wrong by a few percent in both directions and hides the fact that a fifth of your transfers cost twice as much as the rest.
Line 3 — bandwidth, which nobody quotes
Bandwidth is not sold by rental providers in practice, so it is burned. Each transfer is about 345 bytes, priced at 1,000 sun per byte, which is 345,000 sun or 0.345 TRX per transfer.
150,000 × 0.345 = 51,750 TRX — about 6.2% of the energy cost, invisible in every “energy only” comparison and absent from every quote you get when you buy TRX energy. The free daily allowance of 600 bandwidth per account covers a rounding error at this volume; at 5,000 transfers a day it is noise.
Line 4 — failure and retry
At a 1.8% failure rate, 150,000 delivered transfers imply about 2,700 failed attempts. A failed transfer that runs out of energy has consumed the energy it requested, so the waste is the full requirement at the blend rate.
Blended requirement: (0.78 × 64,285) + (0.22 × 130,285) = 50,142 + 28,663 = 78,805 energy per transfer.
2,700 × 78,805 = 212,773,500 energy wasted, or 13,192 TRX. Small as a percentage, but it is spend with no output — and it is the only line here that a monitoring change can eliminate without touching volume.
Line 5 — energy that expires unused
Hourly provisioning against a variable queue always leaves a residue. At 6%, the purchased quantity must be grossed up: 732,886 TRX of consumed energy implies 779,666 TRX purchased, with 46,780 TRX expiring.
This is the quietest loss in the whole teardown, because it never appears as an error. The orders succeeded, the invoices are correct, and the capacity simply ran out of time.
The total
| Line | TRX | USD | Share |
|---|---|---|---|
| Energy consumed | 732,886 | $232,691 | 86.8% |
| Energy expired unused | 46,780 | $14,853 | 5.5% |
| Bandwidth | 51,750 | $16,431 | 6.1% |
| Failed attempts | 13,192 | $4,188 | 1.6% |
| Total | 844,608 | $268,163 | 100% |
Per delivered transfer: 844,608 / 150,000 = 5.63 TRX, or $1.79.
Read as a rate, that is the answer to what it costs to buy TRX energy for a mid-sized payout operation — one number, with every assumption visible above it.
Compare with doing nothing — burning TRX for every transfer. The blend at 100 sun is 78,805 × 100 = 7,880,500 sun, or 7.88 TRX, plus 0.345 bandwidth: 8.23 TRX, about $2.61. Rental saves roughly 32% here, not the 90% that marketing pages quote, and the gap is entirely explained by three things: the rental quote, the bandwidth line nobody counts, and the 6% that expires.
The three levers that actually move it
Ranked by monthly impact at this volume, using the same assumptions:
| Lever | Change | Saving | Difficulty |
|---|---|---|---|
| Contract pricing instead of spot | 62 → 58 sun | ~50,700 TRX ($16,100) | commercial; commitment required |
| Tighten provisioning | 6% → 2% expiry | ~31,200 TRX ($9,900) | engineering; smaller, more frequent orders |
| Reduce failure rate | 1.8% → 0.6% | ~8,800 TRX ($2,800) | engineering; pre-flight energy checks |
Together they take the monthly bill from about $268,000 to roughly $239,000 — 11% — without changing volume by a single transfer. What they do not do is change the volume-driven core, which is 87% of the total and scales one for one with your payout count.
The fourth lever people reach for, once they buy TRX energy on a fixed quantity, is the empty-wallet tail — and it does not work the way it looks. Pre-funding a recipient so the next transfer costs 64,285 instead of 130,285 requires a transfer of its own, which costs the higher amount once. It only pays if the same recipient receives repeatedly. For one-off payouts, the tail is structural.
What changes under a committed contract
If you buy trx energy on a committed basis rather than spot, the model changes in two places, not one. The unit price falls — 58 sun instead of 62 in the table above — but the commitment also fixes a quantity, and any volume shortfall spreads the fixed cost across fewer transfers, raising the effective price.
Worked: a commitment sized at 100% of forecast, priced at 58 sun, delivers the 50,700 TRX saving if volume lands. At 85% of forecast, the effective price rises to about 68 sun — worse than spot. The break-even utilisation on this pricing is around 93%. That arithmetic, and the contract terms that determine it, are covered in buying TRX energy at wholesale.
Line 6 — the cost of provisioning that misses
The five lines above assume provisioning keeps up. When it does not, the cost does not disappear; it moves into the burn column at 100 sun, and the gap between 62 and 100 is the penalty for being late.
Take a modest miss: on 4% of days, the hourly order lands ten minutes late and 200 transfers go out with no energy available. Those 200 transfers pay 100 sun instead of 62 — an extra 78,805 × 38 sun = 2,994,590 sun, or 2.99 TRX each, so 599 TRX per incident day. At 4% of 30 days that is 1.2 incidents, roughly 719 TRX a month, about $228.
That number is small, and it is the wrong number to focus on. The real cost of a miss is not the price difference — it is the transfers that fail outright because the wallet had neither energy nor enough TRX to cover the burn. Those become failed payouts, support tickets, and in the worst case a client asking why a payroll run is late. A cost model can price the first effect and cannot price the second, which is why provisioning latency belongs in the engineering backlog rather than the procurement spreadsheet.
The mitigation is unglamorous: provision slightly ahead of the queue rather than in step with it, and carry a small deliberate buffer whose expiry cost you have already budgeted. A 4% buffer costs about 4% of the energy line — $9,300 a month here, which is more than the burn penalty it prevents. That comparison is uncomfortable, and the honest conclusion — for anyone who has to buy TRX energy on a schedule their clients depend on — is that the buffer is not justified by cost avoidance at all; it is justified by the fact that a late payout is not a cost, it is an incident.
Sensitivity: the five inputs that move the total
Four of the inputs in the table are assumptions, and one of them will be wrong. Here is what each does to the monthly total, holding everything else fixed:
| Input moves | Monthly total | Per transfer | Direction of risk |
|---|---|---|---|
| Base case | $268,163 | $1.79 | — |
| Empty-wallet share 22% → 35% | $295,600 | $1.97 | new-recipient growth |
| Empty-wallet share 22% → 10% | $242,900 | $1.62 | mature recipient base |
| Rental quote 62 → 78 sun | $333,100 | $2.22 | spot market tightening |
| Failure rate 1.8% → 4% | $273,700 | $1.82 | stale energy estimates |
| TRX $0.3175 → $0.40 | $337,800 | $2.25 | fiat reporting only |
Two observations. First, the recipient mix dominates every other assumption — more than the rental quote, more than the failure rate. If you only measure one thing, measure the share of transfers going to wallets that hold no USDT. Second, the TRX price line changes the reported cost but not the TRX quantity: it matters for budgeting and not at all for procurement, and teams routinely confuse the two when TRX moves.
This is also why a single “average cost per transfer” figure is dangerous as a planning input. It is a blend of a mix that shifts with your customer base, and a business adding new recipients each month will watch it rise for reasons that have nothing to do with efficiency, or with what it costs to buy TRX energy.
Why this month is not your month
The model above is deliberately generic, and it will not match your bill. Three reasons, in descending order of impact.
Your mix is different. A payroll operator paying the same 4,000 employees monthly sees almost no empty-wallet tail after the first cycle; a remittance business onboarding new recipients daily may see 40%. The difference between those two is larger than the difference between any two providers.
Your timing is different. Batched runs concentrate energy demand into short windows and require larger buffers; a continuous queue consumes nearly everything it buys. The same monthly volume can produce a 2% residue or a 12% one depending only on how the work is scheduled.
Your scale is different, and scale changes which costs are fixed. At 500 transfers a day, the operational overhead of running a rental integration exceeds the savings, and burning is rational. At 5,000 it inverts. That crossover, not the per-unit price, is the decision most teams get wrong when they first consider whether to buy trx energy at all.
Use the structure, not the totals. Replace the five assumption rows with your own measured values, re-run the arithmetic, and compare the result against the burn alternative at 100 sun. If the saving is under about 15%, the operational complexity is probably not worth it; above 30%, it is hard to justify not doing it.
Rebuilding this for your own numbers
- Count delivered transfers and failed attempts separately for one month.
- Split recipients by USDT balance at send time — an indexer query, not an estimate.
- Sum actual
energy_usedfrom the transactions rather than multiplying by a requirement. - Add bandwidth at 0.345 TRX per transfer unless your accounts hold staked bandwidth.
- Measure expiry residue: purchased quantity minus consumed quantity.
- Divide the total by delivered transfers, then compare against the burn alternative at 100 sun — that ratio is the only figure that tells you whether to buy TRX energy at all.
Step three is where most teardowns diverge from reality. The requirement figures are correct on average, but your own receipts are the only measurement of your mix — and the mix is the difference between $1.79 and $2.61 per transfer.
If the conclusion is that rental at this scale needs to be automated rather than ordered by hand, the integration requirements are set out in wiring energy into a payout pipeline. And if you are still deciding whether to buy trx energy at all rather than stake, the full model in the guide to buying TRX energy covers that comparison at the same level of detail.