A crypto whitepaper tells a buyer what your project does, how the token works, who owns how much of it and what could go wrong. Write it in that order, name real people, and leave out any promise about price.

The most famous one is short. Satoshi Nakamoto's Bitcoin paper, published on 31 October 2008, runs nine pages. The most expensive failure was long on ambition. Telegram raised $1.7 billion for its TON blockchain, the SEC sued in October 2019, and in June 2020 Telegram agreed to return more than $1.2 billion and pay an $18.5 million penalty.

9 pagesBitcoin's whitepaper, published 31 October 2008
$1.7bnraised by Telegram for TON before the SEC sued (SEC)
$18.5mTelegram's penalty, with $1.2bn returned to buyers (SEC)

Who reads it, and what they check first

Three kinds of reader open a whitepaper. Technical reviewers want the mechanism. Journalists, listing sites and exchanges want to know whether the project is real. Lawyers and regulators want to know what you promised.

Robert Stone

Rob's take

I've read a lot of project documents in 18 years of PR. The people deciding whether to take you seriously go to the token allocation table and the team page before they read a word about the technology. A paper that makes them hunt for those two things has already lost them.

The sections, in order

  1. The problem. One paragraph, one group of people, one cost. If you can't say who has the problem and what it costs them, stop here.
  2. The solution and how it works. Plain mechanism first, diagrams second. Say what is live today and what is still planned. Mixing the two is how papers end up in front of regulators.
  3. The token. What it does inside the product. If the answer is "governance" or "access", say exactly what a holder can do that a non-holder can't.
  4. Tokenomics. Total supply, who gets what percentage, and the vesting and unlock dates, in a table. Buyers will check it against the unlock schedule, so make it easy.
  5. The roadmap. Dated milestones you control, to the quarter. A roadmap with no dates is a wish list.
  6. The team. Real names, roles and links to profiles. Some teams are anonymous. If yours is, say so and say why, because you're asking readers to trust code alone.
  7. The risks. Smart contract bugs, regulatory change, thin liquidity, team risk. Write this section first. It forces you to admit what you don't know, and it's the section that makes the rest believable.
  8. The legal notice. Not an offer, not advice, which countries are excluded, no guarantee of value. Have a lawyer read it.

How long should it be?

Nothing sets a length. Bitcoin's is nine pages. The EU's MiCA rules on whitepaper content, in Article 6, give no page limit for the paper or its summary. My rule of thumb, which is not a regulation: 10 to 25 pages for most projects. If a section repeats the one before it, cut it.

The legal lines

United States

⚠ Red flag

There is no US whitepaper law. The SEC reads what you published, along with your posts and your sales pitch, to decide what you were selling. Describe buyers profiting from your team's work and you're describing an investment. Telegram's Gram sale was charged as an unregistered securities offering. Keep the paper about what the product does, and have a securities lawyer check anything about expected returns.

European Union

Since 30 December 2024, MiCA's rules for crypto-assets other than stablecoins have applied. If you offer a token to the public in the EU, or ask for it to be traded there, you must publish a white paper in the set format and notify your home country's regulator at least 20 working days before you publish. The regulator doesn't approve it, and the paper has to say so: "This crypto-asset white paper has not been approved by any competent authority in any Member State." It must also warn that the token may lose its value in part or in full, state that the information is fair, clear and not misleading, and come in a machine-readable format. The ESMA MiCA page has the rulebook.

There are exemptions, including offers totalling under €1 million over 12 months, offers to fewer than 150 people per EU country, and offers to qualified investors only. Check them with a MiCA lawyer before you rely on one.

Mistakes that sink a whitepaper

  • Copying another project's paper. A template is fine for the skeleton. Reviewers search for odd sentences, and a paper carrying someone else's numbers and phrasing gets found.
  • Promising a price or a return. Delete every sentence that says or implies the token will go up.
  • Tokenomics with no dates. "Team: 20%" tells a buyer nothing until it says when those tokens unlock.
  • Claims you can't prove. An audit "in progress" and a partnership not yet signed are the two most common. Say what exists today.
  • No risk section. Or a risk section that lists risks nobody believes.
  • No version or date. Papers change. Put a version number and a date on the cover, and keep the old versions public.

Before you publish

  • Every sentence about the product describes something live, or is labelled as planned.
  • Allocation table with percentages, vesting and unlock dates.
  • Named team with working profile links.
  • Risk section written by someone who wants to find problems.
  • A lawyer has read the legal notice and any line about returns.
  • Run the paper against the due diligence checklist a careful buyer will use, and the rug pull checks reporters use.

When it's done, the next job is getting it read. We cover that in how to get listed on CoinMarketCap and how to promote a crypto project.

Questions founders ask

How long should a crypto whitepaper be?

No rule sets a length. Bitcoin's paper is nine pages, and the EU's MiCA rules set no page limit. For most projects 10 to 25 pages is enough to cover the problem, the mechanism, the token, the tokenomics, the team and the risks.

Do I need a whitepaper to launch a token?

In the EU, MiCA requires one for most public offers and trading admissions unless an exemption applies, and it must be notified to the regulator 20 working days before publication. The US has no whitepaper requirement, but what you publish can be used as evidence of what you were selling, and many exchanges and listing forms ask for a link to one.

Can I use a whitepaper template?

For the structure, yes. Don't copy another project's wording, numbers or claims. Reviewers do search for them, and anything you haven't verified becomes yours.