N5 · Crypto Founder
Token を発行するか決める前に、需要、仕組み、事業、安全、金庫を考え抜き、他者が反論できる二つの文書にまとめる。
この Track は、起業家を対象とします。
出発点は第 30 章の言葉です。Token がなくても利用されることを証明してから、発行するか決めます。 証明とは態度ではなく、実行できる検証です。それを完了し、結果を一つずつ問い直せる二つの文書にすることが、この Track の仕事です。
法律上の意見や、資金調達・投資の助言は提供しません。自分の仮定を明示し、最も弱いものを知り、仮定が変わったときの対応を考える方法を学びます。 具体的な法律や税務は専門家へ相談してください。
この Track に向いている人
「いつトークンを発行するか」と考えている。 第 30 章の三人の創業者の一人です。最初に、実際にはどの問いを問うているかを判断します。三つの状況では、同じ言葉がまったく異なる問いになるからです。
公開したプロダクトの登録は多いが、二度目の利用がほぼない。 トークンやポイントで呼び戻そうとしています。受け入れにくい結論と、具体的な代替行動を学びます。
実際の利用者がおり、発行するかを問われている。 三つの中では最もよい状況で、分配できる実際の資産があります。しかし、競合が発行したという理由ではなく、トークンの仕組み上の役割を説明する必要があります。
調達資料がすべてビジョンで、事業のページがない。 収益、費用、金庫、リスク、退出の五つのうち三つが欠けています。
ツールを作っているのに、ネットワークとして説明するよう求められる。 診断方法と、ツールもよい事業になる道を学びます。
前提
前提が最も多い 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 なしで成立するか」と、その中の五人の実在する相手との対話です。最初の二問の後、自分の案を紹介してはいけません。 省くと、後のすべてが独りよがりになります。
学ぶ内容
十一のテーマを五群に分けます。調達資料の章順ではなく、企業の実際の意思決定順です。
- 需要
- 仕組みの設計
- 事業
- 組織と資金
- 安全と法令遵守
| 群 | 含むテーマ | 解決する問い | 接続する章 |
|---|---|---|---|
| 需要 | 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 か月で何を使うか、90 パーセント下落後に何が残るか、です。順序には理由があります。動かないときに第二問が意味を持ち、動くなら、なぜ発行するかを問います。
必需品かは、一社が現金で参加者へ支払ったらどうなるかで検証できます。費用が増えるだけなら加速器、利用理由である検閲耐性と持続性が失われるなら必需品です。必需品を自称する多くのプロジェクトを、この検証で除外できます。
達しなければ仮定が誤りと認める、検証案で事前に定めた線です。
第 30 章の Lab で最も書きにくく、価値のある一行です。失敗の基準がなければ、どんな結果も「見込みがある」と解釈されます。
まず八週間以内に測れる成功基準を書き、どの水準以下なら方向が誤りと認めるかを問います。書けないなら、検証で意思決定するつもりがなかったということです。
卒業成果物
資金調達資料と、Token の必要性の論証。「Token を発行しない」案を含む。
括弧内が中心です。発行しない案は選択肢ではなく必答です。書いて初めて、必需品、加速器、偽装のどれか分かります。
卒業プロジェクトとの違い。 卒業プロジェクトは他者のプロジェクトを調べ、判断力を示します。この Track は自分のものを対象とします。他者なら疑い、自分なら擁護する傾向があり、そこが難所です。基準の半分は、自分にも同じ基準を使ったかを確かめます。
受け入れ基準は五つです。
調達資料のすべての数字に定義と取得時点を付け、オンチェーンの数字は再現可能にする。
利用者数は四層のどれか、収益は支払い総額、プロトコルの取り分、報酬を引いた純額のどれか、評価はどの指標かを示します。再現できない数字は削除するか、出典と不確かさを明示します。
必要性の四問に個別に答え、第三問には具体案を書く。
Token のない 12 か月の代替は、自分が最初の片側になる、既存の困っている集団に提供する、部品として他者の配布へ入る、現金で報酬を出す、のどれかです。小規模な試用を先に行うだけでは、案ではなく延期です。
発行しない案を、予算、節目、中止基準のある実行可能な 12 か月計画にする。
価格、エアドロップへの期待、ポイントを参照せず、独立して成立させます。それでも成立するなら、トークンは必需品ではなく加速器です。重要な発見として論証に書きます。
90 パーセント下落後に、プロダクト、利用者、収益が各どれだけ残るかを一節で書く。
プロダクトと投機商品を分けます。基盤を書けなければ、現状は後者です。 最も楽観的なページと並べると、普段見えない依存も露呈します。
十種類のリスク、法令遵守の仮定一ページ、金庫一ページを付ける。
分析ツールの十種類を個別に書き、評価できなければ未評価とします。法令遵守では保管者、自主的な引き出し、責任、前提条件、仮定が変わったときの変更を記します。金庫では、資産の種類、現在の消費で続く期間、支配権を答えます。
達成したかを判断するには
達成していれば、トークン、エアドロップ、報酬、ガバナンスの語を使わない 300 字の説明を書いても、存在理由と支払う人が残ります。
動かない仕組みが残るなら必需品、遅くても成立するプロダクトが残るなら加速器、何も残らないなら偽装です。
第三の種類を避けることが大きな目的です。見つかったら設計を直すより、需要の問題へ戻ります。トークンは、特に必要とされていないことを一時的に隠すだけで、その期間は通常 12〜18 か月です。
達成していれば説明でき、友人や同僚ではなく、同じ会社の人でもありません。
答えられなければ、第二、第三、第四段階に土台がありません。第 30 章の経験則は、多くの人は第一段階で止まっているのに、第三段階で止まっていると思うというものです。
支払う人が全員同じ会社なら、PMF ではなく一顧客です。悪い知らせではありませんが、正しく扱います。無関係な第二、第三の源泉を探し、その会社が消えたら収益がいくら残るかを問います。ゼロなら、現在はプロダクトより受託事業です。
達成していれば、厳密な定義、報酬なしの有料操作を行ったアドレスが、完全に報酬のない期間に戻る割合で測った数字を知っています。
受け入れにくいほど小さいことが多くても、騙さない唯一の数字です。知らないチームは、自分の状況を判断できていません。
報酬のない期間がなければ、今から観測区を残します。常に一部の機能へ報酬を付けず、汚染のない唯一の標本にします。
達成していれば、コントラクト、マルチシグ、口座など保管経路を一文で説明し、権限者、必要な同意人数、タイムロック、典型事故での損失の負担先を答えられます。
安全、法令遵守、プロダクトに同時に属します。第 24 章の通り、事故の結果を決めるのは、コードより権限の層であることが多いものです。設計判断であり、後からの変更は高くつきます。
「監査する」とだけ答えるなら未達です。監査は実装が意図に合うかを調べますが、意図自体を決めてはくれません。
正解は一つではありません。次を確認します。
- 事業（収益、費用、金庫、退出）とビジョンのページはそれぞれ何枚ですか。
- 四問で最も曖昧なのはどれですか。通常は第二問です。Token によって誰が何を変え、その行動を本当に必要としますか。
- 発行しない計画には予算と中止基準がありますか。節目だけですか。
- 90 パーセント下落後に残るものはすでに存在しますか。計画上だけですか。
- 十種類の未評価はいくつですか。ゼロなら真剣に評価していないことが多いものです。
- 法令遵守のページは一般的な遵守宣言ですか。保管者、引き出し、仮定の変更時の対応まで具体的ですか。
- 最も避けている問いは、文書に出ていますか。
第 30 章の AI Lab の方法を使い、モデルに利用者、投資家、規制の視点から各三つの疑問を出させます。答えに使える形は二つだけです。「検証済みで、根拠はこれ」と「未検証で、この方法と期限で検証する」です。「解決する予定」は使えません。九問のうち、第一の形で答えられる数が検証の程度です。
よくある誤解
誤解 1：発行を調達と成長の手段にする。
先に発行し、資金と人を得てから作る方法は、短期的にはアドレス、コミュニティ、報道を集めます。
未検証の仮定を、価格の付いた資産に変える点が問題です。注意が利便性から価格維持へ移り、必要な行動は異なり、衝突することもあります。配分、ロック解除、期待が固定され、変更の政治的費用も高く、取り消せません。
支払う人を見つける → 報酬なしでも戻る → 規模拡大で便利になると証明する → 発行を決める順序に戻します。最初の三つは Token なしでできます。発行を先にすることが必ず誤りとは言いませんが、その場合でも発行前に需要の確信が必要です。なければ、得たのは時間よりも後戻りしにくい立場です。
誤解 2：ネットワーク効果を当然視する。
強いネットワーク効果を主張しても、百人から一万人に増えたとき、一人の価値が変わらない例です。
利用者が百倍になると、一人あたりの価値が上がるかを問えば十分です。上がらなければツールであり、ネットワークではありません。
重要な診断であり、悪い知らせではありません。トークンで立ち上げを補助する必要がなく、線形成長と課金が適します。ネットワークのほうが調達しやすいため偽ると、ツールに役立たず、有害にもなるネットワーク型の判断をする代償を負います。
Crypto の実際のネットワーク効果の源泉は、流動性（主張されやすく、移動もしやすい）、接続（相手のコード変更が必要で強い）、資産と標準（強いが作るのが最も難しい）の三つです。
誤解 3：安全と法令遵守を公開直前に回す。
設計をすべて終えてから監査と法律を調べ始めます。
大半が検査項目ではなく設計判断だから問題です。清算、オラクル、更新権限、署名人数、資金の一方的移動、チームが消えた後の権限回復は、コード完成後に変えると高くつき、多くのチームは変更しません。
第 24 章の十種類を設計の入力にし、法令遵守の仮定も更新できる文書にします。中心は変更可能性です。仮定と、変わったときに直すものを記録します。
誤解 4：不確かさをリスクなしと扱う。
コントラクト、変動、規制の不確かさという一般論だけのリスクページです。
どのプロジェクトにも当てはまり、情報を与えません。質は項目数より、正直に未評価とした数に表れます。
十種類を個別に調べ、評価できるものに結論と根拠、できないものに未評価と理由を書きます。資料は悪く見えても、盲点を自ら示すチームは、完璧に見せるチームより、真剣な調査を通過しやすくなります。
次に進むには
まず三つを実践してください。第 30 章の六段階すべて（五回の実際の対話を含む）、第 26 章の損益表、第 24 章の十種類の自己点検です。二つの文書の材料が揃います。
卒業プロジェクトの Crypto Research OS を自分のプロジェクトへ使います。 他者を調べる基準で自分を調べることが、最も有効で、最も受け入れにくい練習です。
継続して維持する二ページは、分析ツールの十二問と十種類のリスク、Crypto に持続的な関心を持つにはです。起業の時間はサイクルより長く、価格に頼る動機は下落時に終わります。
組み合わせられる Track：
| 組合せ | 相性の理由 |
|---|---|
| N2 · Crypto Product | 初期の創業者はプロダクト担当でもあり、最初の文書は N2 の卒業成果物です |
| N4 · Crypto BD & Ecosystem | 初期の BD も自分で行い、未発行でも接続、開発者、エコシステム助成へ接触できます |
| N1 · Crypto Research & Investment | 調査の終点も起業の出発点も、行う価値の判断です。問いの半分以上が重なります |
| N3 · Crypto Growth & Operations | 補助金を除いた四兆候は、成長の振り返りであり、PMF の判断根拠です |
コードを書くなら、T5 · Security Engineerにも進む価値があります。前提の T28、T29、T30は、最初のコントラクトを書く前に読んでください。脅威モデルは設計文書の一部であり、公開直前の検査ではありません。