Token Launch Checklist: Seven Gates to Clear Before You Launch

A token launch checklist is the set of gates a team clears before tokens exist: the business reason, a documented supply and vesting plan, legal sign-off on the offering, tested contracts, a liquidity plan, investor materials, and a stress-tested model. Skipping a gate does not save time. It moves the failure to after launch.

#What a token launch is, in two sentences

A token launch is the point at which a token is issued and can move between holders. Before that moment almost everything is editable, and after it almost nothing is.

That asymmetry is the only reason a checklist is worth your time. A launch does not create a business. It exposes one.

So the question underneath all seven gates is a business question, not a token question. Does the company make money, or have a credible path to making money, and does the token help it make more? If the answer is no, a better allocation table will not fix it. We have watched teams spend months on vesting curves for a product that had no buyers, and the curve was never the problem.

What follows is the order we use. Each gate is something you can show someone.

#Gate 1. The business reason

Write down what the token does that the business could not do without it. One paragraph. No diagrams.

The test is subtraction. Remove the token from the plan and see what breaks. If nothing breaks, the token is a financing instrument wearing a product costume, and the offering should be designed and disclosed as financing rather than as utility. If something does break, name it, because that sentence becomes the spine of the whitepaper, the data room and every investor call.

Three answers hold up in our experience. The token coordinates people the company cannot employ. The token prices something the company cannot price internally. The token carries a right that has to be transferable to work at all. Our view is that anything outside those is worth a second look before you build around it. For the mechanics of writing this down properly, see our guide to token utility design.

#Gate 2. Supply, allocation and vesting documented

One allocation table, one unlock calendar, both in a form a stranger can audit.

A reviewer is not looking for a clever schedule. They are looking for completeness. Every bucket named, every percentage adding to one hundred, every lock with a start date rather than a duration, every cliff shown as a date on a calendar, and a named holder or holder class for each bucket. Percentages that total 97 percent tell a reviewer more about the team than the three missing points are worth.

The calendar matters more than the table, and it is the part teams underbuild. A table says who holds what. A calendar says when that holding becomes sellable, which is the only version of the question the market asks. Our deeper treatment is in the token allocation strategy framework and in token vesting design and schedules.

#Gate 3. Legal sign-off on the offering

Counsel's view, in writing, on two questions. Where is the offer being made, and to whom.

This gate is not a formality you clear at the end. It constrains the design, because the answers change who can hold the token, how it can be marketed and what has to be published before anyone can buy. Get them late and you redesign.

If the European Union is in scope, the instrument to put in front of counsel is Regulation (EU) 2023/1114, the Markets in Crypto-Assets Regulation. Reading the current text, Article 4 provides that a person shall not make an offer to the public in the Union of a crypto-asset other than an asset-referenced token or an e-money token unless two conditions are met. That person has to be a legal person, and they have to have drawn up, notified and published a crypto-asset white paper in accordance with Articles 6, 8 and 9.

Article 6 sets out what the white paper has to contain. Two of its provisions are worth reading before anyone drafts marketing copy. Article 6(4) provides that the white paper shall not contain any assertions as regards the future value of the crypto-asset. Article 6(3) requires a statement on the first page that no competent authority in any Member State has approved it and that the offeror is solely responsible for its content.

Two carve-outs matter for the scoping conversation. Article 4(2) switches off the white paper obligations for certain offers. Among them are an offer to fewer than 150 natural or legal persons per Member State acting on their own account, an offer whose total consideration in the Union does not exceed EUR 1,000,000 over 12 months, and an offer addressed solely to qualified investors where only those investors can hold the asset. Separately, Article 2(4)(a) provides that the regulation does not apply to crypto-assets that qualify as financial instruments. Those are governed by existing financial services law instead.

Which of those paragraphs describes your offering is a legal question with a fact-specific answer, and it is counsel's to give, not ours. We raise the articles so the conversation with counsel starts in the right place. Nothing here says any offering is compliant, registered or exempt.

#Gate 4. Contracts tested and audited

A named auditor, a written scope, and every finding closed or formally accepted with a reason.

The signal is not the existence of a report. It is the distance between the scope in the report and the contracts you actually deployed. We have read audits that covered a staking contract and said nothing about the vesting contract holding most of the supply, which was the contract that mattered. Ask for the commit hash the auditor reviewed and compare it to what is on chain.

"Findings closed" has a specific meaning worth holding people to. Either the code changed and the auditor confirmed the fix, or the team wrote down why the finding is accepted and who accepted it. A spreadsheet of open mediums two weeks before launch is a gate that has not been cleared.

#Gate 5. Liquidity and market plan

Where will the token first trade, who is supplying the liquidity on day one, and what happens on the first unlock date.

Those three answers are mechanical, and we are deliberately not going to say anything about price here. What the plan has to show is the mechanism: the size and composition of the initial pool, who funds it, whether that party has an obligation or only an intention, how long their commitment runs, and who is responsible when it ends. Then the same for the first unlock on the calendar from Gate 2. Who can sell, how much, and into what depth.

Teams that skip this gate usually have not skipped it deliberately. They have assumed that listing is liquidity. It is not. Listing is access.

#Gate 6. Investor and community materials

Three artifacts, each written for a different reader. A whitepaper for the person who wants the design. A data room for the person doing diligence. A plain FAQ for everyone else.

The whitepaper and the data room fail in opposite directions, which is why they are separate documents. Whitepapers get written as marketing and lose the detail a reviewer needs. Data rooms get written as file dumps and lose the argument. We cover the first in our token whitepaper guide, and the second is the whole subject of the Tokenomics Data Room.

The useful test for this gate is handing the pack to someone outside the project and asking them to explain back how the token makes money for the business. If they cannot, Gate 1 is not as clear as you think.

#Gate 7. Model stress-tested

Run the model against a bad market before the market runs it against you.

A stress test is not a sensitivity slider. It is a written run with named assumptions that produces named outputs. Which unlock date lands in the worst position. How much supply becomes sellable in that window as a share of the circulating float. What the treasury's runway looks like if revenue comes in materially under plan. What breaks first, and what you would do about it.

The point is not prediction, and we would not trust anyone who claimed otherwise. The point is that you have already thought about the bad case and written down the response, so the decision gets made calmly rather than in the middle of it. Our method is in token supply modeling.

#Frequently Asked Questions

#What is a token launch?

A token launch is the point at which a token is issued and can move between holders. It is the moment the design stops being a document and starts being something the market can price. The narrower event terminology is defined in our glossary entry for the token generation event.

#What do you need before launching a token?

Seven things. A business reason for the token, a documented supply and vesting plan, written legal sign-off on the offering, tested and audited contracts, a liquidity plan, investor and community materials, and a model that has been run against a bad market.

#How long does a token launch take?

It depends on which gates are already clear. The legal gate and the audit gate set the pace, because both depend on other people's calendars and on findings you cannot predict in advance.

#Do you need a lawyer to launch a token?

You need counsel's view in writing on where the offer is made and to whom before the offer goes out. This post is general information and not legal advice.

#What goes wrong in a token launch?

Based on what we have seen across 100+ companies, the common pattern is a launch date set before the gates are clear, which turns every unfinished item into a problem that now has a public price attached to it. The failure modes are collected in token launch strategy and why most launches fail, and the wider launch sequence is in our complete TGE strategy guide.

#Where to start

Pick the gate you are least able to show someone and work on that one. In our experience it is Gate 1 or Gate 7, and almost never Gate 4, because contracts get attention and arguments do not.

Tokenomics.net is an advisory and education firm for token issuers and asset owners. We have advised 100+ companies through $100MM+ in combined raises. If you want to work the gates yourself, the 67 lessons in the free tokenomics course cover supply, vesting, the whitepaper and the data room. If you want the documented version a reviewer will accept, that is the Tokenomics Data Room.