教育目的の情報であり、投資助言ではありません。投資により損失が生じる可能性があります。
端的な答え
ガバナンスタイムロックは実行を制御する仕組みであり、追加の投票ではありません。ガバナンスがペイロードを承認すると、権限を持つ提案者がその具体的なオペレーションをスケジュールします。コントラクトは実行可能になる時刻を記録し、それ以前の実行を拒否します。この遅延により、保留中のアップグレード、パラメーター変更、トレジャリー送金、ロール変更を、発効前に観察できます。
公称の遅延時間は、制御の一要素にすぎません。オペレーション ID、最短の実行可能時刻、期限切れの規則、先行オペレーション、提案者、実行者、キャンセラー、管理者、そして対象を制御できる他のすべての経路を確認してください。オペレーションのキュー登録が遅い、監視による検知が遅い、出金に時間がかかる、または別の特権鍵が同じ変更を即座に実行できる場合、48-hour のタイムロックが 48-hour の退出可能時間を提供するわけではありません。
タイムロックは、アクションが正当か安全かを判断しません。人や自動監視システムが、呼び出しのデコード、影響のシミュレーション、権限がある場合のキャンセルや一時停止、変更内容の周知、そして実際の退出経路がある場合のポジション解消を行うための時間を提供します。
仕組み
- 権限をタイムロックに付与します。 タイムロックは対象コントラクトを所有するか、そのコントラクト上で必要なロールを保持しなければなりません。ガバナーが対象への権限を持たなければ、提案が可決されても何も変わりません。別の管理者が並行して権限を保持していれば、その経路が遅延を迂回する可能性があります。
- 提案者が具体的なオペレーションをスケジュールします。 OpenZeppelin の
TimelockControllerでは、単一オペレーションの ID はtarget、value、data、predecessor、saltをハッシュして生成されます。バッチオペレーションでは、対応する配列に同じ依存関係とソルトを加えてハッシュします。どのフィールドを変更しても、別のオペレーション ID になります。ソルトは、それ以外が同一のアクションを区別します。 - 最小遅延はスケジュール時に始まります。 投票の可決が必ずしもタイムロックの開始を意味するわけではありません。スケジュール時に、コントラクトの現在の最小遅延以上の遅延を用いて実行可能時刻が記録されます。OpenZeppelin のオペレーションは
UnsetからWaiting、次にReadyへ移り、実行に成功すると最終的にDoneになります。 - 実行時に依存関係と権限が検証されます。 先行オペレーションは、すでに
Doneでなければなりません。呼び出し元は実行者の規則を満たし、対象への呼び出しも成功する必要があります。実行者はスケジュール済みのペイロードを変更できません。実行者ロールをaddress(0)に付与すると、成熟後は誰でも実行できるため可用性は高まりますが、実行可能になった後の正確な実行時点を任意のアカウントが選べるようになります。 - キャンセルすると、保留中のオペレーションは初期状態に戻ります。 現行の OpenZeppelin コントラクトでは、
CANCELLER_ROLEを持つアカウントが、実行可能になったものを含め、未実行の保留中オペレーションをキャンセルできます。再スケジュールすると新たなタイマーが始まります。ロールの設定は重要です。旧バージョンや他のタイムロックでは、提案者や管理者にキャンセル権が与えられている場合があります。 - 期限切れの有無は実装によって異なります。 OpenZeppelin の
TimelockControllerには猶予期間による期限切れが組み込まれていません。実行可能になったオペレーションは、実行またはキャンセルされるまでその状態を維持します。一方、Compound v2 の Timelock はeta + GRACE_PERIODまでの実行を要求し、ソースコードではGRACE_PERIODが14 daysに設定されています。Governor Bravo は、その境界を越えたキュー登録済み提案を期限切れとします。 - 管理権限の変更にも遅延を適用する必要があります。 OpenZeppelin では、タイムロックが自身を呼び出す場合に限り
updateDelayを実行できます。自己管理型の構成にすれば、ロール変更も同様にスケジュール済みオペレーションを経由します。初期設定で使用した一時的な外部管理者は、設定完了後にそのロールを放棄すべきです。そうしなければ、別の信頼経路として残ります。
キュー登録されたアクションごとに、コントラクトの状態とイベントから制御記録を再構築してください。記録する項目は、チェーン ID、タイムロックと対象のアドレス、オペレーション ID、デコード済みペイロード、提案者、スケジュール取引とその時刻、最小遅延、実行可能時刻、期限がある場合はその時刻、先行オペレーション、実行者ポリシー、キャンセル権限、最終的な取引状態です。ガバナンスサイトだけを根拠にこれらの項目を推測してはいけません。
具体例
ある提案が、レンディング市場の清算しきい値を 75% から 60% に引き下げるとします。投票は Monday 12:00 UTC に終了しますが、提案者がオペレーションをスケジュールするのは Tuesday 18:00 UTC です。設定された遅延は 48 hours なので、最短の実行可能時刻は Wednesday 12:00 UTC ではなく Thursday 18:00 UTC です。
このオペレーションでは、リスク管理コントラクトを target、ネイティブトークンの value をゼロとし、エンコード済みのパラメーター変更 data、先行オペレーションなし、開示済みの salt が含まれます。これらのフィールドからハッシュを再計算し、イベントで発行されたオペレーション ID と一致することを確認しなければなりません。画面上の説明が同じでも、市場アドレス、しきい値、ソルトのいずれかが違えば別のオペレーションです。
したがって、ユーザーにはスケジュール時点から 48 hours ありますが、実際に退出へ使える時間はより短くなります。通知がスケジュールの 6 hours 後に届き、アンステーキングまたは出金キューに 24 hours かかるなら、残る余裕は 18 hours だけです。
usable response time = ready time - detection time - exit settlement time
緊急用マルチシグが出金を即座に一時停止できる場合、インシデント中の損失を抑えられる一方、キュー登録済みの変更前に退出できなくなる可能性もあります。この権限は独立して検証してください。実行後は、対象の実際のストレージと発行イベントを確認します。タイムロックの実行取引が成功しても、期待する経済的結果の理解が正しいとは限りません。
リスクと管理策
- 迂回可能な権限。 所有者、プロキシ管理者、アクセス制御ロール、アップグレードビーコン、緊急評議会、モジュール、クロスチェーン実行者を洗い出します。最短の特権経路が実効的な遅延を決めます。
- ペイロードの置換または不十分なデコード。 生のフィールドからオペレーション ID を再計算し、プロキシの実装を特定し、すべてのセレクターと引数をデコードして、バッチ全体をシミュレーションします。人が読める提案文は実行ペイロードではありません。
- 通知時間の不足。 フォーラム投稿だけでなく、オンチェーンのスケジュールイベントとキャンセルイベントから通知します。スケジュール確定から最短の実行可能ブロックまたは時刻までを通知期間とし、そこから検知と退出処理にかかる時間を差し引きます。
- キャンセル機能の不全。 どのアカウントがキャンセルできるか、実際に稼働しているか、必要なしきい値は何か、実行可能になった後もキャンセルできるかを確認します。インシデント前に取引手順をリハーサルしてください。
- 実行者の機能不全またはタイミング操作。 制限付きの実行者は利用不能になったり、意図的に実行を遅らせたりする可能性があります。オープンな実行は可用性を高めますが、第三者が成熟直後に実行できるため、関連する価格、オラクル更新、ユーザーポジションはその境界時点で安全でなければなりません。
- 古いキュー登録済みアクション。 期限切れがない場合、古い実行可能オペレーションが無期限に実行可能なまま残ります。放棄したオペレーションを追跡し、明示的にキャンセルしてください。猶予期間がある場合は正確な終了時刻を監視し、期限切れ後は新たなガバナンス手続きを要求します。
- 依存関係とバッチのリスク。 先行オペレーション ID とアトミックバッチの順序を検証します。一つの呼び出しのリバートがアトミックバッチ全体を阻止することがあり、誤った依存関係が有効なオペレーションをデッドロックさせることもあります。
- 安全でない管理。 遅延の短縮、ロールの付与、タイムロックの置換もタイムロック自体の対象にします。初期設定用の管理者を削除し、実行可能な提案者と実行者を少なくとも一つずつ維持して、制御が永久にロックされる設定を避けてください。
- 信頼できる退出経路がない。 遅延を、出金キュー、ブリッジのファイナリティ、市場流動性、一時停止権限、混雑と比較します。実行前に資産を移動できなければ、公表された遅延はユーザー保護になりません。
運用上の基準は、画面上のカウントダウンではなく、証拠に裏付けられたタイムラインです。スケジュールイベント、デコード済み呼び出し、シミュレーション結果、ロール保有者、キャンセル計画、最短と最終の実行可能時刻、連絡経路、実行後の状態差分を保存してください。
よくある誤解
- 「遅延は投票終了時に始まる。」 デプロイ済みの実装が両者を明示的に連動させていない限り、通常は可決済みアクションがスケジュールされた時点で始まります。
- 「誰でも実行できるなら、誰でも提案を変更できる。」 オープンな実行者が起動できるのは、オペレーション ID と条件が一致するスケジュール済みペイロードだけです。
- 「実行可能になれば、直ちに実行されなければならない。」 Ready は実行資格があるという意味です。実際の実行には、取引、権限、満たされた依存関係、成功する対象呼び出しが必要です。
- 「すべてのタイムロックに実行可能期間がある。」 期限切れは実装によって異なります。Compound v2 は猶予期間を使用しますが、OpenZeppelin の
TimelockControllerではデフォルトで実行可能オペレーションが期限切れになりません。 - 「長いタイムロックはガバナンスリスクをなくす。」 遅延が役立つのは、監視、内容の理解、キャンセルまたは一時停止、周知、退出のすべてが実行前に可能な場合だけです。並行する管理者や出金停止は、その効果を無効にし得ます。
関連トピック
出典
- Governance API: TimelockController - OpenZeppelin Documentation（参照日：2026-08-20）
- Access Control: Delayed operation - OpenZeppelin Documentation（参照日：2026-08-20）
- Timelock.sol - Compound Finance（参照日：2026-08-20）
- GovernorBravoDelegate.sol - Compound Finance（参照日：2026-08-20）