Blog · 7 November 2026

Keeping a payout wallet in energy: stake, rent per transfer, or refill after each one

A payout wallet on TRON spends energy on every USDT transfer it sends: about 65,000 units when the recipient already holds USDT, about 131,000 when it holds none. When the energy is missing, the network takes TRX instead, at 100 sun a unit, which comes to 6.5 TRX or 13.1 TRX a transfer, and the payout still confirms as long as the wallet holds that TRX and the transaction's fee_limit allows the burn (the whole calculation). So the job for a hot wallet is to have energy in place before every send without anyone ordering it by hand. Three patterns do that job, and each of them fails in its own way.

A stake is sized for the busiest day and paid for every day

Staking TRX for energy buys a share of a fixed daily pool. A wallet's daily allowance is its stake times the network's TotalEnergyLimit over TotalEnergyWeight, and on 3 September 2026 that ratio stood at 180,000,000,000 over 18,770,236,993: a little under ten units of energy a day for each staked TRX. The divisor is the network's whole stake for energy, yours included, so the figure drifts from block to block (the formula worked through).

Spent energy comes back gradually over the following 24 hours. A wallet that pays out most of its day in one run at noon needs a stake that covers that run, and the stake stays frozen through the quiet hours and the quiet days as well. Getting out is slow too. On mainnet, TRX unstaked today can be withdrawn fourteen days later.

When payouts outgrow the stake, the transfers that find the allowance spent burn TRX for the shortfall and, with TRX on the wallet and room in fee_limit, confirm anyway. Nothing returns an error, and the first sign is a burn line in the wallet's history (what happens when the limit is too low).

Renting per transfer puts a wait in front of every send

The second pattern buys energy for each transfer as it comes. An order names the sending wallet and the recipient. The API answers 202, with the order's own address in Location and the polling interval in Retry-After, and we buy the energy and watch for it on the wallet. Once the delegation is confirmed, the order carries send_before, and that is your code's signal to send. The window is the lease less three seconds: 297 seconds on the five-minute lease and 3,597 on the one-hour lease.

Every payout therefore waits for a purchase and a block. We measured that wait on our own orders where the client's code does the sending, from the moment the order was created to the last delegation confirmed on chain, over the sixty days to 8 September 2026.

Thirteen orders is a small sample, and most of it is early. Seven came from the first week of live orders, the slowest among them, and the weeks after ran at three to four seconds. We have not repeated the measurement on a larger sample.

A transfer sent before the energy lands burns at the full rate, and one sent after send_before can find the energy gone and burn the same way. The TRX it burns does not come back. Energy that was delivered and not used inside the window closes as expired and is charged, because it was delivered (the three clocks of a rental). A payout queue that sends on its own schedule has to be rebuilt around that signal. For a run of payouts known in advance, one batch order of up to 500 transfers gathers the waiting into one place: the energy for the whole run is bought first, and every transfer in it shares one send_before (what a batch looks like from the inside).

A rule that refills the wallet after every transfer

The third pattern is a rule on the wallet, which we sell as Auto-refill, the hot-wallet case of sending USDT without holding TRX. It takes two fields, address and daily_budget_trx, in one call to POST /v1/auto-refill-rules. From then on the wallet is brought back to about 131,000 units of energy after every transfer it makes. That covers any one next transfer, including one to an address that holds no USDT. The rule creates no orders: GET /v1/orders lists only the ones you placed.

A top-up is priced by what the transfer before it used. If that transfer spent about 65,000 units, the top-up bills at the single rate; if it spent about 131,000, at double. Both rates are in GET /v1/tariff under maintenance_price_trx. They are a price of their own and move separately from the lease prices, and the rate charged is the one in force when the top-up is confirmed. The first top-up of a new rule is always double: there is no earlier transfer to price it by, and the wallet gets the full 131,000 at once.

Billing waits until the energy is visible on the wallet on chain; a supplier saying it delivered is not enough. Each charge arrives as a maintenance.topup event carrying rule_id, address, units and charged_trx, and as a charge line in GET /v1/ledger. A wallet that sends nothing gets no top-ups and pays for none.

How the refill stops, and what the wallet does then

The daily budget, daily_budget_trx, is reserved from your available balance when the rule starts and again at the start of every UTC day, and it is the most the rule can spend that day. Top-ups are drawn from that reservation, and what is left of it returns to the balance at midnight UTC. The rule's spent_today_trx shows how much of the day is gone. Raising the budget at midday adds the difference to the reservation and does not open a second day.

When the budget is spent, top-ups stop until the next UTC day. You get one maintenance.budget_exhausted event, with spent_today_trx and daily_budget_trx in it, and the rule stays active. From that point until midnight, every transfer the wallet cannot pay for in energy burns TRX for the shortfall at 100 sun a unit. A budget sized for an average day runs out on a busy one.

When your balance cannot cover the next day's reservation, the rule stops. Its status becomes paused with paused_reason set to insufficient_balance, and a maintenance.paused event goes out. A paused rule never resumes on its own, and a deposit does not restart it: it waits for PATCH /v1/auto-refill-rules/{rule_id} with {"status": "active"}, and a resume the balance still cannot cover answers 402. A pause you set yourself carries no reason, so paused_reason tells a rule waiting for money from one waiting for your decision.

A budget below the double rate is refused with 422, details.reason set to budget_below_topup_price and the minimum in details.min_daily_budget_trx: the first top-up is double, and a rule with a smaller budget would go live and never pay for it.

About 131,000 units on the wallet covers two transfers to addresses that hold USDT, or one to an address that holds none. A transfer sent before the top-up for the previous one has landed can find less than it needs and pay part of its way, or nearly all of it, in TRX. We have not measured how soon after a transfer the top-up lands. Deleting a rule before its top-ups have covered what we prepaid for that wallet costs the uncovered part, counting prepayments and charges from 6 November 2026 on; a pause never charges for it.

One example day, three ways

To put the three side by side, take one wallet and one day: thirty payouts to addresses that already hold USDT and ten to addresses that hold none. The burn and the stake are network arithmetic. The order price and the top-up rates are ours, read from GET /v1/tariff at 21:46 UTC on 27 October 2026; today's are on the pricing page.

At that hour the orders came to less than the top-ups, and that was the usual case. Over the thirty days of hourly history to the same evening, the top-up rates did not change once, and a five-minute order for the same transfer cost less than its top-up in most hours.

What a top-up costs above the order buys a wallet that already has its energy when each transfer goes out, and a hard ceiling on what it can spend in a day. The budget, like a stake, has to cover the busy day, but what a quiet day leaves of it returns to the balance at midnight UTC. We have no production figure for how many top-ups a rule makes in a day.

Set a payout wallet to refill itself with one request and a daily budget you choose: POST /v1/auto-refill-rules in the API reference →