To keep a TRC-20 swap from failing for lack of resources, compare its simulated Energy use with your available Energy and transaction fee_limit; at 100 sun per Energy, an illustrative 250,000-Energy call equals 25 TRX. The estimate depends on the contract, route and current chain state, so a token transfer estimate is not a reliable substitute for a swap estimate.
A wallet swap can involve contract calls to a router and token contracts, with an approval call sometimes required as well. For the full wallet flow, see how TRON swap works from a wallet; here the focus is diagnosing and budgeting the Energy for a specific swap that is about to be sent.
Which four checks decide whether it can run?
- Estimate the actual swap call. Use the sender address, router, calldata and route intended for the transaction.
- Check usable Energy. Include staked Energy and any amount the contract creator covers.
- Set a sufficient fee_limit. It is denominated in sun and caps the caller’s Energy budget.
- Check whether approval is a separate call. An approval may need its own Energy and transaction.
These checks answer different questions: whether execution is affordable, whether the budget allows it to finish, and whether another transaction must happen first. A TRON swap quote alone does not establish any of those; the quote’s route and the transaction’s execution cost are related, but they are not the same value.
How do you estimate the Energy for this route?
Simulate the exact contract call before broadcast. TRON’s wallet/triggerconstantcontract endpoint runs a read-only simulation and returns an energy_used estimate; wallet/estimateenergy can return energy_required for successful execution, but node support for that endpoint varies. Neither simulation consumes on-chain Energy.
Use the actual owner address, contract address, function selector and encoded parameters. For a swap, changing the input amount, token path, recipient or router changes the call being simulated; copying an estimate from another route or a token’s ordinary transfer is not a sound budget. Simulation also reflects the node’s observed state at that moment, so the result can shift before the transaction executes.
Consider a route that estimates at 250,000 Energy. At the example rate of 100 sun per Energy, the equivalent fee is 25,000,000 sun, or 25 TRX, if the caller had to burn TRX for the entire amount. That is a conversion example, not a prediction that this route will cost 25 TRX: available staked Energy and the contract’s resource-sharing settings can reduce the caller’s burn.
What does fee_limit cap?
fee_limit is the maximum Energy budget the caller can cover for a smart-contract call, expressed in sun; it is not a guaranteed charge. With the example rate, a 30 TRX limit corresponds to 300,000 Energy. If the call exceeds the available caller budget before finishing, it fails with OUT_OF_ENERGY; Energy already consumed is still charged.
That caller budget can be met by staked Energy or by burning TRX, subject to the transaction’s limit. A contract may also cover a share of Energy under its resource settings, but the caller should not assume it will: the contract’s subsidy can be limited, unavailable or consumed by other activity. Check the account’s resources and set the limit with enough room for the estimate and expected variation. The current maximum is a chain parameter, so query it rather than relying on a saved value.
What should you do if the swap fails?
First inspect the transaction receipt and error. OUT_OF_ENERGY means the execution ran out of its allowed Energy; a contract revert can instead indicate a failed condition such as slippage protection. These failures have different remedies: raising the Energy budget does not fix a stale quote or a route whose minimum output is no longer attainable.
If no transaction was broadcast, refresh the simulation using the exact proposed call, check account resources, and adjust the budget if the estimate supports it. If a transaction failed on-chain, remember that consumed Energy is not refunded; correct the cause before sending another call. If the wallet also requires token approval, treat that approval as its own contract transaction and resource check.
For a pending swap, the practical decision is whether the exact call fits both the available resources and the fee_limit, with a buffer for execution changes. Simulate the route, verify the approval state, and read the receipt if it fails; those checks turn an Energy error into a specific next step.