Solana launchpads compared
Eleven properties on which venues genuinely differ, each one explained in terms of what it does to a launch rather than which venue wins on it. Includes a method for reading a venue you have never used.
Open the matrixSolana launchpads, compared property by property
Every launch venue on Solana is the same four decisions wearing different clothes: what shape the pricing function takes, who pays what to whom, what condition ends the primary phase, and which pool the resulting liquidity is deposited into. Change any one of them and the launch behaves differently.
This ledger records those decisions venue by venue and refuses to turn them into a score. There is no best launchpad here, because best depends on what a launch is trying to do. There is a matrix of properties, an explanation of what each property controls, and a note beside every one of them saying that it is a setting rather than a law.
- Curve
- A pricing function held by a program. Its shape decides how steeply the quoted price rises as supply is distributed, and every venue picks a different one.
- Fees
- Trading fee, creation fee, migration fee and creator share. Different venues split them differently and route them to different recipients.
- Graduation
- The condition that ends the primary phase. It can be a reserve target, a supply target, a time window, or a manual trigger held by somebody.
- Destination
- Where the liquidity is put once the curve is finished. A native pool, a third-party AMM, or a concentrated design with very different depth behaviour.
What this ledger covers
Six axes account for nearly every difference a launching team will actually feel. The rest of the differences between venues are interface, branding and community, which matter but are not properties of the market itself.
Curve design
Constant product against a virtual reserve, a linear ramp, a stepped schedule or a quote-denominated target. The choice decides how much of the supply is distributed by the time the price has multiplied, and how violent the last stretch feels.
Axis 01Fee schedule
Who is charged, at which moment, and where the charge goes. Some venues take a percentage of every primary trade; some charge to create; some take a cut at migration; some route a share to the token creator on a continuing basis.
Axis 02Graduation condition
The rule that says the primary phase is finished. Quote-reserve targets behave differently from supply-distributed targets, and both behave differently from a venue where a human decides when a launch is done.
Axis 03Liquidity destination
Which pool the accumulated reserve is deposited into, on which program, with what treatment of the resulting provider position. This decides the depth a token wakes up with and who can withdraw it.
Axis 04Discovery surface
What the venue's own interface promotes, in what order, and on what signal. A launch that would be invisible on one surface is on the front page of another, and neither ordering is a measure of quality.
Axis 05Token and account model
Which token program is used, what authorities are retained or revoked, what metadata standard is written, and whether extensions such as transfer hooks are permitted. This constrains every integration afterwards.
Axis 06Featured ledger notes
Four notes that cover the ground most readers arrive looking for: the whole matrix in one place, the pricing functions underneath it, what the fee schedules actually add up to, and where a token ends up trading afterwards.
How launchpad curves differ
The same demand produces different price paths on different curve shapes. What the constants control, what they cannot control, and why two venues can look identical in a screenshot and behave nothing alike.
Read the pricing noteFee models across launchpads
Six distinct places money leaves during a launch, only three of which most teams count. Who receives each one, which are set by the venue, and which belong to the network rather than to anybody's business model.
Read the cost noteWhere liquidity ends up
The destination pool is a product decision. Native AMMs, general-purpose AMMs and concentrated designs give a graduated token completely different depth profiles, and the difference shows up in the first hour.
Read the destination noteThree sections, one method
Notes are filed by whether they describe a venue, a mechanism, or a decision. The mechanism section is the largest because mechanisms are what actually differ; venue profiles are mostly a way of pointing at which mechanism a venue chose.
Launchpads
Venue profiles. What each launchpad is as a product, who is standing in front of it, what its interface makes easy, and which of its properties are actually different rather than differently named.
Open this sectionMechanics
The four decisions every launchpad has to make: the shape of the pricing function, who pays what to whom, the condition that ends the primary phase, and where the resulting liquidity is put.
Open this sectionChoosing
Turning the property matrix into a decision. Which differences matter for a given launch, which are noise, and what genuinely changes if a team moves to a different venue next time.
Open this sectionThe eleven axes, in one table
This is the working index of the ledger. Every note on the site expands one or more of these rows. None of the rows carries a value, because every value is a setting the venue can change; what the table records is what the setting controls and what it costs you to get it wrong.
| Property | What it controls | What it costs to misjudge |
|---|---|---|
| Curve shape | How the quoted price responds to cumulative buying | A distribution profile nobody expected, concentrated at the wrong end |
| Curve constants | Where the price starts and how far it travels | An entry price that reads as absurd to the audience you wanted |
| Primary trading fee | What each buy and sell costs during the curve phase | A slow bleed that only becomes visible in aggregate |
| Creation cost | What it costs to put a token on the venue at all | Little, on its own; it shapes how much noise the venue carries |
| Migration cost | What is deducted or retained when the primary phase ends | Less depth in the destination pool than the reserve suggested |
| Creator revenue share | Whether and how the token creator earns from trading | An incentive structure your holders will read as a signal |
| Graduation condition | When the primary phase ends and on what measure | A last hour that behaves nothing like the rest of the launch |
| Liquidity destination | Which pool and program the reserve is deposited into | Depth and routing behaviour you did not plan for |
| Provider position handling | Whether the resulting position is burned, locked or held | A withdrawal risk that is either real or imagined, and you cannot tell which |
| Discovery surface | What the venue promotes and on which signal | A launch nobody sees, on a venue that was never going to show it |
| Token account model | Token program, authorities, metadata and extensions | Integrations that quietly refuse to support the token later |
Where activity tooling meets the venue question
Anything that watches or produces market activity is configured against a venue, not against a token. That is fine while a token stays where it started, and it becomes a problem the moment the venue question is answered differently: a different launchpad means a different program, a different pool layout and a different set of accounts to point at.
Teams that treat visibility on activity-ordered screens as a distribution expense therefore inherit the venue decision twice. Once when they pick where to launch, and again when the primary phase ends and the token starts trading somewhere else entirely. Tooling that only covers one venue family stops being useful at exactly the moment it was bought for.
This desk takes no position on whether producing activity is worthwhile. It only insists on describing the mechanism honestly: activity changes what an activity-ordered screen displays, and it does not change whether the person reading that screen decides the token deserves their attention.
What the venue decision reaches
- The program your alerting subscribes to, which is venue-specific and not portable.
- The pool layout your price reader parses, which differs between AMM designs.
- The fee you pay per swap, which is set by the venue and changes the arithmetic of any campaign.
- The screener rows your token can appear in, since not every surface indexes every venue equally quickly.
- The routing an aggregator builds, which depends on the destination program being one it supports.
- The accounts a team has to re-record after graduation, because none of them survive the move.
How this ledger is kept
Three working rules that decide what is published here and, much more often, what is left out.
Parameters, not values
Fees, thresholds, curve constants and destinations are settings. They have been changed before, sometimes quietly, and a page that prints one as a fact becomes wrong without ever announcing it. This ledger names the parameter, explains what it controls, and sends you to the venue for the current number.
No rankings, no scores
There is no league table here and there will not be one. Ranking venues requires a weighting, the weighting depends entirely on what a launch is trying to achieve, and publishing one weighting as though it were universal would be the least honest thing this desk could do.
Differences, stated as differences
Two venues that route fees differently are different, not better and worse. The ledger records what differs and what the difference does, then stops. Where a judgement is unavoidable it is written as a judgement and attributed to the desk rather than dressed up as a measurement.