The resource model in ninety seconds
Tron transactions consume two metered resources. Bandwidth covers the bytes of the transaction itself — cheap, partly free daily, rarely the story. Energy covers smart-contract execution, and a USDT transfer is a contract call. Depending on the state it touches (a fresh recipient costs more than a warm one, and Tron's dynamic-energy mechanism scales popular contracts' costs up), a single USDT transfer runs tens of thousands of energy units.
If the sending account holds no energy, the network silently converts the shortfall into burned TRX at a fixed rate — on the order of ten-plus TRX per transfer, a few dollars at recent prices. That burn is the "USDT-TRC20 fee" most wallets show. It isn't a fee at all; it's the pay-as-you-go price of not having planned your energy.
Three ways to source energy
- Burn TRX per transfer. Zero setup, worst unit price. Fine for a person sending twice a month; ruinous arithmetic for a processor moving thousands of transfers, where it compounds into real basis points on volume.
- Stake TRX for daily energy. Locking TRX generates renewable energy every day — the marginal transfer becomes nearly free, which is why heavy Tron users stake. The catch is capital: the stake is locked (with a multi-day unbond), sized for peak throughput, and idle the rest of the time. You've traded a per-transfer cost for a working-capital cost plus a forecasting problem.
- Rent energy just-in-time. An open market of energy lessors will delegate energy to an address for a fee — typically landing at a small fraction of the burn cost. Rent exactly what one transfer needs, seconds before it broadcasts, and pay no standing capital at all.
What a processor should build (and what we built)
The engineering answer is a hierarchy with fallbacks, because every layer can fail and a payment must not. When an OrbChain payout or sweep on Tron is about to broadcast, the pipeline checks whether the sending address already has sufficient energy (then do nothing — the free case), otherwise attempts a just-in-time rental sized for that transfer with a safety margin, verifies on-chain that the delegation actually arrived rather than trusting the lessor's API, and only then broadcasts. If the rental market is down, slow, or refuses — the transfer falls back to plain TRX burn and goes out anyway. Rental failure can cost us margin; it is never allowed to block a merchant's money.
Two production lessons baked into that design. First, size for the worst case: dynamic energy means the same transfer can cost multiples of its textbook price when the USDT contract is hot — we learned to budget for the penalty regime after meeting it, not before. Second, verify delegation on-chain: rental-market status endpoints are optimistic, and the only truth about whether your address holds energy is the chain itself.
One more Tron oddity: activation
A Tron address doesn't exist on-chain until something touches it — and an inactive address can't receive delegated energy or move tokens. For the per-user deposit address pattern this matters constantly: a brand-new user's address that just received USDT needs a tiny TRX activation nudge before its funds can be swept. It's exactly the kind of invisible bookkeeping that makes "just integrate Tron directly" a bigger project than it looks.
Why you mostly shouldn't care
The point of this post is that you don't have to hold any of it in your head. Merchants on OrbChain see USDT-TRC20 in, USDT-TRC20 out, and a flat 0.4% — the energy sourcing, the fallbacks, the activation drips are our cost line to optimize, not yours. But if you're evaluating processors: ask how they source Tron energy. A shop burning TRX per transfer is either eating margin loss on every USDT payment — or passing it to you somewhere in the fee schedule. The chain-by-chain buyer's view is in our USDT rail comparison.