How to Estimate Gas for a STON.fi Transaction

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: " ", askAddress: " ", offerUnits: " ", 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 g