GMGN Transaction Failed: Every Error Code and How to Fix It

Start here: GMGN's own triage order

Before opening the code table, GMGN tells failed users to check three things, in this order. Every number in the three points below is quoted from GMGN's transaction and limit order failure documentation, read 6 August 2026:

1. Slippage. Auto for manual buys and sells. 30 to 35% for automated orders and limit orders. 50% or more for new and hot tokens.
2. Priority fee and tip. 0.002 SOL total when speed does not matter. 0.006 SOL or above for auto buy/sell and limit orders, and manually higher again when the network is busy.
3. Anti-MEV. It blocks sandwich attacks, but it requires a priority fee of at least 0.002 SOL and it routes through a smaller set of nodes that can fail independently.

Those numbers are recommendations, not rules, and the fee ones get expensive fast on small positions. We price that out properly in GMGN fees explained. For now, treat them as the settings to move first.

Timeouts: A1, A2, A3

A timeout is not the same as a failure. GMGN warns that "the transaction may be successful even if it is timed out, and you need to check the status on the chain." Do not retry a timed-out buy until you have confirmed on Solscan that it did not land, or you can end up holding twice the position you wanted.

A3 is the one people miss. Anti-MEV routes your transaction through a restricted set of nodes. When that path degrades, your trades stop going through while everything else on Solana works fine. If you are getting repeated timeouts and your fees are already generous, turn Anti-MEV off and try once. If the trade lands immediately, you have found your answer. Turn it back on for your next large buy into a thin pool, since that is where sandwich bots make their money. A custom endpoint is not the fix for this one either, for reasons worked through in how to set a custom RPC in GMGN.

Submission failures: B1 to B5

These never reached the chain. Nothing was spent.

B1 is the most common failure on GMGN and the easiest to prevent. The 0.05 SOL reserve exists because a Solana wallet needs SOL for gas, for account rent on any new token account, and for the priority fee, all separate from the amount you are spending. "Max" buys are what usually trip it.

B4 is the one that ruins people. Pixiu is the Chinese term GMGN uses for a honeypot: a token you can buy and cannot sell, either because the contract blocks selling or because the deployer has blacklisted your address. GMGN's documented answer offers no workaround, and neither slippage nor priority fee is the constraint here, because the block sits in the token contract rather than in the terminal. Assume the position is gone.

The defense happens before the buy, not after. GMGN ships CA Security Checks on every token page (mint authority, top-10 holder concentration, blacklist flags, pool burn percentage, rug probability, and the deployer's rug history), plus GoPlus-sourced honeypot detection on EVM chains. Reading that panel takes five seconds and is the single highest-value habit on the platform. The how to trade on GMGN guide covers where it sits in the interface.

B5 deserves more attention than its one-line description suggests. Your wallet looks connected. The interface behaves normally. Orders simply never go anywhere. If GMGN starts refusing everything at once and your balances look fine, log out and reconnect before you touch any other setting.

Execution failure: C1

C1 is the expensive one. GMGN's own wording: "Failure to submit to the chain for execution will consume Gas/priority fee." Your transaction was packed into a block, tried to execute at a price the pool could no longer offer, and reverted. The validator keeps the fee for the work.

GMGN's position is that this money goes to the chain rather than to GMGN, and that matches what the explorer shows for a reverted transaction. There is nothing sitting with the platform to refund. A string of C1s during a violent minute can drain a meaningful amount of SOL with no position to show for it, which is the strongest argument for using auto slippage on manual trades instead of a low fixed number.

The counterweight matters too. Raising slippage to stop C1 errors means accepting worse fills. At 30% slippage a buy succeeds when you receive 70 to 100% of the quoted tokens; at 50% you accept as little as half. That reading of what a slippage setting authorizes is ours, worked out from the setting itself rather than quoted from GMGN, which documents the recommended percentages without spelling out the fill range they permit. You are choosing between a fee you definitely pay on failure and a price you might pay on success. That trade-off is worked through in GMGN fees explained.

No available route: D1, D2, D3

D1 is what GMGN's table calls a creator pulling liquidity. The pool that made the token tradeable is gone, so there is no route to quote against. GMGN's advice is preventative: confirm the pool has been burned before trading, since a burned pool cannot be pulled. The pool burn percentage is one of the fields in the security panel.

D2 catches people constantly and is completely normal. When a bonding-curve token graduates, the launchpad is building a real pool on Raydium or Meteora, and for that window the token cannot be traded anywhere. GMGN documents the threshold as a $69,000 market cap, which is Pump.fun's historical graduation figure and has moved over time, so treat the number as indicative and the mechanic as the point. The wait is typically minutes. If you want to be positioned the moment it opens, GMGN's Migrated Snipe feature creates the buy in advance, though the task has to be set up before migration begins.

All three of these surface to a Telegram-wallet user as one string, No Available Router, which is covered in full further down.

D3 is not your fault and not fixable from your side. GMGN routes through node providers and inherits their outages. If a specific token fails for you and works for others, it is not D3. If everything fails at once, it probably is, and GMGN asks users to report it in the official Telegram community.

Limit orders and automation: G1, H1 to H3, J1, J2, K1 to K5, L1 to L3

Limit orders, auto buy/sell, take-profit and stop-loss run through a parallel error set, because there are two moments that can fail: creating the order, and executing it once triggered.

Creation failure

G1 is worth taking seriously rather than dismissing. An order that fails to create leaves you with no stop-loss on a live position, and nothing in the interface shouts about it. After creating any protective order on a flaky connection, go back to the Holding or Orders tab and confirm it is actually listed.

Timeouts on triggered orders

H1, H2 and H3 mirror A1, A2 and A3 exactly: low priority fee, low slippage, and Anti-MEV RPC failure. The fixes are identical. H3 is the same trap as A3, and it is worse for automation, because a broken Anti-MEV path can silently kill every automated exit you have set while you are away from the screen.

Orders that never trigger

J1 is the code that generates the most anger, and GMGN's answer is unsatisfying. Verbatim from the documentation: "The pin insertion situation basically cannot be triggered, which is a normal situation and does not need to be solved."

"Pin" here means a wick, a candle that spikes to your price and retraces within the same instant. The chart records the extreme; the order book never offered a fill there. Your limit order needed a real, executable price that held long enough for a transaction to be built, submitted and packed into a block, and a wick does not provide one. That is a constraint of on-chain settlement rather than something specific to GMGN, and I have not found a user-side setting on GMGN that works around it. If your exit depends on catching a spike that lasts a fraction of a second, a limit order is the wrong tool; a trailing take-profit that arms at a level and then follows the price down by a set percentage is closer to what you want.

J2 is the quiet one, and it is the same failure as B5. Your wallet session expires. The interface keeps showing you as connected. Every limit order you have placed sits there looking armed and fires at nothing. Traders discover this hours later, after the move they were positioned for has come and gone. If you run automated orders overnight, reconnect the wallet before you leave, and check that positions and orders still load when you come back. The same session expiry is the most common reason a GMGN copy trading task stops mirroring, and copy tasks add their own rule: after three consecutive failures a task auto-pauses and will not restart itself.

Triggered but failed: K1 to K5

These repeat the B and C codes at execution time. K1 is C1 (slippage, already on the chain, consumes gas and priority fee). K2 is B1 (insufficient SOL, and GMGN repeats the 0.05 SOL reserve advice here). K3 is B2 (not enough tokens to sell). K4 is B3 (buy restricted by the token). K5 is B4 (Pixiu or blacklist, unsellable). L1, L2 and L3 repeat D1, D2 and D3.

The pattern worth internalizing: a limit order can fail for a reason that did not exist when you created it. You had 0.06 SOL when you set the order and 0.01 SOL when it triggered, so it dies as K2. Budget the wallet for orders that are still open, not just for the trade in front of you.

Why does GMGN say "No Available Router"?

This is the message people paste into a search bar, so here it is as GMGN's own documentation renders it, rather than paraphrased.

The literal string is No Available Router, capitalized that way, and it arrives wrapped in one of two error identifiers depending on what you were doing:

Both mappings are from GMGN's transaction and limit order failure documentation, read 18 August 2026. Note what the mapping does not give you: one string covers three different causes on each side, which is why the message alone never tells you what to do. It is a category, not a diagnosis.

What it means mechanically

A route is a path from the token you hold to the token you want, through a pool that can quote a price. GMGN's router looks for one, finds none, and stops before building a transaction. That last part is the useful bit: there is nothing on the chain, so it costs you nothing. Unlike C1, where the transaction reached a block, reverted on slippage and still consumed gas and priority fee, a router error is a refusal to submit. Retrying it costs nothing except the retry.

The conditions that reproduce it

Reading GMGN's own cause table rather than guessing, the string appears in three situations:

1. The pool is gone. GMGN's D1 and L1 both describe the creator or project owner removing liquidity, which leaves no pool to route through. This is terminal for that token. GMGN's own advice is preventative rather than corrective: confirm the pool was burned before you buy.
2. The token is mid-migration. D2 and L2 both describe a Solana launchpad token, Pump.fun and Moonshot named specifically, reaching the graduation threshold GMGN documents as $69K market cap, at which point the launchpad is building the Raydium or Meteora pool and the token cannot be traded until that pool opens. This is temporary and completely normal, and it is the version most people hit.
3. The network or the node provider is having a bad time. D3 and L3 both describe Solana congestion or a problem at the node service provider. Not your token, not your settings.

There is a fourth condition GMGN documents separately and it is worth knowing because it looks identical from the outside: order10006, mapping to L1, fires when pool liquidity is under $500. A pool that thin may technically exist while still being unroutable in practice.

On chain coverage: every cause GMGN names in this group is a Solana mechanic, and the migration case is explicitly a Solana launchpad one. Nothing in the documentation describes the equivalent behavior on the EVM chains or Tron, so we are not going to tell you it behaves the same there.

The fix, in order

Telling it apart from the failures next to it

The three adjacent codes get confused with this one constantly, and the distinction is always the same question: did a route exist?

• C1 means a route existed, the transaction reached the chain, and it reverted because the price moved past your slippage tolerance. It consumed gas and priority fee. A router error did not reach the chain and cost nothing.
• A1 and A2 are timeouts on a route that existed. The fixes are a higher priority fee and higher slippage respectively. Neither applies here.
• B1 to B5 never reached the chain either, but for a wallet-side reason such as insufficient SOL rather than a market-side one. If you are short of the 0.05 SOL reserve, that is a B code, not this.

If you cannot tell which you are in from the message, GMGN's own documentation points at the same place we do: look up the failure hash on Solscan. A router error has no hash to look up, and that absence is itself the answer.

What do GMGN's raw error strings mean?

The Telegram wallet returns raw error codes that map back to the numbered table. The useful ones:

Two of those are not really errors. order10007 means you tried to buy an amount worth more than a fifth of the pool, which would move the price against you enormously; the block is protecting you. order10008 means you have 100 active limit orders, GMGN's documented ceiling, and need to cancel some before creating more.

What if none of the error codes match?

A short list of issues that look like transaction failures but are not:

• You sold and no SOL arrived. Check whether it landed as WSOL. GMGN documents this as a Solana mechanic and ships a one-click WSOL to SOL converter in the Solana bot's Wallet screen. The other documented cause is more painful: your priority fee exceeded the proceeds.
• Wallet tracking or the Follow page shows no data. GMGN's fix is to log out, reconnect, and if that fails, clear cookies for gmgn.ai in the browser's site data settings.
• Multiple stacked auto-sell orders firing. Auto-sell is calculated per purchase rather than per position, so several buys create several overlapping take-profit and stop-loss sets. GMGN advises manually closing prior auto-sell orders when you add to a position.
• A transaction that "failed" but actually succeeded. Timeouts do not equal failures. Confirm on chain before retrying.

Confirm it on Solscan

GMGN points users to Solscan for both fee breakdowns and failure diagnosis, and it is the only place that shows what actually happened rather than what the interface reported. Paste the transaction hash and check three things: whether the transaction is on chain at all, what priority fee and tip were actually deducted, and the on-chain error reason.

That answers the question underneath most support requests, which is whether the money went to GMGN, to a validator, or into slippage. In almost every case it is the second or third. GMGN's 1% is fixed and visible; the variable costs are the ones worth auditing. If you want the background on how the platform is structured and who runs it, start with what is GMGN, or compare execution reliability against a rival in GMGN vs Photon.

The fix checklist

1. Read the error code in the failure message and find it above.
2. If it is A or H, the fix is a setting: priority fee up, slippage up, or Anti-MEV off.
3. If it is B or K, check the wallet: 0.05 SOL reserve, real token balance, and whether the session is still live.
4. If it is C1 or K1, the SOL is spent. Raise slippage or switch to auto before retrying.
5. If it is B4 or K5, stop. GMGN's documentation says the token cannot be sold once that is confirmed, and retrying does not address a contract-level block.
6. If it is D or L, the market is the problem. Wait out a migration, accept a rug, or wait out congestion.
7. If it is J1, the wick never offered a real price. Nothing to fix.
8. Still unclear? Pull the hash on Solscan, then report it in GMGN's official Telegram group with the hash attached.