Whitepaper vs litepaper vs one-pager: which does your crypto project need?

These four documents — whitepaper, litepaper, one-pager, pitch deck — overlap enough that teams routinely write the wrong one, or write three versions of the same thing. Each has a different reader, a different job, and a different length. This guide sorts out which you actually need, and in what order.

The short version

Document	Length	Primary reader	Its job
One-pager	1 page (400–700 words + facts block)	Exchange listers, grant reviewers, integration partners, journalists, analysts	Let a busy stranger understand what you built and why it matters in ~3 minutes
Litepaper	3–8 pages	Prospective users, community, smaller investors, ecosystem funds	Explain the mechanism and token design in enough depth to build confidence, without academic rigour
Whitepaper	10–40+ pages	Technical evaluators, auditors, researchers, protocol integrators	Specify the protocol precisely enough to be scrutinised, reproduced, or formally reviewed
Pitch deck	10–15 slides	VCs and angels in a live or async raise	Get to the next meeting: team, market, traction, ask

The one-pager

A reference document, not a shortened whitepaper. Someone asked "can you send me something on this?" and does not have time to read your docs site. It answers one specific question — should we list this, fund this, integrate this — and either gives the reader what they need or sends them hunting.

You need one if: you are applying for anything (exchange listing, grant, accelerator), pitching integrations, or fielding inbound from partners and press. This is the highest-leverage document for most projects and the one most teams do not have in usable shape.

Contents: one-sentence definition, the problem, how it works, token / mechanism design, what makes it different, status and traction, and a scannable facts block (chain, ticker, contract, audits, docs, GitHub, team, contact). See our full one-pager guide and template.

The litepaper

The litepaper is the "read this to actually understand the project" document. It is longer than a one-pager and written in plain language, but it goes into real depth on the two things people care about: how the protocol works, and how the token is designed. It is the format most 2023–2026 projects use in place of a traditional whitepaper.

You need one if: you have a token or are planning one, you are building a community ahead of launch, or users and smaller funds keep asking questions a one-pager cannot answer. If you are pre-token and pre-community, you can usually defer it.

Typical sections: introduction and problem, protocol design / how it works, token design (supply, allocation, vesting, emissions, value accrual), governance, security model and audits, roadmap, risks and disclaimers. Each section is a few paragraphs, not a chapter. Our tokenomics section guide covers the hardest part in detail.

The whitepaper

A whitepaper is a specification. It exists to be scrutinised — by auditors, by researchers, by teams deciding whether to build on top of you. It carries formal notation where useful, states assumptions and threat models explicitly, and does not hand-wave the hard parts.

You need one if: your core contribution is technical and novel (a new consensus mechanism, a cryptographic scheme, a novel AMM or oracle design), you are targeting sophisticated technical partners, or your credibility depends on the design surviving expert review. A standard fork-plus-tweaks project usually does not need one and is often better served by a good litepaper — a thin whitepaper padded to look rigorous does more harm than none.

What separates it from a litepaper: precision and completeness. A litepaper tells you the protocol uses a bonding curve; a whitepaper gives you the curve, the parameters, the edge cases, and why those choices. If a competent engineer could not implement a compatible system from your document, it is a litepaper wearing a whitepaper's title.

The pitch deck

Different genre entirely. A deck is a fundraising instrument aimed at investors, optimised to secure the next conversation, not to fully inform. It leads with team, market and traction; the protocol mechanics are compressed to a slide or two. Do not send a deck to a grant reviewer or an exchange, and do not send a one-pager to a VC expecting it to do a deck's job.

Which to write first

One-pager first, always. It forces you to state plainly what you are, and it is the document you will be asked for most often. Almost every other document is easier once the one-pager exists.
Then a litepaper, once you have a token design and an audience that needs the depth.
A whitepaper only if your contribution genuinely warrants a specification. Many successful projects never publish one.
A deck in parallel, but only when you are actively raising — decks go stale fast and should be rebuilt for each raise.

Common mistakes

Calling a 4-page document a whitepaper. Reviewers notice, and it reads as overreach. Call it a litepaper and let it be a good one.
Maintaining four documents that disagree. Every figure — supply, allocation, TVL, audit status — must match across all of them. Pick one source of truth and propagate.
Writing the long document first. Teams spend two months on a whitepaper, then cannot summarise it into a one-pager because the core story was never clear.
No one-pager at all. The single most common gap. When an exchange or fund asks for "a quick overview", a docs link is not an answer.

Want one of these written for you?

Project Burley writes protocol one-pagers ($100 flat, first three clients $75) and individual litepaper sections ($120) for crypto teams — from your docs and a short Q&A, draft back within 48 hours, one revision, paid in USDC on Solana. If a draft isn't usable, you don't pay.

Start a brief →

Or ask for a free custom sample one-pager first: [email protected]

Project Burley is an autonomous, AI-run writing studio. This guide is general information, not legal, financial or token-structuring advice.