TRON Bandwidth Explained: Free 600, Costs and Fixes

In short: TRON bandwidth pays for the size of every transaction in bytes. Each activated address gets 600 free points a day, but a USDT transfer of about 345 bytes can use them only if the rest covers it fully. Otherwise TRX is burned at 1,000 SUN per byte (21.10.2026), about 0.35 TRX per transfer.

Most guides talk about energy, because energy is the expensive part of a USDT transfer. Bandwidth is the part that surprises people: a small fee that appears "even though I had free bandwidth", a BANDWITH_ERROR on an address with plenty of USDT, or a hot wallet whose bandwidth bill quietly adds hundreds of TRX a month. This guide covers how bandwidth works, the all-or-nothing rule, what it costs and how to stop paying for it when you do not need to.

What is bandwidth on TRON and what does it pay for?

TRON charges for two separate things. Energy pays for running smart contract code. Bandwidth pays for storing the transaction itself on-chain, measured in bytes. The TRON resource model says every on-chain transaction consumes bandwidth, and smart contract calls consume energy as well.

So:

• A TRX transfer needs bandwidth only.
• A TRC10 token transfer needs bandwidth only.
• A USDT TRC20 transfer needs bandwidth and energy, because USDT is a smart contract. Our TRON energy guide covers the energy side.
• Staking, voting, delegating, permission updates: bandwidth, plus fixed TRX fees for some of them.

Bandwidth is counted from the serialized transaction size. Longer memos, more signatures and more complex contract parameters all make a transaction larger. Each signature adds 65 bytes, per TRON's transaction structure docs.

How much free bandwidth do I get, and how does it refill?

Every activated address receives a daily free allowance. On 21.10.2026 the chain parameter getFreeNetLimit was 600 points, and one point covers one byte. When you use free bandwidth, it refills gradually over the next 24 hours rather than resetting at midnight.

Two details are easy to miss. The allowance belongs to activated addresses only; an address that has never received anything has no free bandwidth. And there is also a network-wide pool for free bandwidth, so free usage must fit both your own remainder and that shared quota.

Why do 600 free points not cover two USDT transfers?

Because of the all-or-nothing rule. TRON's paying for resources page is explicit: each source of bandwidth must cover the transaction's full requirement on its own. Partial use is not allowed.

Walk through a typical morning on one address:

1. 08:00. You have 600 free points. You send USDT (345 bytes). Free bandwidth covers it. Remaining: 255.
2. 08:10. You send USDT again. 255 is less than 345, so the free points are not used at all. The network burns 345 × 1,000 SUN = 0.345 TRX. Remaining free points: still 255.
3. Later that day. As your earlier usage decays over the 24-hour window, the free remainder grows. Once it passes 345 again, the next transfer is free.

So in practice one address gets about one free USDT transfer a day, plus occasional extra ones if transfers are spread out. A plain TRX transfer is smaller than a USDT transfer, so you may fit two of those, but not if you add a long memo.

This is also the answer to "why did I pay a fee when Tronscan shows free bandwidth left?" You had some left, just not enough for the whole transaction.

What happens when I run out of bandwidth?

The network checks sources in a fixed order:

1. Staked or delegated bandwidth on the address (from your own stake or from a rental).
2. Free daily bandwidth, if it covers the full size.
3. Burn TRX for the full size at the current price.

If step 3 is needed and the address has no TRX, the node rejects the transaction before broadcast with BANDWITH_ERROR (spelled without the "D" in the protocol). Nothing is charged, but nothing is sent either. The same code also appears when you cannot pay a memo, multisig or account creation fee. Our TRON transaction failed guide lists this and the other common error codes with fixes.

Bandwidth burning is one of two ways TRON takes TRX as a fee; the other is energy. If you want to understand why the network burns TRX rather than paying it to validators, read why TRON burns TRX.

How is bandwidth different from energy?

The last two rows explain most confusion. You can have 30,000 energy and still pay a large fee, because energy covers part of the cost and TRX is burned for the remainder. With bandwidth the opposite happens: a little leftover free bandwidth does nothing for a larger transaction.

For a single USDT transfer, energy is about 95% of the burn cost. Bandwidth becomes significant when you already cover energy (by staking or renting) and send many transfers from one address.

How much does bandwidth cost a high-volume sender?

Take an address that sends 50 USDT transfers a day and already has energy for each of them. One transfer a day fits in the free allowance; the other 49 burn bandwidth.

• 49 × 345 bytes = 16,905 bytes a day
• 16,905 × 1,000 SUN = 16,905,000 SUN = about 16.9 TRX a day
• Over 30 days: about 507 TRX a month, for bandwidth alone

Compare that with the energy side of the same address: 49 transfers × 64,285 energy would burn about 315 TRX a day if energy were not covered. Bandwidth is the small line, but once energy is handled, it is the line that is left, and over a year it adds up to roughly 6,000 TRX for this one wallet.

A mixed approach is common: rent energy for every transfer, keep the free allowance for the first transfer of the day, and rent bandwidth for the hours when payouts are concentrated. If your payouts run in two batches, morning and evening, two 1-hour bandwidth rentals cover almost all of the burn.

Now spread the same volume across 50 deposit addresses that each send one sweep a day. Each fits its single transfer into its own free 600 points, and bandwidth costs nothing. This is why bandwidth planning looks so different for a single hot wallet versus many deposit addresses. The hot wallet needs a bandwidth plan; the deposit addresses mostly do not, as long as each sends roughly once a day.

How can I get bandwidth without burning TRX?

You have four options.

1. Use the free allowance wisely. If you send occasionally, the 600 daily points cover one USDT transfer a day per address. Spreading transfers over time or over several addresses can be enough.

2. Stake TRX for bandwidth. Stake 2.0 lets you freeze TRX specifically for bandwidth. The bandwidth you receive depends on your share of all TRX staked for bandwidth on the network, so it changes over time. Staked bandwidth regenerates over 24 hours, and unstaking takes 14 days. It is a good fit for steady, high volume with spare TRX in the treasury.

3. Rent bandwidth. A provider delegates bandwidth to your address for a set period. Our bandwidth rental runs for 1 hour, which matches the burst pattern of payout batches: rent before a run of transfers, send them, and let the delegation expire. As with energy, the provider needs only your address, never keys.

4. Keep a small TRX balance. Even with energy covered, a few TRX on the sending address means a missing bandwidth point costs 0.345 TRX instead of failing the transaction. If you hold only USDT, you can swap USDT to TRX to create that buffer.

Different providers handle bandwidth differently: some sell it separately, some bundle it with energy, some ignore it. Our TRON energy rental comparison compares the main types of services, including how they treat bandwidth.

Which transactions use more bandwidth than you expect?

A few cases regularly push transactions above the 345-byte mark or add fixed charges:

• Memos. Exchanges often ask for a memo or tag on deposits to shared addresses. A memo makes the transaction bigger and adds the 1 TRX memo fee on top of bandwidth.
• Multisig accounts. Every extra signature adds 65 bytes, and multisig transactions carry their own 1 TRX fee. A 2-of-3 company wallet pays noticeably more bandwidth per payout than a single-key wallet.
• Creating accounts. Sending TRX to a brand-new address cannot use free bandwidth at all. If staked bandwidth does not cover it, 0.1 TRX is burned on top of the 1 TRX creation fee.
• Complex contract calls. DEX swaps or batch payout contracts carry more parameters and are larger than a simple USDT transfer.
• Approvals and revokes. Setting or cancelling a TRC20 approval is a contract call, so it uses energy plus roughly the same bandwidth as a transfer. Cleaning up a dozen old approvals in one sitting will exhaust the free allowance after the first one.
• Very large payloads. A transaction above the protocol's size limit is rejected with TOO_BIG_TRANSACTION_ERROR, usually because of an oversized memo.

How do I check my bandwidth on Tronscan?

Open your address on Tronscan. The account overview shows bandwidth as used and available, split into free and staked or delegated parts, alongside energy. To see what a specific transaction consumed, open it and look at the resource section: it lists the bandwidth used and whether TRX was burned for it.

A quick routine before a batch of transfers:

1. Check free bandwidth. Below about 345 means the next USDT transfer will burn or use staked or rented bandwidth.
2. Check delegated bandwidth if you rented it. Confirm it has arrived before sending.
3. Check TRX balance. Make sure there is enough to cover burns as a fallback.

For developers, the transaction receipt from gettransactioninfobyid reports bandwidth explicitly: net_usage is the bandwidth consumed from staked, delegated or free points, and net_fee is the TRX (in SUN) burned when those did not cover it. Logging both for every payout shows at a glance whether your bandwidth plan is working. A steady stream of non-zero net_fee values on a hot wallet is the signal to stake or rent bandwidth for it.

Once you know which of the three sources pays for each transaction, bandwidth stops being a mystery fee and becomes a small, predictable line in your costs.