We kept switching TRON energy providers to save on USDT fees. Then we built a router

Alex — Tue, 03 Nov 2026 15:00:00 +0000

Our team worked on a project that processed customer payments and handled daily outgoing USDT (TRC-20) transfers. For the first year, a surprising share of our engineering time didn't go into the project itself, but into one tedious question: which provider should we buy TRON energy from this month?

This is how that went, what it taught us, and why we ended up building a separate service for it.

Why a USDT transfer on TRON is not free

A TRC-20 transfer runs a smart contract, and TRON meters contract execution in energy. If the sending address has no energy, the network burns TRX instead, at the chain parameter getEnergyFee — 100 SUN per unit of energy today (1 TRX = 1,000,000 SUN).

How much energy a USDT transfer needs depends on the recipient, not the sender:

Recipient	Energy per USDT transfer	Burned without energy
already holds USDT	64,285	≈ 6.43 TRX
holds no USDT (new or emptied address)	130,285	≈ 13.03 TRX

At a few hundred transfers a day, this was a real cost for the project. The usual fix is to rent energy: a provider delegates energy to your address for a short window (an hour is typical), you broadcast the transfer, and the delegation ends. Renting that same 65k energy costs a fraction of burning TRX directly.

Straightforward enough in theory. The hard part is choosing whom to rent from.

Provider #1, #2, #3… and back to #2

iTRX. Our first provider. At first we topped up the balance by hand, later we automated it.
TronZap. It became cheaper, so we added it and moved orders there.
FeeSaver. Cheaper again. It became our main provider for most of the first half of 2026. At the time it took orders only through its API or its Telegram bot, with no web interface, so for one-off manual transfers we kept using TronZap in the browser.
TronZap, again. Its price dropped below FeeSaver's, so we switched back.
Netts. An aggregator that showed offers from several suppliers. Rates were generally competitive, though buying directly from some of its upstream suppliers, such as CatFee or SoHu, was occasionally cheaper. Once Netts added its own stake, it sometimes came out ahead.

None of these providers did anything wrong. The market simply moves, and each switch was the right call at the time.

What the switching actually cost

The price difference was the visible part. The invisible part was everything around it:

A new integration every time. Each provider has its own API, its own order states and its own error codes.
A balance in every service. Each provider requires a prepaid balance, meaning capital was fragmented across multiple services, each needing dedicated refill jobs and alerts.
One provider for automated backend jobs, another for manual operations. The cheapest provider had no web interface for ad-hoc transfers, so manual payouts went through a second service with its own balance.
Prices change by the hour. The cheapest provider at 03:00 UTC is often not the cheapest at 15:00. Monitoring quotes manually doesn't scale.
Outages. When a provider runs out of energy at peak time, transfers either wait or burn TRX. Every integration needed a fallback anyway.

The price spread is substantial. At the time of writing, the quotes for one hour of 65,000 energy across the providers we track ranged from 28 to 67 SUN per unit — about 1.8 TRX at the bottom, 4.4 TRX at the top, for the same transfer.

At some point we noticed we were dedicating more engineering bandwidth to energy logistics than to the project itself.

Solving it once

So we stopped choosing a provider and started routing:

Poll each provider's API for rates every minute.
For each order, pick the cheapest provider that can fill that amount right now.
If it fails or runs out, send the order to the next one automatically.
Check the delegation on chain before the transfer goes out.
Keep one balance instead of one per provider.

Two lessons shaped the design. First, keep your existing code: most teams already integrate with an existing provider API, so the router accepts the request formats of 22 popular services — switching means changing only the base URL and API key. Second, never trust an order status alone: the only proof that energy arrived is the delegation on chain.

If you send USDT on TRON, check these five things

Read the recipient's USDT balance first. It determines whether the transfer requires ~65k or ~131k energy.
Rent per transfer, not per day, unless your volume is steady around the clock.
Benchmark pricing during your actual peak volume hours, rather than spot-checking at arbitrary times.
Keep a second provider configured, so an outage never turns into burned TRX.
Verify the delegation on chain before you broadcast the transfer.

Where this ended up

We eventually extracted this router into a standalone service, TEnergy, so other teams handling USDT payouts wouldn't have to reinvent provider routing. The live price board and the API docs are at tenergy.me.

To cover server infrastructure and the prepaid balances we keep at every provider, our pricing is pass-through: you pay the rate of the provider that fills the order, plus a routing fee of 2–5% depending on your 30-day volume.

For the dev.to community: open tenergy.me/?promo=DEVTO3 or enter promo code DEVTO3 in the dashboard (Top up → Promo code) to set the routing fee to 3% for your first 30 days.

We have more material than fits here: on-chain data on how much TRX the network burns every day and who actually supplies the energy, and what we learned building gasless USDT and contracts for cheap account activation and payout splitting. If any of it would be useful to you, let us know and we'll write it up.

Disclosure: we build TEnergy. Energy figures: mainnet chain parameter getEnergyFee and measured USDT transfers; price range: TEnergy price board at the time of writing.