A white paper is the document a crypto project publishes to explain what it is building and why. Bitcoin’s own paper, released on 31 October 2008 by the pseudonymous Satoshi Nakamoto, ran nine pages and set the pattern: state the problem, describe the mechanism, show the math. Most projects still follow that shape, and reading one well takes about 30 minutes once a reader knows which sections carry real information.
Start with the problem and the mechanism
The opening sections should name a specific problem and a specific way of solving it. The paper titled Bitcoin: A Peer-to-Peer Electronic Cash System spends its first three sections on double-spending and proof of work, with formulas instead of adjectives. The Ethereum white paper, published by Vitalik Buterin in November 2013, does the same for smart contracts. Vague openings are worth noting. A paper that talks about revolutionizing finance for two pages before describing anything technical is usually short on mechanism.
Skip the market-size slides and look for the parts a reader could test: the consensus rules, the transaction model, the fee design. If a paper claims throughput numbers, say 100,000 transactions per second, check whether it states the hardware, validator count, and trade-offs behind the figure.
Supply, allocation, and unlock terms
Token supply terms decide what early holders end up worth. Three numbers matter.
Total supply is the fixed cap, if there is one. Bitcoin’s is 21 million coins, released on a schedule that halves roughly every four years. Circulating supply is what trades today. The gap between the two is the fully diluted valuation, and a wide gap means more tokens are coming.
Allocation tells who got what at launch: team, investors, treasury, community. Vesting and unlock terms say when those tokens become sellable. A cliff is a date when a block of tokens unlocks at once. A paper that gives insiders 30% of supply with a six-month cliff and a one-year release schedule is telling readers exactly when selling pressure arrives. Papers that leave this out are hiding the schedule rather than forgetting it.
Team, audits, and red flags
Named, verifiable people beat anonymous ones. Check that listed team members have real work history and that advisors actually acknowledge the role. Audit claims deserve the same treatment. Firms such as Trail of Bits, OpenZeppelin, and CertiK publish their reports, so “audited by a leading firm” with no report link verifies nothing.
Red flags add up quickly: guaranteed returns, plagiarized sections (search a distinctive sentence to check), tokenomics that only work if the price rises, and no public code repository. The Ethereum paper from 2013 carried no allocation, no fundraise, and no roadmap slide, because it was a technical proposal. Papers that mix fundraising language into the technical sections are selling first and building second.
Read the supply schedule first, the mechanism second, the team third. That order saves time.