When The Handover Goes Wrong: Migration Failure Cases

Almost everything that looks like a failed migration is one of two things: the transaction genuinely failed and has not been retried yet, or the transaction succeeded and something downstream has not caught up. Distinguishing them takes one lookup. Everything else on this page is a variation on that question, plus the one genuinely adversarial case, which is somebody funding a pool for a mint that shares your token's name.

Failure is first a transaction question

A migration is an ordinary transaction. It can fail for the same reasons anything fails, which the Solana documentation sets out for transactions generally: compute budget exceeded, account state changing between simulation and execution, or simply not landing during a period of congestion. Failure means nothing changed. The curve is still complete, the pool still does not exist, and a retry can succeed.

So the first question in any incident is binary and cheap to answer: does the pool exist? If yes, the migration succeeded and every remaining problem is downstream of the chain. If no, the migration has not completed yet and there is nothing to debug except patience.

Getting this backwards is the source of most bad incident handling. Teams start investigating charts, screeners and aggregators before establishing whether the thing those tools are meant to display exists at all. Establish the ground truth first, then look at layers.

Case one: the routine stalls

The curve is marked complete and no pool has been created. Symptoms: the token cannot be traded anywhere, the launchpad shows the curve finished, and no pool address can be found because there is none.

This is the least alarming case despite feeling the worst, because it is the state the mechanism is designed to pass through. Between completion and pool creation there is a window in which the token is deliberately untradeable, and the window is not fixed in length. A failed attempt extends it until a retry succeeds.

What to do: confirm from the curve account that completion actually happened, then look for pending or failed transactions involving the relevant accounts. Say publicly that migration is in progress and that you will confirm when the pool exists. What not to do is announce a problem, because the ordinary case and the problem case look identical from outside for a period that is normally short.

Case two: the pool exists, nothing shows it

The migration succeeded. The pool holds both reserves. Yet the token has no chart, appears nowhere on the usual screeners, and a swap through a familiar front end fails to find a route.

This is the most common incident of the entire transition and it is not a failure at all. Every third-party surface maintains its own index of pools and updates on its own schedule. A new pool is unknown to them until they notice it, and they notice at different times.

What to do: verify the pool from the migration transaction, then tell people plainly that the token is tradeable and that display surfaces are catching up. Give the pool address to anybody who needs it operationally. Resist the urge to treat a missing chart as evidence, because the chart is downstream of an index that is downstream of the chain, and only the chain is authoritative.

Case three: a front end holds a dead route

The opposite failure. A front end still offers to trade the token, produces a quote, and the transaction fails or produces a nonsensical result. The interface is quoting a route that no longer exists, usually the curve, occasionally a stale pool.

Cached routes are ordinary engineering and every aggregator has some caching somewhere. When the underlying venue changes, cached state is wrong until it refreshes. The user sees a working interface producing failures, which is more confusing than an interface that simply says it cannot help.

What to do: request a fresh quote and read the route it returns, which routing interfaces such as the one covered in the Jupiter documentation expose directly. If the route names the curve or a pool that is not the one migration created, the cache is stale and waiting or switching aggregators resolves it. This case is worth naming explicitly to your community, because a failing swap in a familiar interface is what makes people go looking for an address elsewhere, which is exactly where the next case is waiting.

Case four: the impostor pair

The only genuinely adversarial item on the list. A mint is created with the same name, symbol and image as a token that is graduating. A pool is created for it and funded enough to produce a plausible chart. The address is circulated into channels where people are already hunting for a post-migration address.

Every component is legitimate on its own. Metadata is free text. Pool creation is permissionless. The trades on its chart are real trades against real reserves. Nothing about its appearance is anomalous, which is precisely why appearance is useless as a defence.

What to do: compare the mint in full, always. Not the first and last four characters, which is what the pattern is designed to defeat. Publish only the mint through your own channels, say in advance that you will only ever publish the mint, and treat any address arriving through a forwarded message as unverified regardless of who forwarded it.

Case five: depth is not what was expected

The pool exists, the token trades, and fills are much worse than anticipated. Someone concludes that liquidity was removed.

Several ordinary explanations come first. The launchpad's retained share reduces the quote deposit, and if you assumed a smaller retention you will have expected more depth than was ever going to be there. Providers who added during the busy window may have withdrawn, which is their right and is visible on chain. Or you may be reading a different pool for the same mint, since permissionless pool creation means the migration pool is not necessarily the only one.

What to do: read the reserves of the specific pool you care about and compare them against the deposits recorded on the migration transaction. The difference is trading plus provider activity, and both are readable. Concluding that liquidity was pulled without checking which pool you are looking at is the most common wrong diagnosis in this category.

Case six: the LP position was not disposed as assumed

Everybody says migration liquidity is locked. Somebody eventually checks and finds the LP tokens sitting in a spendable account, or in a lock with an end date nobody mentioned.

Burning and locking are different guarantees. A burn is permanent because the claim no longer exists. A lock is temporary by construction and has a release condition. Both get described as locked liquidity in casual conversation, and the difference matters enormously a month later.

What to do: read the LP mint state on the migration transaction, which an explorer such as Solscan will show as a supply figure and a set of holders, rather than repeating what is generally believed. If tokens were burned, the supply went to zero or moved somewhere provably unspendable. If locked, they are held by a lock program with terms you can read. If neither, that is a fact your community deserves to hear from you rather than from somebody discovering it later.

Case seven: silent tooling stoppage

The most invisible failure and often the most consequential. A bot, alert or dashboard configured against the curve simply stops doing anything when the curve stops accepting trades. No error is raised. No dashboard turns red. The channel goes quiet, and quiet reads as a calm market.

Everything venue-keyed in a stack has this property. Price feeds return the last value they knew. Alert rules stop matching. Anything that trades keeps trying against a venue that rejects it, paying fees to accomplish nothing, or stops attempting and reports success at having nothing to do.

What to do: fix it structurally rather than case by case. Every venue-keyed tool should raise an alarm when it stops receiving updates, so absence becomes an event. That single change converts the worst failure mode on this list into an ordinary one.

It is also the right question to ask when comparing tooling. Teams looking for the best Solana volume bot usually compare features and pricing; the more revealing test is what the thing does on the day its venue disappears, because that is when the difference between resolving a venue and storing one becomes visible.

Symptom to cause, in one table

Illustrative arithmetic on a misread pool

Triage order

1. Does the pool exist? Open the migration transaction. If there is no pool, the migration has not completed and nothing else on this list applies.
2. Is it the right pool? Confirm it holds your exact mint, compared in full. If not, you have an identity problem rather than a market problem, and it is urgent.
3. What are the reserves? Read them directly and compare against the deposits on the migration transaction. This settles most questions about depth immediately.
4. What does an aggregator say? Request a quote and read the route. This tells you whether routing works and which pool is actually being used.
5. Which layer disagrees? If the chain is fine and a surface is not, the incident belongs to that surface, and the correct action is to say so rather than to change anything.
6. Is anything of yours silently stopped? Walk the venue-keyed inventory and confirm each item is receiving data, rather than assuming that no alarm means no problem.

Working in that order means the cheap checks come first and the expensive investigations only happen when the cheap ones have ruled out the ordinary explanations. Working in any other order means investigating an indexer while the actual answer was one lookup away.

What is not a failure

A period of untradeability between completion and pool creation is not a failure. It is the mechanism preventing the same asset from trading at two prices simultaneously, and it exists by design.

A missing chart is not a failure. Charts are derived data maintained by people with no obligation to be prompt, and their absence says nothing about whether the token trades.

A price that does not continue the curve is not a failure. The two venues compute price differently and there is no mechanism requiring agreement, so a jump at the seam is arithmetic rather than an event.

Depth that falls after the first hour is not a failure. Providers who arrived to capture fees during the busy window leaving afterwards is ordinary behaviour, visible on chain, and predictable enough to plan for.

The genuine failures are narrow: a transaction that has not landed, an assumption about the LP position that nobody checked, an impostor address that reached your community faster than your own, and tooling that stopped without telling anybody. Teams that maintain multi-venue volume automation across a launch tend to encounter the last of those first, because it is the one that produces no symptom until somebody notices an absence, and by then the window it mattered in has usually closed.

Questions the desk is sent