How a wallet sends USDT without holding TRX
Most wallets show a USDT transfer on TRON as costing about 13 TRX, and most people read that as a fee. It is not one. It is the network billing the sender for computation the account cannot pay for in energy, so it takes TRX instead. Supply the energy and the burn does not happen. Here is how a wallet arranges that.
Where the TRX actually goes
Sending USDT is a call into a smart contract, and contract execution is metered in energy: roughly 65,000 units when the recipient already holds USDT, roughly 131,000 when the address has never held it and a token account has to be created first. An account with no energy is not refused — the network takes TRX instead, at the protocol rate of 210 sun for each unit. That is 13.650000 TRX for an ordinary transfer and twice that for a fresh recipient (the whole calculation).
Energy can also be handed over. An account that has staked TRX may delegate energy to another account for a period, and what crosses is energy and only energy — no keys, and nothing to approve in the receiving wallet (see what TRON energy is). Renting is buying such a delegation for the few minutes you need it.
The window it arrives in
An order names the transfer — the recipient, and the sending wallet. We price it, reserve that amount on your balance, and buy the energy. Once the energy is on-chain on the sending address, the response carries send_before: the moment the delivery window closes, about four minutes out. Watch for that field rather than the word ready — the order is fulfilled by the delivery of energy, so completed follows immediately. Sending it yourself inside that window is mode A; the arrangements below exist because the window is short.
Short is the point. Creating and ending a delegation are both cheap, which is why energy can be sold by the minute and why the price lands far under the burn it stands in for — current prices are on the pricing page. It also sets the rule about money: what is charged is delivered energy, not your act of sending.
Mode B: you sign it, we broadcast it
Nobody wants a person waiting at a keyboard for a window that opens in seconds. Mode B removes them: you post an already-signed transfer, we keep it encrypted, and broadcast it once the energy is on-chain. Between “energy ready” and “transfer sent” there is no human and no network of yours.
The requirements are strict on purpose — the USDT transfer call and nothing else, one plain owner signature, no TRX attached, at least two minutes of life left on arrival. In exchange there is a promise the other way: if we do not relay it before send_before, we do not charge — the position closes as failed with broadcast_window_missed and the reservation is released in full. Broadcasting late would push your transfer into the network when the delegated energy may already be gone, burning the TRX we were hired to save.
Mode C: charge the wallet before the recipient exists
Sometimes there is no recipient to name yet: your own code builds the batch, and you want the wallet ready. Mode C asks for the wallet and the volume and nothing else — single for a transfer that will land on an address already holding USDT, double for one that will not.
The volume is your call, and the one thing we cannot correct: with no recipient named there is nothing to measure it from, so single where double was needed burns the difference as TRX after all. Positions of such an order stay ready for the window and then expire — the normal ending rather than a failure, since the energy was delivered and held throughout.
A wallet that sends all day
For a hot wallet, ordering per transfer is busywork. An Auto-refill rule is two fields — the address and a daily budget — after which the wallet is topped back up to 131,000 energy on its own, enough for any next transfer, recipient with USDT or without. The first top-up goes at the double rate; after that the rate follows what the previous transfer consumed. Nothing else is in the product: no subscription, no term charge, no premium for speed. A wallet that sends nothing spends no energy and needs no top-up, so an idle one costs almost nothing — almost, because the day's budget stays reserved while the rule is active.
That budget is a ceiling for the UTC day, held from your balance the way an order's price is and returned at midnight. Top-ups count only when the energy is visible on the wallet on-chain — not on a report, not on a schedule — and each leaves an event and a ledger line.
Where to start
Pick the mode by who holds the transaction when the energy lands: mode A if your own code sends, mode B to hand the signed transfer over, mode C if the wallet must be ready before the recipient is, Auto-refill if it sends all day. The API documentation has the request bodies; what goes wrong on the way is a post of its own.