The Pump.fun launch timeline

A launch on a bonding-curve platform moves through four stages defined by program state: the mint exists, the curve takes its first trades, the reserve fills toward the migration threshold, and the position is handed to an external venue. Every transition is a discrete on-chain event with its own failure modes, and each one changes what the numbers on a token page are capable of telling you.

The stages below are not a narrative arc. They are readable from account state at any moment, by anyone, without asking the team anything. That is the useful part, and it is what this note works through: what exists on chain in each stage, what you can observe, what commonly breaks, and what is worth watching while it runs.

Stage boundaries are program state

It is worth being blunt about this because a great deal of launch commentary is not. A stage boundary here is a change in the contents of an account, not a phase somebody declares in a chat. The curve either holds tradeable supply or it does not. The reserve is either below the migration threshold or it is not. Both facts are public and exact.

This has a practical consequence: you never have to take a claim about launch status on trust. If a team says a token is about to graduate, the reserve balance either supports that or it does not. If a team says liquidity has been handed over, either a migration transaction exists or nothing has happened. The verification is a lookup, not a judgement call.

It also means transitions are atomic. There is no gradual handover between the curve and an external pool; the state changes inside a single transaction and everything downstream changes with it. Charts, depth, routing and often the market identity a tracker uses are different on either side of that one signature.

Stage one: mint and metadata

What exists on chain after stage one is smaller than most people assume. There is a mint account with a fixed supply and a decimals setting. There is a metadata account holding a name, a symbol and a URI. And there is a curve account, initialised with pricing parameters, holding the supply that will be sold. That is the whole token at this point.

The metadata URI is the part worth pausing on. It does not contain the image or the social links. It points at a document somewhere else that contains them. Whatever that document says at the moment you look is what the interface will display, and the durability of the token page therefore depends on infrastructure the chain knows nothing about.

What is observable in stage one: the creation signature and its timestamp, the wallet that signed it, the funding history of that wallet, whether the URI resolves at all, and whether an initial buy landed in the same transaction or the same block. All of this is readable in a block explorer such as Solscan within seconds of the mint.

What breaks here: an unpinned image that disappears in a week, a metadata document hosted on a domain that lapses, a symbol that collides with an existing token so that search returns the wrong thing, and social handles that are strings written once at mint and never connected to a real account. None of these are visible from the price chart.

What to watch: whether the signing wallet has minted before and what happened to those mints, whether the initial buy is proportionate or takes a large share of supply in the first instruction, and whether the metadata is mutable. A mutable metadata pointer means the name, symbol and image can be changed after people have bought.

Stage two: first buys and price discovery

Stage two begins with the first swap instruction executed against the curve. On chain this produces three things: reserve growth, token accounts for new holders, and a transaction history. Price discovery in the ordinary sense is not really what is happening. The price is a function of issuance, so what is being discovered is how much buying arrives, not what the market thinks anything is worth.

The first minutes are structurally the most volatile part of a launch, and the reason is arithmetic rather than sentiment. The curve is shallow at low issuance, so each unit of SOL entering the reserve is a large proportional change. A purchase that would barely register later can multiply the quote at the start. That is a property of the pricing function, not evidence of demand.

What is observable: the ordered list of the first transactions, the set of distinct signers, the size distribution of those buys, the intervals between them, and the share of supply taken by the largest single buyer. The funding path of the early wallets is also visible, and it is often the most informative single thing on the page.

What breaks here: a single wallet or a coordinated group absorbing a large share of supply in the first block and then distributing into later buyers, a first few minutes with no buys at all, so the token never enters anybody's list of active launches, and rapid entry and exit that produces a large volume figure with almost no net reserve growth.

What to watch: distinct signers over the first five minutes rather than transaction count, top-holder concentration excluding the curve account itself, and net reserve change measured against gross volume. Those three together separate a launch that gathered participants from one that recycled the same balance through the same formula repeatedly.

Stage three: filling the curve

Stage three is the long middle. Nothing structural changes; the curve keeps quoting, the reserve keeps moving, and the only meaningful state variable is how close the reserve has come to the migration threshold. Interfaces usually express this as a progress percentage, which is a presentation of reserve relative to threshold and nothing more.

The single most misread property of this stage is that progress is not a ratchet. Selling returns tokens to the curve and withdraws reserve, so the progress figure moves backwards as readily as forwards. A token showing eighty per cent can show sixty per cent an hour later without anything unusual having happened. It is a live measurement of a balance, not a completed fraction of a task.

What is observable: the reserve balance and therefore the progress figure, the rate at which it is changing, the buy and sell composition of the flow producing that change, and holder count over time. Comparing the last two is the highest-value read available in this stage, because volume and net inflow can point in opposite directions.

What breaks here: a stall in the middle of the range, where activity continues but net inflow goes to zero; sell pressure from stage-two buyers taking profit into every new buyer; and attention decay, where the token simply stops appearing on the activity-ranked surfaces that were bringing new participants to it. The note on why launches stall works through the repeatable patterns and the responses to each.

Attention decay is also the point at which teams start pricing a volume bot for Pump.fun launches, because a console that schedules swaps across a funded wallet set keeps the transaction list moving while the reserve is flat. Be clear about which variable that buys: it changes what the activity fields display in stage three and it does not change net inflow, which is the only thing the threshold measures.

What to watch: net reserve change per hour rather than volume per hour, whether progress is monotonic over a session, and whether holder count is growing while progress grows. Progress advancing on a flat holder count means existing participants are adding to positions they already hold, which is a considerably narrower base than the progress figure makes it look.

Stage four: migration and handover

When the reserve reaches the threshold, the curve stops accepting swaps and the accumulated reserve, together with the portion of supply withheld for exactly this purpose, is deployed as a liquidity position on an external automated market maker. A new market account exists afterwards that did not exist before. The specifics of the handover differ by protocol version and are worth reading rather than assuming.

What is observable: the migration transaction itself, the address of the new pool, the initial depth of that pool, and the first trades executed against it. The migration signature is the authoritative record of where liquidity went. Any pool address obtained from any other source is a claim that should be checked against it.

What breaks here: readers expecting price continuity across the boundary, when the new venue prices from reserve ratios rather than from the curve function; depth that is thinner than the pre-migration notional implied, which surprises people who read market cap as if it were exit capacity; and trackers that split history across two market records, so displayed volume drops for accounting reasons rather than real ones.

What to watch: take the pool address from the migration transaction, model a sell of your intended size against the new pool to find real depth, and read the first hour of pool activity for composition rather than headline volume. The mechanics of the threshold and the moment itself are covered in detail in the note on the graduation threshold.

The stage table

The table condenses the four stages into the four questions worth asking about each of them. It is meant to be used while looking at a live token page, not read once.

A pre-launch preparation sequence

Most of what determines how stages two and three go is decided before the mint transaction is signed, because that is the last point at which several things are cheap to change. The sequence below is the order the lab would work in, and it deliberately front-loads the parts that become permanent.

1. Settle the identity before anything is written on chain

   Name, symbol and description go into a metadata account at mint. Search the symbol first to find collisions with existing tokens, because a collision costs you search visibility permanently and there is no clean fix afterwards.

2. Host the metadata document and image durably

   The chain stores a pointer, not a picture. Put the document and the image somewhere with durable addressing and confirm the URI resolves from a machine that has never loaded it, so you are not testing a cache.

3. Connect the social accounts that the metadata will claim

   Handles written at mint are strings. If the accounts they point at do not exist, or exist with no history, every careful reader in stage two will register that within a minute of opening the page.

4. Decide the initial buy and write down the reasoning

   The size of the first purchase is visible forever and is read as a signal about intent. Decide it in advance against the curve parameters rather than in the moment, and know what share of supply it represents.

5. Decide what the first hour is supposed to look like

   Not a target price. A target shape: roughly how many distinct participants would count as a real opening, and what you will conclude if the signer count stays in single figures while transaction count climbs.

6. Set up observation before you need it

   Have the explorer view, the token account and the reserve balance open and understood before the mint, not after. In stage two the useful window for reading the transaction list is measured in minutes.

7. Write the stall response in advance

   Decide now what you will do if progress flattens in the middle of stage three, because the decision is much worse when made under pressure by people watching a number that is no longer moving.

What to watch while it runs

These are the checks that survive across all four stages. Each one is a lookup rather than an opinion, and each is stated so that it produces a number you can compare against the same number an hour later.

One caution to carry through all of it. Thresholds, fee schedules and migration destinations on launchpads have been revised before and will be again. Nothing in the stage structure above depends on a specific value, but any specific value you carry away from any article should be re-checked against the protocol itself before you plan around it.

Questions readers ask

Check the stage mechanics against their sources: the Pump.fun protocol for current thresholds and migration behaviour, Solscan for reading mint, curve and migration transactions directly, and the Solana documentation for token and account semantics. Parameters change; the stage structure has been stable.