The Week After Migration: Seven Days of Ordinary Work

The week after migration is ordinary operational work, not a second launch. On day one you verify that the pool exists, that the pair is the one you expect, and that every link you control points at it. Across the rest of the week you hold a reporting rhythm, answer the liquidity question in public, and accept that attention falls. None of that is a growth plan.

What changed at migration is mechanical and narrow. A bonding curve prices a token by a formula that only needed one side of the trade. A pool prices it from the ratio of two reserves that anybody can add to or take from. That single change rewrites how price moves, who supplies liquidity, where the chart is read, and what your links have to point at from now on.

VENUE

Trading now happens in a pool rather than against a curve formula.

PRICE

Derived from the ratio of the two reserves held in that pool.

LIQUIDITY

Supplied by position holders, and a position is itself a token.

VERIFIABLE

Pool address, mint address and liquidity actions are all on chain.

NOT CONTROLLED

Price, volume, routing prominence and whether interest persists.

Day one: verify the venue

Day one is a verification shift, not a communications shift. Before anyone writes a post, one person confirms that a pool exists for the mint address you actually launched, that it pairs your token against the asset you expected, and that the pool address they are looking at is recorded somewhere the whole team can read. Everything published later in the week depends on that record being right.

Read the mint address character by character against your own written copy. Do not read the first four characters and the last four and assume the middle. Addresses that share a visible prefix are trivial to produce, and the entire point of an impersonation is that it survives a casual glance. This check takes under a minute and it is the cheapest minute in the whole week.

• A pool exists for your mint address and you have the pool address written down.
• The pair is the asset you expected, not a second token with a similar symbol.
• Your chart source is reading that pool, not a stale curve page or a different pool.
• Every social profile link, pinned message and site link resolves to the new venue.
• The old curve page is no longer the destination anyone lands on from your channels.
• One named person owns the address record and any correction to it.

The link sweep is dull and people skip it, which is why it fails so often. Profiles carry links in several places at once: a bio field, a pinned post, a link-in-bio page, a footer, an old announcement that still ranks. Migration does not update any of them. Walk the list yourself from a logged-out browser, because a logged-in view can hide a redirect that strangers will hit.

Where the price comes from now

A constant product pool holds two reserves and prices the token from their ratio. If the pool holds more SOL against fewer tokens, each token is worth more SOL. A buy takes tokens out and puts SOL in, which moves the ratio in one direction. A sell does the reverse. There is no separate price feed and no operator setting a level.

The practical consequence is that price impact scales with order size relative to the size of the pool. A small trade barely disturbs the ratio and executes close to the quoted price. A large trade consumes a meaningful share of one reserve and pays a visibly worse average price as it goes. Thin pools make ordinary orders look violent, which is a liquidity fact rather than a market judgement.

An illustrative pool calculation

The arithmetic is worth doing once by hand so the shape of it stays with you. The figures below are illustrative and chosen for clean numbers. They are not a measurement of your pool, of any real pool, or of any particular venue, and they ignore swap fees so the reserve mechanics are visible on their own.

As an illustration, suppose a pool holds 80 SOL and 20,000,000 tokens. The product of the reserves is 1,600,000,000, and a constant product pool keeps that product unchanged across a trade. The starting price is 80 divided by 20,000,000, which is 0.000004 SOL per token. That is the marginal price, the price for an order small enough not to move the ratio.

Now suppose a buyer sends 8 SOL, a tenth of the pooled SOL. The SOL reserve becomes 88. To keep the product at 1,600,000,000 the token reserve must fall to 18,181,818, so the buyer receives about 1,818,182 tokens. Dividing 8 SOL by those tokens gives an average paid price near 0.0000044 SOL, roughly ten per cent above the starting price.

After that trade the pool holds 88 SOL against 18,181,818 tokens, so the marginal price is now about 0.00000484 SOL, roughly twenty-one per cent above where it began. One order of a tenth of the pool moved the quoted price by about a fifth. Nothing about that is a signal of interest. It is a division being performed on two numbers.

Compare a buyer sending 0.8 SOL instead. The SOL reserve becomes 80.8, the token reserve falls to about 19,801,980, and the buyer receives roughly 198,020 tokens at an average near 0.00000404 SOL, about one per cent above the start. Ten times the order size produced roughly ten times the price impact in this range, which is the intuition to carry.

The large row uses the same method: 40 SOL in takes the SOL reserve to 120, the token reserve to 13,333,333, and the buyer receives 6,666,667 tokens at an average of 0.000006 SOL. The quoted price ends near 0.000009, more than twice where it started. A single order sized at half the pool can produce a chart that looks like an event and is only arithmetic.

The liquidity questions you will be asked

Within a day or two somebody asks who provides the liquidity, whether it can be removed, and what happens if it is. These are reasonable questions with checkable answers, and a team that cannot answer them quickly reads as either unprepared or evasive. Decide the answers before migration, as part of preparing for the migration step, rather than drafting them under pressure.

A liquidity position in an AMM is represented by a token. Whoever holds that position token can withdraw the underlying reserves according to the pool rules. That is why locking or burning a position is a meaningful claim: it changes who can take the liquidity out. It is also why the claim must be shown rather than stated, because the transaction that did it is public.

Impermanent loss is the other term that arrives without explanation. In plain language: a liquidity provider ends up holding more of whichever asset fell and less of whichever rose, because arbitrage traders rebalance the pool as the outside price moves. Compared with simply holding both assets, the position can be worth less even while collecting fees. It becomes permanent when the position is withdrawn.

None of this makes providing liquidity wrong. It makes it a decision with a cost that should be understood by whoever takes it, and disclosed rather than presented as a favour to holders. If the team supplies liquidity, say so and say on what terms. If a third party does, say that instead, and do not imply a commitment you have no power to enforce.

Routing, aggregators and the pair being found

After migration your pair has to be discovered by the infrastructure most people trade through. Aggregators index pools and route orders across them; front ends and wallets often quote from an aggregator rather than a single venue. Discovery is usually automatic and not instant, and the mechanics of how routes are built are documented in Solana aggregator documentation rather than decided by you.

This is where an entire tooling category presents itself. Once a token trades in pools rather than on a curve, products that operate across pool venues become applicable, and a Raydium volume bot is the type example: software that submits trades against a pool on a schedule. What such a product records is transactions it paid for. Recorded activity is not demand, and presenting manufactured activity as organic interest is a misrepresentation that a reader can unpick from the chain.

The reason that distinction matters more after migration than before is that pool trades are legible. Every swap has a signer, a size, a time and a counterpart pool. Repetition in size and interval is visible to anyone who exports the transaction list. A team that expects nobody to check is making a bet against a public database that never closes and never forgets.

The reporting rhythm for week one

Attention falls after every launch, and it falls fastest in the first three days. A rhythm is the defence: a short, dull, predictable status that goes out whether or not the numbers are good. Readers calibrate on consistency. A team that publishes every day at the same time earns more trust with plain updates than a team that appears only when there is something to celebrate.

Split what you publish into three buckets and hold the line on the third. Daily items are short and factual. Once-only items are structural: the pool address, the liquidity position and its status, the holder picture. Never-published items are the ones that require inventing something, and the fastest way to lose the week is to reach into that bucket on a slow Wednesday.

The holder picture deserves particular care in week one, because migration does not change concentration. Whatever the distribution looked like at the end of the curve is roughly what you carry into the pool. Reading it honestly is a skill covered in the piece on first buyers and distribution, and week one is when the reading becomes public rather than internal.

Quiet is not the same as finished

Most teams misread the third day. Volume falls, the channel slows, and someone proposes an intervention. The useful question is whether the token is quiet or finished, and those have different evidence. Quiet means activity has fallen while the structural facts hold. Finished means the structure itself has gone: liquidity withdrawn, holders concentrated into exits, nobody asking anything at all.

That last row is the honest test. If every option on the table exists to make the token look busier rather than to build or fix something, the project is finished and the team has not said so yet. Writing that sentence down in advance, before you are tired and defensive, is the only reliable way to be able to read it later.

Whether to run any automation at all

Sooner or later in week one someone proposes buying activity, and the decision deserves a proper meeting rather than a message at midnight. Start by naming the goal out loud. If the goal is that a chart looks busier to strangers, the honest description of that is manufacturing an impression of demand, and it should be rejected on that basis alone rather than debated on price.

If the team still wants to evaluate the category, evaluate it the way you would any vendor. A professional Solana volume bot is an external commercial service, so ask what custody it requires, what it charges, what it actually reports, and whether its output is distinguishable on chain from ordinary trading. Recorded activity is not demand, and presenting purchased transactions as organic interest is a misrepresentation regardless of how the product is marketed.

There is a separate, legitimate reason teams look at tooling in week one, which is measurement rather than production. Knowing what your pool actually did, order by order, is useful. That need is met by an explorer and an export, not by a service that trades. Keep the two motives apart in the discussion, because they get blended precisely when someone wants the second one approved.

The seven-day plan, day by day

The plan below assigns each day one dominant task, one owner and one thing not to do. The owner column matters more than it looks: work that belongs to everybody gets done by nobody at the exact moment the week gets uncomfortable. Adapt the roles to your team size, but keep one name against each row rather than a function.

1. Assign the seven owner names before day one begins, not on the morning of each day.
2. Fix a single publishing time and keep it, including on days with nothing to report.
3. Record the pool address, mint address and liquidity status in one internal document.
4. Log every question you could not answer, with the date it was asked.
5. Write the day seven decision criteria on day one, while nobody is under pressure.
6. On day seven, publish the decision in the same channel as the daily status.
7. Keep the week's log; it is the raw material for avoiding the same errors next time.

Step seven is the one that pays forward. Almost every avoidable failure in a launch has already happened to the same team once before, undocumented. Keeping the log is how a week of ordinary work becomes something reusable, and it feeds directly into the review of the mistakes that repeat phase by phase when you plan the next one.

Week two is not covered here, deliberately. If day seven produces a decision to continue, the work becomes maintenance with a much slower cadence, and the material in the after graduation section covers what that maintenance consists of. If it produces a decision to stop, stopping well is a task in itself, and doing it in public with the record intact is the last honest thing the launch can offer.

Questions the desk is asked