You can send USDT without TRX in your wallet, and it is not a trick — but it works only when two specific conditions hold. Measured on 20 July 2026, a TRC-20 transfer is 211 bytes of raw transaction data, roughly 280 bytes once signed. Every TRON account gets 600 bandwidth points free every day. So the bandwidth side of the bill is usually already covered before you start.
What stops a zero-TRX wallet is the other resource. Understanding which one blocks you is the difference between a fix that takes seconds and an afternoon of failed attempts.
Two resources, only one of them is your problem
A TRC-20 transfer consumes both:
| Resource | What it pays for | Amount needed | Free allowance | | — | — | — | — | | Bandwidth | The transaction’s size on-chain | ~280 points | 600 per day, every account | | Energy | Running the contract code | ~64,285 | none |
Bandwidth is comfortably covered by the daily free grant — one transfer uses under half of it. Energy has no free allowance at all. That asymmetry is the whole story: a wallet with zero TRX fails on energy, not on bandwidth.
If you hold no energy, TRON falls back to burning TRX to cover it. With zero TRX there is nothing to burn, so the transaction cannot execute.
How to send USDT without TRX: delegated energy
Energy can be delegated to your address by someone who has staked TRX. Delegation is free to the receiver — you are not charged, you do not sign anything, and the energy simply appears against your address for the rental period.
That is the mechanism behind sending USDT without TRX. With energy delegated to you and your free daily bandwidth untouched, a transfer costs you nothing out of pocket at execution time. The sender of the energy paid for it; you consume it.
In practice this happens three ways:
1. Someone rents it for you. A rental order can be placed by one party and delegated to a different receiving address — this is how services top up a customer’s wallet. 2. You rent it yourself, paid from a balance you already funded. Not zero TRX overall, but zero TRX in the wallet doing the sending. 3. A staker in your organisation delegates a standing allocation. Common for payroll and merchant setups, where one treasury address stakes and delegates to operational wallets.
The TRON energy market exists for exactly this, and the delegation lands on whichever address you nominate rather than the one that paid.
The catch nobody mentions: bandwidth is free, but not unlimited
600 points a day sounds generous against a 280-byte transfer, and it is — for one transfer. Two in a day exceeds it.
When your free bandwidth is exhausted, TRON charges for the overage at `getTransactionFee`, currently 1,000 sun per byte. A 280-byte transaction costs 280,000 sun = 0.28 TRX. With zero TRX, that fails — even if your energy is fully covered.
So the honest version of “send USDT without TRX” is:
> It works for your first transfer of the day, if energy is delegated to you. Beyond that you need either staked TRX producing your own bandwidth, or a small TRX balance for the overage.
This is why a wallet that worked yesterday can fail today on the second send, with an error that looks nothing like “out of bandwidth”.
Check before you try
Two API calls tell you whether a transfer will go through, before you sign anything:
“` POST https://api.trongrid.io/wallet/getaccountresource { “address”: “<your address>”, “visible”: true } “`
Read three fields:
- `freeNetLimit` minus `freeNetUsed` — bandwidth left today. Need ~280.
- `EnergyLimit` — energy available to you, including anything delegated. Need ~64,285.
- If `EnergyLimit` is near zero, nothing has been delegated and no amount of waiting changes that.
An account with `EnergyLimit: 18` — a real reading from an ordinary wallet — has effectively nothing. That is not a wallet that can move USDT without help.
What does not work
Three things people try that cannot work, so you can stop trying them:
- Waiting for the energy to regenerate. Bandwidth regenerates daily; energy only accrues to addresses that have staked TRX. A wallet that never staked accrues nothing.
- Sending a smaller amount of USDT. Energy cost is the contract call, not the value moved. One dollar and one million dollars cost the same.
- Having the recipient pay. TRON charges the sender. There is no mechanism for the receiving address to cover a transfer’s resources.
What genuinely resolves it is the delegation route above, or someone sending you a small amount of TRX to burn — around 6.5 TRX covers one transfer at the current burn rate, which is the expensive way to do it. See why there are two TRON energy prices for why burning costs several times what renting does.
If the transfer still fails
Check whether the failure is resource-related at all. A transaction that shows `OUT_OF_ENERGY` on TRONSCAN ran short mid-execution — and the TRX consumed getting there is not refunded. A transaction that never appears was never broadcast.
And if the balance shows but refuses to move even with resources covered, the address may be frozen at the issuer level rather than short of anything. The blacklist check takes a minute, and the USDT-not-showing diagnostic covers the other failure modes.
FAQ
How much TRX do I actually need if nobody delegates energy to me? About 6.5 TRX per transfer at the current 100-sun burn rate, or ~13 TRX to an address that has never held USDT. The minimum TRX guide covers the edge cases.
Does delegated energy cost me anything? No. Delegation is paid by whoever placed the rental. It arrives against your address and expires on its own.
Why did my first transfer today work and the second fail? Almost certainly free bandwidth. 600 points covers one ~280-byte transfer; the second needs TRX for the overage at 1,000 sun per byte.
Can I send USDT with zero TRX and zero energy? No. Something has to pay for the contract execution. The only question is whether it is your TRX, your staked resources, or energy someone delegated to you.
Transaction size (211 bytes raw) was measured by building an unsigned TRC-20 `transfer` against the USDT contract at `TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t` via TronGrid on 20 July 2026; `getFreeNetLimit` (600), `getTransactionFee` (1,000 sun/byte) and `getEnergyFee` (100 sun) were read from chain parameters the same day, and the ~64,285 energy figure measured against the same contract. Resource mechanics per the TRON resource model documentation.
