How Reverse Swap Simulation Changes STON.fi Trade Planning Most swap planning starts with "here's my budget, what do I get?" — reverse simulation asks the opposite question, and that single i
How Reverse Swap Simulation Changes STON.fi Trade Planning
Most swap planning starts with "here's my budget, what do I get?" — reverse simulation asks the opposite question, and that single inversion changes how a trade gets planned before anything is ever signed.
Almost every swap interface ever built assumes the same starting point: you know what you're willing to spend, and you want to find out what you'll receive. On STON.fi, standard swap simulation follows exactly that direction — you specify the asset and amount you're selling, and the simulation estimates what comes back.
Reverse swap simulation flips the question entirely. Instead of starting with the budget, you start with the result: "I need exactly this much of the destination token — how much of the source token would that require?" STON.fi exposes this through POST /v1/reverse_swap/simulate, which calculates the required input for a specified output amount.
That difference sounds small. In practice, it changes how traders, applications, and automated strategies can plan a trade.
💭 What makes this genuinely useful isn't the endpoint itself — it's that it removes a specific, annoying workflow almost everyone has done at some point: guessing an input, checking the output, adjusting, and repeating until the number gets close enough.
Neither is universally better. They solve different planning problems, and knowing which constraint you're actually working under determines which one you should reach for.
A normal STON.fi simulation is an input-first calculation. You define the token you want to sell and how many units you want to spend, and STON.fi estimates the resulting output using the selected liquidity environment. The API returns expected ask_units, the pool and router used, swap rate, price impact, fees, gas parameters, and minimum acceptable output after slippage protection.
The mental model:
Fixed input → calculated output
A trader might decide to swap 100 TON into another token. The unknown is how many units those 100 TON currently buy. This works well when the amount you're prepared to spend is the real constraint.
Reverse simulation inverts that relationship:
Fixed output target → calculated required input
The endpoint asks for offer_address, ask_address, the number of destination-token units you want to buy, and a slippage_tolerance. It then calculates how many offer_units would be required under simulated conditions.
Imagine you don't simply want to "spend 100 TON" — you specifically need 10,000 units of a token. With a standard simulation, you'd guess an input, check the result, adjust, and simulate again until the expected output approaches 10,000. Reverse simulation begins with 10,000 directly.
That turns budget discovery by iteration into input calculation from a known target.
One of the most useful consequences: required capital becomes an output of the planning process rather than something you arrive at by trial and error.
Suppose an application knows a wallet needs 5,000 units of Token B. The planning question is no longer whether to swap 20, 30, or 40 units of Token A. The application requests a reverse simulation for 5,000 Token B and inspects the calculated offer_units.
This matters most whenever the destination amount matters more than the source amount:
It also creates a natural budget check:
Target amount → required input → compare against available budget
If the required input is too high, the target can be reduced before a transaction is ever prepared.
AMM pricing isn't necessarily linear. Buying twice as many tokens doesn't always require exactly twice as much input, because larger trades interact differently with available liquidity and create greater price impact.
STON.fi's simulation response includes price_impact and swap_rate, which means reverse simulations can be repeated across several target amounts to see how required input scales. Instead of asking only:
How much TON is required for 10,000 tokens?
...a trader can compare simulations for 5,000, 10,000, 20,000, and 50,000 tokens.
The important signal isn't only the absolute input amount — it's how rapidly the input required per unit of output changes as the target grows. A target that looks reasonable at a small size can become much less attractive when scaled up.
That turns position sizing into a measurable liquidity question rather than a multiplication exercise.
Reverse simulation does not eliminate slippage.
STON.fi still requires slippage_tolerance on the reverse simulation request. The API defines this as the maximum tolerated difference between the expected rate and the rate that may actually occur, expressed as a fraction — 0.001 represents 0.1%.
The response includes min_ask_units, alongside recommended_slippage_tolerance and recommended_min_ask_units. STON.fi describes the recommended values as taking potential sandwich attacks into account.
This distinction is important: reverse simulation tells you approximately how much input is required to hit the desired output under the simulated state. It is not a promise that pool conditions stay unchanged until execution. Liquidity moves, other swaps occur, and the effective rate can shift between simulation and on-chain execution. Slippage protection remains part of transaction planning, not something reverse simulation replaces.
Required input isn't determined only by the two token symbols involved.
STON.fi's reverse simulation accepts an optional pool_address, and the API also provides DEX-version controls. A developer can either let the infrastructure select the relevant environment or restrict the simulation to particular pool or DEX assumptions.
This matters because two liquidity pools supporting the same assets can have different reserves, parameters, or liquidity conditions. Therefore:
Same desired output ≠ necessarily same required input across every pool
Reverse simulation can consequently answer not just "How much do I need?" but also "Where can this target be acquired under better simulated conditions?" For sophisticated integrations, the target amount becomes a useful common reference point when comparing liquidity sources against each other.
A calculated offer_units value matters, but it isn't the only number relevant to planning.
STON.fi's simulation response also contains fee information and gas_params — fee units, fee percentage, fee asset information, and gas-related parameters alongside the swap result.
This becomes especially relevant when working against a strict wallet balance. A reverse calculation might show that the desired output requires nearly all available source tokens, but the transaction still needs sufficient resources for execution. Looking only at the headline required input creates an unrealistic budget.
A better planning model:
Desired output → required swap input → fees and execution requirements → wallet budget check
That produces a more complete picture before the transaction ever reaches wallet confirmation.
Without reverse calculation, exact-output planning tends to become iterative: estimate an input, simulate, see the output is too low, increase the input, simulate again, repeat.
Reverse simulation collapses much of that into a single query, because the target itself becomes the known variable.
Again — neither method wins outright:
Simulation should happen before execution, not replace transaction verification.
STON.fi's own swap guide treats simulation as a separate step before building and sending the transaction through the SDK and wallet. Simulated values can then be used when preparing transaction parameters like the offered amount and minimum acceptable output.
For reverse-planned trades, this creates a clean sequence:
The major benefit is that the financial intention of the transaction becomes explicit earlier. Instead of deciding how much to spend and accepting whatever quantity results, the trader first defines the quantity they actually want.
Reverse simulation is still a simulation. It does not freeze pool reserves, guarantee the quoted market state, or remove execution risk. The result represents conditions evaluated at the moment the simulation was performed.
It also doesn't make a large trade efficient simply because the API can calculate the required input. If the target amount produces significant price impact, reverse simulation may simply reveal that the target is expensive under current liquidity conditions.
💭 That's arguably its most useful function. A good simulation isn't necessarily one that tells you to trade — sometimes its value is showing that the desired trade should be resized, postponed, or evaluated against a different liquidity path entirely.
Reverse swap simulation changes STON.fi trade planning by reversing which side of the trade becomes the fixed constraint.
Standard simulation answers: "What can I receive for the amount I'm willing to spend?"
Reverse simulation answers: "What would I need to spend to receive the amount I actually want?"
That second question is especially powerful when a specific destination-token balance is the objective. It exposes required capital before execution, makes target-size comparisons easier, allows price impact and liquidity to be evaluated around a fixed output goal, and reduces the need for repeated trial-and-error quotes.
The endpoint itself is simple. The planning model behind it is the real point: start with the outcome, calculate its cost, evaluate the conditions, and only then decide whether the trade makes sense.
Does reverse simulation guarantee I'll receive exactly my target amount?No. It calculates the required input under simulated conditions at the time of the request. Pool reserves can change between simulation and execution, which is why slippage_tolerance and min_ask_units remain part of the process.
When should I use standard simulation instead?Whenever your real constraint is how much you're able or willing to spend. Standard simulation is input-first and answers that question directly; reverse simulation is only the better fit when a specific destination quantity is the actual goal.
Why would the same target require different input amounts across pools?Because two pools supporting the same assets can hold different reserves and operate under different parameters. The optional pool_address and DEX-version controls let you simulate against specific assumptions rather than leaving selection to the infrastructure.
Does a high required input from reverse simulation mean something is wrong?Not necessarily — it often means the target amount is simply large relative to available liquidity, producing meaningful price impact. That's useful information: it suggests resizing or reconsidering the trade rather than pushing it through.
Tags: STON.fi, Reverse Swap Simulation, DEX API, Trade Planning, Price Impact, Slippage, TON Blockchain, DeFi Development
