なぜ一部のプロトコルはSecurity Councilの完全な権限一覧を公開しないのか？
情報開示が不十分な理由は通常2つ考えられる。一つは、チームが単に文書を十分に整備していないという、ガバナンスの成熟度不足の問題。もう一つは、チームが意図的に曖昧にしているケースで、詳細を公開すると悪意ある者が標的型ソーシャルエンジニアリング攻撃を設計するのに使われかねないという懸念による。しかし読者のリスク評価の観点からは、どちらの場合も結果は同じである——この署名者グループが実際にどこまでの操作を行えるのかを検証できず、署名者が騙された場合に自分の資金がどれだけのリスクにさらされるかを評価できない。
注目すべきは、Drift Protocolの事件では、攻撃者がまさにソーシャルエンジニアリングを利用して署名者を欺いたという点だ。これは「標的型攻撃を防ぐために詳細を非公開にする」という防御ロジック自体に限界があることを示唆している——攻撃者は権限一覧の詳細を知る必要はなく、誰が署名者であるかさえ分かれば、その人物を直接狙えばよいのだ。
プロトコルのSecurity Councilのタイムロックが24時間しかない場合、それで十分なのか？
この質問に単一の正解はなく、いくつかの変数に左右される。第一に、この24時間の猶予期間に、コミュニティや監視主体に能動的に通知する仕組み（オンチェーンの自動アラートシステムなど）が実際に備わっているのか、それとも完全にユーザー自身がガバナンス提案ページを監視することに依存しているのか。第二に、そのプロトコルの監視システムの反応速度がどれくらい速いか——専門のオンチェーン監視チームやセキュリティ企業と提携しているプロトコルであれば24時間で十分かもしれないが、コミュニティの自発的な監視に完全に依存している場合、24時間では十分な人数が気づいて有効な対抗策を形成するには足りない可能性がある。
さらに重要なのは、タイムロックの日数は長ければ長いほど良いわけではないという点だ——タイムロックが長すぎると、進行中の攻撃のような本当の緊急事態への対応能力が遅くなる。これこそが、多くのプロトコルが「通常のガバナンス提案」と「緊急操作」で異なるタイムロックの長さを設計し、緊急操作についてはタイムロックを完全に迂回させることさえある理由だ。まさにこれがDrift事件における最も重大な設計上の欠陥だった——緊急経路はタイムロックが一切ない設計になっており、効率性と検知可能性のトレードオフを完全に効率性側に賭けていたことになる。
タイムロックと署名閾値の他に、Security Councilの濫用リスクをさらに下げる方法はあるのか？
実務上採用されるいくつかの補完的メカニズムがある。第一に「操作範囲のホワイトリスト」——Security Councilが実行できる操作を事前に定義された特定の種類（例えば契約の一時停止のみ可能で、資産ホワイトリストの変更はできない）に明確に限定し、無制限の万能な権限を与えないというもの。第二に「レート制限」——たとえ正当な緊急操作であっても、一度に調整できるパラメータの幅や引き出せる資金の上限にハードな制限を設け、単一の取引が壊滅的な損失を引き起こすのを防ぐ。第三に「階層型タイムロック」——リスクレベルの異なる操作に対して、一律の日数ではなく異なる長さのタイムロックを設定するというもの。
これらのメカニズムが存在するかどうかも、プロトコルのガバナンス文書や契約コードから確認できる——契約コードにSecurity Councilの操作に対する上限や範囲制限が一切設けられていない場合、この署名者グループが理論上保有する権限範囲は、文書に記載されている内容よりもはるかに広い可能性を示唆している。
あるプロトコルのSecurity Council設定に問題があると気づいた（閾値が低すぎる、タイムロックがないなど）が、既に資金を預けている場合、どうすればよいか？
第一のステップは実際のエクスポージャーを評価することだ。そのプロトコルの現在のTVL規模、自分の資金が占める割合、そしてSecurity Councilの権限が自分が使用している特定の製品モジュールに直接及ぶかどうかを確認する（例えば貸付プールのみを利用していて、Security Councilの権限が別のデリバティブモジュールにしか及ばない場合、直接的なエクスポージャーは比較的低い）。第二のステップは、そのプロトコルのガバナンスフォーラムやDiscordを継続的に注視し、特に他のコミュニティメンバーが既に同様の懸念を提起していないか、チームが改善計画を示しているかに注意することだ。
評価の結果、リスクが自分の許容範囲を超えると判断した場合、パニックになって一度に全額撤退する（不要なスリッページや手数料の損失を招く）のではなく、段階的にエクスポージャーを減らすほうが堅実なアプローチだ。この種のガバナンス設定の問題は通常、前触れなく突然発生するものではなく、多くの場合たどれる痕跡がある——例えばDriftの事例では、閾値の変更とタイムロックの撤廃は攻撃発生の数日前にオンチェーン上の公開記録として既に行われていたが、当時は十分な注目を集めていなかった。
近年、ますます多くのプロトコルが「Security Council」と呼ばれる仕組みを設けるようになっている。これは緊急時に迅速な行動をとる権限を与えられたマルチシグ署名者のグループで、契約の一時停止、リスクパラメータの調整、さらには契約ロジックのアップグレードなど、迅速な対応が必要な操作を担う。この設計の意図自体は健全だ——通常のガバナンス投票は可決まで数日、時には数週間を要することが多く、進行中の攻撃に対応するには遅すぎる。Security Councilはより速い対応経路を提供する。しかしこの「速さ」自体が、十分な牽制メカニズムを伴わない場合、保護の傘ではなく攻撃者にとっての近道になりかねない。
Security Councilに付与される権限の範囲はプロトコルによって大きく異なる。よくある権限には、特定の契約機能の一時停止や再開、清算関連パラメータの調整、価格オラクルが受け入れる資産のホワイトリスト更新、さらには契約アップグレードの直接実行などがある。権限範囲が広いほど、この署名者グループが侵害されたり誤った署名に誘導されたりした場合の被害は大きくなる。多くのプロトコルは、ガバナンス文書やGitHubリポジトリのgovernanceまたはsecurityフォルダに、Security Councilの具体的な権限一覧を明記している——もしこの一覧が見つからない場合、それ自体が警戒すべきシグナルである。
署名閾値（例：3-of-5、2-of-5）は、取引が実行されるまでに何人の署名者の同意が必要かを決定する。閾値そのものに絶対的な安全・危険はないが、留意すべき原則が2つある。第一に、閾値がそのプロトコルが管理する資金規模と見合っているかどうか——数億ドル規模の資産を管理するプロトコルが、わずか2人を懐柔すれば通過してしまう2-of-5のような低い閾値を採用している場合、リスクは明らかに高い。第二に、閾値の数字そのものよりも重要なのが署名者の身元の独立性である——5人の署名者のうち3人が同じ組織の従業員であれば、3-of-5と表記されていても、実質的な安全性はその単一組織の内部統制レベルと変わらない可能性がある。確認方法としては、多くのプロトコルが文書やブロックチェーンエクスプローラー上でマルチシグアドレスを公開しており、EtherscanやSolscanなどのツールでそのマルチシグ契約の署名者一覧と過去の署名履歴を確認し、これらのアドレスが識別可能な独立した実体に紐づいているかどうかを照合できる。
タイムロックは、提案が可決された後、実際に実行されるまで一定期間待たなければならないというルールであり、この待機期間がコミュニティや監視システムに、その取引が異常でないかを審査し、必要であれば警告や対抗措置を発動する機会を与える。タイムロック設定を確認する際は3点を確認する必要がある。第一に、このタイムロックはSecurity Councilの全操作に適用されるのか、それとも通常のガバナンス提案にのみ適用され緊急操作は除外されているのか。第二に、タイムロックの日数はどれくらいか——業界でよく見られる範囲は24時間から7日間で、日数が短いほどコミュニティが反応できる窓は狭くなる。第三に、このタイムロック設定が過去に一時的に調整または撤廃されたことがあるか——プロトコルのガバナンス提案履歴や契約アップグレード記録を確認し、「timelock」「delay」「security council」といったキーワードで検索して、タイムロックを短縮または撤廃することを目的としたガバナンス投票がなかったかを確認する。この種の変更はリスク上昇の明確なシグナルであることが多く、特に変更のタイミングが既知のセキュリティ事件の直前であった場合は、その背景を深く調べる価値がある。
実際の手順としては次の順序で素早く確認できる。第一に、プロトコルの公式文書やGitHubで「Security Council」または「Emergency Multisig」を検索し、権限範囲の一覧が公開されているかを確認する。第二に、マルチシグ契約アドレスを見つけ、ブロックチェーンエクスプローラーで署名閾値と署名者一覧を確認し、署名者の身元の独立性を評価する。第三に、Security Councilの操作にタイムロックが併設されているか、タイムロックの具体的な日数を確認する。第四に、そのプロトコルのガバナンス履歴を検索し、タイムロック設定が過去に調整されたことがあるか、特に調整のタイミングが既知のセキュリティ事件より前だったかどうかに注意する。この4つのステップのいずれかで公開情報が見つからない場合、それ自体がそのプロトコルのガバナンス透明性における問題であり、リスク評価に組み込むべき要素である。
資金をプロトコルに投じるかどうかを判断する際、通常はTVL、APY、監査レポートを確認するが、これらの指標はどれも「もしSecurity Councilの署名者が騙されたら、あなたの資金を救う緩衝時間があるかどうか」を教えてくれない。たとえコードが完璧で監査を全て通過したプロトコルであっても、Security Councilの署名閾値が低すぎたり、署名者の独立性が不十分だったり、タイムロックが撤廃されていたりすれば、ガバナンス層が依然として最大の単一リスク源になりうる。3分かけてこのチェックを行うことで、監査レポートだけでは得られない判断材料を手に入れることができる。