🏛️ガバナンスガイド

ガバナンスプロセスDRCの作成、スナップショットの選択の作成、DIPの作成、スナップショットの選択、DIPの選択、DIPのキューキング、DIPの実行のステップ・バイ・ステップの概要

dYdX Foundationが作成したこのガイドは、dYdXのコミュニティがdYdXのガバナンスプロセスを理解する上で役立ちます。このガイドでは、以下の内容についてのステップ・バイ・ステップの概要を説明しています。

このガイドで紹介されている2つの例は、DIP 2（オフチェーンの提案） - 流動性プロバイダー報酬のしきい値の引き下げ、および_DIP 3（オンチェーンの提案） - セーフティモジュールの復元_、です。

DIP 2（オフチェーンの提案） - 流動性プロバイダー報酬のしきい値の引き下げ

要約：

エポック6で、dYdXコミュニティはマーケットメーカーのLP報酬ボリュームのしきい値を1％から0.25％に引き下げるスナップショットに賛成しました。エポック2でLP報酬のしきい値を5％から1％に引き下げており、それと同じプロセスでエポック6での引き下げが行われます（1％から0.25％へ）。LP報酬ボリュームのしきい値を5％から1％に引き下げるステップ・バイ・ステップの概要は以下のとおりです。

コミュニティの過半数（投票数399、$ethDYDXの86％）は、流動性プロバイダー報酬が得られるボリュームのしきい値を5％から1％に引き下げるスナップショットに投票しました。マーケットメーカーが流動性プロバイダー報酬を得られるボリュームのしきい値を5％から1％に引き下げるオフチェーンDIPは、DeFiance CapitalのJacob Goh氏（jteam0x）によって提出されました。エポック2のしきい値である1%を満たしたマーケットメーカーは、エポック3で流動性プロバイダー報酬を獲得する資格がありました。この提案ではオンチェーンのスマートコントラクトの変更は必要ありませんでした。

背景：

流動性プロバイダー報酬プログラムの一環として、このプロトコルのマーケットメイクを行う流動性プロバイダーに対してエポック（28日間）ごとに115万685$ethDYDXが分配されます。報酬は、稼働時間、両方向のデプス、ビッドアスクスプレッド、およびサポートされているマーケット数の組み合わせに基づく報酬公式に基づいて分配されます。流動性プロバイダーがこの報酬プログラムの対象になるためには、前のエポックにおいて総メーカーボリュームの最小限度割合を提供する必要があります。

dYdXのコミュニティには、流動性プロバイダー報酬のしきい値に関して「即時かつ取り消し不能なコントロール」が存在します。コミュニティをコントロールするパラメータの完全なリストはこちらをご覧ください。

コミュニティには流動性プロバイダー報酬のしきい値を引き下げる動機が与えられています。これは新しいマーケットメーカーや中小規模のマーケットメーカーにdYdXプラットフォームの流動性を高めるインセンティブが与えられるためです。さらに、プラットフォームのマーケットメーカー数を増やすことでdYdXプロトコルの一層の分散化が可能になります。

次に、dYdXのガバナンスが実際にどのように機能するかについてステップ・バイ・ステップの概要を説明します。dYdXのガバナンスプロセスの詳細についてはこちらをご覧ください。

ステップ1 - フォーラムディスカッション、DRCの作成（オフチェーン）、およびDRCのフィードバック

説明：

dYdXのガバナンスプロセスは、ガバナンスフォーラムによって推進されます。コミュニティメンバーはディスカッションスレッドにポストやコメントを行うことで、オフチェーンの大まかなコンセンサスを達成します。フォーラムディスカッションおよびDRCの作成の詳細についてはこちらをご覧ください。\注 - 運営subDAOは、コミュニティ投票のコモンウェルスからDiscourseへの移行に際する新しいフォーラムとしてhttps://dydx.forum/を立ち上げました。このガイドでは以前のDRCのディスカッションに関する言及の一部において引き続きコモンウェルスを対象にしていますが、あらゆる新しいディスカッションは新たに立ち上げられたDiscourseフォーラムで行う必要があります。\

DIP 2への適用：

Three Arrows CapitalのSu Zhu氏（zhusu）は、流動性プロバイダー報酬のしきい値を引き下げるためのオフチェーンのフォーラムディスカッションを作成しました。WintermuteのEvgeny氏、KronosのBen氏、SixtantのJosh氏など、さまざまなコミュニティメンバーがディスカッションに参加し、貴重なフィードバックを提供しています。

Discourseに投稿およびコメントする方法：

メールアカウントでDiscourseに登録し、こちらからdYdXコミュニティに参加してください。

スレッドを選択し、コメントをスクロールし、コメントにいいねや返信をしましょう。
「新しいトピック」をクリックしてトピックカテゴリを選択することで、新しいディスカッションスレッドを作成するか、DRCを投稿します。

DRCを作成する場合、こちらからテンプレートに従ってください。「提案のライフサイクル」の「DRCの作成」で概説しているように、DRCには少なくとも以下の内容を含めなければなりません：
- DRCの短い、簡潔なタイトル
- 提案の短い、簡潔な説明
- DRCの合理的理由（例：なぜ？）
- フォーラムポストのタイトルにはDRC：[DRCの短いタイトルを挿入]（例えば、DRC：新しいマーケットリクエスト）を含めなければなりません。
- コミュニティのメンバーがオフチェーンの改善の選択のために使用できるコミュニティ調査

ステップ2 - DRCのスナップショットの選択（オフチェーン）

説明：

コミュニティが大まかなコンセンサスを達成した後、10Kの提案権を有するコミュニティメンバーはスナップショットのDRCの選択（オフチェーン）を作成できます。提案権により、提案の作成および維持ができるようになります。スナップショットは、ユーザーがオフチェーンでセンチメントを表示できるようにする単純な選択インターフェースです。スナップショットでの投票は、投票に使用したアドレスが保有または委任しガバナンストークンの数によって重み付けられます。スナップショットの選択を行うコミュニティメンバーは、DRC、選択システム、選択開始日、選択終了日、およびスナップショットブロック番号の詳細を提供する必要があります。選択期間は5日間とし、（_13.2秒のブロックタイムに基づいて）_1日の選択遅延を経て選択を開始するものとします。選択遅延により、dYdXのコミュニティメンバーにはDRCの詳細な学習、$ethDYDXの購入、ガバナンストークンの投票権を委任するための時間が付与されます。ガバナンストークンを保有しているか、スナップショットブロック番号以前に投票権を委任されていたコミュニティメンバーは、投票権を有しています。スナップショットの選択の詳細についてはこちらをご覧ください。

DIP 2への適用：

コミュニティメンバーは、Su Zhu氏のポストに関するフィードバックを提供しました。コミュニティによって以下の報酬のしきい値が提案されました：

0.5％ - Three Arrows CapitalのSu Zhu氏、
1％ - BitTradingのSam氏、
2.5％ - Kronos/WOO NetworkのBen氏、
5％ - WintermuteのEvgeny氏。

次に、Su Zhu氏は以下のオプションが付くスナップショットの選択を作成しました：

MMのしきい値を1％まで引き下げる
MMのしきい値を2.5％まで引き下げる
MMのしきい値を5％で維持する

スナップショットの選択方法：

イーサリアムウォレットでスナップショットに登録し、こちらからdYdXの提案をフォローしてください。

アクティブなスナップショットに投票するには、スナップショットの投票がアクティブになる時点でガバナンストークンを保有しているか、またはスナップショットブロック番号以前にアドレスに委任された投票権を有している必要があります。
選択を行うには、提案をクリックして「はい」または「いいえ」を選択し、その後で「選択」をクリックします。

スナップショットの選択の作成方法：

スナップショットの投票を作成するには、最小でも10k ガバナンストークンの保有および/または提案の作成に使用するアドレスに委任された投票権を有している必要があります。
スナップショットの提案は、提案ごとに最大10アクションまで、1つまたは複数のアクションで構成できます。アクションとは、提案で指定された変更を指します。
提案権の最小要件である10k DYDXを満たしている場合、「新しい提案」を選択し、以下のコンテンツ要件に従って空欄に記入してください。

DRCのスナップショット選択のコンテンツ要件：

DRCの詳細（フォーラムディスカッションへのリンク付き）、
選択システム、
（_13.2秒のブロックタイムに基づいて）_選択開始日と選択終了日は合計4日間に設定します。また、
スナップショット選択は、選択開始の1日前（~6570ブロック）前にポストされます。

スナップショット選択の拘束力のある要件

ほとんどの意思決定においてスナップショット選択はシグナルとして機能しますが、スマートコントラクトを変更するような拘束力のある結果にはオンチェーン選択が必要です。オンチェーンでのスマートコントラクトのコールが必要でない意思決定の場合、特にトレードおよび流動性プロバイダーの報酬公式の変更については、スナップショットの選択は拘束力を有する最終選択であるとみなされます。上記のコンテンツ要件に加えて、オフチェーン制御されている変数に対する拘束力ある選択としてのスナップショット選択には、以下の内容を含めなければなりません。

二者択一オプション明確化のため、アドレスは提案への賛成または反対のいずれかを選択します。

選択後、関連情報はIPFSに保存されます。レポートが自動的に生成され、ダウンロードできます。

ステップ3 - DIPの作成（オフチェーン提案）

説明：

（1）スナップショット選択の結果、オフチェーンパラメーター（トレード報酬やLP報酬公式の変更など）が更新される場合、および（2）コミュニティメンバーがオンチェーンスマートコントラクトの変更提案を提出したい場合、DIPを作成する必要があります。オンチェーンでのスマートコントラクトの更新が必要でない場合、スナップショット選択の結果はオフチェーンDIPで定式化され、dYdX FoundationのGithubのPending-DIPブランチにプルリクエストを通じて提出される必要があります。DIPはスナップショット選択の結果を反映する必要があります。DIPは、こちらからご覧いただけるテンプレートに含まれる情報を指定する必要があります。

DIP 2への適用：

この場合、DIPは@Jteamdcによって執筆されました。

DIP 2のドラフト提案が完了したとき、@Jteamdcは使用中のブランチからdYdX FoundationのPending-DIPブランチに対して、****のプルリクエストを作成しました。dYdX Foundationが提案を確認し、署名した後、Pending-DIPの変更はマスターブランチに統合されました。

流動性プロバイダー報酬のしきい値を引き下げる必要はないため、このプロセスは完了し、変更は次のエポック期間に有効になります。

DIPの作成方法：

DIPはスナップショットでのオフチェーンDIP選択の結果に基づく必要があり、提案ごとに最大10アクションまで、1つまたは複数のアクションで構成できます。アクションとは提案で指定された変更を指します。詳細については「DIPの作成」で確認できます。
Githubの口座に登録：https://github.com/signup 。
こちらからdYdXのレポページに移動し、Github口座の下でレポをフォークします。

フォークされたDIPレポで、DIPの内容を含むディレクトリに移動します：https://github.com/[user_name]/dip/tree/master/content/dips 。

dipsフォルダを選択：https://github.com/[user_name]/dip/tree/master/content 。

こちらのdipsフォルダには、DIPテンプレートをフォローしているこれまでの提案のディレクトリが含まれています。

プロポーザルの記述を開始する前に、フォークされたブランチが最新バージョンのマスターブランチに対応していることを確認してください。DIPレポの旧バージョンを使用している場合、フォークされたバージョンが最新の変更に対応していることを確認してください。フォークされたバージョンのリベーシングについては、こちらから手順を確認できます：https://stackoverflow.com/questions/7929369/how-to-rebase-local-branch-onto-remote-master
DIPテンプレートを提案の情報を使用して編集します。DIPレポをフォークしていない場合、管理者ではないため、編集アイコンを選択するとマスターからのレポが自動的にフォークされます。

テンプレートをフォローし、content/dips/ ディレクトリのリポジトリのフォークにDIPを追加します。以下のDIPステータスのネーミングコンベンションに従ってください。

DIPステータス：

WIP - まだ開発中のDIP。
提案済み - オンチェーン提案の準備ができているDIP。
承認済み - dYdXコミュニティによる実装が承認されたDIP。
実装済み - メインネットにリリースされたDIP。
拒否 - 拒否されたDIP。
すべてのコンテンツが正しいことを確認した後、dYdX FoundationのPending-DIPブランチに対して、作業ブランチからのプルリクエストを作成します。外部のパーティーがマスターブランチへのマージを希望する場合、IPFSジョブが失敗するため、dYdX Foundationのマスターブランチに対するこのプルリクエストは提出しないでください。一例として、こちらのプルリクエストを使用してください。

レビュー後、dYdX FoundationはPending-DIPブランチからマスターブランチへの変更をマージします。

マージ前にジョブが自動的に実行され、IPFSにDIPをアップロードします。DIPのアップロードはこちらから確認できます：https://github.com/dydxfoundation/dip/pull/9/checks
DIPは、dip/content/dips/の下に追加されます。

この提案ではオンチェーンでのスマートコントラクト変更の必要はないため、このプロセスは完了し、変更は次のエポック期間に有効になります。

DIP 3（オンチェーン提案） - セーフティモジュールの復元

要約：

11月1日、セーフティモジュールのステーキングプールの機能を復元するため、ParadigmのDan Robinson氏によってオンチェーンDIPが作成されました。コミュニティの過半数（投票者数251、約142M ethDYDX）は、セーフティモジュールの機能の復元に賛成しました。10日間の選択期間の後、コミュニティメンバーがキューを呼び出し、提案を7日間のタイムロック遅延に移動させるために3日間程度を要しました。11月20日、セーフティモジュールは復元され、クリーンな状態にリセットされました。

背景：

dYdXのセーフティモジュールは、dYdXプロトコルのバックストップに使用できる分散型資金プールをブートストラップするように設計されたステーキングコントラクトです。ユーザーは$ethDYDXをセーフティプールにステーキングし、$ステーキングDYDX（1：1）を受け取ります。$ステーキングDYDXは、$ethDYDXと同じ投票権および提案権を有するERC-20として移転されるトークン化したポジションです。ショートフォールイベントの場合、ステーキングされた$ethDYDXをスラッシュし、損失を軽減する必要があります。セーフティステーキングプールでethDYDXをステーキングするユーザーに対して、$ethDYDXのトークンサプライからその2.5％（2,500万$ethDYDX）が分配されます。セーフティステーキングプールの詳細についてはこちらをご覧ください。

セーフティステーキングプール報酬の一環として、ステーカーにエポック（28日間）ごとに383,562$ethDYDXが分配されます。報酬はステーカーに秒単位で分配されます。

dYdXのコミュニティには、セーフティモジュールのスマートコントラクトパラメータに関して「即時かつ取り消し不能なコントロール」が存在します。コミュニティをコントロールするパラメータの完全なリストはこちらをご覧ください。

9月8日午後3時（UTC）に、$ethDYDXトークンの移動制限が解除され、dYdXセーフティモジュールへのステーキングが実質的に開始されました。ほぼ1時間にわたって、50を超えるアドレスが約157K ethDYDXをステーキングしました。デプロイメントプロセスでバグによるエラーが発生し、セーフティモジュールにステーキングしたアドレスに対してはステーキングDYDXが発行されませんでした。その結果、各ステーカーの資金がコントラクトにスタックされ、dYdXチームではdYdXガバナンスUIでのステーキングを無効化しました。

DIP 1はセーフティモジュールの復元機能を提案しました。これは影響を受けたアドレスが資金を回復し、補償としてステーキングされたトークンの10％相当を受け取るというものでした。コミュニティ感情はDIP 1 - セーフティモジュールの復旧とステーカーの回復を強く支持していましたが、長いタイムロック選択の可決に必要な100M $ethDYDXの最小選択者数を満たせなかったため、この提案は否決されました。その結果、DeFiance Capitalのジェイコブ・ゴー（jteam0x）はDIP 4 - セーフティモジュール・ステーカーの払い戻しと補償を作成し、影響を受けたアドレスに対し、逃した報酬分と迷惑料を補償しました。DIP 4には、ステーキングされたトークンのリカバリーコントラクトのデプロイおよび影響を受けたアドレスに対するRewards Treasuryからの10％補償が含まれていました。DIPは、あまり厳格でないショートタイムロックのガバナンスパラメータによって管理されました。

DIPの提案ライフサイクルは通常、DIPの作成まで一貫しています。DIP 3（オンチェーン）とDIP 2（オフチェーン）の主要な違いは、DIP 3ではオンチェーン選択とスマートコントラクトのデプロイメントが必要だった点にあります。フォーラムディスカッション、DRCの作成、ドラフトDIPの作成のプロセスは同じであるため、オンチェーンDIPのドラフト要件に関するステップ・バイ・ステップのディスカッションを開始します。詳細については以下のリンク先をご覧ください：

dYdXのガバナンスプロセス - https://docs.dydx.community/dydx-governance/voting-and-governance/dip-posal-lifecycle 。
セーフティモジュールのインシデントレポート - https://dydx.foundation/blog/en/outage-1 。
オフチェーンのフォーラムディスカッション - https://commonwealth.im/dydx/posal/discussion/1743-safety-staking-pool-on-pause 。
オフチェーンDRC - https://commonwealth.im/dydx/proposal/discussion/1770-drc-incident-report-of-the-safety-module-outage-proposed-solution
オフチェーンDRCのスナップショット選択 - https://snapshot.org/#/dydxgov.eth/proposal/QmbJ5QxHr1pyShKTDaF5DjAr6vxQn8DVxshH2fyWgzDCBn
Githubで提案されたDIP** - ** https://github.com/dydxfoundation/dip/blob/master/content/dips/DIP-3.md

ステップ1 - オンチェーンDIPのドラフティング

説明：

dYdXプロトコルのガバナンスに影響を与えるオンチェーンDIPのドラフティングでは、スマートコントラクトの変更の実装のための具体的なステップを概説する必要があります。コミュニティがスナップショットから大まかなコンセンサスを達成した後か、または以前に失敗したDIPの後、十分な提案権を有するコミュニティメンバーは新しいオンチェーンDIPを提出できます。提案権のしきい値、タイムロックの実行管理者、その他のガバナンスパラメータの詳細についてはこちらをご覧ください。

DIP 3への適用：

この場合、DIPはParadigmのDan Robinson氏によって執筆されました。この提案にはオンチェーンのスマートコントラクトの変更が含まれており、特定のスマートコントラクトの実装リンクも含まれていました。

SafetyModuleV2.solのデプロイメントコントラクトからセーフティフォルダに移動すると、提案の実行方法に関する具体的かつ詳細な記述が含まれているREADMEが表示されます。

READMEに含まれる提案の実装手順はこちらです：https://github.com/dydxfoundation/governance-contracts/tree/master/safety 。

オンチェーンDIP（WIP）のドラフト方法：

新しいウォレットでDIPを作成します。デプロイメントプロセスでは環境変数としてシードフレーズを入力する必要があるため、オンチェーンDIPの作成にはワンオフウォレットを使用することを推奨します。
DIPの作成に必要な提案権をワンオフウォレットに委任します。こちらから提案権を委任できます。提案権の異なるしきい値は以下のとおりで、こちらからご覧いただけます。
- ショートタイムロック：総供給量の0.5％（提案権：5M）
- Starkwareの実行管理者：総供給量の0.5％（提案権：5M）
- ロングタイムロックの実行管理者：総供給量の2.0％（提案権：20M）
- Merkle Pauserの実行管理者：総供給量の0.5％（提案権：5M）
Alchemyキーを作成します。Alchemyキーでは、イーサリアムとのインタラクションやスマートコントラクトのデプロイのためにイーサリアムノードを実行する必要はありません。Alchemyキーの作成ガイドはこちらからご覧いただけます。

イーサリアムと「開始」を選択します。

必要な情報を入力し、Goerli Network、「アプリの作成」の順に選択します。

口座を作成した後、こちらから設定指示に従います。

「4. 構築の開始」で「最初のスマートコントラクトのデプロイを行う」を選択し、ガイドに従います。

Windowsのコマンドラインからデフォルトのターミナルアプリを開くか、iTermをダウンロードします：https://iterm2.com/ 。
Node.jsおよびnpmのダウンロードやインストールが済んでいない場合、以下から行います：https://docs.npmjs.com/downloading-and-installing-node-js-and-npm 。
Hardhatはイーサリアムソフトウェアのコンパイルおよびテストのための開発ツールです。Hardhatはこちらからインストールできます：https://hardhat.org/tutorial/setsing-up-the-environment.html 。
提案されたスマートコントラクトの実装をドラフトします。
IPFSのハッシュが自動的に生成され、こちらから入手できます。IPFSのハッシュは、ファイル名DIP-[新しいDIP #]-ipfs-hashes.jsonのdYdX Foundationのディレクトリに含まれます。

新しいファイル（DIP-[新しいDIP #]-ipfs-hashes.json）を選択した後、エンコードされたHashを使用していることを確認します。

ステップ2 - オンチェーンDIPの提出

説明：

コミュニティメンバーが提案されたスマートコントラクトの実装が正しいことを確認し、DIPが確定した後、そのDIPをオンチェーンで提出できます。オンチェーンDIPが作成されると、提案は選択遅延の「保留」状態に進み、それが1日間（約6,570ブロック）続きます。ユーザーのスナップショットは選択遅延後に、$ethDYDXの保有と委任された投票権を考慮して記録されます。次に、提案は「アクティブ」状態に進み、提案の種類に応じて選択期間は2〜10日間になります。提案が実行される場合、提案の種類に応じて変化する最小クォーラムと最小選択差の要件を満たす必要があります。DIPが最小クォーラム、最小選択差、選択コミュニティメンバーの多数要件を満たす場合、任意のアドレスが提案をタイムロックのキューに移動させるためのキューを呼び出すことができます。このタイムロックコントラクトは、dYdXコミュニティによって選択されたトランザクションのキュー、キャンセル、実行を行うことができます。タイムロックのキューの期間は提案の種類によって異なります。

DIP 3への適用：

ParadigmのチームがSafetyModuleV2.solのソリディティコードを決定しました。

Paradigmのチームが、ローカルとフォークされたメインネットの両方でのアップデートをシミュレートしました。その後、テストスイートが実行され、メインネットでのガバナンス提案の実行に続いて完全な機能復元が行われます。

Paradigmのチームが以下のスクリプトを実行することで、スマートコントラクトのアップデートをデプロイしました。

セーフティモジュールのリカバリーのデプロイメント

ALCHEMY_KEY=<... のエクスポート>

MNEMONIC=<... のエクスポート>

npx hardhat --network mainnet deploy:safety-module-recovery --dydx-token-address 0x92D6C1e31e14520e676a687F0a93788B716BEff5 --short-timelock-address 0x64c7d40c07EFAbec2AafdC243bF59eaF2195c6dc --rewards-treasury-address 0x639192D54431F8c816368D3FB4107Bc168d0E871

ガバナンス提案：セーフティモジュールの修正

ALCHEMY_KEY=<... のエクスポート>

MNEMONIC=<... のエクスポート>

npx hardhat --network mainnet deploy:safety-module-fix-proposal`--proposal-ipfs-hash-hex 0x...\ --governor-address 0x7E9B1672616FF6D6629Ef2879419aaE79A9018D2\ --long-timelock-address 0xEcaE9BF44A21d00E2350a42127A377Bf5856d84B\ --safety-module-address 0x65f7BA4Ec257AF7c55fd5854E5f6356bBd0fb8EC\ --safety-module-proxy-admin-address 0x6aaD0BCfbD91963Cf2c8FB042091fd411FB05b3C\ --safety-module-new-impl-address 0x...`

ガバナンス提案：セーフティモジュールの補償

ALCHEMY_KEY=<... のエクスポート>

MNEMONIC=<... のエクスポート>

npx hardhat --network mainnet deploy:safety-module-compensation-proposal --proposal-ipfs-hash-hex 0x... --dydx-token-address 0x92D6C1e31e14520e676a687F0a93788B716BEff5 --governor-address 0x7E9B1672616FF6D6629Ef2879419aaE79A9018D2 --short-timelock-address 0x64c7d40c07EFAbec2AafdC243bF59eaF2195c6dc --rewards-treasury-address 0x639192D54431F8c816368D3FB4107Bc168d0E871 --safety-module-recovery-address 0x...

DIPはhttps://dydx.community/dashboardに同時にポストされました。

dYdXのガバナンスコントラクトは、0x7e9b1672616ff6d6629ef2879419aae79a9018d2: https://etherscan.io/txs?a=0x7e9b1672616ff6d6629ef2879419aaae79a9018d2&p=10 です。

DIPのデプロイはEtherscan：https://etherscan.io/tx/0x5f2472e7dfcbf50628d29c94f97a072f3c19177f66cde4cca9f376c7934af5ad で確認できます。

このDIPは2021年11月1日、ブロック13532376で作成されました。将来の6,570ブロックの場合、DIPのステータスは「保留」です。

ethDYDXの保有者は、ブロック13538946で「アクティブ」状態に移行した時にDIPを選択できました。

最初の選択は2021年11月2日午後5時51分22秒（UTC）に行われ（ブロック13538959）、オンチェーンDIPが作成された時点から6,583ブロックでした。

ロングタイムロックに関する10日間の選択期間後、コミュニティメンバーはキューを呼び出すことで提案を7日間のタイムロック遅延に移行させることができます。DIP 3では、コミュニティメンバーがキューを呼び出すのに約3日間かかりました。

7日間のタイムロック遅延の後、DIPはオンチェーンで実行されました。

オンチェーンでDIPが実行された時点で、https://dydx.community/dashboard/proposal/3 のDIPステータスは「実行済み」に更新されました。

注：（1）提案はタイムロックの遅延直後に開始される7日間の期間内に実行される必要があり、（2）提案を行うアドレスはDIPが実行されるまでの間、各タイムロックコントラクトで必要な提案権の最小額を維持する必要があります（提案権は5Mまたは20M）。

オンチェーンDIPの提出方法：

DIPを作成するのに十分な提案権を有していることを確認します。詳細については「DIPの作成」をご覧ください。
- ショートタイムロックの実行管理者：総供給量の0.5％（提案権：5M）
- Starkwareの実行管理者：総供給量の0.5％（提案権：5M）
- ロングタイムロックの実行管理者：総供給量の2.0％（提案権：20M）
- Merkle Pauserの実行管理者：総供給量の0.5％（提案権：5M）
ガス代を支払うためのETHがウォレットにあることを確認します。
イーサリアムメインネットネットワークのAlchemyでアプリを作成します。

アプリが作成された後、「キーを表示」をクリックしてAlchemyキー（7LOaQtguSm2kSEcFXQH88B）を入手します：https://eth-mainnet.alchemyapi.io/v2/7LOaQtgusm2kSEcFXQH88B-EN_K7t_ul

Node.jsとnpmをダウンロードおよびインストールします：https://docs.npmjs.com/downloading-and-installing-node-js-and-npm 。
Hardhat：https://hardhat.org/tutorial/setsing-up-the-environment.html をインストールします。
ドラフトしたスクリプトを実行します。
ガバナンスコントラクトをチェックして、提案がオンチェーンで作成されたことを確認します：https://etherscan.io/txs?a=0x7e9b1672616ff6d6629ef2879419aaae79a9018d2&p=10 。
提案を提出したアドレスは、提案が実行されるまでの間、各タイムロックコントラクトで必要な提案権の最小限度額を維持する必要があります。