Does omitting slippageBips apply a default tolerance?

Omitting slippageBips makes the Universal Router calculation service return a minimum output equal to its estimated output. The service does not insert an unspecified percentage allowance for deterioration. An integrator should set the desired tolerance explicitly when requesting the quote and use the corresponding minimum when constructing an exact-input swap.

Where does an integrator find the minimum in token base units?

The amountOutMinimumRaw field contains the minimum output in the output token's smallest units. The amountOutMinimum field expresses the same constraint after conversion by token decimals. Use the raw field for the contract's minimum-fill parameter. Treat the estimated amountOutRaw as a quote, not as a substitute for a minimum calculated with an explicit tolerance.

Can a slippage limit restrict which pools the quote uses?

The typeList parameter restricts eligible pool types, while slippageBips sets the output tolerance. These controls address different choices in a Universal Router quote request. Restricting pool types can change the available paths and their outputs. A slippage setting does not itself restrict the quote to a particular Sunswap version or pool design.

Is an unverified V4 hook automatically excluded from a quote?

The API documentation does not specify whether unverified V4 hooks are excluded by default. For your first quote, set includeUnverifiedV4Hook to false if you want to exclude those pools. The containsUnverifiedHook field identifies whether a returned path includes such a pool. Review that flag separately from the output floor. Slippage tolerance limits an accepted amount; it does not assess custom hook logic or remove the behavior that the selected hook adds.

Why does a quote request return INVALID BIPS?

INVALID BIPS indicates that slippageBips falls outside the calculation service's accepted range of 0 to 10,000. The parameter uses basis points, so 50 represents 0.5%. Check the percentage-to-basis-point conversion when constructing the request. The accepted API range describes valid inputs, not a recommended tolerance for a first swap.

Does zero tolerance make every stablecoin swap slippage-free?

Zero tolerance does not turn an AMM pool into a fixed-ratio swap mechanism. It sets the calculated minimum equal to the quote, which may already include price impact. PSM instead uses a fixed 1:1 ratio; its Universal Router commands cover USDT and USDD. That route's pricing follows its reserve-based mechanism, with network resource costs still applying.

Are poolFees values measured in the same units as slippageBips?

poolFees uses millionths, while slippageBips uses basis points. A poolFees value of 500 represents a 0.05% pool fee; a slippageBips value of 500 represents 5% tolerance. Confusing those scales can produce a much wider output allowance than intended. Pool fee data and tolerance also describe different components of the proposed trade.

Do TRON resource charges reduce the output floor?

The output floor constrains the swap's output-token quantity, while TRON accounts for network resources separately. When the same account pays execution costs and receives TRX, its net balance change can differ from the swap's output transfer. Compare the confirmed transfer with the submitted minimum, rather than treating that account's net TRX balance change as the swap amount.

Sunswap slippage tolerance sets the minimum output accepted by an exact-input swap

Sunswap slippage is the difference between quoted output and executed output for a token swap. For an exact-input trade, tolerance sets the minimum amount that the swap may deliver. Price impact describes the price change caused by the trade itself, which can already affect the quote. Increasing tolerance permits a lower fill without improving pool liquidity. Before a first swap, review both the estimate and the minimum alongside token permissions and TRON execution resources. An unacceptable minimum is a reason to stop before signing. After submission, confirmed execution and the recipient's token transfer establish what the swap actually delivered.

Updated on Tuesday, 13 October 2026

Bottom line: Smaller trades in Sunswap V2 pools can reduce price impact; tighter tolerance restricts deterioration from the resulting quote.

Quoted output and the amount accepted on-chain

The estimated fill

The quote estimates output for a specified input amount using the pools along the selected route. Universal Router's calculation service returns estimated output, price impact, fees, and details for each hop. Those values describe a proposed trade under the quoted conditions. They do not establish that a transfer has happened. A later trade in the same pools can change the available output before your transaction executes.

The output floor

The minimum output states how little of the output token an exact-input swap may accept. Its relationship to the estimate is minimum output = quoted output × (1 - tolerance / 100), when tolerance is expressed as a percentage. The input remains fixed, and a lower floor permits more deterioration from that quote. Token decimals determine how the amount converts into the integer units used by the contract. Compare amounts in the same token units.

Price impact starts inside the pool

Price impact measures the effect of the trade on pool pricing, while slippage measures departure from the quote during execution. In V2, larger trades relative to reserves move the average exchange rate further from the starting reserve ratio. The quote already reflects that reserve-driven cost and the pool fee. A tighter tolerance does not reverse either component. Reducing trade size or finding deeper available liquidity addresses a different constraint from limiting deterioration after quotation.

The same quote with two output floors

For this hypothetical comparison, a fixed input has a quote of 147.83 output tokens. Compare tolerances of 0.37% and 0.83%, with execution output of 146.93 tokens. Both settings start from the same estimate, so they share any price impact already present in that quote.

At 0.37%, the arithmetic minimum is 147.83 × 0.9963 = 147.283029 output tokens. At 0.83%, it is 147.83 × 0.9917 = 146.603011 output tokens. The proposed 146.93-token fill falls below the tighter floor and exceeds the wider floor. The encoded amounts must respect the output token's decimal precision.

A standard atomic exact-input swap would reject that output under the tighter setting. The wider setting passes this output condition, although permissions, resources, and the deadline must also permit execution. Widening tolerance changes which fill the swap accepts; it leaves the quoted price impact unchanged.

Which slippage tolerance fits a first swap?

A suitable tolerance expresses how much deterioration from the selected quote you are willing to accept. For a first wallet-submitted swap, connect a TRON-compatible wallet. Select the input and output tokens, then enter the input amount to obtain a quote. Review the minimum output that the tolerance setting produces. A percentage alone hides the token amount at stake and says little about whether the original quote is attractive. The proposed floor should make sense for that trade before you approve or sign anything.

Tighter settings limit the accepted shortfall and can cause more failures when pool conditions move before execution. Wider settings allow larger shortfalls, including fills that were unacceptable under the earlier bound.

The calculation service returns up to three candidate paths for the requested input. Compare those paths without changing the input amount. A lower pool fee does not necessarily produce more output when liquidity differs. If you select another quote, calculate its minimum from that estimate instead of carrying forward the earlier token amount.

Route changes and pool-specific costs

Liquidity available to the trade

A route's available liquidity determines how its pools respond to the selected input. Universal Router can execute paths across Sunswap versions and other supported protocols. Consecutive quotes need not select identical pools when their conditions change. Concentrated liquidity in V3 and V4 supports trading within selected price ranges. Positions outside their ranges do not supply active trading liquidity, so headline deposits alone do not describe the depth that a swap can use.

Fees that follow pool configuration

Pool fees affect quoted output separately from slippage tolerance. V3 charges the tier that the pool creator selected. V4 can use static fees or hook-based fee logic, including DynamicFeeHook adjustments based on price impact. A route containing such a pool can face different fee conditions when it executes. Raising tolerance can accommodate a smaller output, including deterioration caused by a fee change. The hook's configured logic continues to determine the pool fee.

Why can a swap fail with enough slippage tolerance?

A swap can fail because permissions, resource limits, or its deadline prevent execution, even when its output floor is achievable.

Output and deadline checks

The execution output must still meet the submitted minimum for a standard atomic exact-input swap. Quote changes can push it below that boundary. Universal Router reverts a transaction when its on-chain confirmation time exceeds the submitted deadline. A wider tolerance does not extend that deadline. Refresh the quote and review the transaction deadline before another submission.

Token spending permissions

TRC20 spending from your wallet through Universal Router requires the token's base approval to Permit2. Application authorization then determines the permitted spender, amount, and applicable duration. A sufficient balance does not replace those permissions. The first use of a token may involve approval before the swap can proceed. Signing a permit and executing a transfer remain different operations, even when an application combines authorization and execution within one interaction.

TRON execution resources

TRON transactions consume Bandwidth, and smart-contract execution also consumes Energy. Available resources and any TRX that the network burns for resource costs determine whether the account can fund execution. Tolerance changes the output constraint, without supplying Energy or Bandwidth. Increasing it does not correct an execution budget that cannot cover the required contract work.

The caller's fee_limit caps its Energy budget, including available Energy and the portion funded by burning TRX. A resource failure needs a resource or budget correction, not another tolerance increase.

The stopping point before swap submission

In a wallet-submitted swap, declining the final transaction signature prevents submission, although an earlier successful approval may remain active. Declining the swap does not undo a token allowance that you already granted. Permit2's application authorization and the underlying token approval have different scopes. Expiration of the former does not revoke the latter. Assess the minimum before granting new permissions, and distinguish an approval confirmation from a trade confirmation. Returning to an unfinished swap calls for reviewing its quote again because pool reserves and applicable fees may have changed.

How can you tell whether the swap actually completed?

Confirmed transaction success and the output transfer to the specified recipient establish completion of a standard atomic swap. A wallet signature authorizes an operation; it does not establish its execution outcome. Likewise, a transaction identifier gives you a record to inspect, not a completed fill. Compare the confirmed output in token base units with the minimum encoded in the transaction.

View image file

The estimate describes the proposed fill, the minimum expresses the accepted lower bound, and the confirmed transfer records the actual amount. Keep those roles distinct when comparing the result with the initial quote. A successful quotation response only reports that the calculation service returned paths. It does not report a successful swap.

Exact-output orders and partial-fill plans

Exact-output orders place their bound on the input side. Universal Router supports exact-output swaps through V2 and V3, specifying a desired output and a maximum input. The percentage calculation for a fixed-input minimum should not replace that maximum-input check. Universal Router's V1 integration supports exact-input commands only. Legacy V1 pool contracts also expose exact-output functions, so this restriction concerns the router integration.

Custom Universal Router plans can also allow a particular command to fail while later commands continue. This exception changes the meaning of transaction success. Plans using that allow-revert setting need subsequent cleanup, such as SWEEP, to send leftover tokens to the intended recipient. Otherwise, tokens can remain in the router. An output check for one failed command does not prove that the entire plan reverted. With partial-fill behavior enabled, evaluate the actual fills and refunded balances before treating the trade as complete.

Details worth knowing about Sunswap slippage

Does omitting slippageBips apply a default tolerance?: Omitting slippageBips makes the Universal Router calculation service return a minimum output equal to its estimated output. The service does not insert an unspecified percentage allowance for deterioration. An integrator should set the desired tolerance explicitly when requesting the quote and use the corresponding minimum when constructing an exact-input swap.
Where does an integrator find the minimum in token base units?: The amountOutMinimumRaw field contains the minimum output in the output token's smallest units. The amountOutMinimum field expresses the same constraint after conversion by token decimals. Use the raw field for the contract's minimum-fill parameter. Treat the estimated amountOutRaw as a quote, not as a substitute for a minimum calculated with an explicit tolerance.
Can a slippage limit restrict which pools the quote uses?: The typeList parameter restricts eligible pool types, while slippageBips sets the output tolerance. These controls address different choices in a Universal Router quote request. Restricting pool types can change the available paths and their outputs. A slippage setting does not itself restrict the quote to a particular Sunswap version or pool design.
Is an unverified V4 hook automatically excluded from a quote?: The API documentation does not specify whether unverified V4 hooks are excluded by default. For your first quote, set includeUnverifiedV4Hook to false if you want to exclude those pools. The containsUnverifiedHook field identifies whether a returned path includes such a pool. Review that flag separately from the output floor. Slippage tolerance limits an accepted amount; it does not assess custom hook logic or remove the behavior that the selected hook adds.
Why does a quote request return INVALID BIPS?: INVALID BIPS indicates that slippageBips falls outside the calculation service's accepted range of 0 to 10,000. The parameter uses basis points, so 50 represents 0.5%. Check the percentage-to-basis-point conversion when constructing the request. The accepted API range describes valid inputs, not a recommended tolerance for a first swap.
Does zero tolerance make every stablecoin swap slippage-free?: Zero tolerance does not turn an AMM pool into a fixed-ratio swap mechanism. It sets the calculated minimum equal to the quote, which may already include price impact. PSM instead uses a fixed 1:1 ratio; its Universal Router commands cover USDT and USDD. That route's pricing follows its reserve-based mechanism, with network resource costs still applying.
Are poolFees values measured in the same units as slippageBips?: poolFees uses millionths, while slippageBips uses basis points. A poolFees value of 500 represents a 0.05% pool fee; a slippageBips value of 500 represents 5% tolerance. Confusing those scales can produce a much wider output allowance than intended. Pool fee data and tolerance also describe different components of the proposed trade.
Do TRON resource charges reduce the output floor?: The output floor constrains the swap's output-token quantity, while TRON accounts for network resources separately. When the same account pays execution costs and receives TRX, its net balance change can differ from the swap's output transfer. Compare the confirmed transfer with the submitted minimum, rather than treating that account's net TRX balance change as the swap amount.