Fomo app
Fomo app Failed Trades and Retry Conditions
Fomo app trade retries should wait until you know whether the original attempt completed, failed or remains unresolved. A timeout or missing holding does not establish that nothing happened. If the trade completed, reconcile the display instead of submitting another purchase or sale. If it definitively failed, address the stated cause and review a fresh quote before trying again. Pending activity needs confirmation, while an unexplained balance change needs investigation. The distinction matters most when prices move quickly: another confirmation can create another trade, and its execution terms may differ from those you originally accepted.
Submission errors and duplicate trades
A communication error can leave the outcome unclear even when a transaction has reached the execution infrastructure. Fomo provides access to external protocols and networks, so a problem displaying a response does not necessarily identify where execution stopped. Treat an interrupted response as an unresolved attempt until the transaction record establishes otherwise.
Submitting a new trade during that uncertainty can create an additional instruction to buy or sell. A duplicate purchase increases the holding if both attempts execute. A duplicate sale can sell more than intended if enough tokens remain available. These are reasons to pause additional submissions while checking the original attempt, even when the market opportunity is time sensitive.
Completed trades and delayed display
If a portfolio update is missing, check the matching execution record to establish whether the trade completed. Fomo includes transaction and trade history, which provides a more useful starting point than the portfolio total alone.
Match the record to the intended token, trade direction and amount. Include the transaction identifier where one is available. A record for a deposit or another trade does not resolve the attempt in question.
Successful execution and a refreshed holding are different observations. If the transaction details show the intended swap succeeded, an unchanged display calls for reconciliation. Refreshing the displayed information does not require placing another trade.
Token quantity also differs from the holding’s displayed monetary value. Market movement can change that value without another purchase or sale. For this troubleshooting task, concentrate on whether the intended token movement occurred.
Should you retry a pending trade?
Do not retry a pending trade until you establish that it failed or expired without executing. Elapsed time alone does not prove failure. Preserve the original identifier and any displayed error rather than treating a disappearing progress indicator as cancellation. If the records remain inconclusive, pause additional submissions and ask support to clarify that specific attempt. There is no defensible universal waiting period that applies to every trade across different networks and execution paths.
Wait, retry, adjust or stop
The appropriate response follows the transaction’s outcome and the condition that prevented completion.
| Response | Condition for using it | Boundary before another submission |
|---|---|---|
| Wait | The original attempt remains pending or its outcome is unknown. | Resolve the original attempt; a timer alone is insufficient. |
| Retry | The attempt definitively failed or expired without executing, and the cause no longer applies. | Review the replacement quote before confirmation. |
| Adjust | A confirmed failure identifies an input that can be corrected. | Resolve the old attempt before changing and submitting the input. |
| Stop and reconcile | Execution succeeded, records conflict or a restriction remains. | Reconcile successful execution or conflicting records, and do not submit another trade while an applicable restriction remains. |
| A completed trade with a display discrepancy needs reconciliation; an incomplete trade needs its outstanding condition resolved. | ||
A fresh quote after confirmed failure
A confirmed failure makes a replacement possible only if the replacement still satisfies your intended trading conditions. The earlier quote describes an earlier market state. Review the amount spent, expected amount received and displayed charge again. Fomo shows its applicable transaction fee before confirmation, while external execution costs can depend on settlement conditions.
Define the acceptable output before confirming, rather than deciding that any successful execution counts as recovery. If the revised quote no longer meets that condition, stop before submission. Correcting an invalid amount or refreshing a quote changes the proposed trade; it does not recover the earlier price.
Keep changes tied to the actual error. Changing several settings together makes another failure harder to interpret, particularly when the message identifies only a specific input problem. Reviewing information is reversible. Confirming a replacement creates a new commitment.
Slippage limits and available liquidity
A price-related failure requires separating the movement of the market from the effect of the trade itself. Slippage describes the difference between expected and actual execution prices. Price impact describes the movement caused by consuming available liquidity. Both matter when deciding whether a replacement quote remains acceptable.
A trade that consumes a larger share of available pool liquidity generally causes greater price impact. Fomo exposes token liquidity and trading-volume information that can help explain a difficult execution. Those figures do not guarantee that a particular sale will succeed. A market can have recent activity while offering poor execution for the amount currently proposed.
Where an execution flow enforces a slippage limit, a swap can fail if execution would exceed it. Widening the limit permits a worse execution outcome within that limit. It does not repair connectivity, establish that a pending trade failed or remove a token restriction. A smaller proposed amount may reduce price impact, but that change also alters how much of the holding the trade buys or sells.
Charges after unsuccessful execution
A failed swap can leave a transaction cost even when the intended exchange of tokens never completes. The relevant distinction is whether execution reached a stage that charges a fee, who paid it and how the app accounts for that cost.
On Solana, an executed transaction that fails still charges its transaction fee to the fee payer. This does not establish that every Fomo error charges the user directly. An error before submission differs from a transaction that reached execution, and an application may use a separate fee payer.
Read the actual fee and transfer entries before describing a balance reduction as a missing purchase. A fee debit proves a charge, not successful delivery of the desired token. Conversely, the word failed does not establish a refund entitlement for every cost associated with an attempt.
Expiration and an absent transaction
An absent transaction record needs more interpretation than a definitive execution failure. A lookup can lack a result because submission never reached the network, the information service lags or the transaction did not land. The available status must distinguish those possibilities before a replacement becomes safe from duplication.
A Solana transaction using a recent blockhash cannot execute after that blockhash expires if it never entered a block. This expiration condition differs from an app timeout. It also does not apply identically to every transaction format or network.
For an attempt with an available transaction identifier, preserve that identifier throughout troubleshooting. If expiration is the proposed explanation, establish that the original transaction did not already execute. A fresh request can use fresh transaction data, so protocol protection against replaying the same transaction does not automatically prevent a separate replacement trade.
An incomplete operation across networks
A trade involving multiple networks needs confirmation of the overall result, not merely one successful transaction. Fomo supports trading across supported chains, but an intermediate movement alone does not prove that the intended token purchase or sale completed.
If the visible record shows funds moved while the expected output remains absent, avoid repeating the entire operation. Identify what that movement accomplished and which result remains outstanding. A transaction’s success status describes that transaction’s execution; it does not automatically describe every component of a broader operation.
This boundary also limits refund assumptions. Atomic execution means the operations within a transaction succeed together or their changes are rolled back, although transaction fees can still apply. It does not mean that a separate transaction on another network reverses automatically when a later action fails. An unexplained intermediate balance belongs in reconciliation or support handling before another submission.
When does a failed trade need support?
A failed trade needs support when its records conflict, its cause remains unexplained or repeated attempts encounter the same unresolved condition.
Provide the exact error text, approximate attempt time with its time zone and whether the action was a purchase or sale. Include the token identifier and transaction identifier when available. Explain whether the intended asset movement occurred, rather than reporting only that the screen looked wrong.
Keep screenshots limited to the relevant transaction and error. Account credentials, private keys and recovery phrases do not belong in a trade-status report. A request to disclose those secrets adds an account-security problem to the original execution problem.
Support can help distinguish an app display issue from an execution issue, but a support conversation does not itself cancel a submitted transaction. While the outcome remains unresolved, avoid additional trades that would make the original movement harder to isolate.
Still have questions?
Does closing Fomo cancel a trade that I already submitted?
Closing the app does not establish that a submitted trade has been cancelled. Once execution infrastructure has received the transaction, it can continue processing without an open screen. Reopening the app is a way to inspect the outcome, not evidence that the earlier instruction disappeared. Resolve the existing attempt before confirming a replacement.
Can switching between mobile and desktop resolve a failed Fomo trade?
Switching devices can provide another view of the same account, but it does not change the original transaction’s outcome. Fomo supports mobile and web access. Use another view to inspect existing activity when the first display is unresponsive, without assuming that opening a different interface cancels pending activity or makes another submission necessary.
Is a successful trade with fewer tokens than expected a failed trade?
Receiving fewer tokens than expected does not by itself mean the trade failed or establish why the output differs. Compare the actual amount received with the accepted trade details, relevant charges and any applicable minimum-output condition. A disappointing output alone is not a reason to repeat the purchase. An apparent breach of the accepted conditions needs investigation.
How should I describe a problem that affects only one token?
Report that the failure affects a specific token without assuming the token is fraudulent or the whole app is unavailable. Include its identifier and the exact error. Token-specific liquidity or execution conditions can differ from those of other assets. Successful activity elsewhere does not explain the failing attempt, and repeatedly testing it can add costs.
Last updated —