Batching TRC-20 Payouts on TRON: What One Transaction Can Carry Before It Fails

If you run TRC-20 payouts at volume, one question comes up every time: how many transfers can a single transaction actually hold? The estimates circulating online are often a long way from what the chain really does, and acting on them is an easy way to end up with a reverted batch.

On current TRON mainnet parameters, one smart contract transaction can use about 150 million energy. At the energy a USDT transfer really consumes, that is roughly 2,333 transfers when every recipient already holds USDT, and roughly 1,151 when their balances are zero.

That is the theoretical answer to the question in the title. What sets the number is not how many transactions fit into a block; it is how much energy one transaction is allowed to use. Both figures are estimates, though. The batch contract needs energy of its own, execution time is capped, so the real count usually comes in lower. Guides that quote higher numbers get there by pricing each transfer at base energy and leaving out the dynamic energy penalty.

When you pay a batch, one transaction makes the call and runs your distribution contract. The contract then sends USDT to each recipient on the list, one after another. You cannot send to as many people as you like: three conditions limit the transaction at the same time, and whichever one is reached first is where the batch stops. The rest of this article covers what each limit is, which per-transfer energy figure to divide by, and where the transaction fails if you divide by the wrong one.

If the constraint you are fighting turns out to be cost rather than capacity, the same workflow viewed from that side is in how small teams cut energy costs on bulk USDT payouts.

The three limits

Limit	Current chain value	Recipients it allows
Transaction fee budget (fee_limit)	15,000 TRX, which is 150,000,000 energy at 100 SUN per energy	2,333 with a USDT balance, or 1,151 with a zero balance
Transaction size	512,000 bytes	About 8,000, at 64 bytes of calldata each
CPU time per transaction	80 ms	No recipient count. A limit you hit from contract work

The size of the call data is usually not what limits a batch. At 8,000 recipients those transfers need about 514 million energy, more than three times the per-transaction energy budget. The budget runs out well before the size limit comes into play.

The CPU time limit is the dangerous one, and failing it is expensive.

Mainnet currently caps execution at 80 ms per transaction. If your distribution contract works through too many recipients and runs past that, it can fail with OUT_OF_TIME.

What makes it worse is that the failure does not charge only the energy used. The network records the transaction’s entire energy budget as consumed, including the part the contract never reached.

Say you set a 15,000 TRX fee_limit on a batch and the transaction dies with OUT_OF_TIME. The whole energy budget can be drained, and with no staked energy available and enough TRX in the account, that can mean losing the full 15,000 TRX.

What decides how many recipients fit

Here is how we measured it: on 30 October 2026 we simulated transfers against the USDT contract on mainnet, through triggerconstantcontract on TronGrid. Every recipient fell into one of two groups.

Recipient state	Energy per transfer	Recipients inside 150,000,000 energy
USDT balance above zero	64,285	2,333
USDT balance of zero	130,285	1,151

Three factors affect how many people one transaction can pay. None of them changes the total USDT you are sending.

How much each person receives does not change the count. We sent 1 base unit, 1,000,000 and 1,000,000,000,000 to the same recipient, and it cost 64,285 energy every time. The address decides the capacity, not the size of the payment. A batch of 1,000 payouts at $5 each carries exactly as many recipients as a batch of 1,000 payouts at $5,000 each.

Priced at base energy, the count nearly doubles. 31,895 and 64,895 are the base costs from before the dynamic energy surcharge. If a transfer really did cost base energy, dividing 150,000,000 by 31,895 would cover about 4,700 recipients. It does not work out that way. The USDT contract currently carries a surcharge close to 100%, which puts the real cost at nearly twice base. So the count drops to about 2,333, not 4,700. The surcharge can keep climbing as well, up to 4.4 times base cost, and the higher it goes, the fewer recipients the same budget covers. Where that surcharge comes from, and how it is set, is broken down in how much TRON energy a USDT transfer needs and why that number doubles.

What drives the energy is whether the address holds USDT at the time of transfer, not how long it has been in use. We tested four cases: an address that already holds USDT, a brand-new address, and two addresses that have been active for years but carry a zero USDT balance. Both of the older addresses cost 130,285 energy, exactly what the new address cost. An address can be years old and still cost the higher figure if it holds no USDT today, which means one transaction can pay about 1,151 of them rather than 2,333.

So do not size a batch from whether an address is activated, and do not size it from how long the address has existed. What you need to check is whether it holds USDT when the transfer runs.

Working out a batch’s real energy use

A batch adds work per recipient that a single transfer does not have: a cross-contract call, calldata decoding, a loop index. Each one costs energy, so 150,000,000 divided by 64,285 is a ceiling, not a real number. A careless loop that re-reads storage can double the per-recipient energy and cut that count in half.

The figure to work from is what your own batch contract needs, not what a plain USDT transfer consumes. Simulate a full batch before you broadcast it. Use the wallet that will pay as the owner, your distribution contract as the target, and fill in the recipients and amounts for this particular run. Then have a TRON node estimate the call. The energy_required it returns is what this batch should consume at current chain state, with the dynamic surcharge already included.

Divide 150,000,000 by that number and you have an estimate of how many transfers of this shape one transaction can carry.

Where that energy comes from — staked TRX, rented energy, or TRX burned at the spot rate — is a cost question rather than a capacity one. What renting TRON energy costs compared with burning TRX is where we keep those numbers.

Sizing a batch in five steps

1. Group the list by USDT balance. One balanceOf call per address, batched through a node. Split it into recipients with a balance above zero and recipients at zero.
2. Add up the batch’s energy. Multiply recipients with a balance by 64,285 and recipients at zero by 130,285, then allow 10% for call overhead.
3. Compare that total to the 150,000,000 energy limit. If it is over, split the batch. No setting raises the limit; it is a chain parameter.
4. Simulate your own contract and count again. If energy_required comes back above about 90% of your planned fee_limit, cut recipients until it does not. A batch running close to the limit has no room for the overhead you did not model.
5. Cut chunks small enough that you can afford to lose one. A timeout charges whatever fee_limit you set, so the budget attached to a chunk is the most that chunk can cost you. We keep chunks at a few hundred recipients: 300 recipients with a balance is 19.3 million energy, 13% of the limit. A timeout there costs you that 13%, not the whole budget.

Step 3 is the one people guess at. If you would rather check a live wallet than a spreadsheet, how to check whether you have enough TRON energy for a transfer runs the same numbers against the wallet itself.

Where a batch fails

The first and the last of these show up while you are sizing the batch. The middle two show up at execution, after the fee is already committed.

• OUT_OF_ENERGY — the fee_limit was set below what the batch needs. Renting or staking energy does not rescue this. The chain caps your usable energy at fee_limit no matter how much energy sits in the wallet, so a batch with a 1,000 TRX budget cannot draw 2,000 TRX worth of energy.
• OUT_OF_TIME — the 80 ms CPU budget ran out. It shows up on batches of a few thousand recipients and almost never on batches of a few hundred, and it charges the whole fee_limit.
• One bad recipient reverting the batch — the contract is short of USDT, an address is blacklisted, or a single transfer is larger than what the contract holds. Without try/catch around each transfer, one failure reverts the entire batch.
• TooBigTransactionException — calldata over 512,000 bytes. You only meet this past roughly 8,000 recipients, and the fee budget stops you long before that.

OUT_OF_ENERGY is the one worth ruling out first, because nothing about it is a surprise: you can see it coming from the fee_limit you set. If you have already run into it, why a TRON transaction reverts on an insufficient fee limit works through the fix.

A worked example: 500 payouts

Say 380 recipients hold USDT and 120 are at zero.

Item	Calculation	Result
Energy, recipients with a balance	380 × 64,285	24,428,300
Energy, recipients at zero	120 × 130,285	15,634,200
Energy for the batch	—	40,062,500
Share of the 150,000,000 limit	40,062,500 / 150,000,000	27%
Calldata	500 × 64 bytes	32 KB, 6% of 512 KB

By the fee limit, all 500 fit with room to spare. By the size limit, they fit several times over. We would still send this as two batches of 250, for atomicity: one revert or one timeout takes all 500 transfers down at once, and splitting it halves the loss.

Bandwidth is the other thing that grows with recipients rather than with transactions. It is charged on the byte size of the call, so a 500-recipient batch is about 32 KB against the 600 bytes an account gets free each day. Past that the network charges 1,000 SUN per byte, which is small next to the energy, but it accumulates on the same 64 bytes per recipient that the size limit is measured in.

If the free allowance is not going to cover your batch, how TRON bandwidth works and how to get more of it goes through where the 600 bytes come from and what else raises them.

Before the next batch

• Query getEnergyFee, getMaxFeeLimit and getMaxCpuTimeOfOneTx from wallet/getchainparameters first. All three are governance parameters and all three have changed before; the 80 ms CPU budget in particular is a current value, not a constant.
• Count from balanceOf, not from account status.
• Keep chunks small enough that a total loss is survivable.
• Check the contract’s USDT balance against the batch total before you broadcast. A shortfall at recipient 480 reverts everything.

Sources

1. TRON mainnet chain parameters via wallet/getchainparameters (TronGrid), queried on 30 October 2026: getEnergyFee 100 SUN, getTransactionFee 1,000 SUN per byte, getMaxFeeLimit 15,000,000,000 SUN, getMaxCpuTimeOfOneTx 80 ms, getTotalEnergyLimit 180,000,000,000, getDynamicEnergyMaxFactor 34,000, getFreeNetLimit 600.
2. Author’s simulations via wallet/triggerconstantcontract against the USDT TRC-20 contract TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, 30 October 2026: 64,285 energy for a recipient holding USDT, 130,285 energy for a recipient with a zero balance and for a previously unused address, unchanged at amounts of 1, 1,000,000 and 1,000,000,000,000 base units.
3. Independent measurement of the same two figures, published September 2026 by a TRON fee-tracking blog, cross-checked against our own simulation.
4. TRON developer documentation, Network parameters: parameter IDs #11, #13, #47, #61 and their current mainnet values.
5. TRON developer documentation, FeeLimit and energy cost: 15,000 TRX ceiling, rejection at validation above it, and the callerEnergyLimit = min(staked energy + burnable TRX, fee_limit / energy price) formula.
6. TRON developer documentation, Paying for resources: dynamic energy parameters #72 to #75, penalty range 1× to 4.4× of base cost.
7. TRON developer documentation, Smart contracts on TRON: 80 ms per-transaction CPU budget, OUT_OF_TIME, and full consumption of the energy allowance on timeout.
8. TRON developer documentation, TRON transactions — structure and TAPOS: TRANSACTION_MAX_BYTE_SIZE 512,000 bytes, BLOCK_SIZE 2,000,000 bytes.
9. java-tron source constants (Constant.java, Parameter.java): 3,000 ms block interval, transaction size and CPU time constants.
10. TronScan Help Center, “Why did my transaction fail”: fee_limit as a transaction-level energy budget, and the full fee_limit charge on a contract timeout.

This is not investment advice, and it is not a forecast of network fees. Chain parameters and contract costs change; every figure here was taken from mainnet on 30 October 2026 and should be re-checked before you size a live batch.