Graduation rules compared across Solana launchpads

A graduation rule is a condition the launch program tests before it will end the primary phase. Four types are in use on Solana: accumulated quote reserve, share of supply distributed, elapsed time, and a manual trigger held by an operator. The type matters more than the number, because the type decides what a token looks like at the moment it graduates.

What a graduation condition is

Mechanically it is a comparison. The launch program holds a curve account, the account holds state that changes with every trade, and somewhere in the program is a check that compares one field of that state against a threshold. When the comparison passes, the curve stops accepting trades and the migration path becomes available.

That is the whole of it. There is no judgement involved, no assessment of the token's quality, and no discretion unless the venue deliberately built discretion in. A token graduates because a number crossed another number, and the widespread habit of reading graduation as an endorsement is the most common misunderstanding this desk encounters.

The condition also has a second job that is easy to miss: it caps the primary phase. Without one, the curve would keep quoting prices forever and the token would never acquire an ordinary market. The threshold is therefore not only a bar to clear; it is the definition of when the launch product stops being the market.

The unit is the whole argument

Two venues can quote graduation thresholds that sound comparable and mean entirely different things, because the unit differs. A threshold denominated in accumulated quote asset triggers on money raised. A threshold denominated in share of supply distributed triggers on tokens sold. On a steep curve those two events happen at very different points.

Consider what each implies. Meeting a reserve target on a steep curve can happen while a large share of the supply is still held by the program, because the later tokens are expensive and a modest number of them raises a lot. Meeting a supply target on the same curve requires distributing all those expensive tokens, which takes far more capital. Same curve, same venue, radically different launch depending on which unit the threshold uses.

This is why cross-venue threshold comparisons are close to meaningless unless the curve is specified alongside. A team that hears one venue's threshold is lower than another's has learned nothing until it knows what the two are measuring and what functions sit behind them, a point developed further in the note on how launchpad curves differ.

The four condition types

Hybrids exist. A venue can require a reserve target within a time window, or a supply target with a manual override, and each combination inherits the weaknesses of both parts. The useful question when reading a new venue is not which type it uses but what it does when the condition is nearly met and stalls.

What the last stretch feels like

Under a reserve target the gap is visible and shrinking, which produces a race. Everyone watching can compute how much quote asset is still required, and the last portion tends to be filled quickly by participants who want to be positioned before the venue changes. That is a mechanical consequence of publishing a countdown, not a claim about anyone's intentions.

Under a supply target the final stretch does the opposite. The remaining tokens are the most expensive ones on the curve, so each additional unit of quote asset moves the completion measure less than the one before it. Launches under supply targets often appear to stall near the end when nothing has changed except the arithmetic.

Under a time window, activity clusters at the close for the same reason activity clusters before any deadline. Under a manual trigger there is no observable pattern at all, which is precisely the complaint most often made about the design and the reason it is rare on permissionless venues.

One threshold, two curves

The boundary trade and partial fills

The transaction that satisfies the condition is an ordinary transaction. It lands in a slot, it changes the curve state, and from that point the curve stops accepting trades. Everything submitted moments before it, and evaluated after it, fails.

Venues handle the boundary trade differently and the difference is worth knowing. Some fill the portion of the order that fits within the remaining curve capacity and refund the rest, which means the final buyer receives less than they asked for and a partial refund they may not have expected. Others reject any order that would exceed the threshold, which means the final buyer receives nothing and pays only the network fee.

There is a second-order effect worth naming. Where a venue rejects overshooting orders, the final gap can only be closed by an order sized to fit it, which means the last participants are competing to compute the remaining capacity accurately rather than to bid the most. Where a venue partially fills, size is an advantage again because a large order captures whatever is left. Two implementations of the same idea, two entirely different final minutes, and neither venue describes it as a design choice.

Neither behaviour is a fault and both surprise people. If a launch matters enough to be watching the boundary, it matters enough to have read which of the two the venue does, because the difference determines whether a large final order gets a strange fill or no fill at all.

Condition met, migration not run

A condition being satisfied and the migration routine having executed are two separate events, and on several venues they are two separate transactions. Between them the token is in a state that catches out almost everything: the curve will not trade, and the pool does not exist yet.

The gap is usually short and is not always short. Migration may be executed by a keeper process, and keeper processes queue, fail and retry like anything else. A congested network lengthens the gap. A failed attempt lengthens it further. During that window every interface will show something, and what each one shows depends on which state it happened to read.

Anything that measures or produces activity is affected here, because the venue it was configured against has stopped and its successor has not started. Teams running a SOL volume bot through a graduation should expect this window to exist, plan for the tooling to be re-pointed rather than to continue automatically, and treat a silent period as the expected outcome rather than as a defect.

Manual triggers and time windows

A manual trigger is a privileged instruction that some account can call to end the primary phase. It exists on venues where the launch is curated, attached to an identity, or part of a structured raise rather than a permissionless free-for-all. Its honest description is that graduation timing is a decision somebody makes.

That is not automatically bad. A curated venue that ends a phase deliberately can coordinate the destination pool, the announcement and the liquidity treatment in a way an automatic trigger cannot. It does mean a participant is relying on the holder of that authority, and the authority is visible on chain if anyone bothers to look for it.

Time windows have the opposite property: entirely predictable, entirely indifferent to outcome. A window can expire with a curve that raised almost nothing, and the venue then has to decide what happens - migrate anyway with minimal depth, refund, or leave the token stranded. That decision is a venue policy, it is rarely prominent in the documentation, and it is worth finding before it applies to you.

Watching a condition approach

1. Find the curve account for the token by opening a recent primary trade in a block explorer and identifying the account whose state the instruction modified.
2. Identify the field the condition reads. Usually the accumulated quote reserve or a distributed-supply counter, alongside a boolean completion flag.
3. Read the account directly rather than through a third-party progress bar, which is a cached derivative and can be several slots stale during a fast finish.
4. Compute the remaining gap yourself and check your computation against the venue's own display once, to confirm you are reading the right field.
5. Watch for the completion flag rather than for the number, because the flag is what the migration path actually tests, as described in the account model conventions at the Solana program library documentation.
6. When the flag flips, look for the migration transaction in Solana Explorer and record the destination pool address the moment it exists.
7. Re-point anything that was configured against the curve before assuming it is still working, because it is not going to tell you that it stopped.

What graduation is not

• Not an endorsement. It is a threshold comparison with no assessment of anything.
• Not a guarantee of liquidity. What reaches the pool depends on the migration deduction, not on the threshold.
• Not a change of token. The mint is unchanged and every balance recorded against it survives untouched.
• Not instantaneous. Condition satisfied and pool created can be separate transactions minutes apart.
• Not comparable across venues without the curve, because the unit and the function together define the event.
• Not a reason to expect anything about price, which is set afterwards by an entirely different equation.

All of this is a setting

Every threshold described here is a value held by whoever operates the venue. Several venues have revised theirs, and at least one widely used venue has revised both its threshold and its destination since it began operating; its current material is published at its own site and is the only authority on what it does today.

The practical consequence is a habit rather than a fact. When a threshold matters to a decision, read it from the venue on the day, then confirm the venue behaves as documented by opening a recent graduation and checking what actually happened. Documentation describes intent; the transaction describes behaviour, and only one of those two is binding.

The comparative consequence is that this ledger will not print a threshold. Not because the numbers are secret, but because a page that printed them would silently become a misleading document the first time somebody changed one, and that failure mode is worse than the mild inconvenience of sending you to the source.

Questions this desk is asked