An exact-input swap can require at least a specified output; an exact-output swap can cap the input. These program-enforced conditions constrain accepted execution. They do not reserve a price or describe every cost of the transaction.
Choose what the request fixes
In exact-input mode, you choose how much to spend and obtain a quote for the output. The transaction can include a minimum-output condition. In exact-output mode, where supported, you choose the output and permit at most a specified input.
The two modes protect different sides of the trade. Reading a number labelled tolerance without knowing the mode can lead you to interpret the wrong amount as fixed.
A quote describes terms under observed conditions or a particular supported offer. The bound describes a condition the execution program must check. Neither description guarantees that the operation will pass its other funding, account and program requirements.
Start from input mint, output mint, mode, expected quantities and the exact named bound. Those fields are the basis of a meaningful approval.
Calculate one simple minimum
Choose an exact-input teaching quote of 100 output tokens and an adverse tolerance of 0.5%. The human-unit minimum is 100 multiplied by 0.995, giving 99.5 tokens.
Half a percent is 50 basis points, often abbreviated bps. One basis point is 0.01 percentage point. Confusing 0.5 with 0.005 in an API that expects a fraction can create a dramatically different condition.
Suppose the teaching output token has two decimals. The quote's raw amount is 10,000, and the exact teaching minimum is 9,950 raw units. A program compares integer quantities, not a rounded portfolio-price display.
With other input values, rounding can affect the final integer. Use the actual route or SDK's defined rule and inspect its constructed threshold. The 99.5 calculation explains the relationship; it is not a universal recommendation to choose that tolerance.
Find out which output the bound measures
A quote can include pool fees or an integrator charge before displaying expected output. The program's bound must be interpreted using the actual endpoint and instruction contract.
A token with a transfer-fee extension creates another quantity to understand. A gross moved amount and the recipient's newly available amount can differ. Determine which one the route validates and what the user can ultimately spend.
For a hypothetical gross transfer of 100 units with a separately configured 1-unit withheld fee, the available receipt is 99. An application must handle that difference in its quote and protection logic. Whether a particular route supports that token configuration is a separate compatibility question.
The minimum-output condition also does not cap every SOL expense. Network fees, account funding and additional explicit payments can be outside it. Read the cost breakdown and the final transaction together.
Apply precision before comparing amounts
Compare expected and accepted terms at signing
Review the mints, input amount, mode and expected output. Then read the minimum received or maximum sold and the route's fee inclusion.
For our teaching exact-input request, ask whether you accept 99.5 rather than assuming the quote promises exactly 100. If those terms differ from your intention, obtain another quote or change the request before signing.
An automatic setting is implemented by the product's policy. Its final threshold is still the accepted condition. A well-designed preview explains that result rather than hiding it behind the word automatic.
Builders should compare the constructed instruction's raw bound with the intended value. A correctly formatted percentage in the UI does not prove that serialization, decimals and routing code produced the right integer.
Read what failure and success prove
If the execution-bound check fails, the attempted swap no longer satisfies that condition at execution. A fresh quote helps establish new terms. Widening the condition makes a worse result permissible; it does not repair unrelated instruction errors.
If an instruction fails, the transaction's application changes roll back under atomicity. A network fee can still be charged. A rejected trade therefore does not always mean no SOL movement occurred.
If execution succeeds, reconcile the actual credited token amount under the effective bound's semantics. Compare the original quote separately to measure quote-to-execution change. Account for token fees and unit precision when interpreting a discrepancy.
Preserve the final message or supported decoded terms, signature and receipt when diagnosing a result. The price-effect guide explains the comparisons, while transaction diagnostics handles an unclear outcome before another attempt.
Common questions
Does minimum received mean I will receive exactly that amount?
It is a lower bound under the program’s defined semantics. The actual result can be better, or the operation can fail for that or another condition.
Does tolerance pay for network fees?
No. The output/input bound and the transaction’s SOL expenses are separate mechanisms.
What is 50 bps as a percentage?
It is 0.5%, or 0.005 as a fraction. Verify which unit an API expects before constructing the request.
Sources and documentation
- Jupiter Router: swap construction
- Raydium: slippage and price impact
- Token transfer instructions
- Solana transactions
- Solana transaction fees
Found an error or an outdated detail? Send a correction.
