How to Evaluate a Presale Whitepaper in 10 Minutes

What ten minutes with a whitepaper can and cannot tell you

Ten minutes with a presale whitepaper is enough to decide whether to keep reading. It is not enough to decide whether to buy. That gap is the point of a first pass: you are sorting documents into the ones worth an hour of your attention and the ones that have already failed on the page.

A whitepaper is a claim document

A whitepaper is written by the people selling the token. It states what the project says it does, who it says will pay for that, and what the token is for inside the product. Those are claims. The document is not evidence that any of them are true, and a polished PDF costs nothing to produce.

Why a short first pass beats a full read

Most weak documents fail early. The publisher is unclear or unnamed, the introduction never produces one sentence describing the product, or the token has no stated job beyond being sold. You can reach any of those in minutes. Reading everything first spends attention on a paper that was never going to survive, and length starts to feel like substance when it is only length.

What this pass leaves out

The ten minutes stays on the paperwork and the claims inside it. Tokenomics maths, contract audits, KYC checks, cap mechanics, how claiming works and how a price compares with anything else each need a separate check. A document can pass this read and still fail all of them.

Presales are high risk. You can lose all of the money you put in. Nothing here is financial advice.

The same order every time

The routine runs in the same sequence for every document: identity, product sentence, token job, money and control, team, terms match, risk section. Same order, same questions, so two projects can be compared on the same terms instead of judged on whichever paper happened to look better.

The ten-minute read, minute by minute

The routine

How to read it

Do not read front to back. Skim every heading first, so you know which sections exist and which are missing. Then read the intro. Then jump straight to the token section and the sections on funds and control, because those two decide whether the rest is worth your time. The ten minutes are a filter, not a full read.

You can stop at any row. A stop at minute 2 is a result, not a failure of the method: you have learned that the document cannot be identified, which is enough to move on. The clock is there to keep you from spending an hour proving the same point.

Keep this table open beside the PDF and write one line per row: pass, fail or unclear.

Minutes 1 and 2: identify the document before you read a word

Before a single claim in the paper matters, you need to know who put it there and whether you have the version that is current.

On the cover and first page

Look for four things:

• Publisher. A legal entity name or a brand tied to a company, not just a logo and a token ticker.
• Version or date. A version number ("v2.1") or a date line. Either works; both are better.
• Contact route. An email address or a contact form on an official domain, not only a Telegram handle or an X account.
• Where the file sits. The domain or repository it is served from. A PDF uploaded to a file-sharing host with no link back to a project is unattributable.

The check that matters

Open the official site yourself and confirm the document is linked from there. Do not follow a link someone sent you. A paper that exists only as an attachment in a chat group or a forwarded link tells you nothing about who wrote it, and anyone can produce a convincing PDF.

Open the front matter of two documents

Take a short, product-first paper and a long, narrative one and compare only their cover pages: publisher, date, contact route, host. Open the official sites of Chainers at https://chainers.io/ and eOracle at https://eoracle.io/ and find each one's document from there. Read both purely as practice in identifying a document, not as candidates.

The wallet rule

No wallet connection, signature or seed phrase is ever needed to read a document. A paper that gates itself behind a wallet prompt has ended the read. Never share a seed phrase or private key with anyone, on any site, for any reason.

Pass condition

You can name who published it, when, and where you found it. If a document carries no date and no version, you cannot tell later whether the sale terms changed under you, and terms do move.

Practise the same front-matter read on the Slop Cash entry at /presale/slop-cash-jkmotv and the Mandala Chain entry at /presale/mandala-chain-tci9ed.

Minutes 3 and 4: the one-sentence test

Read the introduction only. Then close the document and write one sentence, in your own words: what the product does, and who pays for it. If you cannot write that sentence, the document has not explained itself, and later pages rarely repair it.

The three parts of the sentence

A usable sentence carries a product, a customer, and a reason that customer spends money. Check yours against all three.

Each substitution describes a category, not a product. A category cannot be checked.

Product-first and narrative openings

A product-first paper opens with the problem and the user: who is stuck, and what they do about it today. A narrative paper opens with an industry story, then arrives at the product. The narrative form is not disqualifying, but it still has to reach a product sentence inside the introduction.

Dependency language

Watch for products that only work once partners, regulators or another chain deliver something. Note the dependency on the scorecard. A stated dependency is honest; a hidden one is not.

What the introduction cannot do

A long market-size section is not evidence of demand. It shows the author can describe a market, which is not the same as finding a customer.

Pass condition

One sentence, your own words, with a payer in it. Pass and keep reading. Fail and mark it.

Minutes 5 and 6: what the token actually does

Find the section that explains why the token exists. It may be headed Token, Token Utility, Tokenomics or the token's own name. Skip the pie charts on this read. You want one mechanism, described in plain words.

Six jobs a token can do

• Fees. Users pay the product in the token, or a charge is denominated in it.
• Access or credits. Holding or spending it unlocks a feature, a seat, storage or compute.
• Staking for a role. Locking it earns a job: validation, listing, moderation, insurance.
• Governance. Holders vote on parameters or spending.
• Settlement. Participants pay each other in it for work done inside the product.
• Supply reward. People who provide something the product needs, such as liquidity, data or hardware, are paid in it.

Any one of these is a real answer. Several at once is fine if each is concrete.

The question the section must answer

What has to happen in the product for someone to need this token, and what would happen to that need if the token did not exist? Read the paragraph and answer both halves out loud. If the honest answer is "nothing changes, they would pay in dollars", the token is decoration.

Weak answers read like this:

• "a store of value"
• "powers the ecosystem"
• "will be used for payments later"

None describes a mechanism. "Later" is the tell.

Present tense or future phase

Check the verb tense. "Fees are paid in the token" is a running mechanism. The token "will be integrated into payments" is a promise for a phase that may not arrive. Write down which one you found. The difference matters when you set the document beside the sale terms.

Supply, allocation and unlock schedules are a separate read. Here you need the job, not the maths.

Pass condition: you can explain the token's job to someone else in two sentences without using the word "ecosystem".

Minutes 6 and 7: money and control

The fund question

Somewhere in the document there should be a paragraph that answers three things: who receives the proceeds of the sale, in what form, and what the money is spent on. Look for an entity name, a wallet structure, and a spending plan broken into categories. "Funds will be used for development and marketing" is a sentence, not a plan.

What a described treasury looks like

You are not verifying an address here. You are checking whether control is described at all. A document that takes this seriously usually shows:

• a named structure, such as a treasury account or a multisig, rather than "the team wallet"
• who holds the keys, either named signers or a stated approval process
• a rule for how funds move, such as spending limits, a required number of approvals, or a vesting schedule on team allocations
• a link between the raise and the budget lines it is meant to cover

Stop signals

• Sale funds described only as going to the team.
• No entity named anywhere in the document.
• No spending plan, or a plan with no figures or priorities.
• A treasury described as controlled by the founder alone.
• Silence on what happens to the money after the sale closes.

Compare it with the sale page

Read what the sale page says the raise is for, then read the document's funding story. If one describes a product build and the other describes liquidity and listings, that mismatch is a signal worth writing down. A document that is vague about money is usually vague on purpose, and a later section rarely repairs it.

Pass condition

You can name who controls the funds and what the plan for them is, in one sentence, even though you have verified neither.

Minutes 7 and 8: team, backers and delivery record

The people check

Look for named individuals with a role attached: who writes the code, who runs the treasury, who handles the sale. A first name and a cartoon avatar is not a name. For each person, look for prior work you can open yourself: a public repository, a company page, a conference talk, a published paper. Then look for a contact route that is not an anonymous form, such as a named address, a personal site or a professional profile. A team page with roles and no way to reach anyone is a poster.

Reading backers

An investor list is a claim until the investor says the same thing. For each logo, check the investor's own site or announcement feed for a matching statement. A logo wall without a linked announcement is decoration.

Shipped versus planned

Ask the roadmap to separate what exists from what is intended. Something already delivered, even something small, tells you more than a calendar of future quarters. A roadmap that starts entirely in the future describes an idea-stage project. That is allowed, but it should raise your caution rather than your confidence.

Look for links to code, documentation or a live product, and open each one. Note whether it loads and whether the page matches the description.

Stop signals

• No named team anywhere in the document.
• Stock or generated portraits with no verifiable history behind them.
• An adviser list with no stated role or commitment.
• A roadmap with no dates and no completed items.

Pass condition

At least one named person whose history you can check, and a roadmap with something already done.

Minutes 8 to 10: three sources, one set of terms

This is the check that catches most of the problems a whitepaper can hide on its own: three sources, one set of terms. The document, the sale's entry on this site and the project's official site should describe the same sale. If the chain, the sale type, the dates or the cap differ between them, you have something to resolve before you read any further.

The order of the check

1. The document. Find the terms section and write four things down: chain, sale type, start and end dates, cap.
2. The sale entry. Open the same sale's page and read the same four fields.
3. The official site. Type the address yourself rather than following a link from a chat, a comment or an ad. Read the same four fields again.

Write the three answers side by side. The comparison is the point, not any single reading.

Two practice runs

Slop Cash. Open https://slop.cash/ and note what it states about the sale: stage, sale type, dates. Then read the same sale's entry at /presale/slop-cash-jkmotv, which records a live sale on the Umia platform, sale type ICM, running from 2026-11-05 to 2026-11-10. Nothing on that entry is estimated; each figure is shown as published. Your job is to see whether the site and the entry agree, and whether the document you hold says the same.

Mandala Chain. Repeat the three steps with https://token.mandalachain.io/ and the entry at /presale/mandala-chain-tci9ed, which records a live Public Sale with no start date announced. If the site or the document names a start date, that difference is exactly the kind of thing to note down and ask about.

What a mismatch means

A mismatch is a reason to stop and ask, not proof of anything. The usual causes are mundane: the document was updated and the sale page was not, a date moved, a chain migration was announced in one place only. Resolve it before you spend more time. A paper that has been revised while the sale page still shows the old terms is still a mismatch worth an answer.

If the read survives, the checks that follow are set out on /how-we-check. For context on where sales sit, browse /presales and /presales/ethereum, and for the shapes fake sale pages take, read /scam-alerts.

Once the document survives the first ten minutes, line its stated chain, dates and cap up against the sale's entry before reading further.

Red flags, the risk section and your stop rules

Read the risk section before anything else in the final minutes. A document that names its own risks, competition, dependence on partners, regulatory exposure, a product that may not ship in the form described, is easier to trust on everything else than one that lists none. Every project has risks. A paper with an empty risk section is telling you something about how it was written, not about the project's safety.

Red flags that end the read

Stop when you see any of these:

• A guarantee of profit, a price floor, or a stated return.
• A line calling the project "audited" with no auditor named and no report link.
• Pressure language about limited time or a closing window inside the document itself.
• A section that describes what the token will be worth rather than what it does.

That last one matters most. Price talk in a technical document is a substitution: the paper is selling the outcome instead of explaining the mechanism.

The audit line is a claim

"Audited" inside a whitepaper counts only when the auditor is named and the auditor's own report can be found on the auditor's site or channels. The check belongs with the auditor, not in the paper. A PDF can say anything; a published report is a separate artefact you can open and read.

Two copy checks

Pick one unusual sentence from the document, put it in quotation marks into a search engine, and see whether it appears in other projects' papers or in generic templates. If the same phrasing shows up elsewhere, the document was assembled rather than written.

Then compare its description of the product with the product on the official site. Boilerplate tends to describe a category ("a next-generation layer for X") rather than a working thing with named parts, users and a delivery history.

Set stop rules before you start

Decide in advance what ends the read: no named publisher, no product sentence, no token job, no fund control, no auditor behind an audit claim. Write them down before you open the file. A decision made mid-document is a decision made inside someone else's argument.

Presales are high-risk and can lose all of the money put in. None of this is financial, legal or tax advice.

The pass/fail scorecard, and when there is no whitepaper

Seven checks, one result each. There is no half mark: a document that almost names its publisher has not named its publisher.

Reading the result

One fail is a question to resolve before you go further. Two fails means you go back to the sale page and check what you might have misunderstood. Several fails end the read. This is not a score out of seven that can be averaged away: five passes do not carry a missing fund-control paragraph.

When there is no whitepaper

A litepaper is shorter, so the product sentence and the token job have to be clearer, not vaguer. If a shorter document says less than a longer one would, that is the finding.

A GitBook or docs site changes nothing about the checks, but adds two: who edits it, and when it last changed. A docs site updated this month reads differently from one untouched since launch.

A pitch deck was written for investors. Expect claims without method, and treat each number as something to verify elsewhere.

Nothing at all leaves no claim to check. That is a reason to stop, not a gap to fill with guesses.

The wallet rule

No document, litepaper, deck or sale page ever needs a wallet connection or a seed phrase to read. If a "read the whitepaper" button opens a connect prompt, close it and open the project's official site yourself.

A read that survives all seven checks is a start, not a green light. The checks that follow are on /how-we-check, and the fake-sale patterns are on /scam-alerts.

Put the two projects still on your list side by side on a PresaleWatch compare page and run the same ten minutes against each, so the decision rests on the same checks for both.

Frequently asked questions

What should a crypto presale whitepaper contain?

A useful presale whitepaper explains the problem, the product, how it works, and why a token is needed. It should describe token utility, supply and allocation categories, vesting and unlock mechanics in words, treasury or use of funds, the roadmap, and who is responsible for delivery. Look for named entities, official links, a version and date, and a risks section. Sale terms such as chain, sale type, start and end dates, price, cap and claim process should match the official sale page. A whitepaper that is only slogans, logos and price talk gives you little to check. None of this removes risk: a presale can lose all the money put in.

Can a whitepaper be faked or copied?

Yes. A whitepaper is a document, not proof of a company or a product. Common warning signs: the text is generic and could describe any project, the token name or ticker changes between sections, diagrams and wording look copied, there is no named team or legal entity, and the only contact is a social account or DM. Check version history, document date, links to the official site, and whether the same terms appear on the launchpad page. Be careful with links in ads and messages; open the official site yourself. Plagiarism or vague text is a reason to slow down, not a finding of fraud. Presales remain high-risk and can lose all money put in.

Does an audit mentioned in the whitepaper count as proof?

No. A line such as "audited by a leading firm" or an audit logo is a claim until you can open the report. A real report names the auditor, the scope, the code commit or version, the date, and the findings, including unresolved issues. Check the auditor's own site and the project's official documentation. An audit covers code, not the team's honesty, the token's demand, the sale terms or a listing. It also does not mean the token will trade or that you will recover your money. If no report is published, treat the audit claim as unverified. Presales are high-risk and can lose all of the money put in.

What if a presale has no whitepaper, only a litepaper or a GitBook?

Judge a litepaper or GitBook by the same tests: does it explain the product, the token's role, allocation and vesting in words, use of funds, roadmap, risks, and who is responsible? A GitBook can be detailed and updated, which is useful, but it can also change after you read it. Save a copy or note the version and date, and check whether the official site and launchpad page link to it. If the document is only marketing bullets, has no owner, or avoids token mechanics, treat that as a warning sign. It is not automatic proof of a scam, but it lowers what you can verify. Presales can lose all money put in.

How do I check a whitepaper against the sale page?

Open the official site yourself, then compare the whitepaper with the sale page line by line. Check the token name and ticker, chain, sale type, start and end dates, price and cap if stated, accepted currency, claim process, vesting and unlock terms, and official links. They should agree, and both should point to the same documents and team. Check the launchpad page too, because sale terms often live there. If a date, figure or wallet flow differs, stop and investigate. Never connect a wallet to "join" a sale, never share a seed phrase, and never send funds to a private address or a DM. Presales are high-risk and can lose all money put in.

Sources

• Slop Cash official site
• Mandala Chain token site
• Chainers official site
• eOracle official site