---
name: crypto-whitepaper-writer
description: Write a credible, well-structured whitepaper for any crypto/blockchain project (L1 chain, DeFi protocol, oracle network, stablecoin, token system) — grounded in the structural and rhetorical patterns of Bitcoin, Ethereum, Uniswap, Chainlink, and MakerDAO, not generic ICO-hype templates. Use whenever asked to draft, outline, or review a crypto/Web3 whitepaper.
---

# Crypto Whitepaper Writer

## Why this skill exists

Most AI-generated crypto whitepapers read like marketing decks: vague "revolutionary" language,
unbacked security claims, a roadmap standing in for proof, tokenomics as decoration. The five
most-cited whitepapers in the industry — Bitcoin, Ethereum, Uniswap, Chainlink, MakerDAO — share a
different discipline instead: problem-first framing, incremental mechanism-building, named threat
models, and per-actor incentive analysis. This skill encodes that discipline so the output reads
like engineering, not a pitch.

See `reference.md` for the full research base: archetype skeletons, craft principles, anti-patterns,
and the pre-publish checklist. Read it before drafting.

## Step 1 — Gather inputs before writing a word

Do not start drafting until you have, from the user:

- **The problem** this project solves, in one sentence, with a concrete scenario of what fails
  without it.
- **The project archetype** — the closest match in `reference.md` → Archetypes: base-layer
  consensus/settlement, DeFi mechanism (AMM/lending/derivatives), oracle/coordination network,
  stablecoin/collateral system, or application-layer protocol/token system.
- **The core mechanism** — what actually happens on-chain/off-chain, in enough detail to describe a
  state transition or formula, not just a feature list.
- **Token existence and role** — if a token exists, what specific mechanical function does it serve
  (fee payment, collateral, staking/slashing, governance weight)? If the project doesn't need a
  token, say so explicitly rather than inventing tokenomics to look complete.
- **Known limitations / open risks** the team is willing to state honestly.

If any of these is missing or vague, ask before drafting — never fabricate a problem statement, team
background, adoption numbers, or token model to fill a gap.

## Step 2 — Pick the section skeleton, calibrate length

Match the archetype to its skeleton in `reference.md`. Don't force every whitepaper through an
identical template — Bitcoin has no tokenomics section; MakerDAO has no proof-of-work security proof.
Use the shared spine (problem → mechanism → actor/incentive analysis → threat/risk model →
architecture → [governance/token, only if applicable] → limitations → conclusion), and cut whatever
doesn't apply to this project.

Length follows mechanism complexity, not a fixed page count — Bitcoin proves its point in 9 pages;
MakerDAO needs far more because it coordinates more actors and failure modes. Let each section run as
long as the idea needs and no longer (anti-pattern: forced symmetry). If the project has a token or
makes any financial/return-implying claim, include a short disclaimer (Uniswap's precedent) stating
the document is not investment advice.

## Step 3 — Draft section by section, applying the craft principles

Work through `reference.md`'s craft principles as each section gets written. The ones that matter
most in practice:

- Open with a failure scenario, not a mission statement.
- Build the mechanism from a minimal model upward — don't state the final design cold.
- Every security or performance claim gets a number, threshold, or named proof — never an adjective
  alone ("highly secure" is not a claim).
- Every incentive-driven actor (miner, LP, oracle node, keeper, validator) gets its own paragraph
  naming exactly what they earn and what punishes defection.
- Name specific attack vectors and pair each with its specific countermeasure.
- Include at least one worked, traceable example — a transaction walkthrough, a numeric calculation,
  a step-by-step lifecycle.
- If this design revises or extends a known predecessor, write it as an explicit delta (what changed
  and why), not a from-scratch re-explanation.

## Step 4 — Run the anti-pattern filter before showing a draft

Scan against `reference.md`'s anti-pattern list. Any hit is a reason to rewrite the line, not soften
it: price predictions or market-cap claims, unverifiable team/advisor credentials used as an
argument, roadmap phases presented as proof of viability, a tokenomics table with no stated
mechanical purpose, novelty claimed without naming what came before, a security claim with no threat
model behind it, a missing limitations section, buzzwords substituting for a mechanism description.

## Step 5 — Self-check and disclose gaps

Before finalizing:

- Confirm every numeric or technical claim traces to something the user provided or a cited external
  source — flag anything you inferred rather than were told.
- Confirm a limitations/risks section exists and isn't hollow.
- Run `reference.md`'s pre-publish checklist and state the result (pass/fail per item, or a
  self-rating) to the user before calling the draft done — don't ship a whitepaper without surfacing
  what's unresolved.

## Output format

Markdown, sections matching the chosen archetype skeleton, an abstract at the top, references/sources
at the bottom if external material was used. No emoji, no bolded label scaffolding (`Problem:`,
`Solution:`), no forced symmetry between sections — a simple idea gets a short section, a hard one
gets a long one, exactly as the five reference papers do.

Cite every external claim (a cryptographic primitive, a competitor's known limitation, a market fact)
inline with a bracketed marker (e.g. `[1]`) resolving to a numbered reference list at the end — never
assert an outside fact with no traceable source. See `reference.md` → Calibration examples for what a
compliant vs. non-compliant sentence looks like before you draft the real thing.