Preparing For The Handover: A Pre-Migration Checklist

Prepare everything that does not depend on the pool address, and prepare a process for the one thing that does. The pool cannot be known before the migration transaction creates it, but who verifies it, who publishes it, where it is recorded and what gets repointed to it are all decidable while the curve is still running, which is when there is time to decide them properly.

Why the window afterwards is the wrong time

The hour after migration has four properties that make it hostile to decision-making. It is the moment of peak attention, so the audience is larger and less forgiving than at any other point. It is the moment of maximum ambiguity, because a new address is circulating and third-party surfaces disagree with each other. It is the moment when impostor addresses are most effective, because people are actively looking for a new address to copy. And it is the moment when anything venue-keyed in your stack has just stopped working without saying so.

None of those are surprising in advance. All of them are surprising at the time, because attention is elsewhere. The purpose of a checklist is to move decisions out of that hour and into a week when nobody is watching.

Phase one: early curve

The calmest phase and the one where the durable work belongs. Nothing here is urgent, which is exactly why it gets skipped.

• Confirm which venue the launchpad currently routes graduations to, by reading the launchpad's own documentation and checking a recent migration transaction. Do not rely on an article, including this one, for the current destination.
• Inventory every tool in the stack and label each one mint-keyed or venue-keyed. Bots, alerts, dashboards, embeds, feeds and anything on a schedule.
• Add a staleness alarm to each venue-keyed tool, so that a stop becomes visible. The default failure of a venue-keyed tool is silence, and silence looks like a quiet market.
• Decide who verifies the migration and who independently confirms. Two named people, not a team responsibility that belongs to nobody.
• Decide where the pool address will be recorded so that anyone on the team can copy it without asking. A pinned message or a shared document, chosen now.
• Write the post-migration announcement with the mint already in place and one blank for the pool. Composing text under pressure is how the wrong address gets pasted.
• Rehearse the verification steps on a token that has already graduated. Fifteen minutes once, and the procedure stops being unfamiliar.

Phase two: approaching completion

The curve is visibly close to its completion condition. Timing is still unknown, because it depends on other people trading, but the event is now plausibly imminent.

• Confirm the two named people are actually available, and name replacements if they are not. A runbook with an absent owner is a document, not a plan.
• Open the curve account and confirm you can read its state directly, which the account model in the Solana documentation makes available to anyone, rather than relying on a third-party progress display you have not verified.
• Pre-open the tools you will need: an explorer, the launchpad interface, an aggregator quote endpoint. Not because they are slow, but because finding them under pressure wastes minutes.
• Tell your community what will happen and what you will do, including that there will be a short period where surfaces disagree. Setting the expectation is most of the work.
• State plainly, in advance, that you will only ever circulate the mint publicly. This is the sentence that immunises people against the address they are about to be sent.
• Check that nobody has scheduled unrelated announcements into the same window. Competing messages at the moment of maximum confusion help nobody.

Phase three: the minutes around it

Completion has occurred or is occurring. This phase is execution only; nothing here should require a decision, because every decision was made in phase one.

• Confirm from the curve account that the completion condition is genuinely met and the curve is marked complete.
• Locate the migration transaction and open it in Solana Explorer. Do not infer migration from a chart appearing somewhere.
• Read the pool address, the program that created it, both deposit amounts and the fate of the LP position.
• Have the second person confirm the pool holds the exact mint, compared in full rather than by the first and last characters.
• Record all of it in the agreed place, then repoint venue-keyed tooling.
• Publish the prepared announcement, with the mint prominent and the pool where operational detail belongs.
• Say explicitly that third-party surfaces will catch up at different times, so that a stale chart does not become an incident.

Decisions that must be made in advance

Illustrative arithmetic on a delayed announcement

The communication plan

Three messages, all written in advance. The first, during phase two, explains what graduation is and what will happen: the token moves venue, the mint does not change, no holder action is required, and different sites will show different things for a while. This message does most of the work because it converts a confusing event into an expected one.

The second, at completion, states that migration has happened and is being verified. It is short, it is honest about the fact that verification takes a few minutes, and it repeats that the mint is the only address anybody needs. Saying you are verifying is not weakness; it is the sentence that keeps people from going looking elsewhere.

The third, once verified, is the announcement proper. Mint prominent. Pool address included where operational detail belongs, clearly labelled as the venue rather than the token. An explicit note that third-party surfaces will update at different times, so nobody reports a stale chart as a problem.

What none of these messages should contain is a prediction. The desk's position on this is unambiguous: a graduation is a change of venue and it entitles nobody to any claim about what happens next.

Auditing your own tooling for venue assumptions

Walk the list and ask one question of each item: does this take a mint or does it take a venue? Holder counts, supply monitors and transfer alerts take a mint and will not notice the migration at all. Price feeds, depth monitors, chart embeds and anything that executes trades take a venue and will stop.

The subtle cases are the ones configured by pair rather than by pool, or by a screener's internal identifier rather than by an on-chain account. These often look mint-keyed and behave venue-keyed, because the third party rebuilt its row when the venue changed. The way to find them is to check what the tool actually stores, not what its interface labels the field.

Anything that trades on a schedule needs the sharpest look, because it fails in the most expensive direction: it keeps trying, keeps paying fees, and lands nothing. A team maintaining activity through a launch should be asking whether their volume bot for Pump.fun launches is configured against the curve or against the mint, because those two answers behave identically right up until the moment they do not.

The same audit applies to anything scheduled to run across the seam. An automated Solana volume bot that resolves the current venue for a mint each cycle survives migration without intervention; one holding a stored pair address needs a human to notice and update it, and the whole point of preparation is to know which of those two you have before the day arrives.

What cannot be prepared

The pool address cannot be prepared, because it does not exist until the routine creates it. Anybody who tells you otherwise is describing a derivation that will break the first time a program version or a routing destination changes.

The timing cannot be prepared. Completion depends on other people trading, and no amount of watching makes the remaining distance close on a schedule. Plan for a window, not a moment, and make sure the plan survives the migration happening at an inconvenient hour.

Third-party indexing cannot be prepared. Every screener, wallet and charting site updates on its own schedule and none of them owe you promptness. The only available preparation is telling your audience in advance that this will happen, so the gap reads as expected rather than as a fault.

And the market cannot be prepared. Nothing on this list makes anybody want the token. A well-run handover removes avoidable confusion and avoidable losses. It is operations, not demand, and a team that expects the checklist to do more than it can will be disappointed by a checklist that worked perfectly.

It is worth being explicit about that last point, because the failure it describes is a common one. Teams that execute a clean handover sometimes read the absence of a market response as evidence that the preparation was pointless. The two are unrelated. Preparation is insurance against a specific set of avoidable losses, and insurance that never pays out has still done its job. The alternative reading, that a smooth transition should produce interest, imports a causal claim that no part of this mechanism supports.

Scaling the checklist down

Not every launch has a team. A single person running a token through a graduation cannot staff a verifier and a confirmer, and pretending otherwise produces a plan nobody follows. The reduced version keeps three items and drops everything else.

Keep the tooling inventory, because it is the item that fails silently and silence is what a single operator is least likely to notice. Keep the drafted announcement with a blank for the address, because composing text at speed is where a wrong address enters circulation. And keep the rule that only the mint is published, because it is a policy rather than a task and it costs nothing to hold.

Everything else on the full list is a coordination device, and coordination between one person and themselves is not a real problem. What remains is the part that protects against errors rather than against confusion, and those are the errors that cost money.

The handover runbook

Short enough to be followed by somebody who is stressed, which is the only test that matters.

1. Locate. Confirm the curve is marked complete and find the migration transaction. Not a chart, not a screener row, the transaction.
2. Verify. Read the pool address, the owning program, both deposits and the fate of the LP position. Second person confirms the mint matches in full.
3. Record. Write the signature, pool address, program and deposits into the agreed place.
4. Repoint. Update every venue-keyed tool from the inventory. Confirm each one is receiving data again rather than assuming it.
5. Publish. Send the prepared announcement, mint prominent, pool labelled as venue, expectations set about third-party lag.
6. Watch. Take depth readings at intervals, because nobody stores depth history and you will want it later.

Six steps and no decisions. That is the point of the preceding checklist: by the time the runbook runs, everything it needed has already been agreed, and the only remaining work is reading the chain accurately.

Questions the desk is sent