Sunswap is TRON’s routed AMM for TRC-20 trades

Pool depth governs execution quality

Broadly, Sunswap trades receive worse execution when an order is large relative to the reserves on its selected route. That ratio is the central trade-off.

V2 pools follow x × y = k, so buying one reserve reduces its balance and raises its marginal price. V3 and V4 concentrate the same basic relationship inside chosen price ranges. A route with deeper active liquidity absorbs a larger order with less price impact, while a thin route moves further along its curve. The quote therefore changes with order size even when the reference market has not moved. The Universal Router compares reachable pools across Sunswap versions, SunCurve and the USDD PSM before presenting an output.

Price impact comes from your own order; slippage comes from pool changes before transaction inclusion.

Slippage tolerance sets a hard floor on the received amount. If pool state changes beyond that floor before execution, the call reverts and the input remains in the wallet, although the failed call still consumes some network resources. A wide tolerance raises the range of acceptable execution; a narrow setting rejects more state changes. Price impact already exists in the quote, while slippage appears between quoting and inclusion.

A token pair can exist on-chain yet lack enough active liquidity for a useful quote. The router needs a reachable sequence of pools, and concentrated liquidity only counts where the present price lies inside provider ranges. Contract identity, active depth and minimum output therefore deserve attention before the signature. Set the maximum acceptable movement after reading those three values.

When should you use SunCurve or the USDD PSM instead?

SunCurve suits closely pegged stablecoins, while the USDD PSM handles eligible 1:1 conversions without AMM price impact. SunCurve uses a StableSwap curve and charges a 0.04% or 0.01% pool fee, while the PSM charges no service fee and still consumes TRON resources. Uniswap, Curve and PancakeSwap serve liquidity on other chains, so using them adds a chain and asset-transfer dependency. For TRC-20 pairs already on TRON, the Sunswap route avoids that extra step. The pair being traded decides the right venue.

Four protocol generations behind one route

The Sunswap router combines four protocol generations and selects a path from their available liquidity.

V1 used TRX as the bridge asset, so a token-to-token route crossed two pool legs through TRX. V2 opened direct pairs between any two TRC-20 tokens and kept the constant-product curve. V3 added concentrated liquidity, four static fee tiers and non-fungible position receipts. V4 retained concentrated liquidity while adding native TRX pairs, Hooks, a Singleton contract and Flash Accounting. These contracts continue to coexist, which lets the Universal Router use legacy liquidity alongside newer pools instead of forcing every trade onto one generation.

The Universal Router treats those versions as route components rather than separate destinations. It also reaches SunCurve, the PSM and the HTX-SUN module within one command flow. Exact-input swaps define the amount sold and a minimum output, while exact-output swaps define the amount wanted and a maximum input. Permit2 supplies the token authorization layer. Inspect the displayed path and output limits before signing the assembled transaction.

Pool fees and TRON resources set the total cost

A Sunswap trade pays the selected pool fee plus the TRON resources consumed by contract execution.

V1 and V2 charge 0.3% per swap. In V2, 0.25% goes to liquidity providers and 0.05% supports SUN buyback and burn. Sunswap V3 and V4 publish four static fee tiers: 0.01%, 0.05%, 0.3% and 1%. A V4 pool can instead attach a Dynamic Fee Hook that adjusts its rate and caps it at 5%. These percentages apply to the input flowing through each pool, so a multi-hop route can cross more than one fee-bearing leg. The quote reflects the assembled route and its expected output.

TRON meters transaction bytes as Bandwidth and smart-contract computation as Energy. An activated external account receives 600 free Bandwidth per day on a rolling 24-hour cycle, but Energy has no free daily quota. Staking or delegation supplies either resource. If those balances are insufficient, the network burns TRX under its chain parameters, so the fallback cost reflects the route’s computation and transaction size. One TRX equals 1,000,000 sun, the chain’s smallest native unit. Leave enough TRX to cover every approval and swap call that the wallet presents.

A first swap from wallet connection to settlement

A first Sunswap trade requires a TRON wallet, an activated account and enough resources to execute.

The interface quotes the output before it asks for a signature. It does not take custody through a deposit account. TronLink and TokenPocket expose the contract request directly, while TRONSCAN records the resulting transaction and token movements.

Use this five-point decision checklist:

• Wallet: use TronLink or TokenPocket on TRON Mainnet and select the address that holds the input asset.
• Token: match the TRC-20 contract address, because a symbol alone does not uniquely identify a contract.
• Resources: retain TRX or delegated Bandwidth and Energy for any approval and the final contract call.
• Quote: check the route, fee tier, price impact and minimum received before signing.
• Position: choose swapping only unless you intentionally want a two-asset liquidity position with its own market exposure.

The first token interaction may add an approval signature before the swap signature. Permit2 lets the Universal Router use signature-based permissions, but a token can still require an initial approval to Permit2. Read each wallet prompt as a separate contract action. After signing, the transaction enters TRON’s block flow, where scheduled producers create a block every 3 seconds. Full solidification requires 19 of 27 active Super Representatives to extend the chain at or beyond that block. Check the final balance and status in TRONSCAN before starting another dependent action.

Liquidity provision adds a second use case

Liquidity provision turns Sunswap users into market makers who earn fees while holding changing token balances.

V2 deposits supply two assets across the full constant-product curve and receive fungible LP tokens that represent a proportional pool share. Trading fees remain in the pool, increasing the assets represented by each LP token. V3 and V4 positions select a fee tier and price range, then use a non-fungible receipt for that configuration. When price leaves the chosen range, the position becomes inactive, holds only one token and stops earning swap fees. Collected V3 fees sit apart from principal and require a separate claim; compounding requires another liquidity action.

Active pools support spot exchange among assets such as TRX, USDT, USDD, SUN and JST. Pool creators also establish new TRC-20 pairs after token information appears in TRONSCAN. Fee income comes from routed volume, so it moves with activity and active liquidity rather than following a fixed yield. SunPump tokens that reach pool trading use the same reserve-driven execution once liquidity exists.

Liquidity changes the composition of a portfolio as relative prices move. Impermanent loss compares the withdrawn pool value with simply holding the deposited assets, while fee income offsets only part of that difference when volume is sufficient. Choose V2 full-range simplicity or V3 and V4 range control before committing two assets.

V4 compresses routing into one settlement

The V4 Sunswap design reduces cross-pool transfers by managing pools in one Singleton contract and settling net balances once.

Earlier versions deployed a contract for each pool and moved intermediate assets between contracts during multi-hop routes. The V4 PoolManager records temporary net deltas, checks that every delta returns to zero and settles the input and output at the end. A multi-pool swap therefore needs two external token transfers: one asset enters and one leaves. Native TRX support removes mandatory WTRX wrapping for V4 pairs. This architecture lowers transfer overhead, but execution still consumes Energy because the TRON Virtual Machine runs the router, pool and any attached hook.

V4 exposes 10 hook callbacks arranged as five before-and-after pairs across initialization, liquidity addition, liquidity removal, swaps and donations. Those hooks fall into two interaction categories: automatic or user-authorized. A hook becomes permanent when the pool is created, and a Dynamic Fee Hook can raise the pool fee up to the 5% cap. Pool selection therefore includes the hook’s rules as well as its liquidity.

From JustSwap to the SUN ecosystem

The Sunswap protocol evolved from JustSwap into an active SUN ecosystem family with four deployed AMM generations. The SUN platform acquired JustSwap in October 2021 and folded the exchange into its DeFi stack. V3 launched on June 28, 2023 with concentrated liquidity; SUN DAO followed on July 31, 2024 and V4 launched on March 2, 2026 with Hooks and Singleton settlement. The protocol now spans legacy constant-product pools, range-based positions and programmable pools. The next choice is routed swapping or position management.