Estimating gas for a STON.fi transaction is less about guessing a fixed fee and more about understanding the TON message path your operation will create. A swap can involve your wallet, a jetton wallet, a STON.fi Router, a liquidity pool, and additional token transfers before the result reaches you.
For most users and integrations, the safest approach is simple: simulate the exact STON.fi operation, use the gas parameters returned for that route, let the current SDK construct the transaction, and keep enough TON in the wallet to cover the attached execution budget.
The harder part is understanding what those numbers actually mean.
Why TON gas is different from the Ethereum mental model
Developers coming from Ethereum often think about transaction cost as roughly:
gas used × gas price
TON works differently at the transaction level. Contract execution still consumes gas, but the amount ultimately spent by a transaction can include several categories of fees.
A TON transaction can pass through storage, compute, action, and sometimes bounce phases. The network may charge for contract computation, persistent storage, and forwarding messages to other contracts. A multi-contract DeFi operation can therefore create several transactions rather than one isolated smart contract call.
For a STON.fi swap, that distinction matters because the initial wallet message may trigger a sequence such as:
- Your wallet sends the operation.
- A jetton or pTON contract processes the asset transfer.
- The STON.fi Router receives the swap request.
- The Router communicates with the appropriate pool.
- Contracts send the resulting asset toward the destination wallet.
- Remaining TON intended for excesses may be returned according to the transaction flow.
Each step can require computation or another internal message.
So when an interface says a transaction needs a certain amount of TON for "gas," it often refers to an execution budget attached to the transaction, not simply the exact compute fee that validators will eventually keep.
What actually contributes to a TON transaction cost
TON documentation separates several fee components. Understanding them makes STON.fi gas estimates much easier to interpret.
| Component | What it covers | Why it matters for STON.fi |
|---|---|---|
| Compute fee | TVM execution of smart contract code | Routers, pools, wallets, and related contracts perform computation |
| Forward fee | Delivery of internal messages | A swap normally moves messages between multiple contracts |
| Storage fee | Persistent blockchain storage | Contracts can owe storage fees when they are processed |
| Action-related fees | Actions created after successful computation | Token transfers and subsequent internal messages can add cost |
| Attached TON budget | TON carried with a message to fund downstream execution | A STON.fi operation needs enough value to complete its message chain |
TON processes fees at different stages of execution. Official documentation lists import, storage, gas, action, and forwarding costs in the transaction lifecycle.
This is why the phrase "gas fee" can be misleading in a DEX interface. The amount attached to a transaction may be larger than the amount ultimately consumed.
Budget is not the same as final cost
Suppose an integration prepares a transaction with a conservative TON execution budget. That does not automatically mean the whole budget becomes a fee.
Part of the attached value may fund downstream messages, while unused value can be handled as excess according to the contracts and message modes involved. TON's message model explicitly allows value to move between contracts while fees are deducted along the route.
For this reason, two numbers are useful to distinguish:
- required transaction budget, which needs to be available for the operation to run safely
- actual network consumption, which is what the completed transaction trace ultimately spent
The first number matters before signing. The second becomes fully observable after execution.
Start with the exact STON.fi operation
There is no single universal gas number that should be hardcoded for every STON.fi transaction.
A TON to jetton swap does not have exactly the same message flow as a jetton to jetton swap. Liquidity provision is different again. Contract versions, token behavior, optional payloads, and the route chosen for the transaction can also affect execution.
STON.fi currently recommends an API-driven workflow for DEX v2 integrations. The application first simulates the swap, obtains the router and transaction information associated with that simulation, and then uses the correct SDK contracts for that router.
That makes the route itself the starting point for gas estimation.
A practical rule is:
Estimate the transaction you are about to send, not an abstract "STON.fi swap."
Consider two swaps for the same monetary value:
- TON to a jetton
- one jetton to another jetton
Their trade value could be identical, but the token transfer and message sequences can differ. Gas therefore follows execution structure more closely than trade value.
A 10 TON swap does not automatically require ten times as much gas as a 1 TON swap. Increasing the token amount usually does not multiply the amount of smart contract computation by the same factor.
Use STON.fi swap simulation as the primary estimate
For a current integration, the most useful first step is STON.fi's swap simulation endpoint.
The DEX API exposes POST /v1/swap/simulate. STON.fi describes the endpoint as calculating expected swap output, fees, and gas costs before execution.
The @ston-fi/api package exposes the same workflow through simulateSwap().
A simplified example looks like this:
import { StonApiClient } from "@ston-fi/api";
const apiClient = new StonApiClient();
const simulation = await apiClient.simulateSwap({
offerAddress: "<offer asset>",
askAddress: "<ask asset>",
offerUnits: "<amount in blockchain units>",
slippageTolerance: "0.005",
});
console.log(simulation.gasParams);
The STON.fi API added a gasParams structure to swap simulation responses. Its documented fields include:
-
gasBudget: an optional TON gas budget for the transaction -
forwardGas: the TON amount intended for forwarding -
estimatedGasConsumption: estimated gas consumption
These fields were introduced specifically so an integration can work from a route-specific estimate rather than relying only on fixed assumptions.
How to interpret the three fields
gasBudget is the practical budget signal. It tells the integration how much TON should be available for the execution requirements associated with the simulated operation.
forwardGas relates to the TON value that must travel farther through the operation's message chain.
estimatedGasConsumption is useful for understanding expected consumption. It should not automatically be treated as an interchangeable replacement for the amount that needs to be attached to the originating transaction.
In other words, avoid taking estimatedGasConsumption, adding an arbitrary percentage, and assuming that number can replace the transaction parameters expected by the STON.fi contracts.
The API and SDK know more about the route than that simplified calculation does.
Let the SDK build the transaction budget
After simulation, STON.fi's current v2 documentation recommends taking the router object returned by the API and passing it to dexFactory(). This selects the contract implementation that matches the router used by the simulated swap.
Conceptually, the flow becomes:
Swap request
|
v
STON.fi simulation
|
+--> expected output
+--> minimum output
+--> router information
+--> gas parameters
|
v
Correct SDK contracts
|
v
Transaction parameters
|
v
Wallet review and signature
The value sent with the transaction should come from the transaction construction logic for that exact operation rather than from a stale constant copied from another example.
This is especially important because STON.fi has multiple DEX contract generations. The current SDK documentation identifies v2 as the latest major architecture while v1 remains supported for backward compatibility. The SDK has also received changes related to gas efficiency and contract routing.
Be careful when TON itself is the asset being swapped
When the input asset is TON, the amount leaving the wallet can include both economic value and execution funding.
Imagine that you want to swap 5 TON into a jetton. The wallet may need to send more than exactly 5 TON because the transaction also needs enough TON to execute the operation.
That does not mean the difference is automatically the final network fee.
By contrast, when swapping a jetton for another jetton, the jetton amount is transferred through its token contracts while a separate amount of TON is attached to finance execution.
This distinction is one of the easiest places to misread a wallet confirmation screen.
When should you calculate fees yourself?
For a normal STON.fi integration, starting from the official simulation and SDK is usually more robust than reconstructing every fee component manually.
Manual estimation becomes useful when you are building infrastructure, auditing contract behavior, testing custom payloads, or trying to understand why actual execution differs from your expected budget.
TON provides tools for both approaches.
Its API includes an estimateFee method that accepts a destination address and serialized message body and returns categories including gas, storage, and forwarding fees. It can be used as an additional check once you have a concrete message to evaluate.
At a lower level, TON documentation explains how contract developers can estimate:
- compute gas from known gas usage
- forward fees from message size
- storage requirements
- fees across a multi-contract transaction trace
The important detail is that a DeFi operation is a system of messages. If contract A sends to contract B, which sends to contract C, estimating only the first compute phase does not describe the whole operation. TON's own gas estimation guidance explicitly treats multi-contract traces as value flows that need enough attached TON for subsequent execution.
For most STON.fi applications, this gives you a useful hierarchy:
- STON.fi simulation for route-specific gas parameters.
- STON.fi SDK transaction construction for the value and payload that should actually be sent.
- TON fee estimation tools when you need a lower-level validation of the constructed message.
- Post-transaction trace analysis when you want to compare the estimate with real execution.
How to validate your estimate after the swap
A good gas estimation system should learn from completed transactions instead of treating every estimate as an unquestionable constant.
After submitting a test transaction, inspect its trace.
Check:
- whether every expected contract action completed
- how much TON was originally attached
- the actual transaction fees across the trace
- whether excess TON was returned
- whether any message bounced
- whether a downstream action ran out of funds
- whether a custom payload introduced additional forwarding work
STON.fi provides endpoints for investigating swap status and transaction action trees, which can help connect the originating transaction to the resulting protocol actions.
TON explorers and APIs can then expose the underlying blockchain transactions and fee components.
This gives developers a useful feedback loop:
simulate
|
build
|
send
|
inspect trace
|
compare estimate with actual execution
|
adjust only when there is evidence to do so
Do not optimize by cutting the attached TON budget until a transaction barely succeeds. A small saving in temporarily attached TON is rarely worth making the operation fragile.
Common mistakes to avoid
Hardcoding an old recommended gas value. STON.fi has multiple contract versions, and execution patterns can change. Use current simulation data whenever possible.
Treating the attached TON amount as the final fee. The amount sent to finance the operation and the amount eventually consumed are different concepts.
Looking only at compute gas. Forwarding and other transaction phases also matter on TON.
Ignoring the route. Different asset types and contract paths can produce different message flows.
Removing safety budget aggressively. A transaction that works in one test does not prove that a lower budget is safe for every equivalent-looking operation.
Using a v1 example as a universal v2 constant. Older STON.fi documentation contains recommended fixed gas values for specific v1 swap types, but those values describe that implementation. They should not be blindly generalized to current v2 routing.
The practical takeaway is straightforward: simulate the exact swap shortly before execution, use the router and gas information returned by STON.fi, build the transaction through the matching SDK contracts, and inspect the final wallet transaction before signing. If you are developing an integration, compare the attached budget with actual transaction traces during testing rather than replacing route-specific values with one permanent gas constant.
Frequently Asked Questions
Does every STON.fi swap use the same amount of gas?
No. The required execution budget depends on the operation and its message path. TON to jetton, jetton to jetton, and jetton to TON swaps can involve different transfers and forwarding steps. Contract versions and additional payloads can matter as well. Use the estimate associated with the actual transaction rather than assuming that all STON.fi swaps have one fixed cost.
Does a larger swap require proportionally more gas?
Usually not simply because the token amount is larger. Gas primarily reflects the computation and messaging required to execute an operation. A larger trade can affect pricing, price impact, and minimum output, but changing 1 TON to 10 TON does not by itself imply ten times the computational work.
Is the TON attached for gas the same as the final transaction fee?
Not necessarily. Attached TON is a budget available to fund execution and downstream messages. Actual network fees are deducted as transactions execute. Depending on the contract flow, some value can continue through subsequent messages or be handled as excess rather than being consumed entirely as a fee.
What happens if too little TON is attached?
A later step in the transaction chain may not have enough value to pay for computation or forwarding. Depending on where and how the failure occurs, the operation can bounce or fail to complete as intended. Multi-contract TON systems therefore need enough value at the beginning to finance the relevant downstream trace.
Can I use TON's estimateFee API for a STON.fi swap?
Yes, it can be useful as a lower-level check once you have constructed the relevant message. TON's API returns estimates for categories such as gas, storage, and forwarding fees. For a STON.fi integration, however, it is better treated as complementary to STON.fi's route-aware simulation and SDK rather than a reason to ignore protocol-specific gas parameters.
What is forwardGas in a STON.fi simulation?
It represents TON intended to support forwarding farther through the transaction flow. STON.fi swaps can create multiple internal messages, so enough value must move with the operation for later contracts to continue processing it. It should not be confused with the final amount of network fees paid by the wallet.
Should developers hardcode STON.fi gas values?
Avoid hardcoding a universal value when current simulation data is available. Historical STON.fi SDK versions published recommended constants for particular swap types, but current integrations have access to route-specific gas information through the API. Hardcoded values can become inaccurate as contract versions, routes, or transaction structures change.
What is the safest way to estimate gas before a STON.fi transaction?
Simulate the exact operation through the current STON.fi API, read its gas parameters, use the returned router with the matching STON.fi SDK contracts, and let that workflow construct the transaction you present to the wallet. During development, execute representative test transactions and compare the estimates against their completed TON traces.
Sources and Further Reading
- STON.fi DEX API Reference - Covers swap simulation, transaction inspection, and DEX API endpoints
- STON.fi DEX v2 Swap Guide - Describes the current API-driven v2 swap workflow and router selection
- STON.fi SDK Documentation - Covers the supported SDK generations and current v2 integration tooling
- STON.fi API Changelog - Documents the addition of
gasBudget,forwardGas, andestimatedGasConsumptionto swap simulation responses - STON.fi SDK Changelog - Provides contract version, routing, and SDK implementation changes relevant to current integrations
- TON Gas Estimation Guide - Explains compute, forward, storage, and multi-contract fee estimation on TON
- TON Transaction Execution Phases - Explains storage, compute, action, bounce, and the sequence in which fees are charged
- TON Estimate Fee API - Describes the network API for estimating storage, gas, and forwarding fees for a message
- TON Message Sending Modes - Explains how message value, gas fees, and forwarding fees interact during internal message delivery
Top comments (1)
Hi. If you find an error in the text or code, please be sure to leave a comment below. This will help others who might also read this article and encounter problems. Thank you in advance for your help and support!