DeFiのガバナンス変更に気づくには｜可決から実行までの対応と自社への影響

ある会社が、手元資金の一部をAaveに預け、それを担保に借入もしています。運用チームは毎日ポジションを見ていますが、見ていないものがあります。Aaveの設定そのものが、投票で変わることです。

担保の条件を厳しくする提案が可決されたと、後から知ったとします。Aaveの公式説明では、通常のプロトコル更新は可決の後、1日のタイムロック（実行までの待機時間）を経て実行されます。ガバナンスの中核権限に関わる変更なら7日です。

通常の変更なら、この1日で全部を終える必要があります。気づく、中身を調べる、どうするか決める、手を打つ、確かめる。間に合わなければ、自社のポジションが清算されるおそれがあります。

どうすれば間に合うのか。まず知っておきたいのは、提案文の説明と、実際に実行される中身が同じとは限らないことです。そのため、ガバナンス変更は、提案文ではなく、次のもので追います。

• 実際に実行される呼出データ
• 対象のチェーン
• 実行できるようになる時刻と、変更前後の値

それを自社のポジションや機能とのつながりに突き合わせます。そしてタイムロックの待機時間を、気づく・調べる・決める・手を打つ、それぞれの締切に割り振ります。そうすれば実行の前に手を打ち、実行の後に結果を確かめられます。

チームの中では、運用・リスクの担当が判断し、呼出データの解析やシミュレーションはエンジニアが受け持ちます。以下では、提案に気づくところから、実行後に確かめるところまでを順に追います。

議論から実行まで、どの段階で気づけるか

ガバナンス変更は、1つの画面では終わりません。Aaveでは次の順に進みます。

1. フォーラムでの議論
2. Snapshotによる温度感の確認（TEMP CHECK）
3. ARFC（最終コメント募集）
4. AIP（オンチェーン提案）と、Ethereum上の投票
5. 必要に応じて、別チェーンへの実行データ（payload）の配送

冒頭の1日と7日は、この後に来るタイムロックです（Aave「Proposals」）。これはAaveの今の例です。ほかのプロトコルに同じ日数を当てはめる根拠にはなりません。

早い段階のフォーラム投稿で気づけば、準備の時間が増えます。ただ、説明や実装はまだ変わり得ます。反対に、オンチェーンの実行だけを見張っていると、手を打つ時間が残りません。利用の停止、担保の調整、承認の流れの変更などです。

そこで、各段階を別々の情報源から取り込み、同じ提案に結び付けます。段階ごとに分かることと、運用の動きは次のとおりです。

段階ごとの取得元と、まだ確定していないことは、後半の「実装する人向けの詳細」にまとめました。

Compound Governor Bravoにも、提案の作成・待機登録・実行を知らせるイベントとTimelockがあります（Compound Governance Docs）。

画面の通知だけに頼らないでください。公式のフォーラム・APIと、オンチェーンのイベントを両方使います。そうすれば、掲載の遅れ、名称変更、サービス停止のどれか1つで見落とすことを減らせます。

1件の変更を、説明と実際の中身の両方で記録する

アラートの本文をそのままチケットに写しても、影響は分析できません。説明文と実際の呼出データ（calldata）を、1件の「変更レコード」にまとめます。実行の時刻も一緒に持ちます。

両方を持つと、突き合わせができます。たとえば説明は「手数料を微調整する」でも、実際にはどの市場の何bp（ベーシスポイント）を変えるのか。これを確かめられます。

プロトコルの公式APIや、ガバナンス情報をまとめたサービスは、気づくためと最初の分析に使えます。ただし、それを唯一の台帳にはしません。最終的な判定では、次のものをRPC（チェーンに問い合わせる窓口）から取り直します。

• チェーン上のコントラクトアドレスと、提案の状態
• calldata
• タイムロックの操作

フォーラムの投稿と提案IDは、1対1とは限りません。1つの提案が、複数のチェーンへ実行データを送ることもあります。そこで、親の変更と、チェーンごとの実行を別々に持ちます。同じメッセージの再送、宛先での遅れ、一部だけの成功を表せるようにするためです。記録する項目と記録例は後半にまとめました。

自社のどこに響くかを、つながりからたどる

「Aaveの提案だから、Aave担当へ知らせる」だけでは、間接的な影響を見落とします。自社が直接預けていなくても、影響を受けることがあります。

• 使っているボールトが、Aaveへ資金を振り分けている
• 価格オラクルを共有している
• 担保のトークンが、別のプロトコルで使われている

そこで、自社のものの依存関係を図（依存関係グラフ）として管理します。最低限、次のものを登録し、変更されるアドレスから逆向きにたどります。

• ウォレット、ポジション、資産、市場
• オラクル、接続用コントラクト、トークン承認、キーパー（自動実行者）
• 会計ルール、顧客向け機能

冒頭の会社で考えます。担保係数（LTV）や清算閾値を下げる提案が出たら、変更後のヘルスファクターを計算し直します。必要な返済や追加担保の額も出します。安全の余裕が社内の下限を割るなら、止める条件に当たります。

ほかの種類の変更でも、実行前に計算する値と、止める条件の例を決めておきます。

それぞれの直接の差分と、波及しうる対象は後半の表にあります。

図には、今のポジションのほかに次のものも入れます。承認済みでまだ実行していない取引、一括処理のジョブ、顧客への約束、会計上の分類です。

影響の大きさは、プロトコルのTVL（預かり資産の総額）や提案のタイトルでは決めません。最大損失、影響する顧客数、復旧時間、元に戻せるか、実行までの残り時間で決めます。ポジションの清算余裕そのものの監視はDeFiポジション監視と清算リスク対策で扱っています。

可決された変更は、安全と言えるか

Beanstalkでは2022年4月、攻撃者がフラッシュローン（同じ取引の中で借りて返す融資）で、一時的に投票力を集めました。その攻撃者の提案が可決・実行され、資産が流出しています（Beanstalk「Governance Exploit」）。

つまり、可決されたことは、安全の証拠になりません。票数は、実行データが安全かどうかを保証しないのです。

そこでエンジニアに頼むのは、次の2つです。

• 中身を読む：呼出先ごとにABI（関数の定義）を特定してcalldataを解読し、現在値、提案値、許容範囲、変更する主体を、機械で読める差分にする。
• 変更後を再現する：本番を写したフォーク環境で、正規の手順どおりに提案を実行し、自社の預入・引出・借入などを試す。

プロキシのアップグレード（コントラクトの中身の差し替え）なら、新しいコードの中身や管理者の経路も確かめます。ガバナンスを実行する側の権限とプロキシの変更は、提案内容を確かめる人とは別の担当が検証します。手順は後半にまとめました。

運用・リスクの担当が知っておくべきことがあります。シミュレーションは、条件を再現しきれていないことがあります。次の場合は、成功しても安全とは限らないので、判定を保留します。

• 使ったブロックが古い、またはオラクルの更新を再現していない
• 別チェーンの実行データを省いた
• フロントエンドだけを試した

逆に、実行が失敗したときは、権限や実行時刻を正しく再現できていないだけのこともあります。危険と決めつける前に、まずそこを切り分けます。

待機時間を、誰のどの締切に割り振るか

待機時間は「いつか確認する期間」ではありません。気づく、技術的に調べる、事業として決める、手を打つ、確かめ直す。この5つに割り当てる持ち時間です。実行できる時刻から逆算し、重大度ごとの締切と、不在のときの代わりを決めます。

役割は5つに分け、判断する人と実行する人を別にします。

各役割が受け取る入力は、後半の表にあります。

自動化するのは、情報集め、解読、依存の候補探し、シミュレーションまでです。資産の移動や顧客機能の停止を、通知だけで自動実行はしません。

事前に承認した、損失を広げない方向の操作を自動にする場合もあります。そのときも、次のことをはっきり決めます。

• 対象のプロトコルと金額の上限
• 許可する関数と有効期限
• 失敗したときに止めること

アラートに何を出し、どう重さを分けるか

フォーラムの更新をすべて同じ通知先へ流すと、大事な変更が埋もれます。アラートは、情報の多さより「すぐ動けるか」で作ります。

提案名より先に出すのは、次の項目です。

• 実行までの残り時間と、次の判断期限
• 自社の影響対象と、変更前後の値
• 最大損失と担当者

道具の例として、OpenZeppelin Monitorがあります。コントラクトのイベント・関数・トランザクションの条件と、確認ブロック数を設定できます。通知先も、Slack・メール・Webhookなど複数を選べます（OpenZeppelin Monitor Docs）。

監視サービス自体が止まることにも備えます。RPCから直近のブロックを読み直せるよう、再開地点（チェックポイント）を持っておきます。

重さは4段階に分けます。

• Critical（緊急）：短い猶予で、清算、資産移動、任意のアップグレード、待機の短縮が起こり得る。すぐに呼び出す。
• High（高）：本番のポジション、顧客機能、会計の値に響く。担当者に「受け取った」と明示してもらう。
• Medium（中）：将来の上限、インセンティブ、対応資産が変わる。通常の変更管理に登録する。
• Info（情報）：議論の初期で、実行内容がまだない。追いかける対象にし、段階が進んだら評価し直す。

監視がうまくいっているかは、通知の件数では測りません。次の指標で測ります。

• 気づけなかった提案、関連付けの誤り、解読できなかった率
• 実行前に分析を終えた率、影響対象の見落とし
• 受け取りの確認までの時間、期限内に対応できた率、実行後の差分の不一致

テスト用の提案や、通知経路の障害を定期的に起こしてみます。担当者が替わっても回るかを確かめるためです。

実行された後、何を確かめるか

実行の取引が「成功」しても、次のようなことが起こり得ます。

• 設定値が別の市場に当たった
• インデクサー（チェーンのデータを集めて検索できるようにする仕組み）が古いABIのまま
• キーパーが新しい条件で失敗する、顧客画面の利率表示が古い

そのため、取引の成功だけで終わりにはしません。実行ブロック、イベント、ストレージ、プロトコルのAPI、自社のデータベース、顧客機能を順に突き合わせます。そしてシミュレーションで期待した差分と比べます。チェーンをまたぐ提案なら、宛先のチェーンごとに受信・実行・重複の防止を確かめます。

食い違いを見つけたら、元の値へ戻す前に、2つを確かめます。

• 正規の提案なしに変更できる権限が、どこかにないか
• 巻き戻すことで、清算や会計のずれを増やさないか

巻き戻し自体が、新たな損失を生むことがあるからです。そのため、自動では戻しません。

緊急時の手順書は、事前に許可した操作だけを選べる形にします。候補は、新規取引の停止、追加借入の停止、担保追加、返済、トークン承認の縮小、退出、顧客への告知です。

導入するときに満たしておくこと

1. 利用するプロトコルごとに、フォーラム、オフチェーン投票、Governor、Timelock、チェーン間の実行コントラクトを登録した。
2. 説明文、calldata、対象チェーン、実行時刻を、同じ変更IDで追える。
3. ウォレット、ポジション、資産、オラクル、接続用コントラクト、顧客機能の依存関係を更新できる。
4. 変更前後の値を解読し、許容範囲と責任者に機械で突き合わせられる。
5. フォーク環境で、正規の実行経路と主な業務の取引を再現できる。
6. タイムロックから逆算した、分析・承認・対応・再検証の締切と代理の担当がある。
7. Critical・Highのアラートに、受け取りの明示と、上位への引き継ぎの手順がある。
8. 実行後に、チェーン、インデクサー、データベース、顧客機能を期待した差分と突き合わせる。
9. 監視の停止・RPCの欠け・チェーン間の遅れがあっても、再開地点から読み直せる。
10. 継続、縮小、停止、退出の判断基準を、資産を動かす前に承認している。

DeFi全体の仕組みと学ぶ順序はDeFi学習ロードマップで整理しています。採用前のプロトコル評価は企業向けDeFiプロトコルの調査・評価で扱っています。DAOを運営する側の実行設計はDAOガバナンスの実行設計をご覧ください。

実装する人向けの詳細

ここからは、冒頭の会社で監視とシミュレーションの仕組みを作るエンジニア向けの内容です。

段階ごとの取得元と、まだ確定していないこと

Compound Governor BravoのイベントはProposalCreated、ProposalQueued、ProposalExecuted等です。

変更レコードの項目と記録例

1件の変更レコードには、次の項目を保存します。

• プロトコル、チェーンID、Governor、提案ID、フォーラムのURL、説明文のハッシュ
• 呼出先、関数セレクタ、解読済みの引数、送金額
• 待機登録の時刻、最短の実行時刻、実行トランザクションのハッシュ

{
  "change_id": "aave:1:proposal-123",
  "stage": "queued",
  "execute_after": "2026-08-14T12:00:00Z",
  "actions": [
    {
      "chain_id": 1,
      "target": "0x...",
      "function": "setReserveFactor",
      "before": 1000,
      "after": 1500
    }
  ],
  "affected_dependencies": [
    "eth-usdc-borrow",
    "treasury-policy-07"
  ],
  "simulation": {
    "block": 24500000,
    "result": "review_required"
  }
}

change_idは、自社の中で関連付けるためのキーです。

変更の種類ごとの直接の差分と波及先

calldataの解読とフォーク環境での再現

プロキシのアップグレードでは、新しい実装のコードハッシュ、ストレージの配置、初期化関数、管理者の経路を確かめます。フォーク環境での再現は、次の5段階で進めます。

1. 基準ブロックを固定：対象チェーンのブロック番号、RPC、全ポジションと価格を保存します。
2. 正規の実行経路を再現：GovernorとTimelockを経由します。実行者だけを偽装して、任意の呼出に置き換えることはしません。
3. 全操作を実行：一部だけでなく、順序、チェーン間メッセージ、初期化も含めます。
4. 業務のトランザクションを再生：預入、引出、借入、返済、資産配分の調整、緊急退出を実行します。
5. 差分と不変条件を保存：残高の総和、ヘルスファクター、権限、価格、上限、イベント、失敗（revert）の理由を比べます。

役割ごとの入力

• 監視当番：フォーラム・API・イベントのアラート
• プロトコル分析の担当：本文、calldata、コントラクト
• 事業・リスクの責任者：最大損失、顧客影響、選択肢
• 実行担当：承認済みの手順書
• 検証担当：実行のレシート、実際の状態

XTELAができること

私たちは、利用プロトコルの依存関係の棚卸し、変更レコード、監視、フォーク環境でのシミュレーション、承認の流れ、対応手順書を設計・開発します。まず貴社が使っている1〜2のプロトコルで、提案の検知から実行後の照合までを通すPoC（概念実証）を組み、締切に間に合う運用かどうかを確かめます。ご相談はお問い合わせからどうぞ。

主要参考資料

• Aave「Proposals」（2026年9月24日確認）
• Compound v2 Governance Docs（2026年8月12日確認）
• OpenZeppelin Contracts 5.x Governance API（2026年8月12日確認）
• OpenZeppelin Monitor Docs（2026年9月24日確認）
• Beanstalk「Governance Exploit」

資料の確認日と注意

プロトコル仕様と一次資料は2026年8月12日に確認しました。AaveとOpenZeppelin Monitorの記述は、2026年9月24日時点の内容に確認し直しています。一般的な技術・運用設計の解説です。プロトコルのコントラクト、権限、提案の手順、タイムロックは変わり得ます。導入時と各提案の実行前に、公式資料とオンチェーンの状態を確認してください。投資・法務・会計・税務の判断は専門家へご確認ください。