Blog · 5 November 2026

Sweeping USDT from deposit addresses on TRON: activation, energy and bandwidth per sweep

A payment gateway or an exchange that gives every customer a deposit address of their own has to gather the TRC-20 USDT on those addresses into one main wallet, the hot wallet, before it can pay any of it out. On TRON each of those moves is an ordinary USDT transfer, signed by the deposit address. It needs an account on chain, energy for the contract call and bandwidth for the bytes, and a deposit address that has only ever been paid in USDT has none of them.

Receiving USDT does not create an account

A USDT balance is an entry in the token contract's own storage. A transfer in writes that entry and creates no account, so an address can hold USDT while the network has no account for it at all. Our measurement of 7 September 2026 found two such addresses on mainnet: each held USDT, and the node we read from returned an empty object when asked for the account behind it, both before our test call and after. On 27 October both still held exactly the balances they held on 7 September.

Energy is delegated to an account, and we do not deliver it to an address that has none: an order in mode A or mode C that names such an address as from comes back 422 invalid_address with details.reason set to inactive_wallet. Whether the chain itself would take a delegation to such an address we have not tested, because our refusal comes first. Our operations notes also record the node's answer to a send from a wallet that has never received anything, no OwnerAccount. That note is about TRX sent from our own hot wallet; we have not tried a USDT transfer out of an address in this state. The wider story of the state is in the post on unactivated accounts.

Activating an address takes one TRX transfer, paid by the sender

Any incoming TRX transfer creates the account, however small, and from then on the address is an account like any other. The first attempt at that measurement went wrong on exactly that, and we discarded it: an address read as having no account, and 22 seconds later someone sent it a single sun, which created one. Its own creation time said so.

The fee for creating it falls on whoever sends the TRX: in a sweep setup, the wallet that funds the activations. Two chain parameters set it. We read them on 3 September 2026, and the network can change them, so read them again before you budget with them.

How the two combine on a plain TRX transfer we have not measured with a send of our own: that takes a live transfer to a fresh address, and we have made none. Either way the fee is paid once per address. A desk that activates every address when it is generated pays it on addresses that may never see a deposit, and one that activates on the first deposit pays it only where there is something to sweep.

Every sweep takes the lower energy figure

What a USDT transfer spends in energy depends on the recipient. When the recipient already holds USDT the transfer takes about 65,000 units; when its USDT balance is zero it takes about 131,000. Whether the recipient has an account does not enter into it. The measurement that found those two addresses put all four combinations side by side, and the balance decided every time (why there are two figures).

A sweep always pays the same recipient, the hot wallet, and the hot wallet holds USDT. So every sweep is the cheaper kind, single, whatever state the deposit address is in. The 7 September calls moved one unit out of a wallet that kept the rest, while a sweep moves everything and leaves the deposit address at zero. On 27 October we asked the node to simulate both on the same two addresses, with a wallet holding USDT as the recipient.

Emptying the deposit address changed nothing, and the figure is the one that measurement gave for every transfer to a holder. These are the node's simulations, and none of them is a receipt of a broadcast sweep; the 7 September figures carry the same caveat. Whether the two addresses have an account today we did not re-read.

The one way to lose the cheaper kind is to empty the hot wallet. A single unit of USDT on the recipient is enough for the lower figure, but at zero the next sweep into it takes about 131,000 units, which is 13.1 TRX if burned. Burned, a normal sweep costs 6.5 TRX at the protocol rate of 100 sun a unit, and what renting the same energy costs moves with the market.

Free bandwidth covers about one sweep per address a day

Bandwidth meters a transaction's bytes, where energy meters its computation (the two meters side by side). Every account gets a free daily allowance of it. The USDT transfer we sent and measured on mainnet on 2 September 2026 paid for its bandwidth in TRX, and that gives exactly how much bandwidth it was billed.

Against 600 a day, one sweep billed that much fits and two back to back do not. Past the allowance, the network burns the sender's TRX for the bytes. So the first sweep of an address in a day costs nothing in bandwidth, and a deposit address that also receives its energy by delegation needs no TRX of its own to send it. A second sweep soon after the first pays for its bytes from the deposit address's TRX. How quickly the allowance recovers between the two we have not measured; our own sweep plans on about one transfer a day per address from the free allowance. If an address will be swept more often than that, the activating transfer can leave it the TRX for those bytes at the same time.

Ordering the energy for a sweep run

Mode A names both ends of each transfer, the deposit address as from and the hot wallet as to, and we read the kind off the hot wallet ourselves. Mode C names only the wallet to energise and takes the kind from you, which suits a custody system that signs its sweeps on its own schedule and wants the energy standing there first (mode C in detail). For a sweep that kind is always single, as long as the hot wallet holds USDT. Either mode takes up to 500 transfers in one order, the same ceiling as a payout run. The lease is five minutes or an hour, and send_before falls three seconds short of its end.

One deposit address without an account refuses the whole order. The 422 names it in details.index and details.address, and nothing is bought. So screen the run first. POST /v1/estimate takes the same 500 transfers and reserves nothing, and it warns where the order would refuse: give it from on each item, and every deposit address without an account comes back flagged inactive_sender. Activate those, let the activations confirm, and send the order. The refusal does not use up the Idempotency-Key, and we re-read activation past our cache before refusing an order for it, so the same key and the same body work as soon as the activating transfer is confirmed.

Rules worth taking from our own sweep

We run a sweep of our own. Clients pay to deposit addresses we hold for them, and a background pass moves those coins to the one hot wallet that pays for purchases. It moves TRX, so it spends bandwidth and no energy, and its records say nothing about the energy side of a USDT sweep.

Our sweep reads the amount from the chain at the moment it decides. Our own records do not know about a fee that was burned, or about a sweep whose database row did not survive a crashed process, and the chain does. The same rule makes a retry safe: if the coins have already left, there is nothing to send.

We keep a broadcast sweep open until its transaction turns up in a block, and we write it off as failed only after a window no shorter than the longest expiry our signer puts on a transaction. Close it sooner and a transfer that can still land is counted as lost, and the next pass may sign a second transfer of the same balance. While a sweep is unconfirmed, its address stays out of the next pass.

Our TRX sweep sends at most the balance less a fee reserve, and keeps that reserve only when the address's free bandwidth is already spent. A USDT sweep pays its fee in a different coin from the one it moves, so the whole USDT balance goes every time, and the reserve becomes the TRX a deposit address needs for the bytes of a second sweep in a day.

Find every deposit address that still needs activating before the sweep is priced, five hundred to a request: POST /v1/estimate with from on each item →