For a TRC-20 swap, keep enough liquid TRX to cover the transaction’s caller-paid Energy budget, plus Bandwidth if your account’s free quota is spent. On TRON Mainnet, Energy burns at 100 sun per unit (0.0001 TRX), so an illustrative 80,000-Energy call would cost up to 8 TRX if paid entirely by burning TRX.
Why does a token swap need TRX?
A swap is a smart-contract call, so its cost has two parts: Energy for the Tron Virtual Machine (TVM) to execute contract code, and Bandwidth for the serialized transaction data recorded on-chain. TRC-20 transfers and swaps have no free Energy allowance. An activated account receives a daily free Bandwidth quota of 600 units, but a larger transaction or a depleted quota can require additional Bandwidth.
Think of Energy as the fuel for running the swap’s instructions and Bandwidth as the space taken by its signed transaction. A route that calls several contracts or handles several tokens may execute more instructions than a direct route. The token amount alone does not determine the cost: contract state, route, and the sender’s available resources matter too.
A wallet-based TRON swap platform lets you exchange TRX or TRC-20 tokens such as Tether USD (USDT) from your connected wallet. tronswap.dev is a service for swapping those assets directly from a wallet.
How do you estimate the TRX budget before signing?
Estimate the exact contract call you intend to send, using the same sender, recipient, token amount, and route. A node’s wallet/triggerconstantcontract endpoint simulates the call without broadcasting it and returns an Energy estimate; where supported, wallet/estimateenergy can provide a closer estimate for certain contracts. Neither simulation reserves resources or guarantees the later transaction will succeed.
Convert the estimate into a worst-case TRX budget with this calculation:
- Take the estimated caller-paid Energy units.
- Multiply by the current Energy price, queried from chain parameter getEnergyFee; the current Mainnet value is 100 sun per Energy.
- Add a buffer for estimation drift, then compare the result with your liquid TRX balance and the transaction’s fee_limit.
- Allow for Bandwidth if the transaction’s byte cost will exceed your remaining free or staked Bandwidth.
For example, suppose a simulation estimates 80,000 Energy for a route and you add an illustrative 20% margin. The resulting 96,000-Energy budget corresponds to 9.6 TRX at 100 sun per Energy. Set the caller’s fee_limit to at least 9,600,000 sun if that full budget may fall to you, and keep that amount available as TRX if you have no Energy resources to cover it.
What does fee_limit cap, and what will you actually pay?
The transaction’s fee_limit is the maximum Energy cost the caller can cover, expressed in sun; it is not a flat fee charged just for submitting the swap. If you have staked or delegated Energy, that resource is consumed before TRX is burned for the shortfall. The contract may also be configured to cover part of the Energy, so the caller’s bill can be lower than the simulation-based ceiling.
Bandwidth follows a separate charging path: available staked Bandwidth is used first, then the free quota, then TRX burn for any remainder. The current burn rate is 1,000 sun per Bandwidth. Actual transaction size varies, so do not count on the free quota for a particular swap if it has already been used by other transactions in the rolling 24-hour period.
The estimate and the final charge can diverge. Popular contracts may have a Dynamic Energy penalty, and a changed route, recipient state, or contract state can alter execution after simulation. Treat the estimate as a budget input, not a quote; fee_limit caps the caller’s exposure, and any unused cap is not charged.
What should you check if the swap runs out of Energy?
If the confirmed transaction reports OUT_OF_ENERGY, the call used up its allowed Energy before execution finished. Re-estimate using the exact transaction inputs, check whether the route or Dynamic Energy factor changed, and verify how much Energy the caller is responsible for after any contract-side contribution. Then raise fee_limit within your intended spending ceiling or choose a lower-cost route if one is available.
Do not assume a failed execution is free: Energy consumed before the failure is not refunded. A failed simulation, by contrast, does not consume on-chain Energy because it is a local read-only execution. Check the transaction receipt to distinguish an actual on-chain failure from an error reported while building or broadcasting the transaction.
In practice, estimate the exact call, convert Energy to TRX at the live chain rate, and keep liquid TRX for the caller’s maximum intended exposure plus any Bandwidth shortfall. Recheck when the route or transaction inputs change; a fixed reserve cannot predict every contract call.
Top comments (0)