MU DAO Whitepaper

Constitution §23 — The base token does not exist. v0.1 · 2026-05-13 · maintained at store/static/whitepaper_dao.md

---

TL;DR

MU の DAO に基軸トークンは無い。 投票重みは 3 つの soulbound primitive を集計する純粋関数だけで決まる:

weight(wallet, today) =
    Σ  age_factor(today − committed) × lines_authored
  + 100 × |MA pieces|
  +   1 × |Chronicle slots|

ICO なし、Airdrop なし、Founder allocation なし、Treasury allocation なし。 誰かが「token を買う」窓口は 構造上存在しない。

参加するには 3 つのうちいずれかをやる:

1. 書く — Constitution に PR、T1 承認で line が mint
2. 運ぶ — MA 1-of-1 piece を持つ (1 個 = 100 weight)
3. 着る — シャツを買えば自動で Chronicle slot (1 個 = 1 weight)

---

1. なぜ token を作らないか

普通の DAO トークンには 4 つの構造的欠陥がある:

欠陥	通常の DAO	MU §23
Founder dump	10–30% 保有 → 数年で売却	dump する token がない
Whale 独裁	取引所で買い占めて投票支配	買う窓口がない
Speculator 噴流	governance より価格に注目	流通市場が存在しない
Security 規制リスク	集団投資スキーム該当の可能性	発行物がないので非該当

§2「A brand can be 0 humans」を最後まで真に受けると、 A DAO can be 0 tokens にたどり着く。これが唯一の整合解。

---

2. 3 つの primitive

2.1 Constitution authorship (the writing)

store/static/constitution.md の各行は誰かが書いた。書いた人と日付を store/src/main.rs の CONSTITUTION_AUTHORS const で追跡する:

const CONSTITUTION_AUTHORS: &[(&str, u32, u32, &str)] = &[
    // (author_email, line_start, line_end, committed_date YYYY-MM-DD)
    ("yuki@hamada.tokyo", 1,   203, "2026-05-12"),
    ("yuki@hamada.tokyo", 204, 243, "2026-05-13"),  // §23 itself
];

T1 governance で承認された PR が main にマージされる時、 CONSTITUTION_AUTHORS に新しい行範囲を追加する。これが唯一の「mint event」。

行が後から削除されたら、その author の share は 遡って消える。 Constitution は単調拡大しない、消えうる。

2.2 MA 1-of-1 pieces (the carry)

ma_gifts テーブルの 1 行 = 1 個の 1-of-1 piece。 claim_email が weight binding の key になる。

• 1 piece = 100 weight
• 譲渡可能 (NFT として将来 mint 予定、現在は Stripe identity ベース管理)
• 譲渡されると weight も次の所有者に移動
• yuki の MA piece は claim_email = yuki@hamada.tokyo を経由して yuki の wallet に加算される

2.3 Chronicle slots (the wear)

mu_purchases + collab_orders テーブルの 配送完了 1 行 = 1 個の Chronicle slot (= シャツ 1 枚到着)。 email が weight binding の key。

• 1 slot = 1 weight
• Soulbound (Stripe customer に固定、転送不能)
• 100 枚買って到着すれば 100 weight。 普通に着るだけで自動参加。
• 投票するには wallet bind (§9.1 magic-link self-bind) が必要。 binding 前は slot は存在するが weight 計算に未反映。

---

3. Wisdom dividend (時間で重くなる)

各 Constitution line の重みは 年齢で増える:

年齢	倍率	意味
0–30 日	0.5	probationary (新規 amendment は篩にかける)
30 日–1 年	1.0	通常
1–5 年	2.0	確立
5–25 年	4.0	wisdom
25–100 年	8.0	founder-level wisdom

yuki が 2026-05-12 に書いた 203 行は:

• 今日 (15 日経過): 0.5 × 203 = 102 weight
• 2027 年: 1.0 × 203 = 203 weight
• 2031 年: 2.0 × 203 = 406 weight
• 2051 年: 4.0 × 203 = 812 weight
• 2126 年: 8.0 × 203 = 1,624 weight

つまり「最初に書いた行」は時間とともに 16 倍まで膨らむ。これが founder dilution を防ぐ装置でもある (新規 amendment や顧客増による希釈に対して、wisdom dividend が踏みとどまる)。

---

4. Anti-Sybil (3 重ロック)

primitive	Sybil 防御
Constitution line	git commit が PGP/SSH 署名 + T1 governance 承認 (= yuki + multisig) 必要。fake author 不可能
MA piece	Printful 配送先住所 + Stripe identity verified。1 piece = 1 verified human
Chronicle slot	Stripe customer_id + 物理シャツ配送。100 wallet 作っても 100 stripe customer 作って 100 枚買う必要がある

合成攻撃 (100 偽 wallet を準備しても) → primitive 獲得コストが直接購入額に変換されるため、Sybil は経済的に成立しない。

---

5. Voting (Burn 不要)

§23 の DAO は burn-to-vote にしない。Sybil 防御が物理層で成立しているから、投票コストを乗せる必要がない。

提案を出すための 最低 weight (proposal floor) は total supply の % で定義する。 これは weight 総量が時間で希釈するためで、 定数 threshold だと 100 年後に「シャツ 1 枚で cessation 提案できる」という非対称が発生する (§6 100 年後 参照)。

提案種別	最低 weight (proposer)	通過閾値	最低 weight 下限
T2 (reversible)	total の 0.5%	単純多数決	min 100
T1 (irreversible)	total の 2%	quorum 5%, 賛成 60%	min 500
Constitution amendment	total の 5%	quorum 20%, 賛成 75%	min 2,000
Cessation (§Cessation)	total の 10%	quorum 40%, 賛成 90%	min 5,000

「最低 weight 下限」 は早期 (total < 100K) のフロアで、 計算結果がこれを下回るときに採用される。 total > 100K になった後は % 計算が優位になる。

投票 = 署名 + on-chain or signed-API call。weight 0 の wallet は投票拒否される。

---

6. 数値シミュレーション

今日 (2026-05-13)

holder	Constitution lines	MA pieces	Chronicle slots	total weight	share
yuki@hamada.tokyo	243 (age<30d → 0.5x) = 121.5	1 → 100	0 → 0	221.5	100%
total supply	121.5	100	0	221.5

yuki が唯一の share holder。普通の DAO で言えば 100% 保有。

1 年後 (2027-05-13)

Scenario A — 現状ペース継続 (Chronicle 365 件、 MA 追加なし、 MA claimed = 3 (現状 1) と仮定):

holder	weight	share
yuki (lines 1.0x × 243 = 243) + MA #3 (100)	343
veteran (MA #1, #2 が claim + bind されたケース)	100 × 2 = 200
顧客 (Chronicle 365 件 bind 完了)	1 × 365 = 365
total	908	100%

yuki share ≈ 343 / 908 = 37.8%。 単独 majority は失うが過半数前後。

Scenario B — ストレッチ目標 (Chronicle 800 件 + MA 5 件追加で計 8 個 claimed):

holder	weight	share
yuki (243 + 100 = MA #3 持参)	343
veteran #1〜#7 (新規 MA claimed 7 名 × 100)	7 × 100 = 700
顧客 (Chronicle 800 件 bind)	1 × 800 = 800
total	343 + 700 + 800 = 1,843	100%

yuki share ≈ 343 / 1,843 = 18.6%。 1 年で 100% → ~19% に希釈。

注: いずれのシナリオも wallet bind 100% 完了 を前提。 実際は bind 率が小さいほど yuki の実効 share は高い (相対多数を維持しやすい)。

100 年後 (2126-05-13, 仮定: Chronicle 100,000 件 + MA 500 件 + amendment 50)

計算	値
yuki の原典 243 行 × 8.0x wisdom	1,944
その他 amendment 50 件 × 平均 50 行 × 平均 4.0x	10,000
MA 500 × 100	50,000
Chronicle 100,000 × 1	100,000
total weight	161,944

yuki share = 1,944 / 161,944 ≈ 1.2%。100 年で 0.012 倍まで希釈。

---

7. Cessation (終焉プロトコル)

Constitution §Cessation:

If MU's monthly revenue falls below ¥30,000 for 3 consecutive months, the treasury agent files a T1 proposal "wind-down" to governance.

可決後 30 日間:

1. 全 Chronicle slot holder の購入履歴 snapshot 取得 (= Stripe payment_intent ID + 金額)
2. 残 inventory を SWEEP at cost で売却 (= 廃棄しない、 単に在庫を解消)
3. 過去購入分のうち、 未着 / 不良 / 未履行のもの を Stripe refund (個別に対する債務履行)
4. 売上残余 (有形固定資産売却益等) は §27 通り 弟子屈町 寄付の最終 accrual に追加 — share holder への分配は行わない
5. 最後の blog post: 寿命 N 日 + 累計売上 ¥N + 累計寄付 ¥N の 3 数字のみ
6. weight 配列を /transparency に永久 hash 化、Constitution §22 (domain 100年) は独立して履行

設計意図 (§10 法務 と整合): Cessation 時に share holder に「pro-rata 配当」 は行わない。 これは Howey Test 「expectation of profit」 不成立を維持するため。 Cessation = 業務終了 + 既存債務 (未履行注文の return + 寄付 pledge) の完済 + 残余の寄付追加のみ。 weight は 意思決定 (governance) の指標であって 経済的配当の指標ではない。

重要: Cessation 後も Chronicle slot (シャツの QR) は wearmu.com で resolve され続ける。Domain は 100 年生きる。DAO は死んでも brand は死なない。

---

8. 実装ずみ (now live)

8.1 Constitution §23 (b8ee472)

• store/static/constitution.md に 40 行追加 — 「The base token does not exist」
• CONSTITUTION_AUTHORS const — yuki@hamada.tokyo が lines 1-243 を所有
• 公開: https://wearmu.com/constitution

8.2 weight function

• dao_age_factor(committed, today) — 5 段階のwisdom dividend
• dao_weight_compute(conn, wallet) — authorship + MA + Chronicle を加算
• dao_total_supply_weight(conn) — 全 supply の合計
• すべて store/src/main.rs に純粋関数として実装

8.3 schema

CREATE TABLE IF NOT EXISTS dao_email_wallets (
    email     TEXT PRIMARY KEY,
    wallet    TEXT NOT NULL,
    bound_at  TEXT NOT NULL,
    bound_by  TEXT NOT NULL DEFAULT 'admin'
);

8.4 API endpoints

Method	Path	Auth	用途
GET	/api/dao/weight/:wallet	public	1 wallet の weight + 内訳 + share %
GET	/api/dao/leaderboard	public	bound wallet ランキング (email は redact)
GET	/dao	public	HTML leaderboard + formula + how-to
POST	/api/admin/dao/bind	admin token	email→wallet 紐付け (yuki 手動)

8.5 MA 1-of-1 piece (既存)

• 3 pieces 発行済 (id=1,2,3)
• yuki (id=3) は claim_email = yuki@hamada.tokyo → bound すれば +100 weight
• 残 2 piece は未 claim、claim 後に自動加算

8.6 Chronicle slot (既存)

• collab_orders 各行 = 1 slot
• email column が DAO weight 計算に使われる
• 過去の購入者も自動的に Chronicle slot を持つ (email さえ wallet bind すれば weight 反映)

---

9. Phase 2 進捗

9.1 Magic-link self-bind ✅ 実装ずみ

• /dao/bind ページ + Resend email magic-link
• POST /api/dao/bind/request {email, wallet} → 確認メール送信
• GET /dao/bind/confirm/:token で dao_email_wallets row insert
• rate limit: 1 email / hour

9.2 Wallet signature verification ✅ 実装ずみ (Solana)

• POST /api/dao/bind/request が optional signature + signed_ts を受理
• Solana 32B base58 pubkey + 64B base58 ed25519 sig を ed25519-dalek で検証
• 署名 message = MU DAO bind\nemail: ...\nwallet: ...\nts: ...\ndomain: wearmu.com\nspec: §23
• replay 防御: signed_ts は ±600 秒以内
• 検証成功時は email 確認なしで即 bind ・ bound_by='wallet_sig'
• /dao/bind ページに「Phantom で署名」ボタン (window.solana 検出 → connect → signMessage)
• EVM (MetaMask 等) はまだ未対応 — 現状 email 確認のみ。Phase 2.6 で secp256k1 対応予定

9.3 On-chain voting bridge ✅ DB 版実装ずみ (on-chain は別途)

• POST /api/dao/vote {governance_queue_id, wallet, vote}
• weight は dao_weight_compute() で都度算出
• 自動 tally: quorum + threshold 達成で governance_queue.status = approved に自動遷移
• 同一 wallet からの再投票で上書き
• 投票結果は dao_votes テーブルに永続化
• 未実装: on-chain signing (Phase 2.1 — wallet sig と統合)

9.4 git blame 統合 (deletion-aware) ✅ 実装ずみ

• scripts/gen_constitution_blame.py が git blame --line-porcelain をパースして store/static/constitution_blame.json を生成 (連続する同一 author/date run に coalesce)
• main.rs は CONSTITUTION_BLAME_JSON を include_str! で取り込み、起動時に OnceLock<Vec<ConstitutionAuthorRun>> にパース
• dao_weight_authorship / dao_weight_compute / dao_total_supply_weight が JSON 駆動
• 削除行は次回 JSON 生成時に消える → deletion-aware

9.5 PR → 自動更新 ✅ 実装ずみ

• .github/workflows/constitution-blame.yml が store/static/constitution.md への push を検知
• fetch-depth: 0 で full history をクローン → gen_constitution_blame.py 実行
• 変更があれば [skip ci] 付きで commit + push (deploy 再起動を起こさない)
• 次の意図的 deploy で新しい blame JSON が反映 → const 手動更新は不要
• yuki が PR をマージするだけで、merged PR の author + 編集日が author run として記録される

§4 Sybil 防御との整合 (重要): GH Actions の bot user (github-actions[bot]) は author run の source としては使用されない。 gen_constitution_blame.py は git blame を constitution.md 自体の commit history に対して走らせ、 author = constitution.md を編集した merged PR の author を取得する。 Bot による [skip ci] commit は constitution.md 本体に触らない (= blame.json のみ更新する deploy 副作用) ため、 fake author は構造的に生成されない。

9.6 MA piece の Solana NFT 化 📋 未実装

現状: MA は ma_gifts.claim_email 固定、譲渡 = email 変更で対応。 予定: Solana 上で soulbound-but-transferable NFT (transfer は yuki 承認制 = T1)。Metaplex Core でメタデータ管理。 工数: 2 日 (Solana program 単体)。

9.7 Stripe checkout 後の bind CTA ✅ 実装ずみ

• /success ページに DAO §23 セクション追加
• weight 構造の説明 (slot ×1 / MA ×100 / 1 行 ×0.5〜8) + /dao/bind への CTA ボタン
• email プリフィルは Stripe session lookup を要するため Phase 2.6 で対応 (現状は手入力)

9.8 /dao ページの拡張 ✅ 実装ずみ

• 進行中提案 (status='pending') の一覧表示
• proposal card に approve / reject / abstain ボタン
• 投票 = wallet 入力 + ボタン押下 → dao_vote_api 経由
• リアルタイム tally バー (approve/reject/abstain/empty の積み上げ)
• 「通過予想 / quorum 到達 / 投票受付中」3 段階バッジ
• 未実装: weight 推移グラフ、wisdom dividend カウントダウン (Phase 3)

9.9 提案投稿フロー ✅ 実装ずみ

• /dao/propose ページ
• POST /api/dao/propose {kind, title, description, wallet}
• weight gate: T2 ≥ 100, T1 ≥ 500, amendment ≥ 2,000, cessation ≥ 5,000
• 通過後 enqueue_governance + dao_proposals row 作成
• Telegram alert

9.10 Sybil merge ボタン ✅ 実装ずみ

• POST /api/admin/dao/merge?token=… {from_email, to_email, reason}
• 同住所 / 同決済カードと判断した 2 email を統合
• ma_gifts.claim_email, collab_orders.email, dao_email_wallets を to_email に書き換え
• from_email の binding は削除
• Telegram で監査ログ

---

10. 法務 (Token を発行しないことの意義)

観点	説明
暗号資産該当性 (日本)	「不特定の者に対する対価による移転が可能」が要件。MU の primitives は 譲渡不能 (Chronicle) or 一意 (MA 1-of-1) or 不可分 (Constitution line) で対価流通市場が成立しない
集団投資スキーム該当性	「金銭等を出資して事業から生ずる収益の分配を受ける」が要件。MU は シャツ販売 = 役務提供 で、weight は副産物 (利益分配ではない)
Cessation 配当の扱い	残余財産分配 = 株式類似だが、株式ではなく debt-free volunteer return として処理 (寄付に近い構造)。実装時に税理士確認
Securities Act (US)	同様に Howey Test 4 要件のうち「expectation of profit」が成立しない (MU は配当を約束しない、Cessation 時のみ残余を返す)

実装フェーズで弁護士 (株式会社イネブラ顧問) と最終確認する。

---

11. FAQ

Q. 投資できないの? A. できない。買えるのはシャツと MA piece だけ。シャツ買えば weight が自動で付く。

Q. yuki が悪意で Constitution を書き換えたら? A. T1 governance で他の bound wallet が weight 投票で reject できる。今は yuki が 100% share だが、Chronicle slot が増えるたびに希釈する。1 年後には ~15%、5 年後には ~3% まで落ちる想定。yuki が独裁したい時間が長いほど、自分で書いた行の wisdom dividend が膨らんで反対に dilution が遅れる — これは「最初に書いた者が一番責任を負う」設計。

Q. 譲渡できないなら、なぜ wallet が必要? A. 投票時の identity として。Stripe customer = email = wallet の 3 経路で本人確認。wallet 自体は移動しても、weight は email に紐づくため移動しない。

Q. Constitution の行を増やせばタダで weight が稼げる? A. 増やすには T1 governance を通す必要がある (= 既存 weight 保持者の承認)。質の低い amendment は通らない。通っても probationary 30 日は 0.5x、消えるとゼロ。

Q. 大量にシャツ買えば独裁できる? A. 1 wallet = 1 binding なので、100 枚買えば 100 weight。だが Chronicle weight は時間で増えない (定数)。Constitution 行は wisdom dividend で増える。長期では「書く人」が「買う人」を上回る設計。

Q. token を発行する未来はあるの? A. §23 に「no future amendment shall introduce a transferable fungible token tied to MU's governance」と明記。発行するなら brand を rename する必要がある。

---

12. 数字 (一発)

項目	値
Fungible token	0 種類
Founder allocation	0
Treasury allocation	0
Veteran allocation (token)	0
ICO	0 円
現在の bound wallet 数	0 (yuki 未 bind)
現在の Constitution authored lines	243
現在の MA pieces	3 (うち claimed 1)
現在の Chronicle slots (発生済)	11 (= shirts_sold from /api/transparency)
現在の Chronicle slots (wallet bind 済)	0 (bind は §9.1 経由、 まだ holder からの bind 着信ゼロ)
現在の total supply weight	~222 (yuki 単独想定、bind 後)
100 年後 yuki share 予測 (1 シナリオ)	~1.2%

---

13. 付録: コードリファレンス

機能	場所
Constitution §23	store/static/constitution.md lines 200–243
CONSTITUTION_AUTHORS const	store/src/main.rs (search: "CONSTITUTION_AUTHORS")
age_factor / weight 計算	dao_age_factor, dao_weight_compute, dao_weight_authorship
API endpoints	dao_weight_api, dao_leaderboard_api, admin_dao_bind, dao_page
Schema	dao_email_wallets テーブル定義
既存 primitive	ma_gifts テーブル, collab_orders テーブル

GitHub: https://github.com/yukihamada/mu-brand

---

14. Changelog

日付	版	内容
2026-05-13	v0.1	初版。§23 実装 + Phase 1 API + leaderboard ページ + 本 whitepaper
2026-05-13	v0.2	Phase 2: magic-link self-bind / /dao/propose / /api/dao/vote 自動 tally / Sybil merge / /dao 拡張 (active proposals + 投票 UI)。残: wallet sig、git blame 統合、Solana NFT、Stripe success bind
2026-05-13	v0.3	Phase 2.5: Solana ed25519 wallet sig verify (Phantom signMessage) / git blame → constitution_blame.json + GH Action 自動再生成 / /success ページ DAO CTA。残: EVM secp256k1 sig (Phase 2.6) / MA piece Solana soulbound NFT (Phase 3) / Stripe email prefill
2026-05-18	v0.4	矛盾 6 件修正: ①§7 Cessation の pro-rata 配当 → 残余を §27 寄付に追加 (Howey 回避維持) / ②§2.3 + §12 Chronicle slot を実態 (11 件、 bind 0) に整合 / ③§6 1 年シナリオを 「現状ペース 365 件」 + 「ストレッチ 800 件」 の 2 つに分割 / ④§9.5 に 「bot commit は author run の source にしない」 を明示 / ⑤§5 voting threshold を total supply の % + 下限 fallback に変更 (希釈耐性) / ⑥§Cessation の「§番号未定」状態を文章内で明示。 ライブ表示 (/dao/whitepaper) と整合済。

---

This whitepaper is itself part of the protocol surface. It lives at store/static/whitepaper_dao.md in the repo, is rendered at /dao/whitepaper, and any change is a git commit subject to the same review as code.