Check the Tron energy for a USDT transfer before you sign

Short answer

Look up the sender and the recipient before you broadcast. If the recipient already holds USDT, have 65,000 energy ready. If their balance is zero, have 131,000. Subtract whatever the sender already has, rent the gap, and only then send. Last month's memory is how this fee surprises you.

The recipient who was cheap last time

You paid this address in September. It held USDT, the fee was the small one, and you started treating 65,000 as the answer for them. They forwarded everything last week. Today the balance is zero, your 65,000 rental is short, and the wallet burns TRX for the rest while the transfer confirms. The rental did not fail. The recipient changed, and you did not look.

The check is a dry run of that exact transfer. It tells you two things: how much energy the sending address has right now, and how much this transfer would use. If the first covers the second, send. If it does not, rent the difference, wait until the energy is actually on the address, and then send. Do it against the real recipient. A sample address tells you what a sample address costs. Do it again if time has passed. A balance can hit zero, and energy you rented this morning may have expired by afternoon. Why an empty balance costs more is a new line in the USDT contract, not a property of the address forever.

The check does not take TRX and does not move energy. The rental is a separate order after you have seen the number. People skip the check because the two round sizes feel like enough. They are enough when you know which one you are in.

What the dry run refuses to guess

The call simulates transfer of 0.000001 USDT on the USDT contract. The amount is fixed because energy does not depend on it. The sender has to be active and has to hold at least that dust. Otherwise the simulation reverts before the real cost, and a reverted energy figure is shorter than a transfer that completes, so it is not reported. You get an error you can act on: the sender has no USDT, the transfer would revert anyway, or the sender is not activated. You do not get a small integer that would cause you to under-buy.

On success you get energy on the sender, and energy_used for this pair, dynamic penalty included. The handbook completions are 64,285 when the recipient's slot exists and 130,285 when it does not. Trust the response for the order in front of you. The handbook explains it. The field is the input.

Then map the gap onto an order you are allowed to place:

• the transfer needs 64,285 and the sender has none: order 65,000. You cannot order 64,285, and the extra 715 is the slack.
• the transfer needs 64,285 and the sender already has 12,000: the gap is 52,285, and the smallest order is still 65,000.
• the transfer needs 130,285 and the sender has none: order 131,000.
• the sender already has enough: do not order.

The check returns no price. A quote prices a volume and a duration without charging. The order after that has no price of its own, and the market can move between the three calls. If the delegation has to be exactly the volume you priced, say so. Left alone, a larger pack may come back when it still costs less than burning what you requested.

The check also measures bandwidth: free_bandwidth, delegated_bandwidth, available_bandwidth and required_bandwidth (345 for a USDT transfer without a note). The two pools are not added together. If available_bandwidth is below required_bandwidth, rent the gap with POST /api/v1/bandwidth, or the network burns TRX for the bytes. How to rent bandwidth. Energy and bandwidth are separate. It will not activate the recipient. An inactive recipient is a different line on the order, and their first USDT, once the account exists, is still the empty-slot 130,285. From a payout script this same call is the first step, before the order on the energy rental API.