DAO(分散型自律組織)が扱う資産――トレジャリーは、しばしば数十〜数百億円規模に達する。Uniswap が約 60 億ドル、Optimism Collective が約 30 億ドル、Arbitrum DAO が約 28 億ドル(2026 年 5 月時点)。これだけの金額をコードと合議だけで動かしているのが Web3 の異常さでもあり、面白さでもある。
そのトレジャリー運用の実務的中核にいるのが、ほぼ例外なくマルチシグ――具体的には Safe。本記事では、DAO トレジャリー運用におけるマルチシグのガバナンス設計を、過去の事故例とセットで整理する。個人運用の話は個人向けマルチシグ構成パターン集で扱った。
DAO トレジャリーが直面する 3 つの圧力
設計に入る前に、なぜ「ただマルチシグを使えばいい」では済まないかを押さえておく。
- 規模の圧力: 数十億円が 1 つのアドレスに集中、攻撃対象として極めて目立つ
- 透明性の圧力: チェーン上でフローが全公開、コミュニティへの説明責任が常時発生
- 意思決定の圧力: トークン投票・コミュニティ提案との接続が必要、Signer 個人の独断は許されない
この 3 つに耐える設計が「DAO 用マルチシグ運用」の中身。
基本構造: 3 層モデル
実務でよく見るのは、以下の 3 層構造。
層1: Governance Token Vote(トークン投票層)
- ツール: Snapshot(オフチェーン投票)、Tally(オンチェーン投票)
- 役割: 大きな方針(プロトコル変更、トレジャリー支出枠)を決める
- 期間: 通常 3〜7 日
層2: Multisig Signer Council(署名者評議会)
- ツール: Safe(M-of-N)
- 役割: 投票で承認された内容を実際にトランザクション化して送る
- 構成例: 5-of-9、4-of-7 など、組織規模で変動
層3: Operational Tools(運用ツール層)
- ツール: Llama、Den、SafeSnap、Zodiac モジュール
- 役割: 投票結果の自動執行、定期支払い、サブトレジャリー管理
「投票 → 署名 → 執行」のパイプラインを途切れさせないことが運用設計のキモ。
主要 DAO の構成事例
公開情報ベースで、いくつかの DAO 構成を並べる。
| DAO | 主要 Signer 構成 | 特徴 |
|---|---|---|
| Uniswap | 6-of-10(Uniswap Foundation 管理) | コミュニティ投票後にFoundationが執行 |
| MakerDAO | Pause Proxy 経由 | スマートコントラクト中心、Signer の権限は限定的 |
| Aave | 5-of-9(Guardian 構成) | 緊急停止権限を Guardian Multisig に集約 |
| Arbitrum DAO | Security Council 9-of-12 | プロトコル緊急対応用、定例運用とは別系統 |
(2026 年 5 月時点の公開情報、変更されている可能性あり)
共通するのは「Signer 数を 9〜12 名に置く」「閾値を半数強に設定する」傾向。Signer が少なすぎると独断のリスク、多すぎると承認集約のコストが上がる。
過去の事故から学ぶ設計原則
事故例1: Wonderland(2022年)
Sifu 氏が過去に詐欺関与歴のあるオンチェーン履歴を持つ人物だったことが発覚、トレジャリー Signer に含まれていたことでコミュニティが大荒れ、トークン暴落。
- 教訓: Signer の過去オンチェーン履歴の事前デューデリは必須
- 対策: Signer 候補のアドレスを公開し、コミュニティチェックを通す手順を入れる
事故例2: BadgerDAO(2021年)
フロントエンドが侵害され、ユーザーが知らずに悪意ある approve トランザクションに署名、約 1.2 億ドル流出。マルチシグ自体は破られていないが、運用周辺の脆弱性を突かれた事例。
- 教訓: マルチシグだけ守っても、UI レイヤが攻撃面になる
- 対策: フロントエンドのコード署名・ハッシュ検証、定期的なペネトレーションテスト
事故例3: Multichain(2023年)
CEO が個人で秘密鍵を集中管理していた疑いがあり、CEO 拘束後に資産が動かせない / 動かされる事態に発展、約 1.5 億ドル流出。
- 教訓: 「マルチシグ」と謳っていても、実態が集中管理なら意味がない
- 対策: Signer の地理的・組織的分散、鍵保管プロセスの監査
設計時に決めるべき 7 項目
実際に DAO トレジャリー用 Safe を設計するなら、以下を文書化しておくのが定石。
- Signer 人数と閾値: 9 名 / 5-of-9 など
- Signer の選定基準: コミュニティ投票、技術評議会指名、Foundation 任命のいずれか
- Signer の任期: 1 年・2 年・無期限のどれか、更新プロセスは何か
- 緊急時対応: Pause / Veto 権限を別 Multisig に分けるか
- 支出枠: 月次・四半期の上限額、上限超過時の追加投票要件
- 報告サイクル: Signer の活動報告頻度、トランザクション開示フォーマット
- 退任プロセス: Signer が抜ける時の Owner 入れ替え手順
「まず作ってから考える」をやると、後で破綻する。事前にこの 7 項目を Constitution(憲法的文書)に書き、コミュニティ承認を取ってから Signer を集めるのが本筋。
補助ツール
Safe 単体では足りない部分を埋めるツール群。
- Zodiac モジュール: Reality Module で「Snapshot 投票結果を自動執行」、Roles Modifier で「特定 Signer に限定権限」を付与
- SafeSnap: Snapshot 投票結果を Safe トランザクションに直結
- Llama / Den: トレジャリーの可視化、ペイロール、サブ DAO 管理
- DeFi Saver / Defender: 定例タスク自動化、アラート
導入順としては「Safe → Snapshot → SafeSnap または Zodiac」が定番ルート。
個人運用との違いをまとめると
| 観点 | 個人 2-of-3 | DAO 5-of-9 |
|---|---|---|
| Signer 選定 | 家族・親友 | 公募 + 投票 |
| 透明性要求 | 不要 | チェーン上全公開 |
| 意思決定 | Signer 合意 | トークン投票が前提 |
| 緊急対応 | Signer 連絡 | 別 Multisig 分離 |
| ガバナンス文書 | 不要 | Constitution 必須 |
「個人マルチシグを大きくしただけ」では運用が回らない、というのが結論。ガバナンス層を別に組む前提で設計する必要がある。
まとめ
DAO トレジャリーにおけるマルチシグは「金庫の鍵」ではなく「ガバナンスの実行装置」。Signer は技術者というより、投票結果を忠実に執行する受託者として設計するのが現代的な思想だと思う。
マルチシグそのものの基礎はマルチシグとは、実機での立ち上げ方はSafeの使い方、DAO 全般のリスクはDAOのリスクと法的位置付けで扱った。
※本記事は情報提供を目的としたものであり、特定のDAO・トークン・投資商品の購入を推奨するものではありません。記載のDAO構成・トレジャリー残高等は2026年5月時点の公開情報に基づき、変動します。投資・参加は自己責任で行ってください。
※本記事は情報提供を目的としたものであり、特定の暗号資産や投資商品の購入を推奨するものではありません。投資は自己責任で行ってください。過去の実績は将来の利益を保証するものではありません。記事内には広告（アフィリエイトリンク）を含む場合があります。
