A later contract check can undo an earlier token movement. If you are used to a centralised exchange, the key difference is that a wallet-based swap executes a chain of contract calls as one transaction: they succeed together, or the swap’s on-chain changes are rolled back.
What happens between sending a token and completing the swap?
A swap contract may first ask a TRC-20 token contract to move your input tokens, then call another contract to exchange them. The transaction is not complete just because one step ran: later code can still check the amount received, the minimum output you set, or a deadline.
If one of those checks fails and the failure propagates, the TRON Virtual Machine (TVM) rolls back state changes made in that transaction. The token transfer inside the swap is undone along with the rest of the swap’s changes. This is atomic execution: on-chain, the swap either completes or its in-transaction effects do not stick.
For the full route from wallet to token exchange, read what a TRON swap does. Here, the important detail is that a successful token-transfer call does not guarantee that the whole swap will pass its later checks.
Which transfer checks can cause a revert?
The token contract and the swap contract can each reject a step. Common causes include a balance too low for the requested input, insufficient allowance for the swap contract to spend your tokens, or a token transfer that returns failure or reverts.
Even when the transfer succeeds, the swap can fail afterward. A minimum-output check may reject a quote if the amount available at execution is too low; a deadline check may reject a transaction that arrives too late. Some tokens also deduct a transfer fee, so the swap contract may receive less than the amount requested and reject the trade if its accounting or later conditions do not allow for that difference.
The TRON developer documentation describes REVERT as rolling back state changes, and the TRC-20 interface defines token-transfer functions used by these contracts. In practice, the precise checks depend on the token and swap contract, so a transfer that works in one route does not prove every route will accept it.
What does a failed swap cost, and what stays changed?
A revert does not mean the attempted execution used no resources. TRON charges Energy for smart-contract execution up to the failure point; for a normal REVERT, unused Energy is not charged, while an OUT_OF_ENERGY failure can consume the available Energy budget. The transaction also uses Bandwidth for its on-chain data.
Here is the distinction that often surprises exchange users: if you approved a token allowance in an earlier transaction, that approval is separate state and normally remains after a later swap reverts. But a token transfer performed within the failed swap transaction is rolled back. Check the failed transaction’s receipt for its execution result and, when available, the revert reason; fix the stated condition before submitting a newly prepared swap.
How should you read a swap failure?
Treat a revert as evidence that one condition failed during execution, not as proof that the token was successfully exchanged. For example, suppose you approve 100 USDT in one transaction, then attempt to swap 100 USDT for TRX with a minimum output of 280 TRX. If the route can deliver only 275 TRX when the contract checks, the swap can revert: the in-swap transfer is undone, but the earlier allowance remains.
A receipt marked REVERT points to an intentional contract abort such as a failed condition; OUT_OF_ENERGY points to an execution budget that was too small to finish. Those outcomes differ in resource cost, even though both roll back the swap’s state changes. Read the receipt before changing your amount or retrying, since raising the minimum output or changing other conditions can alter the trade you are authorising.
My practical tip: before signing, compare the quoted output with your minimum-output setting and leave a sensible margin for price movement; after any failure, use the receipt to identify which check to revisit.
Top comments (0)