Skip to main content

USDT TRC-20 fee in 2026: the formula, live parameters and a TronWeb check

Why one transfer costs ~6.4 TRX and another ~13 TRX, and how to recalculate it yourself in a minute

Updated 5 min readMarkdown
USDT TRC-20 fee in 2026: the formula, live parameters and a TronWeb check

Ask ten people what a USDT TRC-20 transfer costs and you will get ten numbers: "about 1 dollar", "6.5 TRX", "13 TRX", "27 TRX". Most of them were true at some point. The fee on TRON is not a fixed price tag. It is a product of two resources and two network parameters, and once you know the formula you can recompute it on any date without trusting anyone's screenshot, including ours.

The formula

TRON does not charge a percentage of the amount. Sending 10 USDT and 100,000 USDT costs the same. What you pay for is the resources the transaction consumes:

fee (sun) = energy_used × getEnergyFee + bandwidth_used × getTransactionFee
1 TRX = 1,000,000 sun
  • Energy is consumed by executing the USDT smart contract.
  • Bandwidth is the size of the transaction in bytes.
  • If the sending address holds neither resource, the node burns TRX at the current rates.

Both rates are chain parameters that the TRON committee can change by vote. The energy price has moved over the years and currently sits at 100 sun per unit; bandwidth costs 1,000 sun per byte. You can read the live values with one request, no API key needed:

curl -s https://api.trongrid.io/wallet/getchainparameters

Look for getEnergyFee and getTransactionFee in the response.

How much energy one USDT transfer needs

This part is set by the USDT contract, not by the network, and it has two cases:

Recipient address Energy used Burned at 100 sun
Already holds USDT 64,285 ≈ 6.43 TRX
Has never held USDT 130,285 ≈ 13.03 TRX

The second case is almost double because the contract has to create a new storage slot for the recipient's balance instead of updating an existing one. Bandwidth adds about 345 bytes, which is usually free: every activated address gets 600 free bandwidth units per day, enough for roughly one transfer.

We wrote a separate breakdown of the empty-recipient case here: why a USDT transfer to an empty wallet needs double energy.

Check it from code before you send

You do not need to guess which row of the table applies. A dry run of transfer() through triggerConstantContract returns the exact energy_used without signing or spending anything, and getAccountResources tells you how much energy and free bandwidth the sender already has.

const { TronWeb } = require('tronweb');

const tronWeb = new TronWeb({ fullHost: 'https://api.trongrid.io' });
const USDT = 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t';

async function estimateUsdtTransfer(from, to, amountUsdt) {
  const params = [
    { type: 'address', value: to },
    { type: 'uint256', value: Math.round(amountUsdt * 1e6) },
  ];

  // Dry run of transfer(): nothing is signed or broadcast
  const sim = await tronWeb.transactionBuilder.triggerConstantContract(
    USDT, 'transfer(address,uint256)', {}, params, from
  );
  const energyNeeded = sim.energy_used;

  // What the sender already has
  const res = await tronWeb.trx.getAccountResources(from);
  const energyAvailable = (res.EnergyLimit || 0) - (res.EnergyUsed || 0);
  const freeBandwidth = (res.freeNetLimit || 0) - (res.freeNetUsed || 0);

  const missingEnergy = Math.max(0, energyNeeded - energyAvailable);
  const burnTrx = (missingEnergy * 100) / 1e6; // 100 sun = current getEnergyFee

  return { energyNeeded, energyAvailable, freeBandwidth, missingEnergy, burnTrx };
}

If energyNeeded comes back around 130K, the recipient has never held USDT and the transfer will cost double. If missingEnergy is zero, nothing will be burned for the contract call. Replace the hardcoded 100 with the live getEnergyFee value if you want the script to survive the next parameter change.

Why your wallet shows a different number

A few things make real-world fees drift from the table:

  • Partial energy. If you have 40K energy and the transfer needs 64,285, the node burns TRX only for the missing part.
  • Free bandwidth already spent. A second or third transfer in a day adds about 0.35 TRX for bytes.
  • Exchange withdrawals. Exchanges set their own flat withdrawal fee; it is a business decision, not the network price.
  • Old articles. Figures like 13–27 TRX for an ordinary transfer date back to a higher energy price.

Paying less than the formula

Burning TRX is the most expensive way to pay. The formula above gives you the upper bound. Two other routes exist:

  1. Stake TRX under Stake 2.0 and get energy back daily. This works if you can lock up capital and send regularly.
  2. Rent energy for a short window. It is delegated to your address, the USDT contract consumes it instead of burning TRX, and nobody needs your private key.

As of today on Overtron, 65K energy for 15 minutes costs 2.26 TRX against about 6.5 TRX burned, and 131K energy for a transfer to an empty address costs 4.56 TRX against about 13.1 TRX. Energy usually arrives within 10 to 60 seconds. The rate changes with the market, so treat these as a snapshot and check the current price before you pay.

If you prefer Telegram, the same rental is available in the bot: @overtronbot.

A one-minute recipe

  1. Query wallet/getchainparameters and note getEnergyFee and getTransactionFee.
  2. Simulate transfer() with triggerConstantContract to get energy_used for your recipient.
  3. Subtract the energy you already have (getAccountResources).
  4. Multiply the missing energy by getEnergyFee, divide by 1,000,000 to get TRX.
  5. Add bandwidth × getTransactionFee if your 600 free daily units are gone.
  6. Compare the result with the cost of renting the missing energy.

That is the whole fee model. Everything else is rounding and marketing.


Originally published at overtron.io.

About the author

  • I work on Overtron, a service that rents TRON energy so USDT transfers cost about 2.2 TRX instead of 6.5 TRX burned. Here I write about how TRON resources work, why fees jump, and what we learn running a Telegram bot and an API for wallets and payment services.

No comments yet. Be the first to comment.