How to compare TRON energy providers
A TRON energy provider comparison usually comes down to two published rates set beside each other, which is the one thing those numbers will not support. Seventeen vendors' rates stood on the table our watch read on 7 September 2026, and scarcely any two described the same good. Here is what a headline rate leaves out, item by item, and a checklist you can run in ten minutes.
What the price is per
The first thing to establish and the one most often skipped. Across the vendors in our catalogue a rate may be quoted per unit of energy, per an order of 65,000 units, per transfer, per 10,000 units per day, or per prepaid command — a fixed-size delivery bought ahead and spent one at a time. All of those are in use at once, and two numbers are not comparable merely because both are small. Nor is conversion always arithmetic: a per-transfer price becomes a per-unit price only once you know how much energy the seller hands over, and what several publish for that is "about 65,000".
What term you are buying
On the 7 September reading, sixteen of the seventeen rows were one-hour rentals and one was a three-day rental. Inside the hourly group alone the spread was wide: the cheapest sat a little over a quarter of what the network charges to burn the same energy, the dearest above four fifths of it. Same product, same day, and the dearest was more than two and a half times the cheapest.
The three-day row (a rate we converted from the unit the vendor publishes, not a figure it printed) is the one worth staring at: it stood above the burn rate itself, so renting for three days cost more per unit than letting the network take TRX. A longer term is a larger commitment, not a discount, and for a transfer that needs energy for minutes it is the wrong good at any headline. Nor is a vendor's own ladder reliably ordered by term — one catalogue entry lists durations, transcribed from its own announcements, whose one-day rate sits above both its six-hour and its three-day rate.
The floor, the ceiling and the shelf
Three fields, and each turns a price into a non-price when it does not fit you.
The floor. Six of the seventeen published no minimum order. Of the eleven that did, the smallest was fifty units and the two largest sat just under the 65,000 a plain transfer needs — a single transfer clears them, nothing smaller does. A floor stays invisible until something below transfer size bounces off it: a top-up, a partial, a first test.
The ceiling. Seven rows carried a maximum order, the smallest under fifty transfers' worth of energy in one order. A batch that clears the price and fails the ceiling has to be split, which is a different integration and not a cheaper one.
The shelf. available_energy is what the vendor says it can actually deliver. Five publish nothing there. Elsewhere in our catalogue one vendor treats that as policy rather than oversight: no endpoint, no header, ask on Telegram. Among the rest that reading ranged from a shelf holding under eighty transfers' worth to one holding tens of billions of units. A low rate on an empty shelf is not a low rate; it is a row.
Published, computed, and how old
Thirteen of the seventeen rows were the vendor's own published number for the size we rank on. Four were derived — the vendor publishes a rate for some other unit or term, and the row is arithmetic on it, marked computed so it is never read as the vendor's own sentence. Both kinds are honest; only one is a quotation.
Age is the other half. Each row carries how far it moved in the previous day, and on that reading thirteen had not moved while four had — every one upward, three in the cheaper half of the table, and the largest had risen by more than two fifths in a day. "The cheapest vendor" is a statement about a moment: a comparison written on Monday and acted on by Friday is a comparison of Monday.
The recipient that has never held USDT
A transfer to an address that already holds USDT needs roughly 65,000 units of energy; to an address that has never held any, roughly 131,000, because the transfer also has to create the recipient's token account (what energy is and where it comes from). If your recipients are mostly new addresses, that larger size is the column deciding your bill, and a table ordered by the smaller one will not show it.
Fifteen of the seventeen quoted the same rate per unit at both sizes, so on those a fresh recipient simply costs twice; two quoted a lower rate at the larger size. A third case is worth telling apart from both — a vendor that will not serve the larger size at all. In our own answer that field is null rather than the price of the nearest size it does sell: a plausible substitute is how a comparison acquires a number nobody published.
How you actually place the order
All but one of the seventeen are reachable through an API, one was web only, and eight also ran a Telegram bot. The channel is not a formality: for several vendors in our catalogue, buying a wholesale package, topping up a prepaid balance, or finding out how much of it is left, is a conversation with a person rather than a request your code can make.
Two more checks, both cheap. Whether the vendor's documentation agrees with the vendor: one catalogue entry documents one delegation lifetime, has a bot that answers three times that, and measures a third figure on chain — three answers to one question, and only the chain binds. And whether anything has to be signed or connected. Receiving delegated energy needs neither: what crosses to your address is energy, no key leaves your side, nothing is approved in the receiving wallet. A seller who wants a wallet connected or a message signed to receive energy wants something the mechanism does not require.
Readings, not quotes
Our watch reads the vendors' feeds every few minutes — through the vendor's API where there is one, off its page where there is not — and writes each answer down with the moment it arrived. Everything is ranked on one basis, because otherwise the rows are not comparable at all: one unit of energy, fees included, for a single transfer of 65,000 units. Where a vendor publishes nothing for the larger size the cell is a dash, not a guess; one that publishes nothing at 65,000 units is not on the table at all.
"Readings, not quotes" is the load-bearing half. Nothing on the table is an offer, ours included; a listed vendor is not a supplier of ours and not a recommendation, and we link to none of them. A row that has answered nothing for a day drops off, and a reading older than a quarter of an hour is marked as behind rather than shown as current. Nor is it the whole market — only the vendors that publish a machine-readable price, answered recently, and are not currently cheaper than we are: a vendor whose price comes under ours drops off the table until the zone moves.
Which is worth contrasting with the comparison tables that circulate. One widely linked provider table is a constant array compiled into the page's own script bundle: it fetches nothing at all, and two of its own hardcoded arrays disagree about the same vendors. A table is not a measurement because it is laid out like one.
Ten minutes, in this order
- Convert every headline to one unit of energy, fees included, first.
- Establish the term it belongs to, and whether a shorter one is sold.
- Read the minimum and maximum order against your real order size, not your average.
- Look for published stock; treat a missing figure as unknown, not as plenty.
- Find the rate for 131,000 units separately if your recipients are new.
- Ask when the number was read, then read it again a day later.
- Establish the channel — API, page or a person — and what a top-up needs on it.
- Confirm nothing has to be signed or connected to receive energy.
Where our own price sits in that ranking is on the table itself: the market page puts our live tariff among the vendors we watch on the same basis, every reading carrying the moment it was taken, and the tariff behind it is on the pricing page. Neither number is printed here, for the same reason none of the others should be trusted from a page: by the time you read it, it has moved.
Our own side of that checklist is one public request, with no key at all: GET /v1/tariff in the API reference →