How to Read a Whitepaper
A whitepaper is the official document in which a crypto project explains the problem it targets, its technical design and how its token works. Read carefully, it helps separate a project's promises from what it has actually built.
On this page 6
A whitepaper is the official document in which a crypto project explains the problem it wants to solve, its proposed technical solution and the role its token plays. The most famous example is the nine-page Bitcoin paper Satoshi Nakamoto published in 2008.
A good whitepaper shows clearly how the system works, who holds which powers and how tokens will be distributed. A weak one is mostly marketing. Either way, read it as a list of claims to check, not as a guarantee.
What sections does a whitepaper include?
- Abstract: a one-paragraph summary of the project.
- Problem statement: what existing systems fail to do.
- Technical architecture: consensus method, network design, smart contracts and security model.
- Token economics: what the token does, total supply, allocation and unlock schedule.
- Roadmap: planned development milestones and dates.
- Team and governance: who builds it and how decisions get made.
In the EU, MiCA now requires most projects offering tokens to the public to publish a crypto-asset white paper with set disclosures, including risks and information about the issuer.
Whitepaper vs litepaper vs yellow paper
Some projects publish several documents at different levels of detail. A litepaper is a shorter, less technical version aimed at users and investors. A yellow paper is the formal technical specification. The best-known example is the Ethereum yellow paper, published by Gavin Wood in 2014, which formally defines the rules of the Ethereum Virtual Machine.
For mature projects, the most current information often lives in developer documentation and improvement proposals (BIPs for Bitcoin, EIPs for Ethereum) rather than in the original whitepaper. The whitepaper tells you where a project started; those sources tell you where it is now.
How to read a whitepaper in seven steps
1. Get the right, current version
Download it only from the project’s official site; copies elsewhere may be outdated or altered. Check the date and version number. If the project has since changed its network or token model, the original PDF may no longer describe reality, and the developer docs are the better guide.
2. Write the problem in one sentence
Skip slogans like “revolutionizing finance” and look for a concrete problem. The Bitcoin paper does this well: the problem is preventing double spending without a trusted middleman; the solution is a chain of transactions timestamped with Proof of Work. Then ask why a blockchain is needed at all. If one company can rewrite every record anyway, a token usually adds little.
3. Map how the system actually works
Who orders transactions and who validates them? Where are user funds held? Where does outside price data come from? If a component fails, can users exit on their own? A paper that never discusses attacks or outages is missing something important.
4. Find the token’s real job
Is the token genuinely needed to use the product, or can fees be paid in something else? Do holders get any claim on revenue or legal rights? Instead of metaphors like “the heart of the ecosystem,” look for the mechanism that links product growth to token demand.
5. Do the supply math
Do the team, investor, treasury and community allocations add up to 100%? Suppose 20% of 1 billion tokens circulate on day one and 40% is locked for the team and investors. At $1, market cap is $200 million while fully diluted value is $1 billion. The gap is supply still to come. Our guide on reading tokenomics goes further.
A “cliff” is the initial lock-up period; the paper should also say how much unlocks when it ends. A three-year vesting schedule doesn’t necessarily mean equal monthly releases.
6. Separate promises from proof
For claims like “100,000 transactions per second,” ask how they were measured: testnet or mainnet, simple transfers or complex contracts? For security claims, check the audit date and which code version it covered. A feature on the roadmap is not a feature running on mainnet.
7. Check who holds the controls
Who can upgrade the protocol, is there an emergency pause, and who approves treasury spending? If a multisig is used, are the signers independent and how many signatures are required? “Community governance” on its own doesn’t prove that control is actually spread out.
What are the red flags in a whitepaper?
- Price targets or “guaranteed returns” in place of technical detail.
- Sections copied from other projects’ papers.
- No token allocation table or unlock schedule.
- A team whose identities or track record can’t be verified.
- Walls of jargon and performance claims that can’t be measured.
- No mention of risks or failure scenarios.
When several of these show up together, the odds rise that you’re looking at a rug pull or a pump-and-dump.
What to do after you’ve read it
Write two short lists: what the paper proves and what it only plans. Note the questions it leaves unanswered rather than filling the gaps with optimism. Then test the claims against the code repository, official documentation, on-chain contract data and independent technical reviews. A whitepaper is never enough on its own, but it’s the best place to start understanding what you’d actually be buying before anyone talks about price.