DEV Community

Cover image for How to Calculate Minimum Received for a STON.fi Swap

How to Calculate Minimum Received for a STON.fi Swap

Understanding the number that protects your swap when the market moves between quote and execution.

When STON.fi shows a swap quote, the amount you expect to receive and the minimum amount you are willing to receive are not necessarily the same number. The second value is your protection against unfavorable price movement while the transaction is being processed.

The basic calculation is simple:

Minimum received = expected output × (1 - slippage tolerance)

If a swap is expected to return 1,000 tokens and the allowed slippage is 1%, the minimum received is approximately 990 tokens.

The arithmetic takes seconds. The more important part is understanding which number should be used as the expected output, what slippage actually protects you from, and why price impact should not be subtracted twice.

The formula behind minimum received

The formula behind minimum receivedn

Suppose STON.fi calculates that your swap should currently return 2,500 USDT.

If your slippage tolerance is 1%, convert the percentage into decimal form:

1% = 0.01

Then calculate:

2,500 × (1 - 0.01) = 2,475

Your minimum received is therefore approximately 2,475 USDT.

At 0.5% tolerance:

2,500 × (1 - 0.005) = 2,487.5 USDT

At 2% tolerance:

2,500 × (1 - 0.02) = 2,450 USDT

The relationship is straightforward: increasing the tolerated slippage lowers the minimum amount that the transaction is allowed to deliver.

A useful mental model is to treat the quote as the current target and minimum received as the lowest acceptable outcome.

Quick reference

For an expected output of 1,000 tokens:

  • 0.1% slippage gives a minimum of about 999 tokens
  • 0.5% slippage gives a minimum of about 995 tokens
  • 1% slippage gives a minimum of about 990 tokens
  • 2% slippage gives a minimum of about 980 tokens
  • 5% slippage gives a minimum of about 950 tokens

These examples illustrate the calculation rather than recommending a particular tolerance. The appropriate level depends on liquidity, volatility, trade size, route conditions, and how much execution uncertainty you are willing to accept.

Expected output and minimum received are different numbers

Expected output and minimum received

A swap interface has to answer two separate questions.

First: What should this trade return under current conditions?

Second: How bad can the execution become before the transaction should no longer proceed?

Those questions produce different values.

Quote element What it tells you What affects it
Expected output Estimated tokens you should receive now Pool reserves, route, fees, trade size, current price
Price impact How much your own trade changes the execution price Trade size relative to available liquidity
Slippage tolerance Maximum additional price movement you accept Your execution protection setting
Minimum received Lowest output permitted by the swap Expected output and slippage tolerance
Network fee Cost of processing messages on TON TON network and transaction structure

STON.fi's own educational material distinguishes price impact from slippage. Price impact is caused by the trade itself, while slippage concerns changes between the price expected and the price available when execution occurs.

That distinction prevents one of the most common calculation mistakes.

Do not subtract price impact twice

Do not subtract price impact twice

Imagine you are swapping enough TON to move the price inside the relevant liquidity pool.

Before you confirm, the quote already reflects the execution conditions produced by that order. If the trade size causes significant price impact, the estimated output will already be worse than the simple spot-price calculation you might have made before opening the swap interface.

Now suppose the resulting quote is 5,000 tokens and you allow 1% slippage.

The calculation is:

5,000 × 0.99 = 4,950 tokens

You should not first reduce 5,000 by the displayed price impact and then reduce the result again by 1%.

Doing that would count the effect of your trade twice.

The sequence is better understood like this:

  1. STON.fi calculates the swap under current liquidity conditions.
  2. The resulting quote incorporates the execution effect of the trade.
  3. Slippage protection creates a floor below that quote.
  4. The transaction can proceed only while the resulting output satisfies that floor.

This is why minimum received is calculated from the quoted output rather than from a theoretical external market price.

Why can the quote move before your swap executes?

Why can the quote move before your swap executes?

A DEX quote describes the state of liquidity when it is calculated. Blockchain execution happens afterward.

During that interval, other traders may interact with the same liquidity. Pool reserves can change, the relative price of the assets can move, or the conditions along a route can become less favorable.

Consider a quote for 800 tokens.

At the moment you see it:

Expected output = 800

With 1% tolerance:

Minimum received = 792

If conditions move slightly and the swap would return 797 tokens, the output remains above your 792-token floor.

If conditions deteriorate enough that the swap would return only 788 tokens, the protection becomes relevant.

A slippage limit therefore does not promise that you will receive exactly the quoted amount. It defines the point at which a worse outcome is no longer acceptable.

This trade-off also explains why extremely tight tolerances can increase the chance of failed execution, while very loose tolerances permit a wider range of unfavorable outcomes.

How STON.fi enforces minimum received

The calculation becomes more meaningful when you look at how STON.fi represents it at the contract level.

In STON.fi DEX v2, the Router passes a min_out value as part of the swap data. The Pool documentation describes min_out as the minimum required amount of tokens to receive and states that a swap fails if the amount due to the user would be below this value.

So minimum received is not merely an informational estimate displayed by an interface.

It becomes a condition attached to the swap.

Conceptually, the flow is:

Quote → slippage protection → minimum output → contract execution

Suppose the current expected output is 12,000 tokens and your tolerance produces an 11,880-token minimum.

If execution still supports 11,950 tokens, the condition is satisfied.

If it supports only 11,850, the minimum-output condition is not satisfied.

For a simple swap, this prevents the trade from deliberately accepting an arbitrarily worse output just because conditions changed after the quote appeared.

STON.fi's v2 Pool documentation explicitly connects the swap's success condition to min_out.

Calculating minimum received from a STON.fi quote

How STON.fi enforces minimum received

For someone reviewing a swap manually, the process only requires the quoted output and the applicable slippage tolerance.

1. Start with the current expected output

Use the amount generated by the swap quote rather than multiplying the amount you are selling by a price copied from another exchange.

For example:

STON.fi expected output: 3,250 tokens

That quote is the useful starting point because it reflects the actual swap being considered.

2. Convert slippage into decimal form

For example:

  • 0.5% becomes 0.005
  • 1% becomes 0.01
  • 1.5% becomes 0.015
  • 2% becomes 0.02

3. Subtract the tolerance from 1

For 0.5%:

1 - 0.005 = 0.995

4. Multiply the quote by the result

3,250 × 0.995 = 3,233.75

The theoretical minimum received is therefore 3,233.75 tokens.

The actual transaction uses blockchain units and token-specific decimals, so an integration should not casually reproduce UI arithmetic with floating-point numbers and then invent its own rounding rules.

That is where STON.fi's simulation tools become useful.

For developers, use minAskUnits from the simulation

STON.fi's current DEX v2 SDK documentation recommends an API-driven workflow for production swaps.

The example first calls simulateSwap() with the offered asset, requested asset, amount, and slippageTolerance. The resulting simulation contains values including offerUnits, minAskUnits, asset addresses, and Router metadata. STON.fi specifically instructs developers to reuse the simulation values when constructing the actual transaction so the signed transaction matches the simulated swap.

A simplified example looks like this:

const simulationResult = await apiClient.simulateSwap({
  offerAddress: "ton",
  askAddress: tokenAddress,
  offerUnits,
  slippageTolerance: "0.01",
});

const minimumOutput = simulationResult.minAskUnits;
Enter fullscreen mode Exit fullscreen mode

Here, "0.01" represents a 1% tolerance.

For a production integration, minAskUnits is more important than a manually formatted number such as 123.45. Smart contracts work with the asset's base units, and different tokens can use different decimal precision.

Practical developer checklist

Practical developer checklist

Before building the transaction:

  • simulate the current swap rather than relying on an old quote
  • pass the intended slippage tolerance into the simulation
  • use the simulation's minAskUnits
  • preserve the asset addresses and Router information returned by the simulation
  • avoid converting the minimum into floating-point values and rebuilding it unnecessarily
  • request a fresh simulation if the quote has become stale

STON.fi's API also provides swap simulation specifically to calculate swap results before execution, including expected swap information, fees, and gas-related data.

What minimum received does not include

Minimum received is easy to misuse when every cost associated with a swap is treated as "slippage."

They are not the same thing.

Trading economics affect the quote. Pool pricing, liquidity, trade size, and relevant trading fees influence the output calculated for the swap.

Slippage protection applies to movement away from that quote. It defines how much additional deterioration can be tolerated before the minimum-output condition is violated.

TON network costs are separate. Gas and message-processing costs exist because TON must execute and forward blockchain messages. TON documentation describes contract execution and forward fees as separate blockchain costs.

If STON.fi quotes 1,000 units of an asset and your minimum received is 990, you should not subtract the TON network fee from 990 as though the fee were another percentage of the destination token.

Keeping those layers separate makes the calculation much easier to audit.

A practical STON.fi example

Imagine you want to swap TON into another token and STON.fi currently quotes:

Expected output: 10,000 ABC

Assume the swap uses a 1% slippage tolerance.

The manual calculation is:

10,000 × (1 - 0.01)

10,000 × 0.99 = 9,900 ABC

So:

  • Expected output: 10,000 ABC
  • Slippage tolerance: 1%
  • Minimum received: approximately 9,900 ABC

Now imagine liquidity changes while your transaction is moving through the execution process.

If the updated swap result is 9,970 ABC, it is still above the minimum.

If it falls to 9,910 ABC, it is still above the minimum.

If it falls below the contract's required min_out, the minimum-output protection is triggered rather than simply accepting the worse exchange result.

For developers, the same logic should normally be represented by the fresh minAskUnits returned by STON.fi's swap simulation rather than a hand-calculated decimal value.

Practical takeaway: when reviewing a STON.fi swap, start from the current quoted output, distinguish price impact from slippage, and treat minimum received as your execution floor. If you are integrating STON.fi programmatically, let the current swap simulation produce minAskUnits and carry that value into the transaction instead of reconstructing it from an older or rounded quote.

Frequently Asked Questions

What is minimum received in a crypto swap?

Minimum received is the lowest amount of the destination asset that your swap is allowed to deliver under its slippage protection. If the current quote is 1,000 tokens and a 1% tolerance is applied, the approximate minimum is 990. It is a protective floor, not a prediction that you will necessarily receive exactly that amount.

How do I calculate minimum received from slippage?

Multiply the expected output by one minus the slippage tolerance expressed as a decimal. For example, with an expected output of 4,000 tokens and 0.5% slippage, calculate 4,000 × 0.995, which gives 3,980 tokens. Blockchain implementations may apply base-unit precision and rounding, so integrations should use protocol-provided values where available.

Is price impact included in minimum received?

Price impact should first affect the expected swap output because it comes from executing your trade against available liquidity. Slippage protection is then applied relative to that quote. Subtracting displayed price impact from the quote again before calculating minimum received can therefore double-count the same effect.

Does higher slippage increase minimum received?

No. Higher slippage tolerance lowers the minimum received because you are allowing the transaction to accept a wider deterioration from the original quote. A 2% tolerance creates a lower floor than a 0.5% tolerance. That can make execution less restrictive, but it also allows a less favorable result.

What is min_out on STON.fi?

min_out is the contract-level minimum output requirement used in STON.fi swap execution. STON.fi's DEX v2 Pool documentation states that the swap fails if the amount to be received would be below this minimum. It is the on-chain expression of the minimum-output protection discussed in the swap quote.

What is minAskUnits in the STON.fi API?

minAskUnits is the minimum requested output returned as part of STON.fi's swap simulation workflow. The DEX v2 SDK documentation shows it in simulationResult together with the offered amount, asset addresses, and Router metadata. Production integrations should reuse these simulation values when building the corresponding swap transaction.

Should I calculate STON.fi minimum received manually before every swap?

Manual calculation is useful for understanding and checking the number shown by a quote. For actual execution, especially in a software integration, use a fresh STON.fi simulation and its minAskUnits. That avoids problems with token decimals, stale quotes, floating-point calculations, and inconsistent rounding between your application and the swap transaction.

What should I check before confirming a STON.fi swap?

Check the asset pair, input amount, expected output, price impact, minimum received, and network costs. Make sure you understand that expected output is the current estimate while minimum received is the lower execution boundary. If the quote looks unexpectedly poor, review liquidity and trade size rather than simply increasing the tolerated slippage.

Sources and Further Reading

  • STON.fi DEX v2 Swap SDK - Official production swap workflow, swap simulation, slippageTolerance, minAskUnits, and Router handling
  • STON.fi DEX v2 Pool - Official smart contract documentation for min_out and the minimum-output swap condition
  • STON.fi DEX v2 Router - Official Router swap structure and the min_out field passed during swap execution
  • STON.fi DEX API Reference - Official API overview covering swap simulation before execution
  • STON.fi DEX v2 Smart Contracts - Official overview of the current v2 smart contract architecture and swap functionality
  • STON.fi Blog, All You Need to Know About Price Impact on Decentralized Exchanges - Explanation of price impact, slippage, and their distinction in a STON.fi swap context
  • TON Documentation, How to Estimate Gas Usage in TON Contracts - Official explanation of TON gas and forward-fee mechanics

Top comments (0)