Solana launchpads compared
The master comparison. Eleven properties that differ between Solana launch venues, why each one matters to a launching team, and how to read a venue you have never used from its documentation alone.
Launchpad profiles, venue by venue
A launchpad is a product before it is a market. It has an interface, an audience, a set of defaults and an opinion about what a launch should look like, and all of that is expressed through four mechanical decisions plus a shop window. These profiles describe venues on those terms.
No venue is ranked here and none is recommended. Where a fee, a threshold or a destination would normally be quoted, the parameter is named instead, because every one of those is a setting the operator can change and several of them have already been changed more than once.
- Read as
- A product with defaults, not a neutral pipe
- Sorted by
- Nothing; the ledger does not rank venues
- Values
- Named as parameters, never printed as constants
- Sources
- Public documentation and on-chain behaviour
The venue families you will actually meet
Solana launch venues cluster into a handful of shapes. Knowing which shape you are looking at answers most questions about a venue before you read a single line of its documentation.
General-purpose curve venues
Anyone can create a token in a few clicks, it trades immediately on a bonding curve, and it moves to an automated market maker when a condition is met. Pump.fun is the widely known example of this shape and several venues have implemented variations of it.
Family 01Ecosystem-aligned venues
The same mechanical shape, operated by or associated with an existing community, with fees or routing that flow back into that community. LetsBonk, commonly written as Bonk.fun, is associated with the BONK community in this way.
Family 02DEX-native launch surfaces
A launch product built by the same team that operates the destination exchange, so the primary phase and the eventual pool live in the same ecosystem. Raydium documents its own launch tooling alongside its pool programs.
Family 03Aggregator-hosted surfaces
Launch tooling attached to a routing or aggregation product, where the advantage claimed is distribution through an interface people already use for swapping rather than a different curve.
Family 04Identity and creator venues
Venues that attach a launch to a verified person, a social account or a creator profile. Moonshot and Believe are frequently cited examples of launch products built around an identity layer rather than around anonymity.
Family 05Fundraising and fund venues
Products where the token represents a pooled treasury or a fund rather than a standalone asset. daos.fun is the example usually named in this category, and its mechanics differ from a curve venue in ways that matter far beyond the launch.
Family 062 ledger notes in this section
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.
Discovery and audience
A launchpad is a market and a shop window. What each venue puts on its front page, how a token becomes visible on it, and why the same token gets a different first hour on different surfaces.
The venue is a wrapper around the mechanics
Every property that distinguishes one of these families from another is one of the four mechanical decisions in the mechanics section, or a consequence of the discovery surface. If you want to understand a venue you have never used, read its mechanics rather than its landing page.
Mechanics
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 section