DeepSafe × CertiK 2026年機関デジタル資産ガバナンス研究|100のプロジェクトとサービス提供者

  • DeepSafeとCertiKの調査で、日常の資金操作は実行チームに委ねつつ、投資範囲の拡大や限度額引き上げは別途承認すべきとの設計方針を示した。
  • 資管30件中11件が具体的な投資制限を、規則変更権限を説明する50件中16件が変更待機を開示・支持。比率は文書開示やソース対応であり、本番稼働率ではない。
要約

DeepSafeとCertiKは、機関のステーブルコイン決済、プロジェクトのトレジャリー、オンチェーン投資をめぐって共同調査を実施し、機関がどのように取引権限を分割し、投資範囲を制約し、異常時に資金を処分するかを研究した。

研究では、100のプロジェクトとサービス提供者の公式ドキュメント、製品説明、関連コードを整理し、業務類型と制御メカニズムごとに証拠を記録した。レポートは機関資金の実際の運用順序に沿って展開する。チームがどの操作権限を得るのか、投資ルールをどう変更するのか、異常発生後にどう退出・復旧するのか、という順序である。

サンプル事例によれば、機関は日常の資金操作を実行チームに委ねることができるが、投資範囲の拡大や限度額の引き上げといった変更は別途承認すべきであり、緊急停止・撤回・復旧には独立した限定された権限を設定すべきである。

こうした分業により、チームは既定の範囲内で業務を継続でき、同時に新たなリスクを再検討し、異常に対応する機会を確保できる。緊急対応能力は最終的に一つの業務成果、すなわち必要なときに資金が利用可能な口座に戻るかどうかで評価される。

主要な結論

  1. 30の資産管理プロジェクトのうち、11が具体的な投資制限を開示

この11プロジェクトは、参入可能な市場、利用可能な資産、呼び出し可能な機能、または資金規模を明確に制限している。RockSolid、Neronaなどの事例は、戦略の受け入れと日常の資金移動を分離し、運用者が既定の範囲内で作業できる一方、新たな投資方針には別途の承認を必要とする。

  1. 50のプロジェクトのうち、16がルール変更の待機を開示またはサポート

ルール変更権限を説明している50のプロジェクトのうち、16が変更待機メカニズムを同時に説明またはサポートしており、32.0%を占める。Feather、Neverlandなどはさらにアクションごとに分業し、新たなリスクには再検討の時間を確保し、限度額の引き下げや緊急停止は迅速に実行できる。

  1. 20のプロジェクトが停止を説明し、7が退出関連の取り決めを開示

これら7件は、資金の撤回、流動性の引き上げ、参加者変更後の秩序ある退出を含み、7つのプロジェクトが即時に資金を取り戻せることを意味するものではない。別に3つが、鍵の復旧または署名参加者の変更を説明している。

これらの事例が示す共通の考え方は、日常業務を実行チームに委ね、投資範囲の拡大とルール緩和の決定を別途管理し、緊急対応に明確で限定された権限を設定することである。

目次

調査範囲と方法 / 投資制限 / ルール変更 / 緊急対応
業務分析と研究結論 / 資料と研究説明

資料の基準日:2026年10月28日、統計証拠の追加確認:11月3日、事例詳細の追加確認:11月5日。割合はドキュメントの開示またはソースコードによるサポートを反映するもので、本番環境での有効化率を意味しない。

100のプロジェクトが5つの資金業務類型をカバー

調査範囲と方法

調査対象には、デジタル資産決済、投資、融資・貸付、発行サービスが含まれる。当初の主要業務別にグループ化し、各対象を1グループに計上した結果、合計100となった。

サンプル業務分布

融資・信用業務はローン、担保、プロトコル資金に注目し、資産管理・戦略業務は金庫への投資と資金移動に注目し、決済・給与は企業の出金に注目し、RWA・発行業務は現実世界資産のオンチェーン発行と管理に注目する。その他のカテゴリには、クロスチェーンおよび関連プロトコルの資金操作が含まれる。

研究方法

公式ドキュメント、ヘルプセンター、製品説明、およびアクセス可能なコードに基づき、4種類の事実を項目ごとに記録する。人員と署名の権限、取引または投資の制限、ルール変更の権限と発効条件、異常後の停止と復旧の取り決めである。各記録は、出典URL、製品またはバージョン、およびその判断を支持する具体的な内容に対応する。

証拠台帳は140の異なる出典URLを索引している。100の対象のうち、64は少なくとも1つの主要な統計基準に合致するメカニズムが見つかり、32は資料が限定的または主要メカニズムが未確認であり、4は過去の移行またはプレリリース設計に関わるためメカニズム統計には計上していない。64の対象は、署名・人員権限、取引・投資制限、ルール変更、緊急対応をカバーし、以下の3つの主要な発見に限らない。

統計の口径

指標は適用される業務に応じて分母を取る。投資制限は30の資産管理プロジェクトを分母とし、変更待機はルール変更権限を説明する50のプロジェクトを分母とし、緊急対応は全100の対象を分母とする。各メカニズムは重複しうる。ドキュメントの開示、ソースコードによるサポート、本番での有効化は別々に扱う。本レポートの割合は前2種類を統計し、未開示の項目を「備えていない」と判断しない。

署名技術と業務承認は別々に記録する。MPCは複数の参加者が鍵シェアを用いて協力して署名を生成する。マルチシグは通常、異なる鍵でそれぞれ署名し、その後オンチェーンプログラムが署名数を検査する。業務承認者と署名参加者は同一である必要はない。管理者による変更待機と顧客の償還待機も別々に計上する。

レポートは公開された設計とその業務上の意味を分析する。具名事例は対応する製品とバージョンに沿って紹介する。公開資料だけでは、実際の設定、実行効果、復旧時間を確認するには不十分である。

30の資産管理プロジェクトのうち、11が具体的な投資制限を開示

発見一:投資制限

30の資産管理・戦略プロジェクトのうち、11が投資可能な市場、資産、コントラクト機能、または資金上限を明確に説明しており、36.7%を占める。これらのプロジェクトは、誰が署名できるかを列挙するだけでなく、権限を具体的な操作範囲に細分化している。

RockSolid:戦略マネージャーは資金を移動できるが、新規戦略には共同承認が必要

rETH金庫の例では、RockSolidが販売代理店を務める。戦略マネージャーが新戦略を提案し、RockSolidはMPCプロセスを通じてホワイトリスト承認に参加する。その後、戦略マネージャーは承認済み戦略間で資産を配分・リバランスできる。すべての取引は署名ルールに適合しなければならず、ルールに適合しない要求は拒否される。

純資産価値(NAV)も分業を採用する。戦略マネージャーが更新を提案し、販売代理店がオンチェーンデータに基づいて再確認し、共同で確認する。この事例では、戦略の受け入れ、日常の操作、NAVの確認を異なる職責に委ね、運用の余地を確保しつつ、単独で投資方針を変更することを制限している。

投資範囲を承認 → 日常取引を提出 → 署名ルールを実行

戦略とプロトコルを確認 → 承認範囲内で資金移動 → ルールに適合しない要求を拒否

Nerona:リスク配分、戦略運用、署名を異なる当事者が担う

sUSDnr金庫のリスク管理ドキュメントは、Upshiftのホワイトリストとリスク配分、Neronaの戦略運用、Fordefi MPCの署名職責を分離している。運用チームは承認範囲内で資金を配分する。手数料や引き出しサイクルなどの重要パラメータの変更には24時間の待機が適用され、緊急機能には別途の停止と撤回の取り決めがある。

事例から得られる判断

こうした設計は、投資の実行権限と投資範囲を変更する権限を分離する。頻繁な資金移動を必要としつつ、毎回の操作で決定を上に集めたくないチームに適している。制御の本質は、実行システムが承認済みの範囲に従って取引を検査し、範囲を拡大するには別の承認プロセスを経る必要がある点にある。

全100の対象と業務カテゴリを通じて、6がMPCを明確に採用し、そのうち4が取引または投資の制限も説明している。RockSolid、Fipto、Yuzu、Neronaである。決済分野のFiptoは受取人ホワイトリストで取引を制限し、マルチシグプロセスとロール権限を設定している。資産管理の事例はさらに戦略とプロトコルの範囲に関わる。

CertiKのセキュリティ解説|取引制限と署名戦略

MPCやマルチシグは投資リスク管理と同義ではなく、なお取引ルールの適用範囲と回避経路の有無を確認する必要がある。ホワイトリスト以外にも、レバレッジ、負債、集中度に注目すべきである。

Peiyu Wang | Senior Audit Partner at CertiK

図版 Google Cloud Multi-party Compute アーキテクチャ

業界技術事例 | v1beta プレビュー | 「調査範囲と方法」および「投資制限」を参照

Google Cloud Multi-party Compute 公式アーキテクチャ

コーディネーターがリクエストをルーティングし、鍵シェアを保持するトラステッド実行環境(TEE)が認可を検証して協調署名する。図は業界アーキテクチャの参考例である。

出典 Google Cloud Multi-party Compute Architecture

ソースドキュメントは2026年10月27日更新と記載されている。公式SVGをPNGに変換し、図と文はそのまま提示している。

ライセンス CC BY 4.0

50のプロジェクトのうち、16がルール変更の待機を開示またはサポート

発見二:ルール変更

ルール管理または意思決定権限を説明する50のプロジェクトのうち、16が変更待機メカニズムを同時に説明またはサポートしており、32.0%を占める。そのうち7が少なくとも1つの明確な非ゼロの待機時間を列挙している。これは公開開示またはソースコードによるサポートの割合であり、実際の有効化率ではない。設定可能なコードがあるだけでは、本番環境で非ゼロの待機が有効化されていることは確認できない。

Feather:新規市場と限度額の引き上げは待機、限度額の引き下げは即時実行

Feather金庫のキュレーターが新規市場を追加する、または限度額を引き上げる場合、タイムロックを経る必要がある。限度額の引き下げは即時実行できる。資金移動担当者は承認済みの市場と限度額内でのみ操作し、Guardianロールは実行待ちの変更を拒否できる。タイムロックとは、特定の変更をキューに入れ、規定の時間を待ってから実行するメカニズムである。

この取り決めは、新たな投資の承認と限度額の引き締めを区別する。新規市場と限度額の引き上げには再検討の窓を設け、限度額の引き下げは即時実行できる。ただし限度額の引き下げは主に今後の資金配分を制約するものであり、既存のポジションが解消されたこと、または現在のリスクエクスポージャーが減少したことを意味しない。

Neverland:ガバナンス、リスクパラメータ、停止で異なる発効条件

24時間 / メイン市場のガバナンスおよび関連アップグレード、ドキュメントに列挙された待機の下限

1時間 / 関連リスクパラメータの変更、ドキュメントに列挙された待機の下限

即時実行 / Sentinel Safe が別個の緊急権限で緊急停止をトリガー

これらの条件は、ドキュメントに列挙された操作に対応する。Loopscaleもパラメータごとに分類する。新たな担保の追加やローン・トゥ・バリュー(LTV)の引き上げは24時間のタイムロックをトリガーし、オリジネーションフィーなどの手数料設定の変更もタイムロックの制約を受ける。担保の削除、LTVの引き下げ、APYの更新は即時実行できる。LTVはローン金額と担保価値の比率であり、借入可能規模に影響する。

事例から得られる判断

待機メカニズムは、リスクを拡大しうる変更に検査と介入の時間を確保し、停止や限度額の引き下げなどの動作にはより迅速な経路を採用できる。こうした設計を評価するには、変更内容、待機時間、モニタリングと取消の権限、さらにアップグレードやその他の重要な管理エントリポイントが相応の制約を受けているかを併せて見る必要がある。

CertiKのセキュリティ解説|ルール変更、アップグレード、管理権限

タイムロックは有効なモニタリングと取消の権限を組み合わせ、アップグレードおよび重要な権限変更をカバーする必要がある。限度額の引き下げは既存リスクの減少と同義ではなく、その実際の作用を明確にすべきである。

Peiyu Wang | Senior Audit Partner at CertiK

20のプロジェクトが停止を説明し、7が退出関連の取り決めを開示

発見三:緊急対応

100のプロジェクトのうち、20が停止の取り決めを説明し、7が退出、撤回、移行関連の取り決めを開示し、3が鍵の復旧または署名参加者の変更を説明している。これには投資ポジションの引き上げ、資金の移行、参加者変更後の秩序ある金庫の終了が含まれ、資金がすでに機関の利用可能なウォレットに戻ったと一括して解釈することはできない。

Gearbox:個別停止、再開には複数人の承認が必要

Gearbox V3.0のドキュメントでは、2つの指定分析アドレスがそれぞれ停止をトリガーできるが、これらのアドレスは停止権限のみを持つ。再開操作は4/12マルチシグが処理し、すなわち12の署名者のうち少なくとも4が同意する。技術変更は6/12マルチシグが管理し、2日のタイムロックが適用される。したがって迅速対応者は、一般管理権を同時に得る必要がない。

Yuzu:リスク監視を事前承認済みの引き出しに接続

Yuzuのドキュメントは、Hypernativeの監視、Sentinelインシデント対応システム、Fordefi MPCウォレットを接続し、脅威を確認した後に事前承認済みの引き出しを実行する。アラートを送るだけの場合と比べ、この設計は資金処分の動作を追加している。実際にどれだけ撤回でき、いつ着金するかは、なお承認範囲と退出条件に依存する。

Surge:シェアの紛失と閾値漏洩の疑いで異なる復旧方式

Surgeは暗号化バックアップと複数のリカバリーエージェントが参加する閾値復旧により、シェアの紛失や破損を処理する。署名閾値に達するシェアの漏洩が確認または疑われる場合は、新しい鍵を生成し資金を移行する。前者は署名の可用性を回復し、後者はさらに元の鍵への依存を終わらせる必要がある。

7件の退出関連記録のうち、CharmのemergencyBurnは指定区間の流動性を撤出し、RockSolidは利用不能な参加者の交代を通じて秩序ある移行または金庫の終了をサポートする。いずれも資金がすでに機関の利用可能なウォレットに戻ったことを直接証明するものではない。3件の復旧記録のうち、Surge以外の2件はRockSolidの参加者交代とDueの復旧設定に由来し、いずれも復旧演習が完了したことを意味しない。同じ対象は、異なるメカニズムに応じて退出と復旧のカテゴリにそれぞれ計上できる。

事例から得られる判断

緊急対応にはすでに分業が明確な設計が現れている。低いハードルで限定された停止権限はリスクの封じ込めに用い、事前承認済みの引き出しは資金の処分に用い、復旧プロセスは署名能力の再構築に用いる。鍵が漏洩する可能性がある場合には、鍵の交換と移行も必要であり、単に旧署名能力を復旧するだけでは元の制御リスクは解決しない。

CertiKのセキュリティ解説|資金撤回と復旧演習

停止と署名の復旧は資金が利用可能であることと同義ではなく、演習を通じて実際の着金時間を検証すべきである。鍵の漏洩が疑われる場合には、旧鍵が引き続き資産を制御できないことを確保する必要がある。

Peiyu Wang | Senior Audit Partner at CertiK

図版 資金ガバナンスメカニズムの開示状況

「投資制限」「ルール変更」「緊急対応」を参照。

開示されたガバナンスメカニズム

投資制限とルール変更の待機はそれぞれ30と50の対象を分母とする。緊急対応は全100の対象を分母とし、各項目は重複しうる。

投資制限と緊急対応は、最終的に資金が計画通りに使えるかに影響する

業務分析と研究結論

機関がデジタル資産を管理するには、チームに日常の操作を完遂させると同時に、承認範囲内でリスクが蓄積するのを防ぎ、異常後の資金処分能力を確保する必要がある。以下に示す2つの独立して構築したシナリオは、レポートにおけるメカニズムの違いが業務成果にどう影響するかを説明する。

シナリオ一:プロトコルはホワイトリストのまま、ポートフォリオのレバレッジは上昇し続ける

戦略チームは継続的に資産を担保に入れ、借り入れ、借入資金を再び投入し、常に同じ承認済みプロトコルを使用する。相互作用の対象は変わらないが、ポートフォリオの負債、レバレッジ、担保集中度は上昇しうる。このとき、対象コントラクトのホワイトリストだけではリスクを制限できない。

相応の制御は3つの層をカバーする必要がある。呼び出しを許可するプロトコル、実行を許可する関数と金額、そして取引後のポートフォリオの負債と集中度である。前2層はコントラクトやウォレットポリシーで実行できる。ポートフォリオ指標には、価格、ポジションデータ、および相応のリスク管理システムがさらに必要である。

シナリオ二:帳簿上1000万、2日以内の支払いまであと120万不足

即時利用可能 80万 / 貸出ポジション 420万 / 定期戦略 500万

ある機関が1000万USDT相当の資産を保有し、うち80万は即時利用可能、420万は貸出ポジション、500万は定期戦略にある。2日以内に200万の支払いが必要で、少なくともあと120万が期限内に着金する必要がある。投資の停止は直接流動性を解放せず、引き出しの提出も資金がすでに着金したことを意味しない。

この機関に信頼できる支払能力があるかは、退出可能額、引き出しキュー、期間、外部流動性を確認する必要がある。復旧演習でも、システムがいつ再起動したかだけでなく、資産が実際に利用可能なウォレットに戻った時間を記録すべきである。

研究結論

第一に、11の資産管理事例が具体的な投資制限を開示し、日常の実行をチームに委ね、投資範囲の変更を別途管理する手法を示している。機関同士で比較する価値があるのは、制限の適用範囲と実行される位置である。

第二に、16のプロジェクトがルール変更の待機メカニズムを開示またはソースコードでサポートし、一部の事例はリスクの拡大と緊急時の収縮をさらに区別している。管理権限の制約は、日常取引だけを制約するのではなく、変更、待機、取消、最終的な発効を貫く必要がある。

第三に、緊急対応の事例は停止、撤回、署名復旧をそれぞれ処理している。これらの取り決めが資金の可用性を保障できるかは、実際の設定、資産の退出条件、復旧演習の結果に依存する。

資料と研究説明

本文の主要資料は以下のとおり。完全な証拠と統計記録は研究台帳を参照。

RockSolid|Architecture & Roles(rETH 金庫)

Nerona|Risk Management(sUSDnr)

Fipto|Client Asset Security

Charm|AlphaProVault(emergencyBurn と withdraw)

Feather|Vault Mechanics

Neverland|Security

Loopscale|Loopscale Vaults

Gearbox|V3.0 Operational Multisigs

Yuzu|Product Documentation

Surge Credit|Disaster Recovery

Due|Developers Overview

研究説明

本文は公式ドキュメントと公開ソースコードに基づいて、特定の製品とバージョンを分析する。完全なプロジェクト一覧、出典、計数ルールは研究台帳および出典索引を参照。

調査パートナー:CertiK、Lunaray。

メディア協力に感謝:PANews、Techub News、Odaily、金色財経、ChainCatcher、PureNews、Chain Times。

共同調査機関について

DeepSafeは機関級MPCセルフカストディウォレットを中核とし、ウォレット管理、ポリシーエンジン、チーム承認の機能を提供し、Wallet as a Service(WaaS)を通じた業務システムへの接続をサポートして、機関のデジタル資産管理と協働のシナリオにサービスを提供する。

DeepSafe 公式サイト

連絡先メール Ray@deepsafe.net

CertiKはWeb3セキュリティサービス機関であり、スマートコントラクト監査、形式検証、継続的リスクモニタリングなどを提供し、プロジェクトと機関がデジタル資産関連のセキュリティリスクを識別・管理するのを支援する。

CertiK 公式サイト

研究レポート公開ポスター

研究レポート公開ポスター

調査パートナーとメディア協力

調査パートナーとメディア協力

共有先:

著者:加密攻略

本記事はPANews入駐コラムニストの見解であり、PANewsの立場を代表するものではなく、法的責任を負いません。

記事及び見解は投資助言を構成しません

画像出典:加密攻略。権利侵害がある場合は著者へ削除をご連絡ください。

PANews公式アカウントをフォローして、強気・弱気相場を一緒に乗り越えましょう
PANews APP
山東省警察が省をまたぐネット恐喝事件を摘発、資金は代理決済プラットフォーム経由で仮想通貨により洗浄
PANews 速報