A whitepaper explains what a project intends to build and why the token is necessary to it. Bitcoin's, nine pages long, set the template. Almost nothing since has followed it in spirit: the modern form is a long document in which technical material, competitive positioning and fundraising terms are mixed together, and it carries no legal weight, no audit, and no obligation to be accurate.
Read it in a deliberate order rather than front to back, because the order it is written in is designed to impress. Start with the problem statement and ask whether the problem exists independently of the solution being sold. A great many papers describe a difficulty that only appears once you have accepted the architecture proposed to fix it, and the tell is a problem statement that cannot be explained without using the project's own vocabulary.
Then go to the token section, which is usually placed late and written thinly. What does the token do that the system could not do without it? If the answer is that it pays fees on a network with real usage, that is a mechanism. If it is governance over a treasury, that is a mechanism with a well-documented history of capture. If the token exists because the project needed something to sell, the paper will say so by not saying anything — describing incentives and community and ecosystem without ever explaining why a token is required.
Next, supply and allocation. Total supply, emission schedule, and who holds what. Look for the percentage allocated to the team, to investors and to a foundation, and for vesting periods and cliffs. A project where insiders hold a majority with a short cliff is one where the early buyers are the exit liquidity, whatever the technology does. This is arithmetic, it is disclosed, and it predicts more outcomes than the architecture section.
The technical sections deserve a specific kind of scepticism: check whether claims are falsifiable. Performance numbers should state the conditions they were measured under. Security claims should name the assumptions — how many participants must be honest, what happens if they are not. Comparisons to other networks should be like for like rather than a peak figure from a test environment set against a production average. Where a paper cites academic work, the citation can be looked up, and occasionally the cited paper says something different.
Finally, read what is missing. No named team, or names with no verifiable history. No mention of regulatory position in any jurisdiction. No discussion of what could go wrong — a genuine engineering document has a limitations section, and its absence is itself a finding. A roadmap of dates with no dependencies. And a paper that has been silently revised since publication, which is worth checking through an archive service: the version that raised the money is the one that matters.