N5 · Crypto Founder
在决定发不发 Token 之前，先把需求、机制、生意、安全与金库全部想清楚，并且写成两份别人能反驳的文件。
这条 Track 的对象是创业者。
它的起点是第 30 章那句话：先证明没有 Token 也有人用，再决定要不要发 Token。 关键在「证明」两个字——它不是一种态度，是一个可以被执行的检验。这条 Track 的全部工作，就是把这个检验做完，并且把结果写成两份可以被别人逐条追问的文件。
另外先说明：这条 Track 不提供法律意见，也不提供任何形式的融资或投资建议。它教的是怎样把自己的假设写清楚、怎样知道哪一条最脆弱、以及在假设变化时该改什么。 涉及具体法律与税务安排的部分，找专业人士。
这条 Track 适合谁
你在问「我们什么时候发币」。 第 30 章开头那三个创始人里，你是其中一个。这条 Track 的第一件事，就是帮你判断你问的到底是哪一个问题——因为在三种情况下，同一句话是三个完全不同的问题。
你的产品上线了，注册地址不少，但几乎没人第二次回来。 你正在考虑用代币或积分把人吸引回来。这条 Track 会给你一个不太舒服的结论，以及一个具体的替代动作。
你有一批真实用户，正在被问要不要发币。 你的情况是三种里最好的一种——你有一个真实的资产可以分配。但你需要说清楚这个代币承担什么机制职责，而不只是「竞争对手都发了」。
你在写融资材料，发现每一页都在讲愿景，没有一页在讲生意。 收入、成本、金库、风险、退出，这五件事你的材料里缺了三件。
你在做的是工具，但一直被要求讲成网络。 这条 Track 会给你一个诊断方法，以及一个「工具也是好生意」的路径。
前置
这条 Track 的前置最多，因为创始人是唯一一个每个职能都要懂一点的角色。Part A 有九章必须读完。
| 必读章节 | 它在这条 Track 里承担什么 | 缺了它会怎样 |
|---|---|---|
| 第 9 章 · Smart Contract 改变了什么 | 可组合、可升级与权限结构 | 协议设计里把权限当成实现细节 |
| 第 15 章 · 流动性 | 深度决定体验，也决定能不能退出 | 冷启动方案缺了最关键的一项约束 |
| 第 20 章 · Tokenomics | 价值捕获那根连线在不在 | 设计出一个赚钱但持有人无关的代币 |
| 第 24 章 · 归零与攻击 | 十类风险、三层（代码、经济、人） | 把安全推迟到审计前，那时候已经改不动了 |
| 第 25 章 · 30 分钟读懂一个项目 | 十三格与来源等级 | 看不清自己在赛道里的位置 |
| 第 26 章 · Protocol 靠什么赚钱 | 损益表五行、抽成率、金库三问 | 融资材料里没有一页是生意 |
| 第 27 章 · Crypto Product | 三个约束与失败路径 | 产品决策里带着不成立的 Web2 前提 |
| 第 28 章 · Crypto Growth 的本质 | 五层漏斗与撸毛算术 | 把预算堆在接不住人的漏斗上 |
| 第 30 章 · 如何找到 PMF | 这条 Track 的主干：三类项目、Token 必要性四问、去补贴化四信号、四条冷启动路径 | 后面所有内容都没有挂靠点 |
两个 Lab 必须真的做过：第 30 章的「谁付钱、为什么非链上不可、没有 Token 能不能成立」，以及它里面那一步——去和五个真实的人对话，而且在前两问之后不许介绍自己的方案。 这一步跳过，这条 Track 后面的所有内容都会变成自说自话。
你会学什么
十一个主题，分成五组。顺序就是一家公司真实的决策顺序，不是融资材料的章节顺序。
- 需求
- 机制设计
- 生意
- 组织与资金
- 安全与合规
| 分组 | 包含的主题 | 这一组要解决的问题 | 从哪一章接上 |
|---|---|---|---|
| 需求 | Market、PMF | 谁在真的难受，我怎么证明不是我自己想的 | 第 25、30 章 |
| 机制设计 | Protocol Design、Token Design | 规则怎么写，以及 Token 到底承担什么职责 | 第 9、20、30 章 |
| 生意 | Business Model、Treasury | 谁付钱、留下多少、能撑多久 | 第 26 章 |
| 组织与资金 | Fundraising、Team、Growth | 拿谁的钱、找什么人、怎样增长而不透支 | 第 26、28、29 章 |
| 安全与合规 | Security、Compliance | 出事之前先想清楚，出事之后谁负责 | 第 24 章 |
这五组里最容易被做错的三件事
机制设计这一组，要先回答「去掉 Token 还跑不跑得起来」，再谈设计。 第 30 章把项目分成三类——必需品、加速器、伪装，而第一类比大多数人以为的要少。识别方法只有一个动作：把 Token 从项目描述里全部删掉，把剩下的读一遍。剩下一个跑不起来的机制是必需品；剩下一个更慢但成立的产品是加速器；什么都不剩，那么问题不在代币设计上，代币也不会解决它。
生意这一组的产出是一张表，不是一段故事。 第 26 章那张损益表五行要能填满：用户付了多少、归你多少、激励支出多少、净额是多少。再加金库三问：里面是什么资产、够用多久、谁有支配权。一个说不出自己净额符号的团队，对自己的处境其实是没有判断的。
安全与合规这一组，必须在设计阶段就开始，不能等到上线前。 第 24 章那三层——代码、经济、人——里，后两层几乎全部是设计决策：清算参数、预言机依赖、升级权限、多签结构、资金托管路径。这些东西在代码写完之后再改，成本高到大多数团队会选择不改。 合规同理：把你的合规假设写成一份清单（资金由谁保管、用户能不能取回、出事谁负责、这些假设依赖什么条件），比等到有人来问时再临时找答案要便宜得多。
用第 30 章那四问，逐条写出为什么这个项目需要（或者不需要）代币。
四问是：去掉 Token 跑不跑得起来、谁会因为它做一件本来不做的事、没有它的这 12 个月用什么代替、Token 跌 90% 还剩什么。顺序是有意的：第一问答「跑不起来」时，第二问才有意义；答「跑得起来」时，问题就变成了「那为什么要发」。
必需品那一类有一个好用的检验：问「如果由一家公司用现金支付这些参与者会怎样」。答「成本高一点而已」，是加速器；答「那抗审查性和持续性就没了，而那正是用户来这里的原因」，是必需品。这个检验能滤掉绝大多数自称属于必需品的项目。
一个验证方案里预先写好的、达不到就说明假设错了的那条线。
它是第 30 章那个 Lab 里最难写、也最有价值的一行。原因很直接：一个没有失败标准的验证方案，无论跑出什么结果都会被解释成「有希望」。
写它的时候有一个技巧：先写成功标准（一个 8 周内能测到的数字），再问自己「低于多少我会承认这个方向错了」。如果这个数字写不出来，说明你本来就不打算用这次验证来做决定。
毕业作品
一份融资材料加一份 Token 必要性论证（含「不发 Token」的方案）。
括号里那半句是这件作品的重心。「不发 Token」的方案不是一个备选项，它是必答题——因为只有写完它，你才知道代币在你这里到底是必需品、加速器还是伪装。
和毕业项目的区别。 毕业项目要求你完整研究一个别人的项目，它证明的是判断力。这条 Track 的作品对象是你自己的项目，而它最难的地方恰恰在这里：研究别人时你会本能地怀疑，研究自己时你会本能地辩护。这份作品的验收标准，有一半是在检验你有没有对自己用同样的标准。
验收标准五条：
融资材料里每个数字有口径与取数时间，链上数字可复现。
用户数要说明是四层里的哪一层；收入要说明是用户支付总额、归协议的部分，还是扣掉激励后的净额；任何引用的估值口径要说明是哪一种。做不到复现的数字删掉，或者明确标注来源与不确定性。
Token 必要性四问逐条回答，第三问必须是具体方案。
第三问「没有 Token 的这 12 个月用什么代替」，答案要落到四条冷启动路径中的一条：自己当第一边、服务一个已有的痛苦群体、做零件接进别人的分发、用现金而不是代币做激励。「先小范围内测」不是方案，是延期。
「不发 Token」方案是一份可执行的 12 个月计划，含预算、里程碑与失败标准。
它要能独立成立：不引用任何代币价格、任何空投预期、任何积分。如果这份计划写完之后你发现项目仍然成立，那么你的代币是加速器，不是必需品——这是一个重要的发现，要写进论证里。
单独一节写「Token 跌 90% 之后剩什么」，产品、用户、收入各剩多少。
这一节逼你把产品和投机品分开。底盘写不出来，说明这个项目目前是后者。 另外这一节和融资材料里最乐观的那一页放在一起看，会暴露出很多平时看不见的依赖。
附风险十类、一页合规假设、一页金库。
风险按分析工具箱的十类逐条写，评估不了的标「未评估」。合规假设那一页写清楚：资金由谁保管、用户能不能自主取回、出事之后责任怎么划、这些安排依赖哪些假设、假设变化时你要改什么。金库那一页回答三问：里面是什么资产、按当前消耗还能撑多久、谁有支配权。
怎样判断自己达标了
达标的表现是：你写过那份不含「代币」「空投」「激励」「治理」任何一个词的 300 字描述，读完之后这个项目仍然有存在的理由，而且第一步那个付费的人仍然会付钱。
三种结果对应三类项目：剩下一个跑不起来的机制是必需品，剩下一个更慢但成立的产品是加速器，什么都不剩是伪装。
第三种是这条 Track 真正想帮人避开的一类。识别它之后正确的动作不是改代币设计，是回去解决需求问题——因为代币在这里的作用只是让「没有人特别需要」这件事暂时不那么明显，而这个「暂时」通常是 12 到 18 个月。
达标的表现是：能，而且这三个人不是你的朋友或同事，也不来自同一家公司。
说不出来，那么第二、三、四步的所有讨论都还没有地基。第 30 章那句经验值值得贴在墙上：绝大多数人卡在第一步，而且会以为自己卡在第三步。
还有一个相关的检查：如果你找到的付费用户全都来自同一家公司，那不是 PMF，那是一个客户。它不是坏消息，但它需要被正确对待——立刻去找第二个和第三个完全不相关的来源，并且问一句「如果这家公司明天消失，我的收入还剩多少」。答案是零，那么你现在做的是外包项目而不是产品。
达标的表现是：你知道这个数字，而且它是按严格定义测的——只统计完成过非激励付费交互的地址，在完全没有激励的时间窗口里的回访率。
这个数字通常小得让人难受，但它是唯一一个不会骗人的数字。一个团队如果不知道这个数字是多少，那它对自己的处境其实是没有判断的。
如果你从来没有一段没有激励的时间，那就从现在开始留一块观察区：永远留一部分功能不给任何激励，那里的数据是你唯一干净的样本。
达标的表现是：你能一句话说清资金的托管路径（在合约里、在多签里、还是在某个账户里），说出谁有权限动它、需要几个人同意、有没有时间锁，以及在几类典型事故下损失分别落在谁头上。
这一条同时属于安全、合规和产品。第 24 章那十类风险里，真正会决定一次事故后果的通常不是代码那一层，是权限那一层——而权限结构是设计决策，写完代码再改成本极高。
不达标的表现是「我们会做审计」。审计检查的是代码实现是否符合意图，它不会替你决定意图。
没有标准答案，检查这几件事：
- 你的融资材料里，有几页在讲生意（收入、成本、金库、退出），有几页在讲愿景？
- Token 必要性四问里，哪一问你答得最虚？通常是第二问——谁会因为 Token 做一件他本来不做的事，而且这个行为你真的需要吗？
- 「不发 Token」的 12 个月计划，有预算和失败标准吗？还是只有里程碑？
- 你的「跌 90% 还剩什么」那一节，剩下的东西是已经存在的，还是计划中的？
- 风险十类里，你标了几条「未评估」？零条通常说明没有认真评估。
- 合规假设那一页，写的是「我们会遵守相关规定」，还是具体到「资金由谁保管、用户怎么取回、假设变了改什么」？
- 你最回避的那个问题是什么？它在这两份文件里出现过吗？
第 30 章那个 AI Lab 给了一个好用的练法：让模型分别扮演用户、投资人、监管视角各提三个质疑，回答时只允许用两种句式——「我们已经验证了某事，依据是某某」，或者「我们还没有验证某事，计划用某方式在某时间前验证」。不允许出现第三种：「我们会解决这个问题」。九条里第一种句式占几条，就是你目前的验证程度。
常见误区
误区一：把发币当成融资手段和增长手段。
表现是「先发币，有了钱和人再做产品」。短期内它一定有效——地址数、社群、媒体关注全部立刻到位。
它错在把一个待验证的假设变成了一个已经定价的资产。资产一旦被定价，团队的注意力就会从「怎么让产品更有用」转向「怎么让价格别跌」，而这两件事需要的行动完全不同，并且经常冲突。更麻烦的是它不可逆：分配、解锁和预期都固定下来了，改起来的政治成本极高。
正确的做法是把顺序摆回来：找到真实付费的人 → 做到没有激励也回来 → 证明规模化会更好用 → 再决定要不要发 Token。 前三步都可以在没有 Token 的情况下完成。要补一句：这不是说先发币一定错，而是说先发币的项目必须在发币之前就对需求有把握——否则它买到的不是时间，是一个更难回头的位置。
误区二：默认自己有网络效应。
表现是融资材料里写着「具有强网络效应」，而实际上用户从一百个变成一万个时，对单个用户的价值没有变化。
它错在把规模当成了网络。一个检验就够了：用户数增加一百倍，对单个用户的价值有没有提升？ 没有提升，那它是一个工具，不是一个网络。
这不是坏消息，这是一个非常重要的诊断结果——它意味着你不需要用代币去补贴网络启动、你的增长可以是线性的、你的商业模式应该是收费。很多团队在这个诊断上说谎，因为「网络」比「工具」更容易融到钱，代价是他们会按网络的逻辑去做产品决策，而这些动作对一个工具毫无帮助，甚至有害。
顺带一提，Crypto 里真实的网络效应有三个来源，牢固程度差别很大：流动性（最常被声称，也最容易被撬走）、集成（最牢固，因为替换需要对方改代码）、资产与标准（最牢固但最难建立）。
误区三：把安全和合规留到上线前。
表现是产品设计、代币设计全部做完之后，才开始找审计、才开始问法律。
它错在这两件事里绝大部分是设计决策而不是检查项。清算参数怎么设、预言机依赖谁、升级权限归谁、多签几个人、资金能不能被单方面挪动、用户在你消失之后怎么拿回控制权——这些在代码写完之后再改，成本高到大多数团队会选择不改。
正确的做法是把第 24 章的十类风险当成设计阶段的输入，而不是上线前的清单；把合规假设写成一份可以被更新的文件，而不是一次性的咨询。关键是「可调整性」：把你的假设写下来，并且标明假设变化时要改什么。
误区四：把「不确定」当成「没有风险」。
表现是风险页上写着三条通用条目——智能合约风险、市场波动风险、监管不确定性——放在任何项目下面都成立。
它错在这段话不提供任何信息。一份风险清单的质量，不取决于它列了多少条，取决于它有多少条诚实地标了「未评估」。
正确的做法是按十类逐条过，能评估的写清楚评估结论和依据，评估不了的写「未评估」并说明为什么。这个习惯看起来会让材料变难看，但它会带来一个实际的好处：一个主动标出自己盲区的团队，比一个看起来无懈可击的团队更容易通过认真的尽调。
接下来
先回去做这三件事：第 30 章那个 Lab 的全部六步（包括五次真实对话）、第 26 章的损益表、第 24 章的风险十类自查。三件做完，你手上就有了这条 Track 两份文件的全部原材料。
把毕业项目的 Crypto Research OS 用在你自己的项目上。 用研究别人的标准研究自己，是这条 Track 最有效也最不舒服的练习。
两页长期要维护的东西：分析工具箱里的十二问和十类风险（它们是你每次重大决策前的固定检查），以及如何对加密真正产生热情——创业的时间尺度比周期长，而靠价格支撑的动力会在价格下跌时结束。
可以组合的其他 Track：
| 组合 | 为什么合得来 |
|---|---|
| N2 · Crypto Product | 早期创始人自己就是产品经理。这条 Track 的第一份文档，就是 N2 的毕业作品 |
| N4 · Crypto BD & Ecosystem | 早期 BD 也是创始人自己做的，而且不发币时最先够得着的恰好是集成、开发者与生态资助这三类 |
| N1 · Crypto Research & Investment | 研究的终点是判断一个项目值不值得做，创业的起点也是。两边的问题清单有大半重合 |
| N3 · Crypto Growth & Operations | 去补贴化的四个信号，既是增长的复盘方法，也是你判断自己有没有 PMF 的依据 |
如果你自己写代码，T5 · Security Engineer 是值得走一段的延伸方向，而它依赖的 T28、T29、T30 三章应该在写第一行合约之前就读——威胁模型是设计文档的一部分，不是上线前的一道检查。