Read the token table first, then read the white paper

Skip the introduction. Skip the part about the future of finance. Scroll until you find the table showing how the tokens are split, and then find the paragraph that says when each slice unlocks. If the document doesn't have both, you've learned something already and you've spent ninety seconds.

That table is the honest part of the paper. Everything else is a pitch. The allocation is a set of numbers the authors couldn't fudge without lying outright, and it tells you who actually benefits if the price goes up.

What you're looking for: the share going to the team, advisers, "ecosystem fund", treasury and early backers, added together. If insiders hold a large majority of supply, every line about community ownership in the rest of the document is decoration. And check the vesting. A twelve-month cliff on team tokens means there's a date on the calendar when a very large number of coins can be sold by people who paid nothing for them. That date is public information. Write it down.

The question the paper has to answer, and usually dodges

Why does this need a token?

Not "why does this need a blockchain". Narrower than that. Why does the product require its own tradeable asset, rather than charging in dollars or in an existing coin?

There are real answers. A token can pay validators for securing a network. It can meter scarce computation. It can carry governance rights that genuinely matter. Those answers are specific and they're testable.

The fake answer sounds like this: users will purchase tokens to access the platform, creating buy pressure as adoption grows. That's not a mechanism, it's a hope. You could delete the token from the design and the product would work identically, except nobody would get rich early.

Read the utility section twice. If it describes demand for the token rather than a job the token does, the token exists to be sold to you.

Language tells

Count how many times the word "revolutionary" or "next-generation" appears. Then count the equations, the specification tables, the named trade-offs. A good technical document is boring in the specific way that a plumbing manual is boring.

The 2008 Bitcoin paper runs nine pages and spends the back end of it calculating the probability that an attacker with a given share of hash power catches up on the honest chain. It's dry. It shows its working. It also describes, in plain terms, the conditions under which the system fails.

That last part is the strongest signal there's. A serious paper names its own attack surface. Look for a section on what breaks the system: validator collusion, oracle manipulation, a bank run on the collateral, a bug in the upgrade path. If the authors have thought hard about their design, they've thought about how it dies. If the only risks mentioned are regulatory uncertainty and market volatility, nobody has done the hard thinking, or they've done it and decided not to share.

Watch the passive voice too. "Governance will be progressively decentralised." By whom? Starting when? Sentences with no actor are usually hiding the actor.

Who holds the keys

Find the word "upgradeable", "proxy", "admin", "multisig" or "pause". Then find out how many signatures it takes to move funds or change the contract, and who holds them.

This matters more than the whole roadmap. A protocol where three anonymous keys can pause withdrawals or swap the contract logic is a company with extra steps, and you're an unsecured creditor of people you can't name. That might be an acceptable trade for you early on. Plenty of legitimate projects start with admin controls because shipping an immutable contract on day one is reckless. The point is that the paper should say so plainly, and should say what the plan is for handing that power away.

If the paper says "fully decentralised" and the contract has an owner address, one of those two things is a lie.

The comparison grid

You know the one. A table with four competitors along the top, ten features down the side, and a neat column of ticks under the project's own name.

Nobody builds that table honestly. Every design decision in distributed systems costs something. Faster finality costs decentralisation or hardware requirements. Lower fees cost security budget or state bloat. When a paper claims to beat every rival on every axis, it hasn't found a free lunch, it's declined to mention the bill.

The papers worth reading do the opposite. They say: we chose this, it costs us that, we think the trade is worth it for this use case. That sentence is rarer than it should be, and when you find it, slow down and read the whole section.

Claims you can check in twenty minutes

Take the throughput number. Transactions per second figures are usually measured on a private test network with a handful of nodes and no adversarial conditions. Find out whether the number came from a live public network. If the paper doesn't say, treat it as a marketing figure.

Open the GitHub repository. You're not reading the code. You're looking at commit history, how many contributors there are, and whether anything has been pushed in the last two months. A protocol due to launch next quarter with a repo that's been quiet since last year is telling you something the paper won't.

Find the audit. Then actually open it, and go straight to the findings, not the logo on the website. Read what was flagged as high or critical, and whether the fixes were confirmed. An audit of a contract that was subsequently rewritten is worth nothing. Also check the scope line: audits often cover three files out of thirty.

Look at the token holders on a block explorer. If the top ten addresses hold most of the supply and aren't labelled as exchanges or the known treasury, price is whatever those wallets decide it's.

Where this advice doesn't hold

Some genuinely good projects write terrible papers. Engineers are frequently poor writers, and a dense, badly formatted document with no design polish is closer to a green flag than a red one. Judge substance, not typesetting.

Anonymity isn't automatically disqualifying either. Bitcoin's author has never been identified. But anonymity plus a large insider allocation plus admin keys plus a fundraising deadline is a very different combination, and you should treat it as one thing rather than four separate small concerns.

And a clean white paper proves nothing on its own. Some of the worst failures of the last few years had elegant, mathematically literate documents. The paper is a filter for obvious problems, not a verdict.

What to do with what you find

Keep a plain text file. One project per entry, five lines: insider share, unlock dates, who can pause it, whether the token is load-bearing, and the worst thing the authors admit could happen. Revisit it in six months and see which promises landed.

Most won't. That's the useful part of keeping the file.

None of this is investment advice, and nothing in crypto should hold money you need. If you're putting a meaningful amount at risk, talk to a licensed financial adviser who has no stake in the trade, and assume the whole position can go to zero.

The paper that opens by telling you what it can't do is the one worth finishing.