Why a USDT transfer needs 65,000 energy, and 131,000 for an empty address
Ask how much energy a USDT transfer on TRON takes and every source gives the same two answers: about 65,000 units, or about 131,000 when the recipient holds no USDT. At the network's burn rate of 100 sun a unit, those are the 6.5 TRX and 13.1 TRX that wallets show as the fee. Hardly anyone says where the two numbers come from. We asked a node, and its own accounting splits each of them in two. More than three quarters of the energy is a surcharge under the network's dynamic energy model, and USDT pays it at the highest factor the network allows. The extra 66,000 for an address with no USDT is 15,000 units of extra work carrying the same surcharge.
What the node reports for one transfer
A node can run a contract call without sending it. It executes the call against its own copy of the chain and discards the result after answering, so nothing is signed or paid. On 7 September 2026 we ran four such calls, each a transfer of the smallest amount, one unit or a millionth of a USDT, from a wallet holding thousands, to four kinds of recipient: with or without USDT, with or without an account on chain. Minutes later we ran the set again on different addresses, eight calls in all.
Each answer carries the figure everyone quotes, energy_used, and a second one beside it, energy_penalty. Both runs gave the same pair for each kind of recipient:
| Recipient, 7 September 2026 | energy_used | energy_penalty | Difference |
|---|---|---|---|
| Holds USDT, account activated | 64,285 | 49,635 | 14,650 |
| Holds USDT, never activated | 64,285 | 49,635 | 14,650 |
| No USDT, account activated | 130,285 | 100,635 | 29,650 |
| No USDT, never activated | 130,285 | 100,635 | 29,650 |
Whether the recipient has an account makes no difference: an address the network has never heard of costs the same as an old one with the same balance. The balance decides, and its line sits at zero. In the second run a recipient holding a single unit of USDT, a millionth of a token, got the cheaper figure. What that means for an order is in the post on accounts that are not activated.
On 27 October 2026 we ran two of those calls again, from the same wallet to the same two addresses, one holding USDT and one empty. Both came back with the same energy_used and the same energy_penalty as in September, to the unit.
The surcharge and its parameters
The chain has a switch for what it calls dynamic energy, and each contract carries its own energy_factor. Three more network parameters go with it, and going by their names they are a usage threshold, a step by which the factor rises, and a ceiling: a contract that is used heavily pays more energy for every call. We read the parameters on 3 September 2026 and again on 27 October, when we also read USDT's own factor. The parameters had not moved between the two reads.
| Read from the chain | Value |
|---|---|
Dynamic energy switched on, getAllowDynamicEnergy | 1 |
Threshold, getDynamicEnergyThreshold | 5,000,000,000 |
Step, getDynamicEnergyIncreaseFactor | 2,000 |
Ceiling, getDynamicEnergyMaxFactor | 34,000 |
USDT's energy_factor, 27 October 2026 | 34,000 |
Burn rate in sun per unit, getEnergyFee | 100 |
USDT sits at the ceiling. On the same evening we read that factor, the transfer to a holder reported the same energy_penalty as in September, so the September figures fit a factor of 34,000 as well.
Splitting 65,000 and 131,000
Read energy_penalty as the surcharge and the rest as the call's own work, its base cost. The two kinds of transfer then differ by 15,000 units of work and 51,000 units of surcharge:
| Energy per transfer | Holds USDT | No USDT | Difference |
|---|---|---|---|
| Base cost | 14,650 | 29,650 | 15,000 |
| Surcharge | 49,635 | 100,635 | 51,000 |
| Total | 64,285 | 130,285 | 66,000 |
The arithmetic in the difference column is exact: the extra 15,000 units of work carry 51,000 units of surcharge, seventeen for every five, which is the factor of 34,000 counted in parts of ten thousand. So the 66,000 that separates the two quoted figures is one block of extra work, surcharged at USDT's factor.
The rest of the call misses that rate by a little. Seventeen fifths of 14,650 would be 49,810, and the node reported 49,635, which is 175 units lower. The empty-balance case is 175 units lower too, so the gap sits in the work both kinds share. Because 49,635 is not seventeen fifths of any whole number, the shortfall cannot be a slice of the call that escapes the surcharge, and the factor read 34,000 on the evening the same call reported the same penalty. The pattern looks like rounding, with the surcharge worked out on many small steps of the call one at a time. We did not check that against the node's code, so the table prints what the node reported and leaves the 175 unexplained.
What the extra 15,000 units of work are
A USDT balance is an entry in the token contract's own storage, kept apart from the TRON account, which is how an address without an account can hold USDT. A transfer to an address with a balance overwrites an entry that already holds a number. A transfer to a zero balance writes into an empty one. The usual explanation of the gap is that a write into an empty entry costs more than an overwrite, and 15,000 fits it. Our probes measured the cost without testing that reason, so take it as an explanation the numbers agree with.
If it holds, an address that once held USDT and has sent all of it away should cost the higher figure, because its entry is back at zero. At least one page in search results says such an address may still get the lower one. We did not plan a probe for this case, and one of the recorded ones covers it anyway. A zero-balance recipient in the first run had been picked off the USDT transfer feed as a sender: exactly one week before the probe, it sent a little over forty-four USDT. So it had held USDT and been emptied, and the transfer to it came to 130,285, the same as the address generated for the run. That is one address, read once.
From 64,285 to 65,000
The round figures sit just above the measured ones. Our service rounds up the same way: an order here is sized at 65,000 or 131,000 units for the two kinds of transfer, against measured needs of 64,285 and 130,285. That leaves 715 units of headroom either way. Rounding up is the safe side, because a transfer that runs short of energy either burns the sender's TRX for the rest or, with nothing allowed to burn, fails with the energy already spent (what that failure looks like). Burned instead of rented, the measured figures come to a little less than the round ones:
| Recipient | Measured energy | Burned at 100 sun a unit |
|---|---|---|
| Holds USDT | 64,285 units | 6.4285 TRX |
| No USDT | 130,285 units | 13.0285 TRX |
Both figures are energy alone. A transfer also spends bandwidth, a separate meter with a much smaller bill (energy and bandwidth side by side).
What would move the numbers
The first lever is the factor. It belongs to the contract, and going by the parameters' names it rises in steps with the contract's use, up to the ceiling. USDT is at the ceiling now, so from here the factor can only hold or come down, unless the ceiling itself is changed. The threshold, the step and the ceiling are network parameters, which the network's governance can change. At the ceiling, the surcharge is more than three quarters of what a USDT transfer spends. On these figures, without it the same transfer to a holder would come to its base cost of 14,650 units.
The second is the burn rate, getEnergyFee, 100 sun a unit on both days we read it. It decides what burning the energy costs in TRX, and the energy count stays the same whatever it is. The network has changed it before, and the guide to the fee shows the arithmetic at today's rate. The energy side did not move in the seven weeks between our two sets of probes: 64,285 and 130,285, both times.
Check which figure a recipient will cost before anything is signed: GET /v1/address-check in the API reference →