Investigate a failed sell before changing settings

The short answer

A failed sell can have many causes: insufficient native balance, an expired quote, no available route, weak liquidity, a migration in progress, transfer rules, a paused contract, missing wallet authorisation, network congestion, or a platform outage. The same symptom does not prove the same cause, so diagnose before you act again.

Step one: did a transaction exist?

Determine whether a transaction was submitted, and whether it succeeded. Use the platform's status display and the chain explorer. An interface showing "pending" may simply not reflect the latest chain state.

This matters because repeated submissions can create extra cost, and on some platforms duplicate execution, if an earlier attempt eventually lands. Resubmitting is a decision with its own risk.

Step two: check the inputs

• Exact chain and token address — are you selling the asset you think you hold?
• Actual wallet balance of that token.
• Native asset balance for fees, where required. This is the most common trivial cause.
• The route the platform selected, and whether it still exists.
• Quote age.
• The literal error message, saved rather than paraphrased.

Step three: check the token itself

If the inputs are fine, the token may be the cause. Look for transfer restrictions, a transfer fee that changes the amount delivered, a pause function, a blacklist, an active freeze authority on Solana, or a migration that moved liquidity elsewhere.

When a token has no executable route, a chart price is not evidence that a sale can occur. A chart can continue updating from a pool you cannot reach at your size.

What not to do

Do not respond by repeatedly widening tolerance. If the cause is a restriction, a missing route or an empty native balance, tolerance is irrelevant and the attempts cost money. Document what you observe instead, and change one variable at a time.

Getting help safely

Use the platform's official support instructions, reached from the official domain rather than from a search result or a direct message. Preserve transaction IDs and error messages.

Never send a seed phrase, private key, account recovery code, or unrestricted signing access to anyone, for any reason. Anyone promising guaranteed recovery, or demanding a separate "unlock" or "gas" payment to release your funds, is describing a second loss.

Compromise is a different problem

If a private key is compromised, disconnecting an app does not secure that key; the key can still sign. Moving remaining assets to a new wallet created on a clean device is the relevant action.

If the issue is an approval or delegate on EVM, that is a permission problem requiring chain-specific investigation of what was granted and to whom. If a social account was compromised, that is a third distinct problem. Treat wallet key compromise, token allowances, app sessions and social-account compromise as separate mechanisms with separate remedies.

What this cannot establish

Explorer evidence shows what happened on-chain. It does not show platform-internal state, off-chain order handling, or why an operator's system behaved as it did. Record what you can verify, and label the rest unknown.

Checklist

• Was a transaction submitted, and what does the explorer say?
• Native balance sufficient for fees?
• Chain, address and token balance confirmed?
• Route available and quote fresh?
• Token-level restrictions investigated?
• Error message and transaction IDs preserved
• Support reached only through the official domain
• No keys, seed phrases or recovery codes shared with anyone