The Pre-Launch Checklist: Sign-Off Before You Mint

What sign-off means on a launch sheet

A token launch checklist is a sign-off sheet rather than a to-do list. Each item has one owner, a deadline expressed relative to the mint, and a state that is either signed or not signed. Nothing is half done. The sheet exists because the mint transaction converts a set of reversible choices into permanent facts, all at once, without warning.

The distinction matters in practice. A to-do list tolerates ambiguity, and ambiguity is exactly what fails on launch day. Sign-off forces a person to look at a thing and say that it is finished. If nobody will say that, the item is not finished, and the honest response is to move the mint rather than to hope the gap does not matter.

The sheet is grouped by owner rather than by topic for the same reason. Topic grouping hides the coverage problem: two people each assume the other checked the wallet, because wallets appear under an infrastructure heading that belongs to nobody. Owner grouping surfaces it immediately, including on a solo launch where one name appears against every line.

Seven groups cover a launch: identity and metadata, wallets and key policy, communications and channels, budget and treasury, monitoring and tooling, the human schedule, and the abort conditions. The first five are things you prepare. The sixth is people. The seventh is the only group written entirely about failure, and it is the one most likely to be skipped.

That table is the sheet in miniature, and it is worth printing on its own page. The rest of this article expands each group into the specific items a desk signs. The wider four-phase context, including where preparation ends and launch day begins, is set out in the launch strategy handbook.

Group one: identity and metadata

This group is signed first because it is the least forgiving. The fields written into the token at creation define what a stranger sees three seconds after landing, and several of them cannot be changed afterwards at any price. Everything else on the sheet can be improved during the week. This group cannot be improved at all once the mint has landed.

• Final name, checked for spelling by someone who did not write it
• Final ticker, checked against existing tokens using the same string
• Image file at the required dimensions, viewed at small size on a phone screen
• Description text, read aloud once, with no unverifiable claims in it
• Social links, each one opened and confirmed to load a live account
• A written note recording which of the above are permanent after mint

Two of those items catch most real errors. Spelling checked by a second reader catches the mistake the author literally cannot see, and viewing the image at small size catches an artwork that is legible at full resolution and a grey smudge in a list. Both take a minute. Both are permanent if missed.

The technical shape of token metadata on Solana is not something you configure by hand on a launchpad, but it is worth knowing that it follows a documented standard, described in the Metaplex developer documentation. What the launchpad form does is fill that structure for you. The field-by-field treatment of what each entry does to a reader belongs in metadata and token setup.

Sign this group forty-eight hours out, not because the work takes two days but because a permanent decision deserves one night of distance. A name that still looks right the following morning is a name. A name that only looked right at midnight is a name you will explain apologetically for as long as the token exists.

Group two: wallets and key policy

Wallet items sit in the permanent class in effect rather than in form. Nothing here is written into the token, but a transfer to the wrong address is as irreversible as a misspelled ticker and considerably more expensive. The purpose of the group is to make sure that on launch day nobody is typing an address from memory or approving something they have not read.

1. Decide which wallet signs the mint and write the address down in full, in the shared sheet, not in a private message.
2. Decide which wallet holds the operating budget, and confirm it is not the same wallet that signs the mint.
3. Send one small test transfer to each address you intend to use, and confirm it arrived by looking at the address on a block explorer rather than in a wallet interface.
4. Confirm who holds each key, where the recovery material is, and what happens if that person is unreachable during the window.
5. Agree in writing that no new wallet is introduced during the staffed window for any reason.
6. Fund the operating wallet to the agreed ceiling before the mint, so that no funding transfer has to happen while the curve is live.

Step three is the one people skip and the one that pays. A Solana address is base58 text with no built-in meaning to a human eye, and two addresses can look similar enough at a glance to pass. Confirming arrival on the Solana explorer takes seconds and removes an entire category of expensive mistake.

The last step matters more than it sounds. Funding during a live curve means doing treasury work while distracted, and it also means the moment of highest urgency is the moment you are moving the largest amounts. Pre-funding to the ceiling makes the ceiling physical: the operating wallet cannot spend money it does not hold.

Group three: communications and channels

Communications items are editable, and that is precisely why they get written in advance. Nothing on this list is impossible to fix later. What it does is remove the need to compose anything original at the moment your attention is worth the most. Copy written before the mint is calm, checked and consistent. Copy written at minute four is neither.

• The launch announcement, written in full, with the token address left as a clearly marked blank
• A pinned message for each channel, describing what the project is in plain terms
• Answers drafted for the five questions you already know will be asked
• A statement of what you will not answer, agreed by everyone who might be asked
• The order in which each channel is posted to, with one named person doing the posting
• A correction template, so that publishing a correction is a form to fill rather than a decision to agonise over

The correction template is the item experienced teams add after their first launch. Under pressure, the instinct is to quietly edit and hope, and quiet editing is how a small factual mistake becomes a credibility problem. A pre-written format makes the correct behaviour the path of least resistance, which is the only reliable way to get it under stress.

Deciding what you will not answer is equally practical. Every launch attracts questions about price, timing and future plans that cannot be answered honestly, and an improvised non-answer sounds evasive while a prepared one sounds like a policy. Agree the wording once, share it with everyone on the rota, and let it be boring.

Sign this group twenty-four hours out. That leaves a full day in which someone can read the copy cold and notice the sentence that promises something you cannot deliver. Recurring versions of that sentence, and the rest of the failures this desk sees repeatedly, are collected in launch mistakes that repeat.

Group four: budget and treasury

Budget items convert intentions into constraints. A number in someone head is not a budget; it is a preference that will be renegotiated at hour four by a tired person who wants the chart to look different. A budget on the sheet is a ceiling with named lines, agreed while calm, and funded into a specific wallet before the mint.

• A total ceiling in SOL that the launch will not exceed under any circumstances
• That ceiling divided into named lines, each with a rule saying when it may be spent
• An allowance for network fees and failed transactions, sized separately from the trading lines
• A line held back for the migration step, ring-fenced and not available to launch-day decisions

Fee handling deserves its own line rather than being absorbed into the trading budget. Network fees on Solana are small individually and the launchpad takes its own cut on curve trades, but retries and failed transactions accumulate quietly during a busy hour. The current fee schedule is published by the launchpad itself and should be read there rather than assumed from any secondary source.

The ring-fenced migration line is the one most often raided. It exists because if a curve does complete, the busiest and most time-pressured hour of the whole launch arrives immediately afterwards, and having to find funding at that moment is a self-inflicted problem. How to size lines like these against your own circumstances is worked through in budgeting the curve.

Sign the budget twenty-four hours out, and sign it as a pair if you have a pair. The signature that matters is not that the numbers are optimal, because nobody can know that. It is that two people agreed the ceiling before anything was at stake, which is what makes it defensible when someone wants to move it later.

Group five: monitoring and tooling

Monitoring is signed late, two hours out, because it is the group that must be tested in its final state rather than planned. The question this group answers is narrow: what will the person on the desk actually look at, on what screen, at what interval, and what will they do with what they see. Everything else is browsing.

• The two or three views the desk will refresh, opened, logged in and confirmed working
• The interval at which they are checked, written down so it is not a matter of mood
• A place to record what was observed, so hour four can be compared with hour one
• Any third-party tool decided on, configured, funded and tested before the mint

That last item is where most tooling regret originates. Teams that have not decided in advance end up evaluating software during a live curve, which means learning an unfamiliar interface, funding it in a hurry and spending unplanned money while distracted. Deciding beforehand is an operational discipline, not an endorsement of any particular product.

If automated trading activity is part of your plan, decide it now, at this point on the sheet, and treat it like any other line item with a cost and a rule. Services in that category, such as an automated Solana volume bot, route trades across wallets and produce recorded activity on a venue. Signing the decision in advance is the discipline. No tool of any kind removes the uncertainty of who turns up, and none of them decide whether a curve completes.

Testing in final state means exactly that. Log in on the machine you will use, on the network you will be on, at the time of day you will be working. A tool that worked on a laptop last week and a session that has since expired are indistinguishable until the moment you need it, and that moment is always hour one.

Group six: the human schedule

This group has no technology in it at all, which is why it disappears from most checklists. It answers one question: who is awake, at what time, doing which job. A launch runs on attention, and attention is a finite resource with a schedule. A rota is the only item on the sheet that protects the other six from being run by an exhausted person.

The handover note is the item that turns two shifts into one continuous desk. It should be written even when nothing happened, because "nothing happened between hour one and hour three" is genuinely useful information to the person taking over, and a blank note is the most common way a team loses track of what it already knows.

Confirming availability in writing sounds bureaucratic and is not. Verbal agreements to be around dissolve quietly, and the failure surfaces at the worst point in the window. A written confirmation, however informal, gives the launch lead a real answer to the only question that matters at hour three, which is whether the next shift is actually coming.

Group seven: abort conditions

Abort conditions are the last group and the least popular. They describe circumstances in which you postpone the mint or stop the launch, written while calm and applied without renegotiation. Their entire value comes from being decided in advance, because the moment you need them is precisely the moment your judgement about them is least trustworthy.

• Any permanent field unsigned at T-2h: postpone the mint
• Any wallet whose control cannot be demonstrated by a test transfer: postpone the mint
• A factual error in published copy that cannot be corrected: stop and correct before continuing
• A rota shift with nobody confirmed: shorten the staffed window rather than run it uncovered
• The spend ceiling reached: stop spending, regardless of what the record looks like

Postponing a mint feels catastrophic in the hour before it and looks trivial a week later. Almost nothing about a launch depends on the specific hour it happened, and everything about it depends on the permanent fields being right. Teams that have moved a mint by a day rarely regret it. Teams that shipped a misspelled ticker regret it permanently.

Notice that every condition above is observable by someone other than the person who wrote it. That is deliberate. A condition phrased as a feeling, such as stopping if it does not feel like it is working, cannot be applied consistently and will be argued about. A condition phrased as a fact can be checked by whoever is on the desk.

The countdown and a two-person worked example

Deadlines on this sheet are relative to the mint, never to a calendar date. Launches slip, and a sheet anchored to dates rots the moment one moves. Anchor everything to four markers and the whole document survives a change of plan intact. The countdown below is the same sheet, sorted by time instead of by owner.

As an illustration, take a sheet of twenty-eight items split between two people. The groups above contain six identity items, five wallet items, six communications items, four budget items, four monitoring items and three rota items, which totals twenty-eight. The abort conditions are written by the launch lead and reviewed by both, so they are not counted as a separate owner load.

Person A takes identity, communications and the rota: six plus six plus three, which is fifteen items. Person B takes wallets, budget and monitoring: five plus four plus four, which is thirteen. Fifteen and thirteen is twenty-eight, and the split holds because the two halves rarely need to talk to each other except at the cross-check points.

By deadline the same twenty-eight items fall differently. Eleven are due forty-eight hours out, being the six identity items and the five wallet items. Ten are due twenty-four hours out, being the six communications items and the four budget items. Seven are due two hours out, being the four monitoring items and the three rota items. Eleven plus ten plus seven is twenty-eight.

That distribution is the useful output, because it shows the load is front-heavy. Nearly forty per cent of the sheet must be finished two days before anything happens, and it is the permanent forty per cent. Teams that discover this on the day of the mint are not disorganised so much as unlucky in their sequencing, and the fix costs nothing except doing it earlier.

Cross-checking is the one place the two owners must meet. Person B reads person A permanent fields before they are signed, and person A reads back the wallet addresses person B has recorded. Neither check requires expertise in the other half of the sheet. Both catch the specific class of error that the person closest to the work cannot see.

GROUPS

Seven, grouped by owner rather than by topic

MARKERS

48 hours out, 24 hours out, 2 hours out, T-0

PERMANENT

Name, ticker, image and supply, fixed at creation

EDITABLE

Copy, channels, pinned messages, how you answer

CEILING

Funded into the operating wallet before the mint, not during

ABORT

Written 48 hours out, applied without renegotiation

Run the sheet once end to end the evening before, out loud, with the second person listening. Anything that cannot be said plainly is either unfinished or untrue. What survives that reading is a document a tired person can follow at hour five, which is the only condition under which any checklist has ever been worth writing. The rest of the phase sits in the preparation hub.

Questions the desk is asked