DEV Community: Overtron

64,285 or 130,285 energy: detect an empty USDT recipient on TRON before you send

Overtron — Tue, 03 Nov 2026 16:13:19 +0000

If you send USDT TRC-20 from a backend, your fee estimate is probably a constant. Something like "65,000 energy per transfer". That constant is right most of the time and wrong in a way that costs exactly double.

A USDT transfer to an address that already holds USDT uses 64,285 energy. A transfer to an address that holds zero USDT uses 130,285. The amount does not matter: 1 USDT and 100,000 USDT cost the same. Only the recipient's balance does.

This post shows where the extra 66,000 energy comes from, how to detect the case from code before you sign, and how to turn energy into TRX at the current network rate.

Where the extra 66,000 comes from

The USDT contract keeps balances in a mapping from address to amount. When the recipient already has a non-zero balance, transfer updates an existing storage slot. When the balance is zero, the contract writes a fresh slot, and the TVM charges much more for a new storage write than for an update.

130,285 − 64,285 = 66,000. That difference is the price of the new slot.

Two practical consequences:

An address whose balance dropped back to zero is "empty" again. A wallet you paid last month can cost 130K today if it was swept since.
Splitting a payment into smaller parts never saves energy. Each part costs the full price, and only the first one to an empty address pays the 130K.

Check 1: does the recipient hold USDT?

The cheapest signal is a balanceOf call. It is a read, so it costs nothing.

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

const tronWeb = new TronWeb({
  fullHost: 'https://api.trongrid.io',
  headers: { 'TRON-PRO-API-KEY': process.env.TRONGRID_KEY },
});

const USDT = 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t';

async function recipientIsEmpty(recipient) {
  tronWeb.setAddress(recipient); // any valid address works as caller for a read
  const usdt = await tronWeb.contract().at(USDT);
  const balance = await usdt.balanceOf(recipient).call();
  return BigInt(balance.toString()) === 0n;
}

Same thing in Python with tronpy:

from tronpy import Tron
from tronpy.providers import HTTPProvider

USDT = "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"
client = Tron(HTTPProvider(api_key="YOUR_TRONGRID_KEY"))

def recipient_is_empty(recipient: str) -> bool:
    usdt = client.get_contract(USDT)
    return usdt.functions.balanceOf(recipient) == 0

If this returns true, budget 130,285 energy for the transfer, not 64,285.

Check 2: simulate the exact transfer

A balance check tells you which bucket you are in. A dry run tells you the number. triggerConstantContract executes the call on a node without broadcasting it and returns energy_used.

async function estimateTransferEnergy(from, to, amountSun) {
  const res = await tronWeb.transactionBuilder.triggerConstantContract(
    USDT,
    'transfer(address,uint256)',
    {},
    [
      { type: 'address', value: to },
      { type: 'uint256', value: amountSun },
    ],
    from
  );
  if (!res.result || !res.result.result) {
    throw new Error('simulation reverted: check that `from` holds the amount');
  }
  return res.energy_used;
}

Two things trip people up here. The simulation only succeeds if from really holds at least amountSun USDT (6 decimals, so 10 USDT is 10_000_000). And it is an estimate on the node's current state: if someone funds the recipient between your simulation and your broadcast, the real transfer gets cheaper, never more expensive.

Check 3: convert energy into TRX

Energy has no fixed TRX price. The network sets the burn rate with the chain parameter getEnergyFee, in sun per energy unit, and it has changed by vote before. Read it instead of hard-coding it.

async function energyFeeSun() {
  const params = await tronWeb.trx.getChainParameters();
  const p = params.find((x) => x.key === 'getEnergyFee');
  return p.value; // 100 at the time of writing
}

async function burnCostTrx(energyNeeded, sender) {
  const r = await tronWeb.trx.getAccountResources(sender);
  const available = (r.EnergyLimit || 0) - (r.EnergyUsed || 0);
  const missing = Math.max(0, energyNeeded - available);
  return (missing * (await energyFeeSun())) / 1e6;
}

At 100 sun per unit the two cases come out as:

Recipient	Energy	Burned if you have none
Holds USDT	64,285	~6.43 TRX
Holds zero USDT	130,285	~13.03 TRX

Bandwidth adds roughly 0.35 TRX on top when the free daily allowance is used up. That is the small part of the bill.

Putting it together

async function planTransfer(from, to, amountSun) {
  const empty = await recipientIsEmpty(to);
  const energy = await estimateTransferEnergy(from, to, amountSun);
  const burn = await burnCostTrx(energy, from);
  return { empty, energy, burnTrx: burn };
}

Use the result for three decisions:

fee_limit. Set it from energy * energyFee plus a margin, not from a constant tuned for the 64K case. A fee_limit sized for 64K fails with OUT_OF_ENERGY on an empty recipient. I wrote about reading that failure in an earlier post.
Pre-funding energy. If the sender stakes or receives delegated energy, check that available covers 130,285 for payouts to new users, not just 64,285.
Showing the fee to users. If you pass the network fee to the customer, an empty-recipient flag lets you quote the right number up front instead of explaining the difference afterwards.

Verify the numbers yourself

You do not have to trust the two constants. Take a few recent USDT transactions, call wallet/gettransactioninfobyid on each and read receipt.energy_usage_total. In a sample of ten consecutive transfers checked in July, seven showed exactly 64,285 and three showed exactly 130,285. The full method, with a sample transaction ID, is in the original article.

Where renting fits

If the sender has no energy, every transfer burns TRX at the network rate. Renting energy delegates it to the sender's address before the send: a 65K package for one regular transfer costs 2.26 TRX instead of about 6.5 TRX burned, and a 131K package that covers one transfer to an empty address (or two regular ones) costs 4.56 TRX instead of about 13 TRX. Delegation goes to a public address, no private keys involved, and lands in 10 to 60 seconds. That is what we built at Overtron; there is also a Telegram bot.

Whichever way you pay, the check stays the same: look at the recipient's USDT balance before you size the fee.

Originally published at overtron.io.

TRON Stake 2.0 from code: how much energy your TRX buys and how to check a delegation

Overtron — Tue, 20 Oct 2026 14:01:51 +0000

Every USDT TRC-20 transfer is a smart contract call, and contract calls cost energy. If the sender has none, the network burns TRX instead: about 6.5 TRX per transfer to an address that already holds USDT, about 13 TRX to an empty one.

There are two ways to stop burning: stake your own TRX for energy, or get energy delegated to your address by someone who already staked. Both run on the same Stake 2.0 machinery. This post shows how to read that machinery from code with TronWeb, so you can size a stake, verify a delegation, and stop guessing.

The formula the network uses

Under Stake 2.0 your energy is a share of a fixed network-wide pool:

yourEnergy = yourTrxStakedForEnergy / totalTrxStakedForEnergy * TotalEnergyLimit

TotalEnergyLimit is a chain parameter (180 billion at the time of writing). The denominator changes every day as other people stake and unstake. So the same stake gives you a different amount of energy next month. Don't hardcode a ratio, read it.

Step 1: energy per staked TRX, right now

getAccountResources returns both totals, for any address:

const { TronWeb } = require('tronweb'); // v6; for v5 use: const TronWeb = require('tronweb');
const tronWeb = new TronWeb({ fullHost: 'https://api.trongrid.io' });

async function energyPerTrx(address) {
  const r = await tronWeb.trx.getAccountResources(address);
  // TotalEnergyWeight is the total TRX staked for energy, in whole TRX
  return r.TotalEnergyLimit / r.TotalEnergyWeight;
}

Turn it around to get the stake you need for a daily volume:

const ENERGY_EXISTING = 65_000;  // recipient already holds USDT
const ENERGY_EMPTY = 131_000;    // recipient never held USDT

async function trxToStake(address, toExisting, toEmpty, buffer = 1.15) {
  const perTrx = await energyPerTrx(address);
  const dailyEnergy = toExisting * ENERGY_EXISTING + toEmpty * ENERGY_EMPTY;
  return Math.ceil((dailyEnergy / perTrx) * buffer);
}

The 15% buffer covers your share shrinking when others stake more. Two details matter in practice:

Energy recovers over a rolling 24 hours, so a stake behaves like a capacity. If your payouts come in one batch, size the stake for the batch, not the daily average.
The per-transfer numbers are approximations. Before a real send, simulate it with triggerConstantContract and read energy_used. I covered that in the OUT_OF_ENERGY post.

Step 2: staking and delegating

Freezing and delegating are two transactions. Amounts are in sun (1 TRX = 1,000,000 sun):

async function stakeForEnergy(owner, trx) {
  const tx = await tronWeb.transactionBuilder.freezeBalanceV2(
    trx * 1e6, 'ENERGY', owner
  );
  const signed = await tronWeb.trx.sign(tx);
  return tronWeb.trx.sendRawTransaction(signed);
}

async function delegateEnergy(owner, receiver, trx) {
  // how much of your stake is free to delegate
  const { max_size } = await tronWeb.trx.getCanDelegatedMaxSize(owner, 'ENERGY');
  const amount = Math.min(trx * 1e6, max_size || 0);
  if (amount === 0) throw new Error('nothing left to delegate');

  const tx = await tronWeb.transactionBuilder.delegateResource(
    amount, receiver, 'ENERGY', owner, false // lock = false
  );
  const signed = await tronWeb.trx.sign(tx);
  return tronWeb.trx.sendRawTransaction(signed);
}

Note what delegation is: the staked TRX stay on the owner's address, and only the right to use the energy moves to receiver. The receiver never signs anything and never shares a key. That is also how energy rental works under the hood.

Step 3: verify a delegation landed

On the receiving side, the quickest check is the same call you'd use before a transfer:

async function availableEnergy(address) {
  const r = await tronWeb.trx.getAccountResources(address);
  return Math.max(0, (r.EnergyLimit || 0) - (r.EnergyUsed || 0));
}

EnergyLimit already includes delegated energy. To see who delegated and how much, use the V2 index:

async function incomingDelegations(receiver) {
  const index = await tronWeb.trx.getDelegatedResourceAccountIndexV2(receiver);
  const fromList = index.fromAccounts || [];

  const result = [];
  for (const from of fromList) {
    const res = await tronWeb.trx.getDelegatedResourceV2(from, receiver);
    for (const d of res.delegatedResource || []) {
      if (d.frozen_balance_for_energy) {
        result.push({
          from: tronWeb.address.fromHex(d.from),
          trx: d.frozen_balance_for_energy / 1e6,
          lockedUntil: d.expire_time_for_energy || null,
        });
      }
    }
  }
  return result;
}

frozen_balance_for_energy is the TRX amount behind the delegation, not energy. Multiply by energyPerTrx() from step 1 to estimate the energy. expire_time_for_energy is only set for locked delegations; an unlocked one can be withdrawn by the owner at any time.

If you prefer Python, tronpy exposes the same node endpoint:

from tronpy import Tron

client = Tron()  # mainnet via TronGrid
r = client.get_account_resource("TYourAddressHere")
available = r.get("EnergyLimit", 0) - r.get("EnergyUsed", 0)
per_trx = r["TotalEnergyLimit"] / r["TotalEnergyWeight"]
print(available, round(per_trx, 2))

Step 4: unstaking takes time

unfreezeBalanceV2(amountSun, 'ENERGY', owner) starts the exit, but the TRX return only after the waiting period (the getUnfreezeDelayDays chain parameter, 14 days on mainnet today). After that, withdrawExpireUnfreeze(owner) moves them to your spendable balance. Pending unstakes are visible in getAccount(owner).unfrozenV2. You can't unstake TRX that are currently delegated out; reclaim them first with undelegateResource.

Put that in your capital planning: a stake is money you can't touch for at least two weeks after you decide you need it.

Stake or rent: the honest math

Staking costs no TRX per transfer, but it ties up capital, keeps you exposed to the TRX price, and has the 14-day exit. Renting costs money per transfer and nothing else. A simple monthly comparison:

Renting = transfers per month x price of energy for one transfer.
Staking = value of the staked TRX x what that capital would earn elsewhere per month.

High, steady volume with idle capital favours staking. Small or bursty volume favours renting. A common setup is a hybrid: the stake covers base load, short rentals cover peaks.

For reference, Overtron rents 65K energy for 15 minutes for 2.26 TRX (131K, enough for a transfer to an empty address, for 4.56 TRX), delivered by the same delegateResource mechanism in 10–60 seconds. No keys, no wallet connection; the incomingDelegations() function above will show it. There is a Telegram bot and an API for payout scripts.

The full break-even walkthrough, with scenarios for different volumes: Stake TRX for Energy or Rent It: How to Find Your Break-Even Point.

Originally published at overtron.io.

OUT_OF_ENERGY on TRON: how to check energy before you send USDT (TronWeb)

Overtron — Fri, 09 Oct 2026 09:53:28 +0000

If you send USDT TRC-20 from code, sooner or later you will see a transaction with contractRet: OUT_OF_ENERGY. The tokens are fine, because TRON transactions are atomic and a failed call changes no balances. What you lose is the TRX the network burned trying to run it.

This post covers why it happens and the three checks we run before every transfer so it doesn't.

Why a USDT transfer runs out of energy

A USDT transfer is a call to transfer(address,uint256) on the TRC-20 contract TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. The VM charges energy for that work:

Case	Energy used	Burned without energy (100 sun/energy)
Recipient already holds USDT	~64,285	~6.4 TRX
Recipient has never held USDT	~130,285	~13 TRX

The second row is the classic trap. The contract has to create a new storage slot for the recipient, so the cost roughly doubles. A wallet or script that budgets for the first row and hits the second one fails.

Execution stops with OUT_OF_ENERGY when your available energy plus the TRX you allow it to burn (fee_limit) is less than what the call actually needs. Typical causes:

rented or staked energy expired before the transfer went out, and there was no spare TRX;
the recipient is a fresh address, so the call needs ~130K instead of ~65K;
fee_limit set too low in your integration.

Check 1: how much energy the call will really use

Don't hardcode 65,000. Ask a node to simulate the call:

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

const USDT = 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t';

async function estimateUsdtEnergy(from, to, amountUsdt) {
  const params = [
    { type: 'address', value: to },
    { type: 'uint256', value: Math.round(amountUsdt * 1e6) },
  ];
  const res = await tronWeb.transactionBuilder.triggerConstantContract(
    USDT, 'transfer(address,uint256)', {}, params, from
  );
  return res.energy_used; // e.g. ~64285 or ~130285
}

triggerConstantContract runs the call without broadcasting it, and energy_used is what the real transfer will consume. The simulation only works if from actually holds that much USDT, otherwise it reverts.

Check 2: how much energy the sender has right now

async function availableEnergy(address) {
  const r = await tronWeb.trx.getAccountResources(address);
  const limit = r.EnergyLimit || 0;
  const used = r.EnergyUsed || 0;
  return Math.max(0, limit - used);
}

EnergyLimit includes energy delegated to the address, so rented energy shows up here as soon as the delegation lands.

Check 3: set fee_limit from the numbers, not a constant

The burn price is a chain parameter (getEnergyFee, in sun). Read it instead of assuming 100:

async function energyFeeSun() {
  const params = await tronWeb.trx.getChainParameters();
  return params.find(p => p.key === 'getEnergyFee').value;
}

async function sendUsdt(from, to, amountUsdt) {
  const need = await estimateUsdtEnergy(from, to, amountUsdt);
  const have = await availableEnergy(from);
  const price = await energyFeeSun();

  const shortfall = Math.max(0, need - have);
  const feeLimit = Math.ceil(shortfall * price * 1.2) + 1_000_000; // +20% and 1 TRX headroom

  const tx = await tronWeb.transactionBuilder.triggerSmartContract(
    USDT, 'transfer(address,uint256)', { feeLimit },
    [{ type: 'address', value: to }, { type: 'uint256', value: Math.round(amountUsdt * 1e6) }],
    from
  );
  // sign and broadcast as usual
  return { need, have, shortfall, feeLimit, tx };
}

If shortfall is zero, the transfer burns no TRX for energy at all. If it's not zero, you have a choice: burn TRX, stake your own TRX for energy, or rent energy for the transfer window.

Reading a failed transaction

const info = await tronWeb.trx.getTransactionInfo(txid);
console.log(info.receipt.result);        // 'OUT_OF_ENERGY'
console.log(info.receipt.energy_fee);    // sun burned

A FAILED transaction can simply be resent once the shortfall is covered. Nothing went out, so there is no double-payment risk.

Where renting fits

For services that send many transfers, burning ~6.4 TRX each time adds up. Delegated energy turns the same transfer into roughly 2.2 TRX. With Overtron, 65K energy for 15 minutes costs 2.26 TRX at the time of writing, delivered to the address in 10–60 seconds, with no keys or wallet connection involved. There is also a Telegram bot and an API for automated payouts. The checks above work the same either way: estimate, compare with EnergyLimit - EnergyUsed, cover the gap.

More on the error itself, including a Tronscan checklist: TRON "FAILED — OUT_OF_ENERGY": why it happens and whether your money is safe.

Originally published at overtron.io.