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

A failed trade on https://gmgn.ai is rarely a broken platform. GMGN publishes a full error-code table for transactions and limit orders, and nearly every code in it points at one of three settings you control: slippage, priority fee, and whether Anti-MEV is switched on. The remaining codes point at something that cannot be fixed at all, and knowing which bucket you are in saves a lot of wasted retries.

This guide walks through every published code from A1 to L3, what each one actually means, and what to change. All of it comes from GMGN's transaction and limit order failure documentation, checked August 6, 2026.

Start here: GMGN's own triage order

Before opening the code table, GMGN tells failed users to check three things, in this order:

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. 0.01 SOL or above when the trade is larger than 1 SOL.
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.

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 contains no workaround. There is none. Once you hold a honeypot, the position is gone, and no amount of slippage or priority fee changes that.

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 is accurate. There is nothing to refund and nobody to refund it. 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. 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 a rug. The liquidity that made the token tradeable is gone, taken by whoever deployed it. 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.

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. This is true of every on-chain limit order on every platform, and no setting on your side changes 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.

Reading the raw error strings

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.

When nothing in the table applies

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. The token cannot be sold and no retry will change that.
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.