Claude × Crypto — 5 Whitepaper Teardown Frameworks (200K Context Power Plays)

1. Why Claude for whitepaper teardowns #

For whitepaper work, what matters is fitting the whole document into context without chunking, so the tokenomics table up front and the vesting details further back can be checked against each other. Check each vendor's official docs for context-window sizes. As for which model holds detail better on your material, run the same whitepaper and the same questions through each one yourself and keep the raw outputs before you decide.

2. Framework #1 — Six-axis whitepaper teardown #

This is the baseline. Every project starts here. Upload the PDF directly to Claude — Sonnet 4.5 is more than enough.

Prompt template:

The attached PDF is the whitepaper for [PROJECT NAME].
Tear it down along the six axes below.

For every axis, use the format: "Quote from the whitepaper → your read."
If something is not stated in the document, mark it "not stated in the whitepaper" — do NOT fill in the gap with general knowledge.

1. Problem statement: what does the project claim to solve? One sentence, in their words.
2. Technical approach: what tech do they use, and how is it different from what already exists?
3. Tokenomics: token utility, total supply, initial allocation.
4. Unlock curve: vesting schedules for team / investors / community.
5. Roadmap: key milestones in the next 12 months, and what has already been delivered.
6. Risk section: what risks does the whitepaper itself disclose?

Final step: list the five things the whitepaper SHOULD have addressed but did not.

That last line — "should have but didn't" — is where most of the alpha lives. Blind spots worth checking for:

• Validator hardware and economic requirements (i.e. how decentralized this actually is)
• Bridge fund-safety model (usually papered over with a vague "audited")
• Whether the team has any disclosure commitments around selling their unlocked tokens
• What the governance path looks like if a mainnet upgrade fails

3. Framework #2 — Tokenomics unlock-pressure model #

Whitepaper unlock curves are almost always described in prose, which makes "which months actually hurt" impossible to eyeball. Pair Claude with Artifacts and it will draw the chart for you.

Prompt template:

Based on the vesting schedule on pages X–Y of the attached whitepaper:

Build a 36-month token-release table with these columns:
- Month (1–36)
- Team unlock (% of total supply)
- Investor unlock
- Ecosystem fund unlock
- Community rewards release
- Total new monthly float
- Cumulative circulating supply (%)

Then, using that table, answer:
1. Which 3 months carry the heaviest unlock pressure, and from which tranche?
2. Holding price flat, the USD value unlocked each month (assume FDV = $X).
3. Which months see unlocks greater than 5× the chain's recent average daily volume (i.e. mechanical sell pressure)?

Finish with a markdown table plus a 36-month bar chart (Artifacts).

The chart is the point. A cliff structure — fully locked for 12 months, then a one-shot team release in month 13 — can be buried in a single sentence of a whitepaper, but once it is drawn as a bar it is impossible to miss.

4. Framework #3 — Audit report vs. on-chain contract diff #

This is where 200K context actually flexes: feed the whitepaper, the audit report, and the deployed .sol source from Etherscan into the same conversation. Drag the .sol files in directly.

Prompt template:

I am giving you three attachments:
- Attachment 1: the whitepaper PDF
- Attachment 2: the audit report PDF (CertiK / OpenZeppelin / Halborn)
- Attachment 3: the .sol source code actually deployed on mainnet

Run a three-layer diff:

Layer 1 — Contract permissions as described in the whitepaper vs. permissions reviewed in the audit report vs. modifiers in the actual source.
- Are they consistent? Where do they diverge?

Layer 2 — Audit issues marked "Acknowledged but not fixed."
- For each: title, severity, the team's response, and whether the issue still exists in the deployed version.

Layer 3 — Admin functions in the source.
- List every onlyOwner / onlyAdmin / emergency-pause function.
- Which ones have a timelock and which do not.
- Multi-sig N-of-M configuration, if visible in code.

Do NOT give me a "this project is safe / unsafe" verdict. I want the fact list. I will judge.

That last line matters. An AI verdict on "is this project safe?" is worthless — the value is in the fact list. You take the facts, you make the call.

5. Framework #4 — Team reverse background check #

Paste in the team's LinkedIn screenshots, their previous project pages, their Twitter history, their Crunchbase entries — whatever you can find. Gather the material yourself first — clear sources make the checking easier.

Prompt template:

I am giving you publicly available info on five core team members of this project (LinkedIn summaries + Twitter history + previous project pages).

Output:

1. Per-member timeline:
   - Publicly claimed history vs. independently verifiable history (flag any inconsistency).

2. Fate of previous projects:
   - Still running? Acquired? Shut down? Rugged?
   - Time from launch to shutdown / acquisition.

3. Red-flag list:
   - Past SEC actions, community complaints, contract exploits.
   - Members simultaneously listed on 2+ active crypto projects.
   - Visible contradictions between their LinkedIn and their Twitter self-description.

4. Suggested follow-up keywords I should search to cross-verify.

Do NOT conclude "the team is trustworthy / not trustworthy." Just give me the structured facts.

Claude's strength here is cross-referencing horizontally — five resumes laid side by side. It will catch things like "three of them claim to have worked at the same company but their tenures never overlap," which is exactly the kind of thing the human eye glides over.

6. Framework #5 — Competitor matrix #

Last one. Use this after you have finished single-project work — drop three to five whitepapers from the same sector into Claude in a single turn.

Prompt template (Opus recommended):

Attached are the whitepapers for four projects in the same sector (A / B / C / D).
Build a comparison matrix with these columns:

- Consensus mechanism
- Mainnet launch date
- Current TVL (I will paste DefiLlama numbers separately)
- Team token allocation + end of unlock
- Investor vs. community allocation ratio
- Development activity over the last 6 months (GitHub commit cadence — I will provide)
- Number of audits + audit firms
- Whitepaper page count and writing rigor (your subjective grade)
- One-line unique positioning

Then answer:

1. Of the four, which tokenomics design is most retail-friendly?
2. Which project shows the largest gap between roadmap promise and actual delivery?
3. Which whitepaper most obviously prioritizes marketing language over technical detail?

Finally, list the fields you could NOT fill in from the whitepapers alone — i.e. where you need external data.

That final line is critical. By default the model will brute-force every field even when the source is silent. Forcing it to admit "insufficient data" is what keeps you out of the trap of making decisions on values the AI invented.

7. What Claude cannot do #

Before using Claude for crypto DD, know these limits:

Limit 1 — Don't trust live numbers at face value. Any "current TVL," "last 7 days of price," or "real-time contract balance" it gives you, unless it comes from material you pasted in or a web source it explicitly cites, may be a stale value from training data — or simply made up. Fetch live data yourself and paste it in.

Limit 2 — It will still occasionally mis-align numbers inside a long document. Say the allocation table up front and the vesting detail further back give two different team percentages: the model may output one of them without flagging the contradiction. The fix: cross-check critical numbers against the source yourself, and when in doubt ask Claude to list "every page where this number appears in the whitepaper."

Limit 3 — Anything that smells like leverage/derivatives triggers a wall of disclaimers. Asking "how do I run a 3x leveraged structured trade" gets you a paragraph of "this is not advice" that buries the signal. Reframe: instead of asking for a recommendation, hand Claude a position and ask for analysis — "assume I already hold position X; analyze its exposure if BTC drops 10%." Switch the model from "advisor" to "analyst."

Limit 4 — The free tier is tighter on usage. Upload a whole whitepaper and follow up over several turns, and the free plan can hit its usage cap; in long conversations the model may also start "forgetting" earlier material. Long-document DD is better done on a paid plan — check Anthropic's official pages for the actual limits.

Browse the full Prompt Library →

8. FAQ #

Q1 — Is Claude better than ChatGPT for crypto project analysis?

For long-document teardowns, yes — 200K context fits the whitepaper, the audit, and the team's tweets all at once. The trade-off: don't take live numbers on faith — have it search and cite sources, or paste the data in yourself. For ordinary back-and-forth chat the two models are roughly even.

Q2 — Sonnet or Opus for whitepaper analysis?

Sonnet 4.5 handles most of the work, and on the official price list it costs less than Opus 4.5 ($3 vs $5 per million input tokens). Use Opus 4.5 for heavy multi-variable reasoning — e.g. five projects compared simultaneously with assigned tokenomics risk grades.

Q3 — Will Claude refuse to discuss crypto projects?

Structural questions, tokenomics, technical details — fine. What Claude refuses is "will token X pump?" and "recommend a leverage strategy." That refusal is a feature: it stops the model from generating confident-sounding noise.

Q4 — Can I run automated analysis through the Claude API?

Yes. Anthropic's API is priced per token. Sonnet 4.5 input runs roughly $3 per million tokens; a 200K input pass costs about $0.60. Batching 50 projects of due diligence overnight comes in under $50.

Q5 — How do I build a crypto-specific workflow in Claude Projects?

In Claude.ai, create a Project and put your "crypto DD framework," your "blacklist of common project-team marketing phrases," and your own risk tolerance into the Project Instructions. Upload the whitepaper for each new project — the framework auto-applies. Reuse across analyzes.

PromptDeck · 2026-05-15