Launchpad or manual mint: the same decisions, made differently
A launchpad does nothing the token program cannot do. It runs the same instructions in the same order with the parameters already chosen, then usually adds a pool and a fee arrangement on top. That convenience is real, and so is the fact that several permanent decisions are made before you have seen them. This note compares the two routes decision by decision, then shows how to read the result either way.
- Question
- What is actually different between launching a token through a launchpad and minting one yourself?
- Compared on
- The permanent decision list: token program, decimals, authorities, metadata mutability, initial distribution and liquidity structure.
- Permanent here
- Every decision a launchpad makes about decimals, program choice, extensions and authority revocation is as permanent as if you had made it.
- Not covered
- Ranking or recommending individual launchpads, predicting outcomes, or any technique for disguising how a token was set up.
- Confidence
- High on the mechanics of both routes. Descriptive on launchpad behaviour, which is a product decision and changes without notice.
Steps on this page that cannot be undone
- A launchpad that revokes authorities on your behalf has performed a permanent action you cannot reverse afterwards.
- Decimals chosen by a launchpad default are as permanent as decimals you choose yourself.
- Liquidity provider tokens that are burnt as part of a launch flow are destroyed, and the underlying liquidity can never be withdrawn.
- The token program and extension set are fixed at creation on either route.
The difference in one paragraph
A launchpad runs the same token program instructions you would run yourself, with the parameters already filled in and a liquidity arrangement bolted on. Manual minting runs those instructions with parameters you choose, and leaves the liquidity arrangement to you. Nothing about the resulting token is technically different; what differs is who made the permanent decisions and whether you were shown them.
That framing is worth keeping because it removes the false question. The useful question is never which route is better. It is which decisions each route takes out of your hands, and whether you would have made them the same way.
What a launchpad actually runs
Underneath any launch interface is the same sequence described on the head note: allocate the mint, initialise it with decimals and authorities, create a token account, mint the supply, create the metadata account, then optionally revoke one or more authorities. Launchpads then add steps of their own, typically creating a pool or a curve position and deciding what happens to the liquidity provider tokens.
Because it is the same sequence, everything a launchpad produces is readable in the same way afterwards. There is no proprietary state and no hidden field. A mint created by a launch interface and a mint created by a script are indistinguishable in an explorer except through the transaction history that produced them.
The practical consequence is reassuring: you are never locked out of understanding your own token. Whatever an interface displayed at the time, the account fields are the record, and they can be read months later by anyone with the address.
The decisions it makes for you
A launch form usually asks for a name, a symbol, an image and sometimes a supply. Everything else is a default. Those defaults are the whole subject of this note, because several of them are permanent.
| Decision | Typically set by | Reversible | Consequence of a wrong default |
|---|---|---|---|
| Token program | The platform, usually the original SPL Token program | No | No extensions available later; migration means a new mint and a new address |
| Decimals | The platform, commonly six or nine | No | Granularity fixed forever; can also affect how wallets classify the token |
| Initial supply | You, or a platform default | Only while the mint authority exists | A wrong figure becomes permanent if authority revocation happens in the same flow |
| Mint authority | The platform, often revoked automatically | No, once revoked | No issuance is ever possible, including corrections |
| Freeze authority | The platform, usually left unset | No, in either direction | A regulated design that needs freezing cannot use the mint at all |
| Metadata mutability | The platform | One way only | Either no correction path, or an update authority you did not know existed |
| Liquidity provider tokens | The platform | Depends entirely on the arrangement | Liquidity that cannot be withdrawn, or liquidity that can be withdrawn by someone else |
Note the pattern in the reversible column. Almost everything a launchpad decides is either permanent or one-way, which is why reading the resulting state immediately after launch is a good habit even when nothing appears to have gone wrong. The state is the specification; the interface was only a form.
Bonding curve launchpads
A distinct category prices the token against a curve rather than seeding a conventional pool. Buyers trade against a program that holds the reserve, the price moves along a defined function as cumulative purchases grow, and on many such platforms the position migrates to a standard automated market maker once a threshold is met. Platforms in this category, including Pump.fun, made this the default shape of a small launch on Solana.
Two structural properties follow. There is no initial liquidity to provide, because the curve is the liquidity, which removes the largest single cost of a conventional launch. And the parameters are the platform's, not yours: the curve shape, the migration threshold and the fee split are product decisions you accept by using the platform.
The market around these launches is its own subject. Because a curve launch is cheap and instant, the number of new pairs is very large and visibility becomes the binding constraint, which is the reason a Pump.fun volume bot exists as a product category at all. That is a market-side observation rather than an endorsement, and it belongs on the other side of the boundary this workshop keeps.
What to establish before using any curve platform
Three questions settle most of it. What happens to the reserve at migration, and into which pool. Who ends up holding the liquidity provider tokens afterwards, if any exist. And what the fee arrangement is, expressed as a proportion of each trade rather than as a headline.
All three are answerable from the platform's own documentation and confirmable on chain afterwards. None of them is a judgement about the platform; they are the facts that determine what a holder is actually exposed to.
What minting by hand requires
Manual minting means composing the instructions yourself, through a command line tool, a script or a wallet that can build transactions. The token program is documented in full in the SPL Token documentation, and the metadata instructions in the Metaplex documentation, so nothing about the route is obscure.
What it demands is care rather than expertise. The failure modes are consistent: a raw amount that is out by a factor of a billion, a decimals value accepted from an example without thought, an authority revoked before the result was checked, and a metadata account created with a URI that was never fetched to confirm it resolves. Every one of those is caught by running the whole sequence on a development cluster first, which costs nothing.
The benefit is that no decision is made without you. You choose the token program, the extension set if any, the decimals, the exact raw supply, whether a freeze authority exists at all, when and whether authorities are revoked, and what happens to liquidity afterwards. For a token with any unusual requirement, that control is not a preference; it is the only route that can express the requirement.
There is a middle route that gets overlooked. Nothing prevents you from minting by hand and then using a platform only for the liquidity step, or from using a launch interface and immediately performing the remaining authority decisions yourself. The two routes are not exclusive because they are made of the same instructions, and splitting them lets you keep control of the decisions that are permanent while accepting help with the ones that are merely tedious.
A separate discipline applies either way: rehearse on a development cluster. A test run costs nothing, takes a few minutes, and surfaces the two errors that account for most launch damage, which are a raw amount that is out by orders of magnitude and an authority revoked before anyone read the resulting state. A rehearsal is also the only way to see what a launch interface will actually do, because the defaults it applies are usually visible only in the accounts it produces.
The comparison, line by line
Fast, and the whole sequence is one signed flow. The common mistakes are prevented by construction because you never touch the raw amounts.
Liquidity is handled for you, often including the arrangement that determines whether it can be withdrawn. This is the largest single convenience and the largest single thing to verify afterwards.
The defaults are chosen for the median launch. If your token is the median launch, they are probably reasonable. If it is not, they are silently wrong.
You inherit a fee model and a product roadmap you do not control.
Slower, and every parameter is yours, including the ones you did not think about. The common mistakes are all available to you.
Liquidity is a separate project: choosing a venue, seeding the pool, and deciding what happens to the provider tokens. Nothing is done on your behalf and nothing is hidden.
Every unusual requirement is expressible: a freeze authority for a regulated design, a Token-2022 extension set, an issuance schedule with the authority in a multisig.
No third-party fee, and no dependence on a platform continuing to exist.
What each route costs
Protocol costs are the same on both routes, because the same accounts are created. The mint deposit, the token account deposits and the base fee of 5,000 lamports per signature do not care which interface composed the transaction. Anything above that is a product charge or a market cost.
Illustrative comparison, invented figures describing no particular platform
Suppose both routes create one mint, one token account and one metadata account. The rent deposits are identical, and both pay the same base fee per signature. Call that shared floor the protocol cost.
Now suppose a launchpad charges a flat creation fee plus a proportion of each trade, and suppose a manual launch instead seeds a pool with an amount of SOL the team chooses. The launchpad cost is small at the start and continues for as long as the token trades. The manual cost is large at the start and does not recur.
Neither is cheaper in general; they have different shapes. The figures are deliberately unnamed because platform fees change, and any specific number written here would be wrong within months.
Which route suits which project
- A small community token with no unusual requirements. A launchpad is a reasonable default, provided you read the resulting authority state and the liquidity arrangement before announcing anything.
- A token that needs an ongoing issuance schedule. Manual, because a flow that revokes the mint authority automatically has destroyed the model before it started.
- A regulated or asset-backed design that may need to freeze accounts. Manual, because a freeze authority can only be set at initialisation and most launch flows leave it unset.
- A token that needs Token-2022 extensions. Manual, unless the platform explicitly supports the exact extension set, since extensions are fixed at creation.
- A test or an experiment. Either, and the choice does not matter, but say so in public before people treat it as a product.
- A token whose team cannot describe what a mint authority is. Neither, yet. The defaults will be accepted without understanding and the permanent decisions will be made by accident.
What neither route settles
Both routes end at the same place: a token exists and can be traded. Neither has said anything about how deep the pool is, which venues the pair appears on, whether an aggregator will index it, or what its turnover will look like on the screens people use to find new pairs.
That is a genuinely separate discipline with its own tooling and its own vocabulary. Liquidity may be spread across several automated market makers, routing decides which one a trade actually hits, and a multi-DEX Solana volume bot exists because turnover on one venue is not the same thing as turnover on a pair. None of that is decided by the fields in a mint account, and none of it is the subject of this workshop.
What does carry across is the reading habit. Whichever route produced the token, the way to establish what it is remains the same sequence of account checks, in the same order, from the mint address. That sequence is set out in full in the field guide.
What this note does not do
It does not rank launchpads or name a best one. Platform behaviour is a product decision that changes without notice, and a comparison written today would misdescribe several platforms within a quarter. What it does instead is give the decision list, so any platform can be evaluated against it at the time you use it.
It does not predict outcomes. Neither route makes a token succeed, and the workshop has no data connecting launch route to anything that happens afterwards. Any claim in that direction would be invented, and inventing one is the failure this site is built to avoid.
And it contains nothing about disguising how a token was set up. There is no section on presenting a launchpad default as a deliberate decision, on obscuring who holds liquidity provider tokens, or on making a launch history harder to read. Every field here is described so that a reader can check it against the chain, which is the only use this workshop supports.
Questions the workshop is asked
Does a launchpad token differ technically from a manual one?
Once it exists, no. Both are mints owned by a token program, with the same fields and the same behaviour. An explorer cannot tell you which route produced a token except by reading the creation transaction history. What differs is who chose the values in those fields and whether you saw the choice being made.
Is a launchpad cheaper than minting manually?
The protocol costs are identical, because the same accounts get created and the same rent deposits are paid. A launchpad adds its own fee, which is a product charge rather than a network one. Manual minting costs your own time and the risk of a mistake, which is a real cost even though it does not appear in a fee schedule.
Can I change what a launchpad set after launch?
Only the parts that were reversible to begin with. If it left the mint authority with you, you can revoke it later. If it revoked the authority during the launch, that is permanent. If it created metadata and kept the update authority, the ability to change the name may not be yours at all. Read the resulting account state rather than the marketing copy.
What is a bonding curve launch?
A launch where a program prices the token against a curve as people buy and sell, rather than starting from a conventional liquidity pool. The curve holds the reserve, the price rises with cumulative purchases, and on many such platforms the position migrates to a standard automated market maker once a threshold is reached.
Who holds the liquidity in a launchpad launch?
It depends entirely on the platform and is the single most important thing to establish. Some flows leave liquidity provider tokens with the creator, some burn them, and some hold them in a program-controlled account. Each arrangement has different consequences for whether liquidity can be withdrawn, and all of them are visible on chain.
Is manual minting difficult?
It is a short sequence of well-documented instructions, but it is unforgiving. The common failures are a wrong raw amount, a decimals value chosen without thought, and revoking an authority before checking the result. Testing the whole sequence on a development cluster first removes almost all of that risk at no cost.
Which route is safer for buyers?
Neither, inherently. Safety for a buyer comes from the resulting account state, which either route can produce well or badly. A manual mint with everything revoked and liquidity handled carefully is safer than a launchpad token with a live authority, and the reverse is equally possible. The state is what should be read, not the origin.
Filed on the Launchpads bench by The Forge Notes Desk. Field values, account sizes and instruction names are taken from the token programs and the metadata standard; any arithmetic in an example is labelled as illustrative and describes no particular token. The order this workshop checks a token in is set out in the field guide.