> For the complete documentation index, see [llms.txt](https://staking-primer.gitbook.io/staking-primer-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://staking-primer.gitbook.io/staking-primer-docs/how-does-a-tron-swap-work-for-an-app-integrator.md).

# How Does a TRON Swap Work for an App Integrator?

A TRON swap exchanges one asset for another on the TRON blockchain through a transaction that takes an input asset and delivers an output asset. For an app, the useful result is a confirmed output balance in the user’s wallet, with the amount and execution cost recorded. A quote alone does not establish either result.

### What assets can it exchange?

It commonly exchanges TRC-20 tokens, the fungible tokens defined by TRON’s token contract standard. Both assets must be available through the route you select on the same chain. A TRC-20 token swap does not move an asset to another blockchain; that requires a separate bridge or conversion process.

Some routes also accept or return native TRX, often by handling a wrapped representation inside the transaction. Check that support explicitly before presenting a pair. Identify tokens by contract address and chain, then read their decimals from the contract: a ticker can be reused, and an amount of 1 token with six decimals is passed to a contract as 1,000,000 base units.

### How does the exchange settle?

A TRON swap usually settles through a router contract that sends the input to one or more liquidity pools and returns the output to a specified recipient. A pool is a smart contract holding assets available to trade; its pricing rule changes the exchange rate as its balances change. A route may use one pool or several connected pools when there is no suitable direct pair.

For a TRC-20 input, the user generally signs an approval transaction before the router can spend it. The token’s *allowance* is the amount approved for that router; an exact-amount approval limits what it can draw, while a larger allowance avoids another approval on a later trade. Approval consumes network resources and can succeed even if the subsequent exchange never happens, so track the two transactions separately.

The app then submits the exchange transaction with an input amount, recipient, minimum acceptable output and deadline. The contract either completes under those conditions or reverts; it cannot promise the earlier quote after pool balances have changed. After execution, use the transaction receipt and the recipient’s balance change to establish what was actually delivered.

### How do you judge the quoted output?

Judge a quote by the output after pool fees and price impact, then set a separate limit for movement before execution. Price impact is caused by the trade itself. Slippage is the additional change between quoting and execution, often caused by other trades reaching the pool first.

Consider a simple pool holding 100,000 units each of tokens A and B, with no fee. Under a constant-product pricing rule, selling 100 A returns about 99.9 B, while selling 10,000 A returns about 9,090.9 B. The larger trade gets roughly 0.909 B per A instead of roughly 0.999 because it consumes much more of the pool’s available B. Fees reduce both outputs further.

For a TRON DEX swap, compare routes using the same input amount and include every pool fee; a route with more hops can still yield more if its pools are deeper. If you need the output delivered on TRON to the user’s own address, choose a [TRON swap](https://tronswap.dev); if the required output is on another chain, account for that separate transfer when comparing the whole journey. Set the minimum output from a fresh quote: for example, a quote of 100 tokens with 0.5% slippage tolerance means accepting no fewer than 99.5. That tolerance does not undo price impact already reflected in the quote.

### What does it cost to execute?

Execution costs include the pool fee and TRON network resources: Bandwidth for transaction size and Energy for smart contract work. An approval and an exchange are separate contract calls, so budget for both when approval is needed. Staked or delegated resources can cover some usage; otherwise the account burns TRX.

Energy use depends on the contracts and route, so estimate the actual call before setting its *fee\_limit*, the caller’s Energy budget expressed in TRX. At a rate of 0.0001 TRX per Energy, for example, 100,000 uncovered Energy would burn 10 TRX, plus any uncovered Bandwidth cost. Read the current chain parameters rather than fixing that rate in an app. A fee limit below the required budget can cause a failed transaction that still consumes resources, while the limit itself is not the fee paid.

### How should an app build and verify the trade?

Build it from verified contract addresses, token decimals and a fresh route quote. Convert amounts to integer base units, check the user’s input balance and allowance, and make sure the account can cover the estimated resources. Submit an approval only when required; after it succeeds, refresh the quote before constructing the exchange transaction with its minimum output and deadline.

Keep the transaction ID when broadcasting. A successful broadcast response means the node accepted the submission, not that the contract executed successfully. For a completed smart contract call, check the execution result in the solidified receipt through */walletsolidity/gettransactioninfobyid*, then reconcile the actual output amount. If a request times out, query the original transaction ID before creating a replacement; an unobserved transaction may already have executed.

I would start with a small trade on the intended pair, record the quoted and received amounts alongside Energy used, and use those observations to set the app’s quote refresh and resource budgets. Once that path reconciles from approval through solidified receipt, the same checks can support larger trades.