Module 5: Fundamental Analysis and Tokenomics
Reading a Whitepaper Critically
Chapter 2 of 15 · about 5 minutes
2.1 Forty pages of confidence
Mint opened the whitepaper of a new project that everyone online was excited about. It had forty pages, beautiful diagrams, complex equations, and phrases like "revolutionary paradigm," "next-generation infrastructure," and "trillion-dollar opportunity."
After an hour, Mint closed it. "I read every page and I still don't know what it does."
"That's information too," said Hash. "Bitcoin's whitepaper explained something genuinely new in nine pages. When a document uses forty pages and you still can't tell what problem it solves, be careful."
2.2 What a whitepaper is
A whitepaper is a document describing a project: the problem it addresses, how its solution works, and often how its token functions. Many projects also publish litepapers (shorter summaries), technical documentation, and tokenomics pages.
Whitepapers are written by the project itself. They're not audited, regulated, or independently checked in most cases. Treat them as a sales document with technical content, not as neutral facts.
2.3 The six questions
Hash gave Mint six questions to answer from any whitepaper or documentation.
1. What problem does it solve? Can you explain it in one or two plain sentences? Is it a real problem that real people or businesses have?
2. Why does it need a blockchain? Recall Module 1, Chapter 3: blockchains are slow and expensive compared with normal databases. They're worth it when you need a shared, tamper-resistant record without a trusted middleman. If the project would work just as well as a normal app, the blockchain may be decoration.
3. Why does it need a token? This is often the most revealing question. Does the token play an essential role, such as securing the network or paying for a scarce resource? Or could the product work just as well using ETH or a stablecoin?
4. How does it actually work? Is there a clear technical explanation, or only vague claims? Has the system been built and tested, or is it all future plans?
5. Who is it competing with? Does the paper honestly discuss existing solutions, or claim to have no competition?
6. What are the risks? A credible paper acknowledges limitations, trade-offs, and open problems. A paper that claims no downsides is either naive or not being honest.
| Question | Strong answer | Weak answer |
|---|---|---|
| What problem? | Specific, real, explained simply | Vague, buzzword-heavy, or "everything" |
| Why a blockchain? | Needs shared trust without a middleman | Would work fine as a normal app |
| Why a token? | Essential to security, payment, or coordination | Added mainly for fundraising |
| How does it work? | Clear mechanisms, working product or code | Mostly future promises |
| Competition? | Honest comparison with alternatives | "No competitors" |
| Risks? | Openly discussed | Not mentioned |
2.4 Language red flags
Certain language patterns appear again and again in weak or fraudulent projects.
| Language | Why it's a concern |
|---|---|
| "Guaranteed returns," "risk-free," "passive income for life" | No legitimate project can guarantee returns |
| "Revolutionary," "disruptive," "game-changing" with no specifics | Marketing in place of substance |
| Huge market size claims, such as "a $100 trillion market" | Market size says nothing about whether this project will capture any of it |
| Price predictions for the token | Projects predicting their own price are selling, not informing |
| Heavy jargon without explanation | Complexity can hide a lack of substance |
| Long sections on the token's price and almost nothing on the product | Priorities are clear |
"So a project saying its token will reach $10 is a red flag?" Mint asked.
"A big one," said Hash. "Serious teams talk about what they're building. They don't promise prices."
2.5 Check what's real
Whitepapers describe intentions. Your job is to compare them with reality.
Is there a working product? Try it, ideally on a testnet or with a small amount. Does it work as described?
Is the code public? Open-source code on a public repository lets others check what the project actually does. Closed code isn't automatically bad, but it means trusting the team's description.
Has the code been audited? Security audits by reputable firms don't guarantee safety, but their absence is a warning sign for anything holding user funds. Read the audit summary: were serious issues found, and fixed?
Do the smart contracts match the documentation? For tokens, check the contract on a block explorer (Module 3, Chapter 6). Is it verified? Does the total supply match what the paper says? Can the team mint new tokens or freeze transfers?
Has the roadmap been met? Compare past roadmap promises with what was actually delivered and when.
2.6 Plagiarism and copies
Some projects copy whitepapers, or large sections of them, from other projects, changing only the names. Searching a few distinctive sentences from a whitepaper in a search engine can reveal this quickly. Copied documentation is a strong sign that a project isn't doing original work, and often a sign of a scam.
Similarly, many projects fork existing open-source code: they copy another project's code and launch it with small changes. Forking is legitimate and common in open source. But a fork claiming to be revolutionary, without explaining what it improved, deserves skepticism.
2.7 Node reads a whitepaper
Node tried the six questions on a project described in its whitepaper as "decentralised AI infrastructure for the next billion users."
| Question | Node's finding |
|---|---|
| What problem? | Couldn't summarise it after two readings |
| Why a blockchain? | Not explained |
| Why a token? | Token "powers the ecosystem," with no specific function |
| How does it work? | Diagrams but no technical details; product "coming soon" |
| Competition? | Claimed "no direct competitors" |
| Risks? | None mentioned |
"Six weak answers," said Node.
"That doesn't prove it's a scam," said Hash. "But it tells you the burden of proof is on them, and they haven't met it."
2.8 Try it yourself
Read the Bitcoin whitepaper, which is about nine pages. Answer the six questions from section 2.3. Then choose the whitepaper or documentation of a newer project you're curious about and answer the same questions. Compare how clearly each document answered them.
Finally, take two distinctive sentences from the newer project's whitepaper and search for them online in quotation marks. Do they appear anywhere else?
Key takeaways from this chapter
- Whitepapers are written by projects themselves and should be read as sales documents with technical content.
- Ask six questions: what problem, why a blockchain, why a token, how it works, who it competes with, and what the risks are.
- "Why does it need a token?" is often the most revealing question.
- Guaranteed returns, price predictions, empty buzzwords, and huge market claims are red flags.
- Compare the paper with reality: working product, public code, audits, contract details, and roadmap delivery.
- Search for copied text, and be skeptical of forks that don't explain their improvements.