A crypto whitepaper checklist comes down to one question: can a stranger with money, a listing decision or a reputation at stake understand what you are building, what the token does, who gets how much and when, and what could go wrong? Exchanges, investors and launchpads each read your whitepaper with a different purpose, but they all hunt for the same thing, which is a document that is specific, internally consistent and honest about risk. This guide walks through what to include, why each reviewer cares, and which gaps get a project quietly passed over.
It is written for teams preparing a token launch. If you are mainly after the numbers side, our tokenomics design guide goes deeper on supply and incentive design. Here the focus is on how that work should be presented.
Whitepaper vs Litepaper vs Docs Site
Before drafting, decide what each document is for. One file rarely serves investors and diligence teams equally well.
| Format | Length and tone | Main audience | Best used for |
|---|---|---|---|
| Whitepaper | Long, structured, formal | Exchanges, launchpads, institutional investors, counsel | Due diligence and the permanent record of the token's design |
| Litepaper | Short, plain language | Early community, retail, first-pass investor screening | Explaining the idea quickly and linking out to detail |
| Docs site | Modular, frequently updated | Developers, integrators, power users | Technical reference that changes as the product changes |
The whitepaper vs litepaper question is really about depth: the litepaper summarises, the whitepaper holds the detail, and the docs site covers anything that changes often. All three must agree, because a number that differs between them quickly loses a reviewer's trust.
The Crypto Whitepaper Checklist
Each section below has checkbox items and a note on who cares most and why. Use it as a token whitepaper structure, then trim to fit your project.
1. Problem and product
- A specific problem stated in a few sentences, with the user who has it
- What the product does today, separated clearly from what is planned
- Why a blockchain or token is needed here, not simply used because it is available
- How the product differs from existing alternatives, named honestly
- Current status: live, testnet or in development
Investors care most here, because the whole case rests on a real problem. Reviewers at exchanges and launchpads use this section to judge whether a project is a product or only a token.
2. Technical architecture
- Chain choice and the reason for it
- Core components and how they interact, ideally with a diagram
- Smart contract overview, including which contracts hold funds or control the token
- Admin keys, minting rights, upgradeability and who holds them
- Audit status: firms, scope, dates and where the reports can be read
- Any cross-chain or bridge design
Exchange listing teams read this section for security and operational risk. Admin rights are the detail most often missing and the one reviewers look for first.
3. Token design and utility
- What the token is used for in the product, in concrete actions
- Whether utility exists at launch or arrives later, and which
- How value or demand is meant to connect to usage, without promising returns
- Minting, burning or emission rules, stated precisely
- The token standard and contract address, or a statement that it is pending
Launchpads and exchanges want to see a token with a function. Vague wording such as "the token powers the ecosystem" suggests there is none.
4. Supply, allocation and vesting tables
- Total supply and whether it is fixed or variable
- Allocation table: team, investors, advisors, community, treasury, liquidity, ecosystem
- Percentages and absolute token amounts that both add up to the total
- Vesting terms per category: cliff, vesting length, release cadence, unlock at TGE
- Any private round prices and how they compare with the public price
This is the section reviewers open first. Investors compare allocations and entry prices against their own terms, and exchanges check whether large early unlocks could pressure the market. Put the figures in tables rather than prose, so nobody has to rebuild them.
5. Circulating supply schedule
- Circulating supply at TGE, with the calculation shown
- A month-by-month schedule for at least the first 12 to 24 months
- Which wallets are counted as locked, and how locks are verified
- Initial market capitalisation and fully diluted valuation at the planned listing price, with the method
Data aggregators and exchange listing teams need a clear circulating supply figure, and a schedule that matches on-chain locks prevents later disputes. For the method, see our article on how to calculate and report circulating supply.
6. Treasury and governance
- What the treasury holds, how it is controlled and who can spend it
- Multisig or other custody setup, described at a level that can be checked
- Spending policy: what the treasury funds and how it is reported
- Governance model: who can change parameters, how decisions are made, what is on-chain
- Transition plan if control moves from the founding team to token holders
Investors read this to see who really controls the token. Exchanges want to know who is accountable for treasury movements that could affect the market.
7. Team and backers
- Named core team with roles and verifiable professional history
- The legal entity behind the project and its jurisdiction
- Advisors included only if they have agreed to be listed
- Disclosed investors and the rounds they took part in
Every reviewer type cares about accountability. Exchanges and launchpads typically run their own checks on the team, and a mismatch between the whitepaper and what they find is a quick way to end the process.
8. Roadmap
- Milestones already delivered, with dates
- Upcoming milestones tied to deliverables, not slogans
- Realistic time frames, with dependencies noted
- A statement that the roadmap can change, and how changes will be communicated
Investors judge execution from the track record on the roadmap. A roadmap made entirely of future items with no history behind it reads as an idea rather than a project.
9. Risks and disclosures
- Technical risks: smart contract bugs, dependencies, key management
- Market risks: liquidity, volatility, concentration of holdings
- Regulatory risk: that the legal treatment of the token may differ by jurisdiction and change
- Operational and team risks, including key person dependency
- Conflicts of interest, such as team holdings or related-party arrangements
A risk section that names real risks signals maturity, and counsel at exchanges and launchpads read it closely.
10. Legal disclaimers and regulatory status
- Clear statement that the document is informational and not an offer or investment advice
- Jurisdictions where the token is not offered
- Description of the token's intended legal treatment, as advised by counsel
- Whether the document is intended to meet any formal disclosure regime
Some regimes require a formal document for certain offerings or admissions to trading. The EU's MiCA regulation, for example, includes a crypto-asset white paper requirement for certain tokens. Whether it applies to you, and what exactly must be in it, depends on your token and where you offer it, so get legal advice early. Our overview of token launch legal considerations is a starting point for the questions to ask counsel. A marketing whitepaper should not be assumed to satisfy a regulatory one.
11. Versioning and maintenance
- Version number, date and a short change log on the first page
- A named owner responsible for updates
- A rule that any change to supply, allocation or vesting is published as a new version
- Old versions kept accessible
- One source of truth for numbers, used to generate the whitepaper, litepaper, docs and website
Reviewers compare versions. A silent change to allocations after a listing review is among the most damaging things a project can do.
Who Reads What
Different reviewers weigh the sections differently, so it helps to know where each one starts.
- Exchanges: architecture and admin rights, circulating supply, allocation and unlocks, legal disclaimers. See our crypto exchange listing requirements for the wider application picture. A whitepaper for exchange listing should make these sections easy to find.
- Investors: problem and product, token utility, allocation and entry prices, governance and team.
- Launchpads: team, tokenomics, audit status, and the post-sale plan. The model you choose affects what they ask for, as covered in launchpool vs IEO vs launchpad.
Red Flags Reviewers Notice
- Numbers that disagree. Supply, allocations or vesting differ between the whitepaper, the deck and the website.
- Allocation tables that do not add up. Percentages that total more or less than 100, or token amounts that miss the supply.
- Utility that exists only in the future. The token has no function now, and none is specified for later.
- Unexplained early unlocks. Large team or investor releases near launch, with no reasoning given.
- No admin-key disclosure. Minting, pausing or upgrade rights exist, but the document is silent about who holds them.
- Guaranteed returns or price talk. Language about expected price or yield invites legal and reputational trouble.
- Anonymous or unverifiable team. No names, or names that cannot be checked.
- No risk section, or a generic one. Boilerplate that fits any token suggests nobody thought about this one.
How to Use the Checklist
Start with the tables, since everything else refers back to them. Write the product and architecture sections from what is true today. Have counsel review the risk and legal sections, and have someone who did not write the document check every number against the model. Publish with a version and date, and treat later edits as releases.
Final Word
A good whitepaper does not need to be long. It needs to be precise on supply, allocation, vesting, contract control and risk. Teams with a clean, consistent document spend reviews discussing the product rather than defending gaps.
The whitepaper is also the base that your listing and liquidity plan is built on. At Fibonacci Capital we work with token teams on market making, liquidity planning and listing support, and the clearer your supply and unlock disclosures are, the easier it is to plan healthy trading from day one. If you are preparing a launch and want to pressure-test the plan, get in touch about our pre-TGE support.