Choosing a Solana launch venue: a decision framework

Choose a launch venue by deriving weights from the launch goal and applying them to the eleven properties in the ledger, after removing any venue that fails a hard constraint. The framework produces a ranking under your weighting, which is the only kind of ranking worth having. It takes an afternoon and its main output is a decision you can explain later.

Start from the goal, not the venue

Almost every unproductive venue debate is a goal debate in disguise. Two people arguing about fee models are usually disagreeing about whether the launch is a distribution exercise or a fundraising exercise, and they will not resolve the fee question until they notice.

The goal has to be specific enough to eliminate options. "We want it to do well" eliminates nothing. "We want two thousand people holding a small position each, drawn from a community we already have, with the token integrated into our product within a quarter" eliminates most venues immediately, because it prioritises distribution and the token account model over price travel and surface reach.

Write the sentence first. A team that cannot write it is not ready to pick a venue, and picking one anyway means the venue's defaults become the plan by omission.

Four goals and what each implies

Most launches fall into one of four shapes, and each shape has a different decisive property. Recognising which one you are running answers more of the venue question than any comparison table.

The fourth column is the one worth reading twice. Teams routinely spend their attention on a property that is genuinely irrelevant to their goal, usually because it is the property the venue's own marketing emphasises.

Hard constraints end the discussion early

Some requirements are binary. A venue either satisfies them or it does not, and no amount of strength elsewhere compensates. Applying these first saves most of the work.

• Token account model. If a custody provider, exchange or bridge you need requires a specific token program, authority state or metadata standard, venues that produce anything else are out. The relevant conventions are documented at the Solana program library, and the requirement should be confirmed with the counterparty rather than assumed.
• Provable liquidity commitment. If somebody downstream needs liquidity that demonstrably cannot be withdrawn, only venues whose migration burns or verifiably locks the provider position qualify.
• Identity requirements. Identity-gated venues exclude anonymous launches by construction, and some teams have the opposite constraint for their own reasons.
• Extension compatibility. If the token needs transfer hooks, transfer fees or other extensions, most launch venues will not produce it and this ends the conversation quickly.
• Operational coverage. If a tool your operation depends on does not support the venue's programs, that is a constraint even though it feels like a preference.

Anything that survives all of these goes into the weighted comparison. Anything that does not is not a lower-scoring option; it is not an option, and treating a failed constraint as a low score is the most common way teams talk themselves into a venue that cannot work.

Turning properties into weights

The method is deliberately crude, because crude and written down beats sophisticated and implicit. Take a fixed budget - one hundred points is convenient - and distribute it across the eleven properties according to the goal. The budget being fixed is the entire discipline: raising one property must lower another, which forces the trade-offs into the open.

A distribution-focused launch might put forty points across curve shape and constants, twenty on the graduation unit, fifteen on the discovery surface and the rest spread thinly. A product-focused launch might put fifty on the token account model alone and treat curve properties as nearly irrelevant, which is a perfectly coherent position that would look bizarre to the first team.

The eleven properties are not equally weighty in practice, and the budget makes that visible. Most goals concentrate sixty or seventy points on three or four properties and spread the remainder thinly across the rest, which is the correct shape: a weighting that distributes evenly across eleven properties is a weighting that has not made a decision. If your budget comes out flat, the goal sentence is not specific enough yet and the honest move is to go back and sharpen it rather than to proceed with a comparison that cannot discriminate.

Two rules keep it honest. No property gets zero without somebody saying out loud why it does not matter here. And the weights are written before any venue is scored, because weights assigned after the fact are simply a justification of a decision already made.

A worked weighting across three archetypes

Building a shortlist in an afternoon

1. Write the goal sentence and get everyone who has an opinion to agree to it in that form. Most of the afternoon's disagreements will surface here, which is where they belong.
2. List the hard constraints and confirm the ones that depend on third parties by asking them, not by inferring from documentation.
3. Apply the constraints to the venue list and write down which venues were removed and why. The record matters when somebody asks later.
4. Assign the weight budget across the eleven properties, before looking at any venue in detail.
5. Read each surviving venue against the properties using its own documentation plus one completed launch opened in a block explorer, because behaviour and documentation sometimes disagree.
6. Score, multiply and read the result, then sanity-check it. If the output disagrees with a strong instinct, investigate the disagreement rather than overriding either side.
7. Write the one-page decision covering what was chosen, what was given up, and what would change the answer.

Operational readiness as a property

The eleven properties describe the venue. A twelfth question describes you, and it is frequently the one that decides whether a launch runs smoothly: can your operation actually work with this venue, before and after graduation?

That question has concrete parts. Does your monitoring understand the venue's curve account layout? Does your alerting subscribe to the right program? Will anything you run against the curve keep running after the token moves to a pool, or does it need re-pointing at a program it has never spoken to? The mechanics of that boundary are set out in the note on graduation rules compared.

The same applies to anything that produces market activity as part of a visibility budget. Coverage varies by venue family and by destination program, so a team planning to run a professional Solana volume bot across a graduation needs to confirm the tool speaks both the launch program and the destination program before the venue is chosen, not after. This is a five-minute check that regularly gets made on launch day, which is the worst possible time.

Questions to answer in writing

• Who should be holding this token in a month, and how many of them are there?
• How much of the supply should be distributed before a pool exists, and why that much?
• What integrates with this token later, and what does that integration require of it?
• Does anybody downstream need provable liquidity commitment, and have they said so in writing?
• Which discovery surface is this launch actually targeting, and what would it take to appear on it?
• Does a continuing creator fee help or hurt the story we intend to tell?
• What would we do if the venue changed its threshold, its fee or its destination next month?

Seven questions, answerable in an hour, and they eliminate more venues than any comparison table. Teams that skip them tend to arrive at a venue by inertia and then discover the constraints one at a time, in the least convenient order.

The debates that waste a week

Some venue arguments are genuinely unresolvable and consume enormous effort anyway. Which venue has better vibes is the honest form of most of them. Which venue has more successful launches is the same argument dressed as evidence, and it is survivorship bias with a chart attached: the venue with the most launches will have the most successful ones and also the most failures, and neither ratio tells you anything about your launch.

Which venue is cheaper is resolvable but only conditionally, because the answer depends on trade count nobody can predict, as set out in the note on fee models across launchpads. Arguing it to a conclusion means arguing about an assumption, and the assumption is where the disagreement actually lives.

Whether a venue is about to lose relevance is unanswerable, is argued constantly, and would only matter if a launch depended on the venue existing in a year, which almost none do. The token outlives the venue by construction: the mint is independent of the program that created it, and the standard account model that makes this true is described in the Solana documentation.

Recording the decision

One page, written the day it is made. What was chosen. Which venues were eliminated by hard constraints and which constraint eliminated each. What the weight budget was and why. What was given up by choosing this venue over the runner-up. And what specific change would make the answer different.

The value of that page is not that it improves the decision, because it does not. It is that six weeks later, when the launch is being reviewed by people who were not in the room, there is a document explaining the reasoning. Without it, the retrospective is conducted entirely on outcome, and outcome is dominated by factors the venue decision never touched.

It also makes the next launch faster. Most of the page is reusable: the constraints rarely change, the goal changes in known ways, and the weighting can be edited rather than rebuilt.

What the framework will not do

It will not tell you whether the launch will work. No venue property has any bearing on whether people want the token, and a framework that implied otherwise would be selling certainty it does not have.

It will not produce a clear answer every time. Two venues finishing close together is a legitimate output meaning the decision does not matter much, and the correct response is to pick one quickly and spend the saved time elsewhere.

It will not survive contact with a venue that changes its parameters. Every input is a setting somebody can revise, so the framework is a snapshot taken deliberately rather than a permanent answer. Rerunning it takes an afternoon, which is the whole reason it was designed to be crude.

Questions this desk is asked