N5 · Crypto Founder
Resolve demand, mechanisms, business, safety, and treasury before deciding on tokens. Produce two documents others can challenge.
This track serves founders.
It starts from Chapter 30: prove people use it without a token before deciding to issue one. Proof is an executable test. Perform it and document the results in two files open to detailed questioning.
This track provides no legal, fundraising, or investment advice. It teaches explicit assumptions, identifying the weakest one, and adapting when assumptions change. Consult professionals for specific legal and tax arrangements.
Who This Track Serves
You ask when to launch a token. Chapter 30's three founders used the same words for three fundamentally different questions. Identify yours first.
Your launched product attracts registrations but few repeat users. You consider tokens or points to bring them back. Expect an uncomfortable diagnosis and a concrete alternative.
You have real users and face token-launch questions. This is the strongest position: something real exists to allocate. Explain the token's mechanism responsibility beyond competitors having one.
Your pitch discusses vision everywhere and business nowhere. Revenue, costs, treasury, risks, and exits are missing.
You build a tool but are pressured to describe a network. Learn to diagnose the difference and recognize tools as viable businesses.
Prerequisites
This track has the most prerequisites because founders need some understanding of every function. Complete nine Part A chapters.
| Required chapter | Role here | Consequence of omission |
|---|---|---|
| Chapter 9 · Smart Contracts | Composition, upgrades, permissions | Treat permissions as implementation details |
| Chapter 15 · Liquidity | Depth, experience, exits | Missing cold-start constraint |
| Chapter 20 · Tokenomics | Value-capture connection | Profits unrelated to holders |
| Chapter 24 · Collapse and Attacks | Code, economic, human risk | Safety postponed until expensive to change |
| Chapter 25 · Project Review | Thirteen cells and sources | Unclear sector position |
| Chapter 26 · Protocol Revenue | Income statement, take rate, treasury | No business in the pitch |
| Chapter 27 · Crypto Product | Constraints and failures | Invalid Web2 assumptions |
| Chapter 28 · Crypto Growth | Funnel and farming arithmetic | Spending on acquisition without retention |
| Chapter 30 · Finding PMF | Backbone: three project types, four token questions, four demand signals, four cold starts | No framework for later work |
Complete two practical exercises: Chapter 30's payer, chain necessity, and token-free viability Lab, and conversations with five real people without presenting your solution after the first two questions. Skipping conversations makes everything afterward self-confirmation.
What You Will Learn
Eleven topics form five groups. Order follows company decisions rather than pitch-deck chapters.
- Demand
- Mechanism design
- Business
- Organization and funding
- Safety and compliance
| Group | Topics | Problem addressed | Connecting chapters |
|---|---|---|---|
| Demand | Market, PMF | Who genuinely suffers and how you know | 25, 30 |
| Mechanism design | Protocol Design, Token Design | Rules and token responsibilities | 9, 20, 30 |
| Business | Business Model, Treasury | Payers, retained revenue, runway | 26 |
| Organization and funding | Fundraising, Team, Growth | Funding, people, sustainable growth | 26, 28, 29 |
| Safety and compliance | Security, Compliance | Prevention and responsibility | 24 |
Three Frequently Mishandled Tasks
Before token design, ask whether it operates without a token. Chapter 30 distinguishes necessity, accelerator, and disguise; necessity is rarer than people think. Remove all token references: a broken mechanism suggests necessity; a slower viable product, acceleration; nothing remaining, a demand problem tokens cannot solve.
Business outputs a table rather than a story. Fill Chapter 26's income statement: user payments, your share, incentives, and net. Add treasury assets, runway, and authority. Not knowing whether net is positive means not knowing your position.
Safety and compliance begin during design. Economic and human risks largely arise from liquidation parameters, oracle dependencies, upgrades, multisigs, and custody. Changes after coding often cost enough that teams avoid them. Record custody, withdrawal, responsibility, and dependent assumptions before someone asks.
Apply Chapter 30's four questions to why a project needs—or does not need—a token.
Can it operate without one; whom does it motivate to do something new; what substitutes over twelve token-free months; what remains after a 90% fall? The order matters: if it runs without one, ask why issue at all.
Ask what happens if a company pays participants cash. Higher costs alone imply acceleration. Lost censorship resistance and continuity essential to users imply necessity. This filters most self-proclaimed necessities.
A prewritten validation threshold whose failure disproves an assumption.
This is Chapter 30's hardest and most valuable row. Without failure criteria, every result becomes hopeful.
Start with a measurable eight-week success target, then ask below what level you would admit the direction is wrong. No answer means validation was never intended to guide decisions.
Final Deliverable
A pitch deck and token-necessity case, including a no-token plan.
The no-token plan is mandatory, establishing whether your token is necessary, accelerative, or disguising missing demand.
Distinguish this from the Capstone Project. It studies someone else's project; this studies your own. Skepticism toward others becomes self-defense toward yourself. Half the acceptance criteria test equal standards.
Five acceptance criteria:
Every pitch number has definition and date; onchain figures are reproducible.
Specify user layer, gross payments versus protocol share versus post-incentive net, and valuation definition. Remove unreproducible numbers or mark source and uncertainty.
Answer all four token questions; the third requires a concrete plan.
For twelve token-free months, choose a cold start: supply the first side yourself, serve an existing pain group, integrate into another distribution channel, or incentivize with cash. A small beta is postponement rather than a plan.
Provide an executable twelve-month no-token plan with budget, milestones, and failure criteria.
It must stand independently of token prices, airdrops, and points. If the project remains viable, the token accelerates rather than enables it. Record that discovery.
Explain what product, users, and revenue remain after a 90% token decline.
This separates product from speculation. No describable foundation suggests a speculative asset. Compare it with the pitch's most optimistic slide to expose dependencies.
Include ten risks, one compliance-assumption page, and one treasury page.
Use Analysis Toolkit risk categories and explicit nonassessment. Explain custody, independent withdrawal, responsibility, assumptions, and what changes when assumptions change. Treasury covers assets, current runway, and spending authority.
Assess Your Readiness
Ready: a 300-word description without token, airdrop, incentives, or governance still explains existence and why the first payer pays.
A broken mechanism suggests necessity; a slower viable product, acceleration; nothing, disguise.
For disguise, return to demand, rather than token design. Tokens temporarily hide a lack of need, usually for twelve to eighteen months.
Ready: three people outside friends, colleagues, and a single company.
Otherwise later discussions lack foundations. Most founders are stuck at step one while believing they are stuck at step three.
One-company paying users mean one customer rather than PMF. That can be useful, but classify it correctly. Seek unrelated second and third sources. If losing that company eliminates revenue, you currently have outsourced work rather than a product.
Ready: return rates for non-incentivized paying addresses in a genuinely incentive-free window, measured strictly.
It may be uncomfortably small, but it is honest. A team without this number cannot assess its position.
If incentives never stop, reserve a permanently unincentivized observation area as your clean sample.
Ready: explain contract, multisig, or account custody, authorized parties, signature threshold, timelocks, and loss allocation across typical incidents.
This spans safety, compliance, and product. Permissions often determine consequences more than code and become expensive to change after implementation.
“We will audit” is insufficient. Audits check implementation against intent; they do not choose intent.
No standard answer; check:
- How many pages explain revenue, costs, treasury, and exits versus vision?
- Which token answer is weakest? Usually the second: whom does it motivate, and do you need that behavior?
- Does the token-free plan include budget and failure criteria rather than milestones alone?
- Are post-collapse foundations already present or merely planned?
- How many risks remain unassessed? Zero often indicates superficial work.
- Does compliance specify custody, withdrawal, and changed assumptions rather than generic promises?
- Does your most avoided question appear?
Chapter 30's AI Lab asks user, investor, and regulator personas for three challenges each. Allow only two answer forms: verified claim with evidence, or unverified claim with method and deadline. Exclude “we will solve it.” The number of verified responses among nine measures current validation.
Common Mistakes
Mistake one: token issuance as fundraising and growth.
“Issue first, then build with money and users” reliably attracts addresses, community, and attention briefly.
It turns an unverified hypothesis into a priced asset. Attention shifts from utility to price defense, often conflicting with product needs. Distribution, unlocks, and expectations become politically expensive to change.
Find real payers → retain them without rewards → prove scale improves utility → decide on a token. The first three require none. Early issuance can work when demand is already understood; otherwise it purchases a harder-to-reverse position rather than time.
Mistake two: assuming network effects.
A pitch claims strong effects even though ten thousand users offer no more value per user than one hundred.
Does a hundredfold user increase improve value per user? If not, you have a tool rather than a network.
This useful diagnosis removes the need to subsidize network formation, supports linear growth, and suggests charging fees. Calling a tool a network may aid fundraising, but induces useless or harmful network-style decisions.
Real effects arise from liquidity (easy to move), integrations (durable because replacing requires code changes), and assets/standards (durable but hardest to establish).
Mistake three: postponing security and compliance until launch.
Audits and legal questions begin after product and token design.
These are largely design decisions: liquidation, oracles, upgrades, multisig thresholds, unilateral fund movement, and user control after your disappearance. Late changes are often avoided because of cost.
Use Chapter 24's risks as design inputs and compliance as a maintained document. Record assumptions and required adaptations.
Mistake four: treating uncertainty as no risk.
Generic contract, market, and regulatory risks fit every project.
They supply little information. Risk quality depends on honest nonassessment rather than list length.
Assess each category with evidence or explain why it remains unassessed. Explicit blind spots survive serious diligence better than apparent perfection.
Next Steps
Complete three tasks: all six steps of Chapter 30's Lab (including five conversations), Chapter 26's income statement, and Chapter 24's risk assessment. These supply both documents' raw material.
Apply the Capstone Project's Research OS to your own project. Equal research standards make this effective and uncomfortable.
Maintain two resources: Analysis Toolkit questions and risks before major decisions, and Finding Genuine Interest in Crypto. Founding outlasts cycles; price-dependent motivation does not.
Compatible tracks:
| Combination | Why it fits |
|---|---|
| N2 · Crypto Product | Founders initially own product; N2 supplies the first document |
| N4 · Crypto BD & Ecosystem | Early founders handle integration, developers, and grants without tokens |
| N1 · Crypto Research & Investment | Both begin by judging whether a project deserves to exist |
| N3 · Crypto Growth & Operations | Unsubsidized demand signals assess both growth and PMF |
If you code, extend toward T5 · Security Engineer. Read T28, T29, and T30 before writing your first contract. Threat modeling belongs in design.