How to Resolve the “Not Enough Bandwidth” Error on TRON: Complete Fix Guide

Your wallet blocks the transfer and shows one line: not enough bandwidth. Users come to me with this almost every week. So I have written the fix up here, starting with the point most guides never mention.

This error has nothing to do with energy. The problem is the size of the data the transaction carries. Bandwidth is what carries that data onto the chain. The message means your bandwidth cannot cover the data size of this transaction. One more thing to note: a charge can sit behind that message. No wallet breaks it out on its own line.

Before the steps, one point worth stating clearly. This is a fairly cheap error to fix on TRON. Where people actually lose money is getting the cause wrong.

Why the error is not an energy problem

The node returns this failure as BANDWITH_ERROR. That spelling is not a typo on my side. The protocol enum spells it without the second D. Clients have to match it as written.

The official description of this code surprises most people. It means the transaction failed before it was broadcast to the chain. It does not mean the account ran short of energy while the transaction was executing. TRON lists several costs behind it: bandwidth, creating a new account, a multi-signature transaction, and a memo. I go through them one by one in the next section.

Too little energy returns a different code, OUT_OF_ENERGY. That one appears only after the transaction has started running. So when a wallet says bandwidth, topping up energy will not clear it. We see users walk into that trap every week. Energy is a separate resource with its own rules, covered in what TRON energy is and how it works.

There is one more key mistake to correct here. Bandwidth is not used only for TRX transfers. A plain TRX transfer consumes bandwidth alone. A contract call consumes bandwidth and energy together. Sending USDT is a contract call, so a USDT transfer takes up bandwidth too. A USDT transfer runs about 350 bytes, against about 267 bytes for a plain TRX transfer.

What the error can be charging you for

The wallet shows one line of error. Several kinds of cost sit behind it. While writing this guide I called getchainparameters. I read the live values from the chain parameter endpoint.

Cost	Chain parameter	Value today	When it applies
Bandwidth shortfall	getTransactionFee	1,000 sun per byte, so 0.001 TRX	The transaction is larger than the bandwidth you have left
A brand-new account	getCreateNewAccountFeeInSystemContract	1 TRX, burned	Your transfer is the first one to reach an address the chain has never seen
Bandwidth for that new account	getCreateAccountFee	0.1 TRX, burned	The same case, but you hold no staked or delegated bandwidth
A second signature	getMultiSignFee	1 TRX	The transaction carries two or more signatures
A memo	getMemoFee	1 TRX	The transaction carries a note or memo

The one most people overlook is the bandwidth cost attached to a new account. The 600 free bandwidth points that come with an address cannot be used to create an account. Only bandwidth from your own staked TRX counts. A delegation from another account counts too. That allowance, and what counts toward it, is explained in what TRON bandwidth is and how it works.

So a first transfer to a brand-new address gets no help from the free allowance. That transfer needs the 1 TRX account creation fee plus 0.1 TRX for bandwidth. Both are charged on top. Neither is taken out of the amount you are sending.

What the 600 free points cover

Every activated account gets 600 free bandwidth points a day, and one point covers one byte of transaction data. A plain TRX transfer takes up about 267 bytes. So the free allowance covers roughly two TRX transfers, with a small amount left over.

These 600 points are not reset in one go at midnight. They recover over a rolling 24-hour window, at about 25 points an hour. After about 11 hours you have enough for another small transfer. That is the difference between waiting until tomorrow and waiting until tonight.

Beyond the basic transfer data, two hidden items quietly make a transaction bigger. Each one costs extra.

First is the memo. The text you type into the memo field takes up bytes and eats into more of your bandwidth. More important, a flat 1 TRX is charged once a memo is attached. The fee is the same whether you write one word or a whole paragraph.

Second is the multisig case. If the wallet you use is a multisig account, every extra signature adds bytes. A multisig fee is charged on top of that.

Bandwidth belongs to the address, not to a single transfer. Every transaction you send from that address shares the same 600 free points. Votes, staking, resource delegations and contract approvals all draw on that allowance. That is why a transfer goes through in the morning and gets blocked by a bandwidth error at night. When one address sends all day, that allowance turns into a planning problem. How small teams plan bulk USDT payouts on TRON works through it at team scale.

How to check your bandwidth before you send

Neither route needs a wallet, and neither needs anything installed. This is the check we run before our own transfers.

Copy this into a browser address bar and replace the address with your own:https://api.trongrid.io/wallet/getaccountresource?address=YOUR_T_ADDRESS&visible=true

Read freeNetUsed against freeNetLimit. That pair is your free bandwidth. Then read NetUsed against NetLimit, which is the total of free and staked. The same reply carries EnergyLimit and EnergyUsed, so one call checks both resources.

If the reply is {}, the address has no record on the chain. An unactivated address has no free bandwidth at all, so there is nothing to compare.

For a visual check, paste your T-address into the search box on tronscan.org. Then open the account page. The Resources section shows bandwidth used against the limit. No wallet connection, no signature, no seed phrase.

How to fix it

1. Read your bandwidth first, with the check above. Do not guess at the number.
2. Work out which cost applies. An ordinary transfer to an address that already holds TRX usually needs bandwidth alone. A first transfer to a new address adds 1 TRX and 0.1 TRX. A memo or a second signature adds 1 TRX each. If the check above came back as {} for your own address, stop here. There is nothing to top up, because that address has nothing to spend. It has to receive a first transfer before it can send.
3. Keep a spare balance. The network can burn TRX to cover a bandwidth shortfall at 0.001 TRX per byte, about 0.27 TRX for a plain TRX transfer. Keep an extra 1 TRX for each flat fee you expect. A 1 TRX transfer to a brand-new address can need about 2.1 TRX in the account, counting the amount you are sending.
4. If only the byte count is short and you can wait, wait. The points return at about 25 an hour.
5. If you cannot wait, freeze TRX for bandwidth. In TronLink the path is Stake 2.0, then Freeze, then choose Bandwidth. The extra bandwidth arrives with the next block. Unfreezing takes 14 days, so lock only what you need.
6. Or ask for a delegation. Any account with TRX frozen for bandwidth can delegate bandwidth to your address, and it works the same way as delegated energy. Give that account your T-address only. No legitimate service ever needs your private key or your seed phrase.
7. Make the transaction smaller. Drop the memo if you do not need it. Drop the extra signatures. Send a batch as ordinary transfers instead of one oversized transaction. If the node answers TOO_BIG_TRANSACTION_ERROR instead, the cause is the same, and a long memo is the usual reason. If the memo is not optional, dropping it is not a fix. An exchange deposit is the usual case, and the memo there is what tells the exchange which account the money belongs to. Keep the memo and hold the extra 1 TRX instead.

Three of these fixes only clear the current transaction. Staking TRX is different. It raises the limit itself, which cuts the problem off at the root.

FAQ

Does “not enough bandwidth” mean I have run out of energy?

No. They are separate resources with separate error codes. A bandwidth shortage fails before broadcast. An energy shortage shows up as OUT_OF_ENERGY, and only after the transaction has started running.

Does a USDT transfer use bandwidth?

Yes. Sending USDT calls a contract, and a contract call consumes bandwidth and energy together. A USDT transfer is about 350 bytes. Topping up energy will not clear a bandwidth error on a USDT send. The energy the same transfer spends is a separate figure, and it is not fixed. See how much TRON energy a USDT transfer needs, and why it doubles.

Why does it fail when there is TRX in the wallet?

Because the balance has to cover the amount you are sending and every fee the transfer triggers. A 1 TRX send to a brand-new address can need about 2.1 TRX. That is 1 TRX for the new account, 0.1 TRX for its bandwidth, and the 1 TRX you are sending.

How do I get more bandwidth?

Three ways. Wait for the rolling refill, freeze TRX and select Bandwidth as the resource, or receive a bandwidth delegation from another account.

Can the free 600 points create a new account?

No. The daily free bandwidth cannot be used to create an account. Only bandwidth from staking, or from a delegation, is eligible.

Sources

1. TRON developer documentation, “Broadcast and RPC error diagnostics” — the response codes returned by /wallet/broadcasttransaction, including BANDWITH_ERROR, defined there as a pre-broadcast failure covering insufficient bandwidth and insufficient TRX for bandwidth, new-account creation, multi-signature and memo costs, and stated not to indicate an execution-phase energy shortage; also TOO_BIG_TRANSACTION_ERROR, described as an oversized transaction body usually caused by a long memo; the note that the spelling follows the protocol enum and must be matched as written; and a pointer to the smart-contract error page for what happens after a transaction is packed into a block, where OUT_OF_ENERGY belongs.
2. TRON developer documentation, “Bandwidth and Energy” — bandwidth measures the byte size of a transaction written to the chain and is required by every transaction except read-only queries; a plain TRX transfer consumes bandwidth only, while contract deployment and contract calls consume both bandwidth and energy; the free allowance is 600 bandwidth per activated account, recovering linearly across a rolling 24-hour window; the burn price is 0.001 TRX per bandwidth; and a transaction consumes bandwidth equal to roughly its serialized byte size, so more signatures and longer parameters cost more.
3. TRON developer documentation, “Account Model” — how an account is created by an incoming transfer, the 1 TRX creation fee burned from the sender’s balance, the 0.1 TRX charge taken instead of bandwidth when the creator holds no staked or delegated bandwidth, and the rule that the daily free bandwidth cannot be used to create an account.
4. Live mainnet chain parameters, read with /wallet/getchainparameters on 20 September 2026, with 79 parameters returned: getTransactionFee 1,000 sun per byte; getFreeNetLimit 600; getCreateNewAccountFeeInSystemContract 1,000,000 sun; getCreateAccountFee 100,000 sun; getMultiSignFee 1,000,000 sun; getMemoFee 1,000,000 sun; getUnfreezeDelayDays 14 days.
5. Live mainnet account resource read with /wallet/getaccountresource against api.trongrid.io on 20 September 2026 — the field set used in the checking section of this guide: freeNetLimit, freeNetUsed, NetLimit, NetUsed, EnergyLimit and EnergyUsed; and the empty response object returned for an address that has no record on the chain.
6. Wallet and custody platform fee documentation — the 1 TRX memo fee charged to the sender each time a memo is attached, the one-time 1 TRX account activation fee charged to the sender on a first transfer to a new address, and the deposit practice on custodial platforms, where the memo is what identifies the account a deposit belongs to.
7. Open-source TRON wallet integration notes — worked fee examples for a native TRX transfer with the free allowance exhausted, which corroborate the 267-byte transfer size and the 1 TRX memo fee used above: 0.266 TRX of bandwidth, 1.266 TRX once a memo is attached, and 2 TRX where a memo is combined with account activation.
8. Industry fee references listing typical transaction sizes — about 267 bytes for a plain TRX transfer and about 350 bytes for a TRC-20 transfer. These are estimates. The real figure depends on the transaction’s own parameters.

The figures here are mainnet values at the time of writing. Chain parameters change by committee proposal, so re-read them before you rely on an exact number. This is not financial advice.