Blog · 30 October 2026

How much TRX a wallet needs to send USDT

A wallet that sends USDT on TRON has two numbers to get right, and they are easy to mistake for each other. One is the fee: what a transfer takes from the account. The other is the TRX the account has to hold, and the limit the transaction has to carry, for the transfer to go through at all. With energy on the wallet it needs TRX only for bytes: none for the day's first transfer, about 0.345 TRX for each one after it. Without energy it needs 6.5 TRX for each transfer to a recipient holding USDT and 13.1 TRX to one holding none, plus the same bytes. Either way the transaction's fee_limit has to reach the full burn. A wallet funded to the fee and short of the second number fails in a way that still costs TRX.

The node takes the smaller of two limits

Sending USDT is a call into a smart contract, and before the call runs the node decides how much energy it may spend. It computes two figures and takes the smaller. The first is what the account can pay for: the energy it already holds, plus as many units as its TRX would buy at the protocol rate of 100 sun each. The second is what the transaction allows: its fee_limit, divided by the same 100 sun.

Two rules follow. The TRX on the account has to cover whatever energy the transfer will burn, because a balance short of the burn caps the call below what it needs. And the fee_limit has to permit that burn, because a low limit caps the call just as hard however much TRX sits behind it. Fall short on either and the call stops partway with OUT_OF_ENERGY, and the TRX it burned on the way stays burned (what that result means).

The second figure catches wallets that rent or stake. The node counts energy the account already holds against the fee_limit too, the same way it counts TRX it would burn. A transaction signed without a fee_limit carries a limit of zero, and a limit of zero lets the call spend no energy at all, delegated or burned. Whatever a wallet's own warning says, the node does this arithmetic: the account's own energy will not cover the call, the node will burn TRX for the rest, and the transfer goes through only if the balance and the limit both reach that far.

Three attempts by one wallet on mainnet

The fee_limit side of the rule can be watched on mainnet. On 6 October 2026, walking the public record of the USDT contract, we came across one sender that tried the same transfer three times in under forty minutes. The transfer needed 130,285 units of energy, the figure for a recipient holding no USDT, and the account had no energy of its own, so every unit had to be bought by burning TRX. Each row is that transaction's own record.

The first attempt stopped at exactly 11,000 units, which is its fee_limit divided by 100 sun. The account could have paid for more: it paid the whole burn on the third attempt, and its record shows no TRX arriving in between. The second attempt carried no fee_limit, and its receipt reports a limit of zero at the first instruction of the contract. It spent no energy, moved no USDT, and still paid for its bytes. The third was signed with a fee_limit just above the burn and went through.

That sender was the exception. Of 12,000 consecutive USDT calls we counted the same afternoon, every one carried a fee_limit.

What to set the fee_limit to

The fee_limit caps the energy the call may use, held or burned, and charges nothing by itself. A transfer whose energy is already on the wallet burns none of it, so a generous limit is free on a wallet that has its energy. The value that never stops a transfer short is the larger burn, 13.1 TRX. A limit of 6.5 TRX is enough only while the recipient still holds USDT when the transfer lands, and a recipient with an empty balance costs the larger figure whether or not it ever held any (where the two figures come from). A limit below what the transfer needs stops the call even on a wallet holding all the energy it needs, because the node counts that energy against the limit.

When we broadcast a signed transfer for you, in mode B, we hold it to this rule before any energy is bought. A fee_limit that cannot pay for the transfer's energy at the network's current price is refused with 400 invalid_request and details.reason set to fee_limit_too_low. An estimate of that one transfer returns its burn as burn_cost_trx, and a limit at least that high always passes.

The limit matters most on a transfer whose cost changes after it was priced. A recipient that held USDT when you checked it, and has emptied its balance by the time the transfer lands, costs the larger figure. If the wallet holds energy for the smaller one, the node burns the difference from TRX. The balance has to cover that difference, and the fee_limit has to cover the whole larger figure, because the energy the wallet held counts against it too. Short on either, the transfer stops with OUT_OF_ENERGY, and what it burned on the way stays burned.

With energy on the wallet, bandwidth is what is left

Energy pays for the contract call and for nothing else. The bytes of the transaction are metered separately, as bandwidth (the two meters side by side). Every account gets 600 bytes of bandwidth free each day, which covers about one USDT transfer. Past that, the network burns TRX for all the bandwidth each transaction is billed, at ten times the energy rate: one byte costs what ten units of energy cost.

A USDT transfer is billed a few hundred bytes of bandwidth. The one we sent and measured on 2 September 2026 was billed 345, and the three attempts above between 339 and 345. So once the free allowance has gone on the day's first transfer, every further transfer pays for its bytes in TRX, whether its energy was rented, staked or burned. A wallet holding no TRX at all can still send its first transfer of the day on delegated energy, with the free allowance paying for the bytes; the second needs TRX on the account (sending without holding TRX).

Charges outside the transfer

A sending wallet has to exist on chain before energy can be delegated to it (what activation is), and sending TRX to an address the network has never seen is what creates its account. Two chain parameters price account creation. We have not activated an address to see whether one such transfer pays the first of them alone or both, so the table lists both, and their sum is the amount to keep for it. Two more parameters price a memo on a transaction and a transaction signed under a multi-signature permission. Unlike activation, both are charged on every transaction that carries a memo or a multi-signature permission, so a hot wallet signed that way adds the parameter to every transfer counted in the table below. We have sent neither, and those rows give the parameter and nothing measured.

The buffer for a day of transfers

Put together, the TRX a sending wallet goes through in a day depends on where its energy comes from and, when it burns, on what kind of recipient it pays. The table below assumes 345 bytes of bandwidth billed per transfer, the free allowance spent on the first transfer of the day and the parameters above. A wallet that burns pays 6.5 TRX or 13.1 TRX of energy on every transfer, and its bytes from the second transfer on. A wallet with energy on it pays only the bytes.

Rented energy is paid for from your balance with us, and its price per transfer is on the pricing page. Staked energy costs the TRX locked to produce it, which sits outside this table (staking against renting). The daily figure is what a top-up once a day has to leave on the wallet. Before any single transfer, the floor is smaller: that transfer's burn, if it burns, and its bytes.

The last row is the margin for energy bought at the smaller figure. Auto-refill tops a wallet back up to about 131,000 units after its transfers, enough for either kind of recipient, so on such a wallet a recipient that turns out to need the larger figure is covered in energy and the margin drops to zero (how Auto-refill works). Whatever the energy source, the fee_limit still has to cover the transfer's whole energy, which is 13.1 TRX for a recipient that may hold no USDT when the transfer lands.

We did not measure how quickly the free allowance comes back over a day; the table assumes only the day's first transfer rides on it, so for a wallet that spreads its transfers out the bandwidth figures are an upper bound.

Size each transfer's limit from the burn the node will hold it to: POST /v1/estimate and its burn_cost_trx, in the API reference →