A token generation event is the moment your token contract mints supply and that supply becomes tradeable. Everything before it is preparation; everything after it is consequence. This runbook covers the twenty-four hours either side of that moment — what to confirm before you are committed, who owns each decision while the clock is running, what to watch once the book is live, and what to do when something breaks. It assumes the strategic work is already done and the remaining risk is execution.
Most launch-day failures are not strategic failures. The tokenomics were fine, the listing was confirmed, the audit passed. What went wrong was operational: a contract parameter nobody re-checked, a wallet whose signers were in three time zones, a liquidity pool funded at the wrong ratio, a market maker who was not told the listing time changed. Those are all preventable with a runbook and a rehearsal.
Assign Ownership Before You Assign Times
A runbook without named owners is a wish list. Before you build a schedule, write down who holds each of these, by name, with a backup for each:
| Role | Owns | Must be reachable |
|---|---|---|
| Launch commander | The go/no-go call and any decision to delay | Entire window |
| Contract owner | Deployment, minting, ownership transfer, any on-chain parameter | T-24h to T+4h |
| Treasury signer(s) | Every multisig transaction moving tokens or quote assets | T-24h to T+24h |
| Exchange liaison | The relationship with each listing venue | T-12h to T+12h |
| Liquidity lead | The relationship with your market maker and pool funding | Entire window |
| Comms lead | Announcements, community channels, incident messaging | Entire window |
| Security lead | Phishing monitoring, fake token reports, wallet drainer takedowns | T-2h to T+48h |
Two rules make this work. First, one person makes the call — committees do not function under time pressure, and a launch with two people who each think they have authority to delay will produce a contradictory public statement at the worst moment. Second, everyone has a backup who has actually been briefed, because the person who has been awake for thirty hours preparing the launch is not the person you want signing an irreversible transaction.
Confirm signer availability in writing, with time zones, before you set a launch time. A multisig requiring three of five signatures is only as available as its third-fastest signer.
T-24 Hours: Freeze and Verify
By this point nothing should be changing. This block is verification, not construction. If you find yourself writing code, deploying a fix or renegotiating a term at T-24h, the correct decision is almost always to delay.
Contract and supply
- Deployed contract address recorded, verified on the block explorer, and matched against the audited source
- Total supply, decimals and token symbol confirmed against the tokenomics document
- Mint authority, pause and blacklist functions in their intended final state — and documented publicly if retained
- Ownership transferred to the intended multisig, not an individual key or the deployer wallet
- Vesting and lock contracts deployed, funded, and their unlock dates verified on-chain rather than in a spreadsheet
Read the deployed state directly from chain. Do not verify parameters from the deployment script, the documentation or a screenshot — read them from the contract as deployed. This is the single highest-value hour of the entire launch.
Distribution
- Circulating supply at TGE calculated, agreed and matched against what you have told the market
- Every wallet due to receive tokens confirmed, with amounts, and the total reconciled to supply
- Airdrop or claim mechanism tested end to end on mainnet with a small allocation
- Treasury, foundation and team wallets labelled and, where you have committed to transparency, published
Liquidity and venues
- Listing time confirmed in writing with each venue, in UTC, including any pre-open or call-auction period
- Deposit addresses tested with a small transfer that has actually settled and credited
- Market making agreement signed, and the specific spread, depth and uptime obligations restated in the runbook
- On-chain pool ratio, initial price and locking arrangement agreed and pre-funded where the venue permits
If you have not sized the book against an explicit slippage target, do that before launch day rather than on it — how much liquidity a token needs at launch sets out the method.
T-12 to T-1 Hours: Rehearse and Position
This window is for movement and dry runs, not decisions.
Run a signing rehearsal. Have every signer execute a low-value multisig transaction on the same devices and network they will use at launch. Hardware wallet firmware, browser extension versions and a signer's expiring session are all things you want to discover twelve hours early rather than four minutes late.
Position inventory. Tokens and quote assets need to be in the right place before the window narrows: on the exchange for centralised venues, in the pool or the market maker's wallet for on-chain. Deposits that require confirmations, manual review or a compliance check can take far longer than the transaction itself. Move early, verify credited balances, and never assume a deposit is available because the transaction confirmed.
Confirm the market maker is live and ready on each venue, with the agreed parameters loaded and a direct communication channel open — a shared channel with a named human, not a support inbox. Your liquidity lead should be able to reach them within a minute at any point in the launch window.
Pre-write your communications. Draft, review and stage the announcement, the contract address post, the claim instructions, and — critically — the delay notice and the incident notice. Writing an incident statement while an incident is happening produces bad statements. Contract addresses should be published from your official channels and pinned; assume scam accounts will post a lookalike address within minutes of launch.
Finally, hold a formal go/no-go at roughly T-1h. Every owner reports ready or not ready. Anything not ready is either resolved or triggers a delay. Silence is not consent — poll each owner explicitly.
T-0: The Launch Sequence
The sequence itself should be short, ordered and boring. The typical order is: enable trading or unpause the contract, then seed liquidity, then confirm both venues and pools are quoting, then announce.
Announcing before liquidity is confirmed live is a common and expensive mistake. It concentrates the first wave of buyers into a book that may not be there yet, producing exactly the violent first candle you spent months preparing to avoid.
For a listing on a centralised exchange, the venue controls the open. Your job is to confirm that your market maker is quoting the moment the pair opens, that deposits and withdrawals are enabled as expected, and that the pair is discoverable under the correct symbol. Symbol collisions with an existing token are worth checking directly, not assuming.
For an on-chain launch, the seeding transaction sets the opening price. Verify the token and quote amounts, the resulting implied price and the recipient of the LP tokens before signing. If you intend to lock or burn the LP position, do it in the same session and publish the transaction hash.
T+0 to T+4 Hours: Monitor the Things That Actually Matter
Price is the least useful metric in the first hours. It is noisy, it is what everyone is already staring at, and it tells you nothing you can act on. Monitor the mechanics instead:
- Spread and depth against your agreed targets. Are the quotes actually there, on both sides, at the committed size? This is the single most informative signal about whether your launch is functioning.
- Book resilience. After a large trade clears part of the book, does it refill? A book that empties and stays empty is worse than a thinner book that replenishes.
- Cross-venue price consistency. Persistent gaps between venues mean liquidity is not being maintained somewhere, or that arbitrageurs cannot move inventory between them.
- Claim and distribution success rates. Failed claims are a support and reputation problem that compounds quickly if it is not caught in the first hour.
- Scam surface. Fake contract addresses, impersonation accounts, phishing claim sites. Have your security lead searching actively and reporting them, not waiting for community reports.
Set thresholds in advance for what triggers a call to your market maker or exchange contact, so that escalation is a rule rather than a judgement made by a tired person. "Spread wider than the agreed target for more than fifteen minutes" is an actionable trigger. "The chart looks bad" is not.
When Something Goes Wrong
Assume something will. The three most common launch-day incidents and the response to each:
Liquidity is thinner than agreed. Contact the market maker immediately through the direct channel and ask specifically why: an inventory problem, an exchange connectivity problem, or a risk decision on their side. Each has a different fix, and the distinction determines whether this is a technical issue or a commercial one. Document what you observe with timestamps — you will want it for the post-launch review and, if the shortfall was discretionary, for the contract discussion.
A contract or distribution error. Stop distribution before communicating, then communicate quickly and precisely. State what happened, what is affected, and what you are doing — even if the answer is that you are still investigating. Silence is read as concealment. Never rush an unaudited fix onto mainnet under time pressure; a contained problem is far cheaper than a second, larger one introduced while fixing the first.
A scam contract gaining traction. Publish the correct address again from every official channel, report the fake to explorers, aggregators and the relevant social platforms, and make sure your community moderators are amplifying the correct address rather than debating the fake one.
For any incident, one person writes the public statement and one person approves it. Multiple people posting partial information to different channels turns a manageable problem into a credibility problem.
T+24 to T+48 Hours: Close Out
Before the team disperses, do three things while the detail is still fresh.
Reconcile: on-chain circulating supply against your published figure, distributed amounts against the allocation table, and treasury balances against expectation. Discrepancies found now are administrative; found in three months, they are an accusation.
Review liquidity performance against the agreement — actual spread, depth and uptime versus committed. This is the baseline for every conversation you will have with your market maker for the next year, and it is much harder to reconstruct later.
Write the post-mortem while people remember. What slipped, what was missing from the runbook, what nearly happened. If you have further listings ahead, this document is worth more than any other artefact the launch produces.
Then shift focus. The launch is an event; the market you have created is a continuing obligation. Post-TGE strategy covers the first ninety days, and the 90-day pre-launch timeline is the upstream companion to this runbook if you are still in preparation.
The Condensed Checklist
- Named owner and briefed backup for every role, with signer availability confirmed in writing
- Deployed contract parameters verified by reading chain state, not documentation
- Circulating supply at TGE reconciled to what the market has been told
- Listing times confirmed in UTC with every venue, in writing
- Deposits tested and credited, inventory positioned well before T-0
- Multisig signing rehearsed on production devices
- Market maker live, parameters loaded, direct human channel open
- Announcement, delay notice and incident notice pre-written and approved
- Formal go/no-go held with every owner polled explicitly
- Liquidity confirmed live before the announcement goes out
- Monitoring thresholds and escalation triggers defined in advance
- Reconciliation, liquidity review and post-mortem completed within 48 hours
At Fibonacci Capital we sit on the liquidity side of this runbook, quoting the book from the moment a pair opens and through the volatility that follows. The teams whose launches go smoothly are consistently the ones who treated launch day as an operation with owners and thresholds rather than a date on a calendar — and who agreed what the book would look like long before anyone was watching it.
If you are planning a token generation event and want the liquidity side handled properly, get in touch with our team.