Save up to 50% on USDT transfers — rent TRON energy instead of burning TRX

Free trial

Save up to 50% on USDT transfers — rent TRON energy instead of burning TRX

Free trial

Save up to 50% on USDT transfers — rent TRON energy instead of burning TRX

Free trial

FeeLimit is a mandatory parameter in TRON smart contract transactions that defines the maximum Energy budget, denominated in TRX, that a user is willing to cover for execution — combining both staked Energy and any TRX burned to make up a shortfall.

• Default value: 0 TRX (unless configured by the calling application or wallet).

• Maximum value: 15,000 TRX (the current upper limit enforced by the TRON network protocol — this is a chain parameter and can change via SR vote, so it shouldn't be hard-coded in production code).

• Core purpose: It acts as a safety mechanism to cap transaction costs. If a smart contract execution encounters an error, an infinite loop, or high network congestion, the FeeLimit prevents the transaction from completely draining the sender's wallet balance.

What is FeeLimit on TRON?

FeeLimit is a code-level instruction inside a transaction's raw data, setting the maximum Energy budget the Tron Virtual Machine will let a transaction consume during smart contract execution.

• Technical calculations occur strictly in sun, the smallest unit of the network (1 TRX = 1,000,000 sun).

• The field caps the caller's total Energy budget — staked Energy plus any TRX burned to cover the rest — not just the burn portion on its own. Once that combined ceiling is hit, execution stops with an OUT_OF_ENERGY error.

• The protocol restricts this configuration strictly between the 0 TRX baseline and the 15,000 TRX network ceiling.

FeeLimit vs. the actual fee you pay

FeeLimit is a maximum spending ceiling. The network only burns liquid TRX for the portion of Energy consumed during execution that isn't already covered by the caller's staked Energy — and only up to the amount FeeLimit authorizes.

A high FeeLimit provides a crucial financial safety margin to prevent transaction crashes. It never increases your actual transaction expenses.

How FeeLimit, Energy, and Bandwidth work together

TRON transactions consume Bandwidth and Energy. Lacking staked resources, the network burns liquid TRX to buy Energy. Your FeeLimit must equal or exceed the required Energy multiplied by the dynamic, governance-set Energy Price. If the Energy Price increases, your FeeLimit must scale up to prevent failures.

Why FeeLimit causes contract execution failures

The TVM executes contract instructions sequentially. If staked resources run out and your FeeLimit is too low to buy the remaining Energy, execution fails instantly. All burned TRX is permanently lost because nodes must be compensated for the computational power spent up to the failure point.

Common execution errors and what they mean

FeeLimit too low vs too high

Finding the right balance for your FeeLimit avoids severe financial and operational risks:

• The risk of a low limit: Setting the boundary too tight triggers an OUT_OF_ENERGY failure. The network permanently consumes your burned TRX to pay for node processing time, leaving you with lost funds and a failed transaction.

• The balance lock risk: Setting an excessively high limit doesn't require your wallet to hold that entire balance upfront — the network only draws on your actual TRX balance to cover the Energy genuinely consumed. The practical risk is different: if your balance is too low to cover the real execution cost, the transaction fails regardless of how high FeeLimit is set, since FeeLimit is a ceiling, not a reserved or locked amount.

• The infinite loop risk: If you interact with a buggy or malicious contract, an inflated FeeLimit allows the Tron Virtual Machine to continuously burn your funds all the way up to that high ceiling, maximizing your financial loss.

How to estimate Energy consumption

To configure an accurate FeeLimit, you must estimate the transaction's Energy footprint using programmatic endpoints or graphical tools.

Node HTTP API endpoints

• /wallet/triggerconstantcontract: The most reliable endpoint. It runs a local, read-only dry run on the node and returns a precise energy_used integer.

• /wallet/estimateenergy: A specialized estimation API for executions or deployments. It requires vm.estimateEnergy = true to be enabled in the node configuration file; otherwise, developers default back to constant calls.

Estimating calls vs. deployments

• Contract calls: Supply the sender address, contract address, function selector, and parameters to the constant call endpoint. Multiply the returned energy_used by the dynamic network price and add a 20% safety margin.

• Contract deployments: The node evaluates raw bytecode size and constructor initialization logic. You must explicitly include ABI-encoded constructor arguments in your simulation payload to prevent resource underestimation and subsequent OUT_OF_ENERGY deployment failures.

No-code verification methods

• TronScan explorer: Search the target contract address on TronScan, open its transaction history, inspect recent identical operations, and check the "Resources Consumed" section.

• Wallet preview engines: Modern interfaces like TronLink run automatic background simulations upon initiating a transaction, displaying expected Energy costs and checking wallet balance sufficiency before you sign.

How to determine the right FeeLimit value

Accurately calculating the FeeLimit requires analyzing current network congestion, the smart contract's baseline resource consumption, and active protocol penalties. A precise setup ensures successful execution without setting a ceiling too low to succeed.

The dynamic Energy model explained

The Dynamic Energy Model is a protocol safeguard designed to protect the TRON network from overloads caused by high-demand smart contracts like USDT.

• Congestion penalties: When a specific contract is called frequently over a maintenance cycle (recalculated roughly every 6 hours, not instantly), the network applies a multiplier factor to its energy consumption for the next cycle.

• User impact: A standard TRC-20 USDT transfer to a wallet that already holds USDT typically requires roughly 64,000 energy; a transfer to a wallet that has never held USDT can require around 130,000 energy or more, largely due to additional initialization plus the current dynamic penalty factor.

• Cost volatility: Because energy requirements fluctuate based on contract traffic and the maintenance-cycle penalty factor, relying on hardcoded static limits frequently causes unexpected OUT_OF_ENERGY failures.

Three methods to calculate FeeLimit

The wallet or script runs a read-only transaction dry run right before broadcasting. You take the baseline energy returned by the node, multiply it by the current network energy price, and add a safety margin to absorb changes in the penalty factor before your transaction lands.

Systems query the contract's current penalty multiplier once per maintenance cycle (roughly every 6 hours) and size the fee limit against that cached value — a lighter-weight approach than simulating before every single call, at the cost of some staleness if conditions shift mid-cycle.

This conservative approach multiplies the contract's baseline energy by the absolute maximum penalty multiplier permitted by TRON network governance. This configuration is designed to guarantee transaction success even during extreme, unexpected network overloads, though it typically over-budgets and requires the wallet to be able to cover the higher cap.

Recommended FeeLimit values for common operations

If you cannot calculate the resource costs programmatically prior to each transaction, utilize these standard manual targets for full liquid TRX burning:

How to set FeeLimit step by step (by tool)

Configuration methods vary depending on whether you are interacting directly with the protocol raw data, utilizing developer SDKs, or executing transactions through graphical user interfaces.

Setting fee_limit in the Transaction (raw_data)

At the blockchain protocol level, every smart contract transaction object contains a fee_limit field located directly within its raw_data block.

• The core requirement: The value assigned to this field must always be defined as an integer denominated in sun.

• Conversion example: To configure a safe maximum budget of 150 TRX, you must write the value as 150000000 inside your transaction construction payload.

Via Node HTTP API

When constructing a smart contract transaction via direct HTTP requests to a TRON Full Node, the fee_limit parameter must be supplied inside the JSON payload body.

• Target endpoints: This parameter is explicitly required by the /wallet/triggersmartcontract endpoint for executing contract functions and the /wallet/deploycontract endpoint for publishing new contracts.

• Format: The value inside the JSON payload must be passed as a standard integer represented in sun.

Via TronWeb

In JS/TS, define your spending cap using the feeLimit property (denominated in sun) inside the options configuration object:

• Contract calls: Pass within .send(), for example: contract.methodName().send({ feeLimit: 120000000 }).

• Deployments: Include directly inside the options parameter of the tronWeb.contract().new() function.

• Manual building: Add inside the options argument of tronWeb.transactionBuilder.triggerSmartContract().

Via Trident (Java)

Developers utilizing the official Java SDK, Trident, must programmatically assign the resource ceiling using the native transaction builder classes.

• Builder pattern: When using the ApiWrapper to prepare a smart contract trigger or deployment, you must call the setFeeLimit method directly on your active TransactionBuilder instance.

• Data type: The setFeeLimit() method strictly accepts a long primitive value denominated in sun, which is attached to the transaction payload prior to signing.

Via TronBox

When compiling, testing, and executing smart contract migrations using the TronBox framework, configurations are managed globally or on a per-transaction basis.

• Global defaults: Open the tronbox.js configuration file and add the feeLimit property directly inside your targeted network object block (such as mainnet or shasta testnet).

• Per-transaction overrides: For unique deployment scripts, pass a custom options object containing the transaction parameters directly into your migration deployment commands.

Via TronIDE

For developers utilizing the browser-based TronIDE development environment, adjusting the spending ceiling requires zero code adjustments.

• Interface field: Navigate to the "Deployment & Run Transactions" control panel located on the left side menu.

• Input values: Locate the explicit text field labeled FEE LIMIT. This specific interface field takes inputs directly in TRX rather than sun, automatically converting your input into the protocol-level unit when you click compile or deploy.

In the TronLink wallet

End-users interacting with decentralized applications handle FeeLimit configurations through the graphical user interface of the TronLink browser extension or mobile application.

• Automated baseline: TronLink automatically simulates the transaction bytecode in the background and presents a pre-calculated safe fee limit on the signature confirmation screen.

• Manual customization: To adjust this value manually, click the settings or edit icon next to the transaction fee breakdown on the confirmation pop-up window, input your custom TRX cap, and proceed to sign the transaction.

Best practices to prevent contract wxecution failures

To eliminate transaction errors and avoid wasting funds on failed node executions, implement this operational checklist:

1. Apply a dynamic buffer: Always calculate energy requirements programmatically right before broadcasting. Add a 20% to 30% safety margin to the result to absorb real-time network fluctuations.

2. Verify wallet liquidity Prior to Dispatch: Ensure the sending wallet holds a liquid TRX balance that is equal to or greater than the specified FeeLimit. If the balance is even slightly lower, network nodes will reject the transaction immediately.

3. Monitor governance parameter updates: Keep track of TRON DAO governance votes. Changes to base energy pricing alter the underlying cost structure, meaning static values in older scripts must be adjusted.

4. Optimize code structures: Design smart contracts with lean execution pathways, clean up unused storage variables, and minimize expensive loops to lower the base energy requirement natively.

Renting vs staking Energy and FeeLimit

Users avoid burning liquid TRX by staking tokens or renting energy. However, setting your FeeLimit to zero is a critical mistake. If TRON’s Dynamic Energy Model spikes transaction costs or your allocated energy pool falls short, the network automatically switches to burning liquid TRX. Without a configured FeeLimit, the transaction fails instantly with an OUT_OF_ENERGY error, wasting your resources. A safe FeeLimit acts as essential insurance, providing a vital financial fallback the moment your staked or rented Energy is completely exhausted.

FeeLimit FAQ

Conclusion

Mastering FeeLimit ensures secure, cost-efficient TRON transactions. It protects your wallet from excessive drains while providing sufficient financial runway. Avoid static hardcoding; pair energy renting with real-time simulations to slash costs, and always maintain a safe margin to eliminate unexpected execution failures.