Solana Launchpads Compared: A Property By Property Read

Solana launch venues differ on eleven properties: curve shape, curve constants, primary trading fee, creation cost, migration cost, creator revenue share, graduation condition, liquidity destination, provider position handling, discovery surface and token account model. Four of those are the mechanical decisions; the rest are consequences of them. Everything else about a launchpad is interface and audience.

What a launchpad is, mechanically

A launchpad is a program that creates a token, sells it against a pricing rule the program holds, collects fees while doing so, and then hands the accumulated proceeds to a market venue when a condition is satisfied. Everything a launch team experiences as branding, community and momentum sits on top of that skeleton without changing it.

The skeleton matters because it is what determines behaviour. Two venues with entirely different interfaces will produce indistinguishable launches if they made the same four decisions, and two venues that look like siblings will behave nothing alike if their curve constants differ. Comparing the interfaces tells you almost nothing about the second case, which is the case that costs money.

The pricing rule is worth being precise about, because it is the part most often described loosely. During the primary phase there is no counterparty. A buyer is not matched against a seller; they are transacting with a program that quotes a price derived from how much of the supply has already been distributed. That is why the primary phase has no order book, no spread in the usual sense, and no possibility of the market failing to fill an order at some price.

The eleven properties in one table

The table below is the working index of this ledger. It records what each property controls and the specific way a launch suffers when the property was misjudged. It records no values, because every value in this list is a setting the operator can change.

Eleven properties on which Solana launch venues differ, with the practical consequence of getting each one wrong.
Property	Type	What it controls	Failure mode
Curve shape	Mechanical	How the quoted price responds to cumulative buying	Distribution concentrated at the wrong end of the launch
Curve constants	Mechanical	Starting price and total travel across the primary phase	An entry price that reads as absurd to the intended audience
Primary trading fee	Cost	What each primary buy and sell costs the trader	An aggregate drain that is invisible per trade
Creation cost	Cost	The price of putting a token on the venue at all	Mostly shapes how much noise the venue carries
Migration cost	Cost	What is deducted or retained as the primary phase ends	A destination pool thinner than the reserve implied
Creator revenue share	Cost	Whether the creator earns from continuing trading	An incentive your holders will interpret, correctly or not
Graduation condition	Mechanical	The measure that declares the primary phase finished	A final stretch that behaves unlike the rest of the launch
Liquidity destination	Mechanical	Which pool and program receives the reserve	Depth and routing behaviour nobody planned for
Provider position	Consequence	Whether the migration position is burned, locked or held	A withdrawal risk that cannot be assessed by eye
Discovery surface	Consequence	What the venue promotes, in what order, on what signal	A launch nobody sees on a venue that would never show it
Token account model	Consequence	Token program, authorities, metadata and extensions	Integrations that decline the token months later

The curve and its constants

The pricing function is the first decision and the least visible one. Most venues use a constant product relationship between a token reserve and a quote reserve, where at least one of those reserves is virtual: a number the program treats as present for pricing purposes without anybody having deposited it. The virtual component is what stops the opening price from being effectively zero.

Other designs exist and are used. A linear curve raises the price by a fixed increment per unit sold, which produces a far more predictable path and a much less dramatic final stretch. A stepped schedule holds the price flat across tranches and jumps between them, which creates queues at the boundaries. Each shape produces a different distribution of holders from identical demand, and that distribution outlives the launch.

The constants matter as much as the shape. Two venues both using constant product against a virtual reserve can differ by an order of magnitude in where the price starts and how far it travels before the graduation condition triggers, purely because they chose different virtual reserve sizes. This is the single most common reason two venues that are described identically behave nothing alike, and it is set out in detail in the note on how launchpad curves differ.

The four places money moves

Cost is where comparisons go wrong most often, because venues advertise the component that flatters them and stay quiet about the rest. There are four venue-controlled costs and one that belongs to nobody's business model.

Primary trading fee. A percentage of each buy and sell during the curve phase. It compounds against the number of trades rather than against the amount raised, so a venue with lively churn extracts more from the same eventual reserve.
Creation cost. What it costs to bring a token into existence on the venue. Where this is near zero the venue carries an enormous volume of launches, which is a discovery problem rather than a cost problem.
Migration cost. A deduction or retention applied as the primary phase ends. Whatever is taken here is depth the destination pool never receives, which makes it the most consequential fee on the list.
Creator revenue share. A continuing routing of some fee component to whoever created the token. Mechanically small, narratively large, and read by every holder who bothers to look.
Network cost. Transaction fees, priority fees and the rent deposits for accounts a launch creates. These go to the network and its validators rather than to the venue, and no launchpad controls them.

Comparing two venues on the headline percentage alone is therefore close to meaningless. A venue with a lower primary fee and a larger migration retention can cost a launch more in total than one with the opposite arrangement, and which is cheaper depends on how much trading the curve phase actually sees.

The exit and where it lands

The graduation condition is a threshold expressed in some unit, and the unit is the interesting part. A condition denominated in accumulated quote asset triggers on money raised. A condition denominated in supply distributed triggers on tokens sold. On a steep curve these two are wildly different events: the reserve target can be met while most of the supply is still in the program, whereas a supply target on the same curve would require far more capital.

Some venues add a time dimension, either a window within which the condition must be met or a cooling period before migration executes. A few reserve a manual trigger. Each variant changes the texture of the final stretch, and the note on graduation rules compared works through what each one does to the last hour of a curve.

The destination is a separate decision from the condition. A venue may deposit into an automated market maker it operates itself, into a general-purpose one such as those documented by Raydium, or into a concentrated design where the same nominal deposit produces a very different depth profile. Whichever it is, the deposit produces a liquidity provider position, and what happens to that position - burned, locked, or simply held by an account - is the difference between a liquidity claim you can verify and one you have to believe.

The window and the token model

The discovery surface is the property teams underestimate most consistently. Every venue front page is a ranked list, the ranking is computed from a signal the venue chose, and a launch that ranks nowhere on that signal is functionally invisible on that venue no matter how good it is. Some surfaces order by recency, some by activity, some by a graduation-progress measure, and some by a curated selection.

This is where activity-producing tooling enters the picture honestly. If a surface orders by an activity measure, producing activity changes the position of a row on that surface. It does not change whether the person who sees the row decides the token is worth their time, which is the part no tool can supply. Teams that budget for a multi-DEX Solana volume bot as a distribution expense are buying placement on activity-ordered screens, and it is worth being clear with yourself that placement is the whole of what is being bought.

The token account model is the quiet one. Which token program the venue uses, whether mint and freeze authorities are revoked, which metadata standard is written, and whether token extensions such as transfer hooks are permitted all constrain what can integrate with the token afterwards. Exchanges, custodians, bridges and staking products each have their own tolerances, and discovering an incompatibility after launch is the most expensive possible ordering.

The venue families in practice

Named venues are useful as landmarks provided nothing is asserted about them that is not in their own documentation. Pump.fun is the widely known general-purpose curve venue and publishes its own material at its site; the mechanics of its curve phase and its migration have been revised more than once, which is itself the most instructive fact about it.

LetsBonk, usually written Bonk.fun, is the ecosystem-aligned example: the same broad shape, associated with an existing community, with fee routing that community members can inspect. Teams that plan a campaign there frequently ask about a Bonk.fun volume bot for exactly the reason described above, because that venue's surface is activity-ordered in the same way its peers are.

Moonshot and Believe are the identity-oriented examples, where a launch is attached to a verified account or a creator profile rather than to an anonymous key. daos.fun sits in a different category entirely: the token represents a share of a pooled treasury, which changes what the token is rather than merely how it was sold. Raydium's own launch tooling is the DEX-native case, where primary phase and destination share an ecosystem by design.

None of that is a ranking and none of it is a recommendation. It is a map of shapes, so that when a new venue appears you can place it in one of them within a few minutes of reading.

One demand curve, two venues

Illustrative arithmetic

Invented figures used only to show a mechanism. Two venues, identical constant product designs, identical graduation condition expressed as a quote reserve target of 80 units. Venue A opens with a virtual quote reserve of 30 units; venue B opens with 10.

Under constant product, the fraction of the token reserve a buyer receives depends on how much they add relative to the reserve already present. Venue A begins with three times the virtual depth, so the first 10 units of real buying move its price far less than the same 10 units move venue B. By the time each venue has accumulated 80 units of real quote asset, venue B has travelled through a much larger price multiple than venue A.

The consequence is distribution. Venue A hands out more tokens per unit of quote asset across the whole primary phase, so more of the supply is in more hands when the condition triggers. Venue B produces a steeper chart, a more dramatic screenshot, and a holder set concentrated among whoever arrived earliest.

Neither is better. They are different products, and a team that wanted broad distribution and picked venue B because the chart looked exciting got the opposite of what it asked for. The arithmetic is invented; the mechanism is not.

Reading a venue you have never used

New venues appear constantly and almost none of them will have been written about by anyone independent. The following sequence gets you to a working understanding in under an hour using only public material.

Find the program, not the website. Locate the on-chain program the venue uses and confirm it from a transaction rather than from a marketing page. Everything else you conclude rests on having the right program.
Read the pricing instruction. Identify what the buy instruction does to the reserves and which of them are virtual. This gives you the curve shape without needing the venue to describe it.
Find the fee accounts. Follow where fee lamports and tokens go on a completed primary trade. The recipients tell you the fee model more reliably than any published table.
Locate the graduation check. Find the condition the program tests before it will run migration, and note its unit. Reserve-denominated and supply-denominated conditions behave very differently.
Open a completed migration. Find a token that has already graduated on this venue and read the migration transaction end to end: which program created the pool, what was deposited, and what became of the provider position.
Check aggregator coverage. Request a quote for a graduated token through a router such as the one documented at Jupiter's developer docs and see whether the destination program is routed at all.
Read the front page as a ranking. Work out what signal orders the venue's own discovery surface, because that is what your launch will be competing on from its first minute.

Comparison mistakes worth avoiding

Comparing headline percentages without asking which of the four cost components each venue also applies.
Treating a graduation threshold as a difficulty level rather than as a unit of measurement attached to a curve.
Assuming the destination pool is fixed, when it is a parameter several venues have already changed.
Reading a steeper chart as stronger demand, when it may simply be a smaller virtual reserve.
Judging a venue by the best launch that happened on it, which selects for survivorship rather than for the venue.
Ignoring the token account model until an integration partner asks a question you cannot answer.
Believing a liquidity claim that has not been checked against the provider position on chain.

What this comparison cannot tell you

It cannot tell you whether a launch will work. Venue properties describe the machinery a token is launched into and nothing about whether anybody wants the token, and no property in the table above has any bearing on that question.

It cannot tell you what the numbers currently are. Every value behind these eleven properties is a setting held by whoever operates the venue, several have been changed without announcement, and a page that printed them would be a document that becomes wrong silently. Read the parameter here, read the value at the venue.

It cannot rank the venues, because ranking requires a weighting and the weighting belongs to the launch rather than to the ledger. What it can do is make sure the argument you have about venues is an argument about properties, which is an argument that can actually be settled.

Questions this desk is asked

Which Solana launchpad is the best one?

This desk does not answer that question, and any page that does is smuggling in a weighting it has not shown you. Best depends on who you want holding the token in hour one, how much of the supply you want distributed before a pool exists, whether a continuing creator fee helps or hurts your story, and what has to integrate with the token later. Answer those first and the venue list narrows itself.

Do all Solana launchpads use bonding curves?

No. The curve venue is the shape that became familiar, but launch products on Solana also include fixed-price sales, auction formats, fundraising vehicles where the token represents a pooled treasury, and identity-gated launches that attach a token to a verified account. The curve is a common answer to the pricing question, not the only one.

Are launchpad fees the same across venues?

They are not, and more importantly they are not even the same kind of thing. Some venues charge a percentage of each primary trade, some charge to create a token, some deduct or retain value at migration, and some route a continuing share to the token creator. Two venues quoting a similar headline percentage can produce very different totals depending on which of those they also apply.

Can a launchpad change its rules after I launch?

Yes. Fees, thresholds, curve constants and graduation destinations are parameters held by whoever operates the venue, and several venues have revised them. A token already launched normally continues under whatever the program does at the time it executes, which is why this desk names parameters rather than printing values and why a launch plan should not depend on a setting staying put.

Does the launchpad decide where my token trades afterwards?

It decides where the primary liquidity is deposited, which is not quite the same thing. The migration routine seeds one pool on one program. After that, pool creation on Solana is permissionless, so anybody can open a second pool for the same mint on a different venue, and aggregators will route across whichever ones they index. The launchpad sets the starting point, not the map.

Is it worth launching on a smaller venue to stand out?

It is a real strategy with a real cost. A smaller venue has a shorter list to be visible on and usually a more forgiving discovery surface, so a launch that would vanish elsewhere can get attention. The cost is everything downstream: fewer integrations, slower indexing by screeners and aggregators, and a smaller pool of people who already have the venue open.

How do I verify what a launchpad claims about liquidity?

Open the migration transaction and read it rather than reading a screenshot of it. The transaction shows which program created the destination pool, what was deposited into it, and what happened to the liquidity provider position the deposit produced. Burned, locked and simply held are three different outcomes with three different risk profiles, and the chain distinguishes them without needing anyone to be trusted.