Paying a remote team or freelancers in USDT (TRC-20) is fast and borderless — but if every payout burns TRX, the fees add up quickly across dozens of people, every month. This guide shows how to run USDT payroll on TRON cheaply using bulk sending and rented energy.
Where the cost comes from
Each USDT (TRC-20) payout is a smart-contract transfer that needs energy — about 65,000 per transfer (more for first-time recipients). Without energy, the network burns your TRX, so a 50-person payroll can quietly cost far more than it should. The fix is to send in batches and cover energy in bulk.
The burn rate is fixed by the protocol: since TRON Proposal #104 took effect on 29 August 2025, energy burns at 100 sun per unit, and 1 TRX = 1,000,000 sun. So one ordinary USDT payout with no energy on the wallet costs 6.5 TRX in burned TRX. A payout to someone who has never held USDT before needs roughly double — around 130,000 energy, or 13 TRX — because the token contract has to create a fresh balance entry for that address instead of updating an existing one. Onboard five new contractors in one cycle and that single detail adds about 32 TRX of avoidable cost.
What a payroll run actually costs
| Payouts | Energy needed | Burned TRX (100 sun) | Rented at 30 sun | Rented at 10 sun |
|---|---|---|---|---|
| 50 | 3,250,000 | 325 TRX | 97.5 TRX | 32.5 TRX |
| 100 | 6,500,000 | 650 TRX | 195 TRX | 65 TRX |
| 1,000 | 65,000,000 | 6,500 TRX | 1,950 TRX | 650 TRX |
The burn column is protocol-fixed and will not change. The rental columns are illustrative only: energy is priced by an order book in sun per unit of energy, so your real cost is energy × unit price ÷ 1,000,000 TRX. Read the live price off the TronSave market before you size a run — never budget from a number in an article.
Step 1 — Batch the payouts
Instead of 50 separate transactions, use bulk token sending to pay everyone in one streamlined flow. It’s faster, less error-prone, and easier to reconcile.
TronSave’s Bulk-Send tool (SaveSender) takes a CSV of address,amount rows — one line per person — and flags invalid addresses and duplicates before anything is signed, which is exactly where payroll mistakes happen. Duplicates can be merged or kept deliberately, so paying someone twice becomes a decision rather than an accident. Recipients are processed in batches of 100, and because TRC-20 tokens require an allowance there is an Approve step before the first send — itself a contract call that consumes energy, so budget for it the first time you pay from a new wallet.
Step 2 — Cover the energy in bulk
Before the run, rent the energy the whole batch needs. Two easy ways:
- Buy energy in bulk — size it to the number of payouts (≈65,000 each, ≈130,000 for anyone receiving USDT for the first time).
- Auto-Buy — set it once so the paying wallet is always topped up before each cycle.
Either way, you replace burned TRX with cheap rented energy and cut the fee by roughly 60–80%.
Two mechanics to get right. The minimum energy order is 64,000 units, sized just below a single USDT transfer so no order is too small to be useful. And every rental has a duration: 15 minutes, 1 hour, 3 hours, or 1 to 30 days, defaulting to 3 days. Payroll is predictable, so pick a duration covering the whole run plus margin for a re-run — not the shortest option that looks cheapest. When it expires the delegation is reclaimed; if a run is still in progress, the Extend feature pushes the expiry out instead of making you place a fresh order.
Step 3 — Automate recurring payroll
Payroll repeats, so automate it. With the TronSave SDK or API, your payroll script can rent exactly the energy each run needs and fire the batch — no manual steps every payday.
Official SDKs cover TypeScript, Python, Rust, Java and PHP against the v2 API at api.tronsave.io. The production-safe pattern is estimate-then-buy: the estimate call returns the unit price, duration and TRX cost, so your payroll job can abort when the market moves above your ceiling rather than quietly overspending. Nile testnet mirrors the same endpoints at api-dev.tronsave.io — rehearse a new payroll script there, not against real salaries.
Auto-Buy is the no-code version of the same safety net. You nominate the paying address, an amount, a duration, a price tier, and a resource buy threshold: whenever that address’s on-chain energy drops below it, a new order fires automatically. Cap it with a budget limit — a total TRX ceiling or a maximum order count — and a validity window, so the rule can never spend more than you decided. It draws from your TronSave internal balance, so keep that funded ahead of payday.
A quick worked example
Paying 50 contractors, all of whom already hold USDT: budget ≈ 50 × 65,000 = 3,250,000 energy. Rent that in one bulk order, run the bulk send, done — for a fraction of what 50 TRX-burning transfers would cost.
Now the realistic version. Say 45 of them already hold USDT and 5 are new hires with fresh wallets: 45 × 65,000 + 5 × 130,000 = 3,575,000 energy. Add headroom for the approve transaction and a retry or two, and you would sensibly order 3.8–4 million. Burned outright at 100 sun that same run would cost 357.5 TRX; the rental is a fraction of it. The point is not the exact ratio — it is that you must size against the worst case per recipient, not the average.
The failure you are trying to avoid
Under-buy and the run breaks in the middle. A transfer that runs out of energy reverts with OUT_OF_ENERGY: the payment does not arrive, but the fee consumed before the revert is gone. In a batch that means some contractors are paid, some are not, and your accounting no longer matches the chain — the worst possible state for payroll, because now you have to work out who to re-pay without double-paying anyone.
Three habits prevent it. Count first-time recipients explicitly and budget 130,000 for each. Confirm the energy has actually landed on the paying address before you sign the batch — delegation usually shows up within seconds, but “usually” is not “always”. And leave Auto-Buy armed as a backstop so a shortfall triggers a top-up instead of a failure. If a run does break, this guide to failed TRON transactions covers diagnosing which payouts landed.
Tips
- Double-check addresses before a batch — TRON transfers are irreversible.
- Budget extra energy for first-time recipients (~130,000 each).
- Keep a small TRX buffer for bandwidth on the paying wallet.
- Run payroll from a dedicated address, not your treasury — it makes reconciliation and energy budgeting far simpler.
- Ask new hires to send a test transaction first, so their address is already active and holding USDT before the real run.
FAQ
Is this non-custodial?
Yes — energy is delegated to your wallet; you keep custody of funds and keys throughout.
Can I pay in a mix of TRX and USDT?
Yes, but USDT (TRC-20) payouts are the ones that need energy; plain TRX transfers use bandwidth.
Do recipients need to do anything?
No — they just receive USDT. If their wallet is brand new, see account activation.
Can I schedule payroll for a fixed day each month?
The energy side can be automated with Auto-Buy or the API, and Auto-Buy rules can be limited to a validity window. The send itself is triggered by you or your script — TronSave delegates the energy, it does not hold or release your USDT.
How much energy should I over-buy?
Enough to cover every first-time recipient at 130,000 plus one or two retries. Over-buying slightly costs a little; under-buying breaks the run halfway. See the per-transfer energy breakdown to size it precisely.
Run cheaper payroll: rent the energy your batch needs on the TronSave energy market.
