How much energy a USDT transfer needs
For a common USDT transfer to a receiver with existing token state, plan on roughly 65,000 energy; a path that needs additional receiver-state work may be closer to 130,000. These are estimates: actual use follows the code executed, current contract state, and transaction details.
Why there are two numbers, not one
The two figures describe commonly observed USDT transfer paths, not a protocol rule. When the receiver already has relevant token state, the contract may only update existing storage; a first or different interaction may require additional writes and substantially more energy. Contract version, sender and receiver state, and the proposed transaction can change the path, so transfer history alone does not establish the cost.
The amount is usually not the main factor
Energy is metered for the contract instructions that actually execute, not charged as a percentage of value. For otherwise equivalent ordinary USDT transfers, changing only the token amount often leaves usage similar. But amount-dependent checks, transaction data, sender and receiver state, contract changes, or a different method can alter execution. Estimate the actual call rather than treating one-dollar and million-dollar transfers as a universal invariant.
Using planning estimates with margin
Use roughly 65,000 for a common existing-receiver path and roughly 130,000 for a path that needs extra receiver-state work, then add margin. These are planning inputs, not measured transaction limits. Separate recipient groups only when you have evidence for their current state, and use the transaction estimate or simulation available from your wallet, node, or provider close to submission. Recheck after contract or network-parameter changes.
What if the account has less energy than estimated
Under current TRON resource rules, a sender with insufficient energy may have TRX burned for some or all of the shortfall, subject to current network parameters and transaction settings. The transaction can still fail because of insufficient balance, fee limits, contract reverts, or changed state, and resources may still be consumed. Check a pre-execution estimate and the resulting receipt rather than assuming a small shortfall will be covered.
Other TRC-20 tokens are not the same
The figures on this page are planning estimates for common USDT contract calls. TRC-20 defines an interface; execution cost comes from the invoked contract logic and state. Other token contracts, and different methods or states in the same contract, can execute different logic. Estimate each proposed transaction for its token and contract address.
Frequently asked questions
How do I check whether the receiving address has held USDT?
Use a block explorer to inspect the address and token history as context, but a current or past balance does not prove which path the next call will take. Prefer an energy estimate or simulation built from the actual sender, receiver, contract, amount, and call data. If that is unavailable, use the higher planning estimate plus margin and recognize that the transaction can still differ.
How should I use the 65,000 figure?
Treat it as a planning estimate for a common USDT transfer path. Actual consumption can change with the contract implementation, execution path, sender and receiver state, transaction details, and network rules. Estimate the workload near execution and keep margin.
Does the sending address matter?
It can. Receiver state commonly explains part of the difference between the estimates, but sender state and the invoked contract path can also affect execution. Bandwidth is a separate resource tied largely to the encoded transaction size; estimate both when relevant.
Can I send USDT with no energy at all?
Possibly. If the account supplies no energy, TRON may burn TRX according to the energy actually consumed and current resource parameters, within the transaction's fee settings. Calculate the burn cost from those current inputs; adequate TRX alone does not override fee limits or contract failures. Estimate immediately before sending.