Why Did My STON.fi Transaction Fail? A Complete Guide to Diagnosing Failed Transactions
A failed transaction on STON.fi can be frustrating, especially when your wallet shows an error without clearly explaining what went wrong. But a failed operation does not automatically mean that the STON.fi protocol is broken.
The cause can be much closer to the user: insufficient $GRAM for network fees, a change in market conditions, excessive price impact, slippage limits, wallet or connection issues, a token specific problem, a farm lock, or an actual on chain execution failure.
The most reliable way to troubleshoot the problem is to identify exactly what operation you were performing, determine whether the transaction was actually broadcast to the TON blockchain and then inspect the relevant conditions before trying again.
STON.fi’s Help Center separates issues across transactions, withdrawals, token problems and technical issues, while its swap documentation explains the price, slippage and blockchain fee conditions that can affect execution.
1. Start by Identifying the Operation
The first question should always be: What were you trying to do?
A swap, liquidity withdrawal, farm withdrawal, pool operation and token transfer can fail for different reasons.
For example, a liquidity withdrawal requires $GRAM to cover the blockchain fee. STON.fi explicitly instructs users who cannot withdraw liquidity to first verify their $GRAM balance before assuming there is a protocol problem.
Farming operations can introduce another condition: some farms have a lock-up period. If a user attempts to withdraw while the position is still locked, the transaction may not be available regardless of the wallet balance. STON.fi recommends checking the remaining lock period first, then checking the $GRAM balance and reconnecting the wallet if necessary.
This makes the operation type an important diagnostic clue.
Before retrying, determine whether the failed action was:
A token swap
Check the quoted rate, price impact, minimum received, slippage tolerance, token warnings and $GRAM available for the blockchain fee.
A liquidity withdrawal
Check whether the wallet contains sufficient $GRAM and whether the wallet connection is functioning correctly.
A farm withdrawal or close operation
Check for an active lock-up period, sufficient $GRAM, wallet connectivity and, where necessary, whether another compatible wallet produces the same result.
A custombtoken interaction
Verify the token contract address, metadata, decimals, liquidity and any warnings before interacting again. STON.fi specifically warns that a custom token's name, ticker or logo does not prove that it is legitimate.
Correctly identifying the operation prevents you from applying the wrong solution.
2. Check Your Wallet's $GRAM Balance
One of the simplest causes of failed transactions is also one of the easiest to overlook: the wallet needs enough $GRAM to pay the network fee.
STON.fi describes the blockchain fee as the network cost required to execute a transaction, and its documentation states that users need $GRAM in the wallet for network fees. The exact fee depends on the operation and can be displayed in the interface before confirmation.
This matters because the token you are swapping is not necessarily the asset used to pay the blockchain fee.
For example, you could hold enough USDT to perform a swap but still be unable to execute the transaction if your wallet does not have enough $GRAM for the required network fees.
STON.fi's withdrawal documentation makes the same point: withdrawals from liquidity pools and farms require $GRAM to cover blockchain fees.
Why the balance can be misleading
Having a non-zero $GRAM balance does not automatically mean that it is sufficient.
A transaction may require more network value than the amount currently available after accounting for the transaction's processing requirements. TON transactions can include storage, gas, action and forwarding fees depending on the message flow.
Therefore, do not simply ask:
"Do I have $GRAM?"
Ask:
"Do I have enough $GRAM for this specific operation?"
The blockchain-fee field shown by STON.fi before signing is useful for this check.
3. Understand Slippage and Price Impact
For swaps, one of the most important distinctions is between price impact and slippage.
They are related, but they are not the same thing.
Price impact
Price impact refers to how much your own trade changes the price inside the liquidity pool.
Because STON.fi uses an automated market maker model, swapping tokens changes the ratio of assets in a pool. A large swap relative to the available liquidity can therefore move the pool price significantly.
This means a swap can fail to provide the expected execution even when the market itself has not moved dramatically. The trade may simply be too large compared with the available liquidity.
Slippage
Slippage is different.
It describes the difference between the price you see when requesting the transaction and the actual price when the transaction executes on-chain.
Network delays, market volatility and other traders can cause the expected price to change between those two moments.
STON.fi currently documents a default 1% slippage tolerance and a default 5% price-impact threshold. These values can be changed in the swap settings, but increasing them exposes the user to potentially worse execution.
This is why blindly increasing slippage is not a proper troubleshooting strategy.
If the transaction fails because the market moved outside the accepted limits, the correct question is not simply:
"How do I make the transaction go through?"
It is:
"Why did the expected execution become unacceptable?"
You may need to reduce the trade size, wait for market conditions to stabilize, or reconsider the selected token pair rather than simply accepting a worse rate.
4. Check the Minimum Received and Swap Details
Before confirming a swap, STON.fi displays several important parameters.
Swap rate tells you how much of the output asset you are expected to receive.
Price impact indicates how much your trade affects the pool price.
Minimum received represents the lowest amount of the output token you should receive under the configured slippage conditions.
Blockchain fee indicates the network cost required to execute the transaction.
These numbers should be reviewed before signing, not only after something goes wrong.
A transaction that looked attractive at the beginning can become less favorable if the market moves, liquidity changes, or the expected execution price deteriorates.
Large orders deserve particular attention because a large trade against a relatively small pool can create significantly higher price impact. STON.fi notes that splitting a large swap into smaller trades can reduce price impact, although multiple transactions also introduce additional fees and therefore do not automatically guarantee a better overall result.
5. Pay Attention to Token Warnings
Not every failed or problematic transaction is caused by liquidity or network conditions.
The token itself may be the problem.
STON.fi allows users to import custom tokens by entering their smart-contract address. However, the platform explicitly warns users to obtain the correct official contract address and independently research the token because fraudulent tokens can copy legitimate names, symbols and logos.
This is particularly important when interacting with unfamiliar assets.
A token may look legitimate because its displayed name and logo resemble a known project, while its underlying contract is completely different.
TON's own documentation reinforces this security concern: token metadata alone should not be treated as authentication, because attackers can create fake jettons with matching names, symbols and images.
Before retrying a transaction involving a custom token, verify:
the official contract address;
the token's metadata and decimals;
whether sufficient liquidity exists;
whether the asset is actually the intended token;
whether STON.fi displays a warning;
whether the token has unusual or suspicious behavior.
STON.fi's glossary also identifies fake tokens and honeypots as known risks.
A failed transaction is sometimes a warning to investigate an asset more carefully rather than something to force through.
6. Check Whether the Transaction Was Actually Broadcast
This is one of the most important diagnostic steps.
There is a difference between:
A transaction that was never successfully submitted by the wallet
and
A transaction that was submitted to TON but failed during blockchain execution.
If the wallet refused the request before broadcasting it, there may be no corresponding on-chain transaction to inspect.
But if the transaction reached the blockchain, its execution can be investigated using a TON explorer.
TON's documentation explains that transaction links can be generated using the account address, logical time and transaction hash, allowing the transaction to be inspected through an explorer.
Therefore, after a failed transaction, look for the transaction hash or explorer link provided by the wallet or application.
If there is no transaction record, focus first on the wallet, connection, signing or submission stage.
If there is an on chain transaction, inspect its blockchain status and execution details.
7. Read the TON Transaction Result
An explorer can reveal information that a simple wallet error message may not show.
TON transactions are processed through different execution phases, including storage, compute and action phases. Depending on what went wrong, the blockchain may record an execution failure or generate a bounced message.
A bounce is particularly useful as a diagnostic signal. TON documentation explains that a bounce message can be generated when a bounceable message fails during contract execution or when an action fails under the appropriate conditions.
This means a transaction appearing as "failed" does not tell the entire story by itself.
Look at the transaction trace and determine:
Was the transaction included on-chain?
Which contract received the message?
Did execution reach the expected contract?
Was there a compute-phase failure?
Was there an action-phase failure?
Was the message bounced?
Was there an indication of insufficient funds?
Did a subsequent message succeed or fail?
For complex operations, one user action can involve several blockchain messages. Examining the transaction trace can therefore provide more information than relying on the first error displayed in the wallet.
8. Wallet and Connection Problems Can Also Be the Cause
STON.fi's own troubleshooting guidance repeatedly recommends reconnecting the wallet when an operation fails.
For certain withdrawal problems, STON.fi suggests disconnecting and reconnecting the wallet, then, when necessary, trying the same wallet through another compatible TON wallet application. If the operation works in another wallet, the problem may be associated with the original wallet application rather than the STON.fi protocol.
This is an important diagnostic method because it helps isolate the source of the failure.
For example:
Failure only in one wallet:
There may be a wallet-specific connection, signing or implementation issue.
Failure across multiple compatible wallets:
The problem is less likely to be limited to one wallet application and may require investigation at the protocol or blockchain level.
STON.fi specifically recommends contacting the wallet's support team when an issue appears only in that wallet, while issues reproduced across wallets should be escalated to STON.fi support.
9. Farming and Withdrawal Transactions Have Extra Conditions
Not every transaction is a swap.
Farming positions can have lock-up periods, and those restrictions must be checked before treating an unsuccessful withdrawal as a technical failure.
STON.fi states that the lock period is shown before a farming position is confirmed. If a "blocking" message appears, the first step is to verify whether the lock-up period has expired. After that, check the $GRAM balance and reconnect the wallet if necessary.
Likewise, closing a farming position can require $GRAM for the network fee. STON.fi's troubleshooting sequence is to check the lock period, verify the $GRAM balance, reconnect the wallet and then try a different compatible wallet if the problem continues.
This demonstrates why the operation type matters so much: a failed swap and a blocked farm withdrawal are not necessarily diagnosed in the same way.
10. Do Not Immediately Retry the Same Transaction
One of the most common mistakes is repeatedly pressing Retry without understanding the cause.
If the problem is insufficient $GRAM, another attempt will not solve it.
If the problem is excessive price impact, immediately repeating the same trade may produce the same result.
If the market has moved beyond your slippage tolerance, retrying without reconsidering the quote can leave you in exactly the same situation.
If the token itself is suspicious, repeated attempts can increase your exposure to the underlying risk.
And if the transaction has already been broadcast, creating another transaction before checking its status can make it harder to understand what actually happened.
A better sequence is:
Identify → Inspect → Diagnose → Correct → Retry.
Not:
Fail → Retry → Fail → Retry.
11. A Practical STON.fi Troubleshooting Workflow
When a STON.fi transaction fails, work through the following sequence.
Step 1: Identify the operation
Was it a swap, liquidity deposit, liquidity withdrawal, farming action, staking operation or token interaction?
Step 2: Check the wallet
Confirm that the correct wallet is connected and that it contains enough $GRAM to cover the network fee.
Step 3: Review the transaction parameters
For swaps, check:
swap rate;
price impact;
minimum received;
slippage tolerance;
selected route or execution option;
blockchain fee.
STON.fi exposes these parameters to help users understand the transaction before confirmation.
Step 4: Check token legitimacy
For unfamiliar or manually imported tokens, verify the official contract address and investigate any warnings before interacting further.
Step 5: Check transaction status on-chain
Find the transaction hash and inspect it with a TON explorer. Determine whether the transaction was broadcast, executed, bounced or failed during one of the execution phases.
Step 6: Isolate the source
Reconnect the wallet.
If appropriate, test the same wallet in another compatible TON wallet application. STON.fi uses this approach in its own troubleshooting documentation to distinguish wallet side issues from broader problems.
Step 7: Correct the actual cause
Add sufficient $GRAM if fees are the problem.
Wait or reconsider the trade if market movement is the problem.
Reduce trade size if price impact is excessive.
Verify the token if the asset is unfamiliar.
Wait for a farm lock-up to expire if the position is still locked.
Reconnect or change the wallet application if the problem appears wallet-specific.
Step 8: Retry only after diagnosis
Once the likely cause has been identified and corrected, a new attempt becomes meaningful.
What Information Should You Collect for Support?
When the issue continues after basic troubleshooting, avoid sending only a message such as:
"My transaction failed."
That gives support very little information to work with.
Instead, collect the relevant transaction data.
Include:
Wallet address: preferably the public address involved in the transaction.
Transaction hash or explorer link: when the transaction was actually broadcast.
Operation type: swap, withdrawal, farming, liquidity, etc.
Token pair: for swaps.
Amount: the amount attempted.
Approximate time of the transaction: useful for locating the event.
Error message: provide the exact wording shown by STON.fi or your wallet.
Wallet application: identify which TON-compatible wallet was used.
Screenshots: where useful, especially for displaying the exact error or warning.
Do not provide your seed phrase, private key, recovery phrase or other sensitive wallet credentials to anyone claiming to be support.
STON.fi directs users to its official support channels when troubleshooting cannot resolve the issue.
The Key Lesson
A failed STON.fi transaction is not automatically a protocol failure.
The most effective troubleshooting approach is to locate where the transaction failed.
It may have failed before broadcasting because of the wallet or connection.
It may have been rejected because there was insufficient $GRAM for network fees.
It may have become unacceptable because of price impact or slippage.
It may have been restricted by a farm's lock-up conditions.
It may involve a token that requires additional verification.
Or the transaction may have reached TON and failed during blockchain execution.
The solution is therefore not to blindly increase slippage or repeatedly press retry.
The correct approach is to identify the operation, check the wallet balance, review the transaction parameters, verify the token, inspect the TON transaction status, isolate the likely cause and only then retry.
That turns a vague "transaction failed" message into a structured troubleshooting process.
Final Diagnostic Checklist
Operation: What exactly was I trying to do?
$GRAM: Is there enough native $GRAM for the network fee?
Swap conditions: Did price impact or slippage exceed the acceptable limits?
Minimum received: Did the expected output change?
Token: Is the contract address legitimate and is the asset safe to interact with?
Wallet: Is the correct wallet connected and responding properly?
Explorer: Was the transaction actually broadcast, and what happened on-chain?
Farm/withdrawal: Is there an active lock or another operation-specific restriction?
Retry: Have I identified and corrected the likely cause before submitting another transaction?
Support: Do I have the transaction hash, wallet address, operation details, timestamp and error message ready?
Troubleshooting becomes much easier once these questions are answered in order.
STON.fi's official Help Center remains the primary reference for transaction and withdrawal issues, while TON's explorer and blockchain documentation provide the deeper on-chain evidence needed when a transaction has already been broadcast.