Почему bandwidth в TRON бесплатна (пока не закончится)

Every TRON account gets 600 free bandwidth points per day. For casual users sending an occasional TRX transfer, this is enough. The transaction feels free, and TRON's marketing proudly claims zero-fee transfers. But for any application processing more than a couple of transactions daily, that free bandwidth runs out fast - and what happens next can be surprisingly expensive if you are not prepared.

This article explains how TRON bandwidth actually works, when the free allocation fails you, what it costs when it does, and how to manage bandwidth at scale.

What Bandwidth Actually Is

Bandwidth is the resource consumed by the raw byte size of every transaction on TRON. Not just smart contract calls - every single transaction, including simple TRX transfers, account updates, and votes. If it touches the blockchain, it uses bandwidth.

The amount of bandwidth consumed equals the transaction's serialized byte size. A typical TRX transfer is 250-300 bytes. A USDT transfer (smart contract call) is 340-400 bytes.

Think of bandwidth as a data quota. The TRON network limits how much data you can write to the blockchain per day. The free allocation gives every account a small daily quota. Exceed it, and you pay.

The Free 600 Bandwidth Points

Every activated TRON account receives 600 bandwidth points per day. These regenerate continuously over a 24-hour window, similar to energy regeneration.

What 600 Bandwidth Gets You

That is it. Two simple transfers, or one USDT transfer, per day. For a personal wallet that sends the occasional payment, this is adequate. For anything else, it is not even close.

Regeneration

Bandwidth regenerates continuously over 24 hours. If you use 300 bandwidth at noon, you will have those 300 points back by noon the next day. But regeneration is linear - after 12 hours, you will have regenerated 150 of those 300 points.

Regeneration rate = 600 / 86400 = 0.00694 bandwidth points per second

Or roughly 25 points per hour. If you exhaust your bandwidth in the morning, you will not have meaningful capacity again until the next day.

When Free Bandwidth Runs Out

When your bandwidth reaches zero and you send a transaction, the TRON network does not reject it. Instead, it burns TRX from your account to cover the bandwidth cost. This is the "invisible fee" that surprises developers who assumed TRON transactions are free.

The Burn Mechanism

The bandwidth burn price is a network parameter set by super representative voting. As of early 2026, the effective bandwidth burn rate is approximately:

1,000 SUN per bandwidth point (byte)

This means:

At $0.25/TRX, a single TRX transfer costs about $0.07 in bandwidth burns, and a USDT transfer costs about $0.09. These numbers look small in isolation. They become significant at volume.

The Volume Problem

Let us calculate bandwidth costs for a payment processor handling different transaction volumes. We will assume all transactions are USDT transfers (350 bytes each) and that only the free 600 bandwidth offsets the first transfer's cost.

Daily Bandwidth Consumption

10 transfers/day:    10 x 350 = 3,500 bytes
  Free bandwidth:    600 bytes
  Burned:            2,900 bytes
  Burn cost:         2,900,000 SUN = 2.9 TRX = $0.73/day

100 transfers/day:   100 x 350 = 35,000 bytes
  Free bandwidth:    600 bytes
  Burned:            34,400 bytes
  Burn cost:         34,400,000 SUN = 34.4 TRX = $8.60/day

1,000 transfers/day: 1,000 x 350 = 350,000 bytes
  Free bandwidth:    600 bytes
  Burned:            349,400 bytes
  Burn cost:         349,400,000 SUN = 349.4 TRX = $87.35/day

Monthly Bandwidth Costs

At 1,000 transfers per day, bandwidth alone costs over $2,600 per month. This is often overlooked because energy costs are larger (roughly $42,000/month at the same volume for USDT transfers), but $2,600 is not negligible. It is the cost of a junior developer or a production server.

Bandwidth vs Energy: A Cost Comparison

For a USDT transfer, how do bandwidth and energy costs compare?

Energy cost (burning):     27.30 TRX per transfer
Bandwidth cost (burning):   0.35 TRX per transfer

Energy is 78x more expensive than bandwidth. This is why most optimization discussion focuses on energy. But bandwidth costs are:

• Unavoidable: every transaction uses bandwidth, even TRX-only transfers
• Not covered by energy rental: renting energy does not include bandwidth
• Cumulative: they add up across all transactions, not just smart contract calls

How to Get More Bandwidth

Option 1: Stake TRX for Bandwidth

Just as you can stake TRX for energy, you can stake TRX for bandwidth. The mechanism is identical - you call freezeBalanceV2 with resource: "BANDWIDTH".

The staking ratio for bandwidth is different from energy. As of early 2026, approximately:

1,000 TRX staked = ~5,000 bandwidth/day

For 100 USDT transfers per day (35,000 bytes needed):

Required bandwidth: 35,000 bytes/day
Free bandwidth:     600 bytes/day
Need from staking:  34,400 bytes/day
TRX to stake:       34,400 / 5 = ~6,880 TRX
Capital at $0.25:   $1,720

This is dramatically cheaper than staking for energy (which would require $900,000 for the same volume). Bandwidth staking is accessible even for small operations.

Option 2: Let It Burn

For many operations, simply burning TRX for bandwidth is the pragmatic choice. The cost is low enough that managing bandwidth staking may not be worth the operational overhead.

At 100 transfers/day, the bandwidth burn cost is $258/month. If staking $1,720 worth of TRX saves you $258/month, the payback period is about 6-7 months (accounting for opportunity cost). Reasonable, but not urgent.

Option 3: Rent Bandwidth

Some energy providers also offer bandwidth delegation. This is less common than energy rental because bandwidth costs are lower and demand is smaller. MERX supports bandwidth delegation for users who need it:

import { MerxClient } from 'merx-sdk';

const client = new MerxClient({ apiKey: 'your-key' });

// Check current bandwidth status
const resources = await client.checkAddressResources({
  address: 'your-tron-address'
});

console.log(`Bandwidth: ${resources.bandwidth.remaining}/${resources.bandwidth.limit}`);

When Bandwidth Becomes Critical

Scenario 1: High-Frequency Trading Bots

A trading bot executing 500+ transactions per day will burn through free bandwidth instantly. If the bot does not hold sufficient TRX for burns, transactions will fail entirely. This is a hard failure - the bot stops working.

500 trades/day x 300 bytes = 150,000 bytes/day
Free: 600 bytes
Burn cost: 149,400,000 SUN = 149.4 TRX/day
Monthly: ~$1,119

For a trading bot, $1,119/month in bandwidth costs is a cost of doing business. But if the bot's TRX balance runs dry, it halts. Monitoring TRX balance for bandwidth burns is as important as monitoring trading capital.

Scenario 2: DApp With Many Users

A DApp where each user has their own address faces a different challenge. Each address gets its own 600 free bandwidth. If users make only 1-2 transactions per day, bandwidth may not be an issue. But if the DApp sponsors transactions (paying on behalf of users), all bandwidth consumption comes from a single address.

DApp address sponsors 10,000 user transactions/day
10,000 x 350 bytes = 3,500,000 bytes
Free: 600 bytes
Burn cost: 3,499,400,000 SUN = 3,499.4 TRX/day = ~$875/day
Monthly: ~$26,250

At this scale, bandwidth staking becomes essential. The required stake of approximately 700,000 TRX ($175,000) would eliminate the $26,250 monthly burn entirely.

Scenario 3: Multi-Signature Wallets

Multi-sig transactions are larger than standard transactions because they contain multiple signatures. A 3-of-5 multi-sig transaction can be 600-800 bytes. This means a single multi-sig transaction can consume the entire daily free bandwidth allocation.

Multi-sig transfer: ~700 bytes
Free bandwidth: 600 bytes
First transfer already exceeds free allocation by 100 bytes
Second transfer: 700 bytes fully burned

Organizations using multi-sig wallets should plan for bandwidth costs from day one.

Bandwidth Monitoring Best Practices

Track Remaining Bandwidth

Before submitting transactions, check your available bandwidth:

const resources = await client.checkAddressResources({
  address: 'your-address'
});

const available = resources.bandwidth.remaining;
const needed = 350; // estimated for USDT transfer

if (available < needed) {
  console.log(`Bandwidth depleted. Will burn ${needed * 0.001} TRX`);
  // Ensure sufficient TRX balance for burn
}

Monitor TRX Balance for Burns

If you rely on bandwidth burning, ensure your address always has enough TRX to cover burns. Set alerts when the balance drops below a threshold:

Alert threshold = max_daily_transactions x bytes_per_tx x 0.001 TRX/byte x 3 days

This gives you a 3-day buffer to replenish before the address runs out of TRX and transactions start failing.

Separate Energy and Bandwidth Concerns

When budgeting for TRON operations, track energy and bandwidth costs separately. They have different characteristics:

• Energy is expensive and can be rented efficiently.
• Bandwidth is cheap and often best handled by burning or modest staking.
• Optimizing one does not optimize the other.

Bandwidth in the MERX Context

MERX provides complete resource visibility through its API. When you check prices or create orders, the platform accounts for both energy and bandwidth requirements:

// Estimate total cost including bandwidth
const estimate = await client.estimateTransactionCost({
  type: 'trc20_transfer',
  from: 'sender-address',
  to: 'recipient-address'
});

console.log(`Energy cost: ${estimate.energyCost} TRX`);
console.log(`Bandwidth cost: ${estimate.bandwidthCost} TRX`);
console.log(`Total cost: ${estimate.totalCost} TRX`);

API documentation and full SDK reference: https://merx.exchange/docs

Заключение

TRON bandwidth is genuinely free - for the first 600 bytes per day. After that, it costs real TRX. The amounts are modest compared to energy costs, but they are not zero, and at scale they represent a meaningful line item.

The key takeaways:

1. 600 free bandwidth covers 1-2 transactions per day. Plan accordingly.
2. After free bandwidth, TRX is burned at roughly 1,000 SUN per byte. A USDT transfer burns about 0.35 TRX.
3. At 100+ transactions per day, consider staking TRX for bandwidth. The capital requirement is modest (thousands, not millions).
4. Always monitor TRX balance when relying on burns. A zero balance means failed transactions.
5. Bandwidth and energy are separate resources. Renting energy does not cover bandwidth.

For developers building high-volume TRON applications, bandwidth management is a minor but essential detail. Get it right once, and it never becomes a problem. Ignore it, and it will surprise you at the worst possible time.

Start monitoring your TRON resource usage at https://merx.exchange.

This article is part of the MERX knowledge series on TRON infrastructure. MERX is the first blockchain resource exchange, aggregating energy and bandwidth providers into a single API.