1 of 29

jp

👋紹介

ethDYDXトークンおよびガバナンスの概要。

$ethDYDXと$wethDYDXは、ユーザー体験の向上につながるdYdX v3の将来の成長と分散化を促進するために設計されたガバナンスと報酬に関する強固なエコシステムを実現します。

dYdX v3ウインドダウン

dYdX Trading、Inc.は、2024年10月28日にdYdX v3のサポートを終了しました。

ここからスタート

🖥️インターフェイス

dydx.communityでのガバナンス、報酬、およびステーキングの拠点

ガバナンス

アクティブなおよび過去のガバナンス提案を表示でき、アクティブなガバナンス提案を選択できます。

DYDXおよびstkDYDXの保有者は、権限および選択権の提案という2種類のガバナンス権限が付与されます。ダッシュボードを通じて、ユーザーは提案および選択権限を表示し、他のアドレスに委任できます。

ステーキング

ユーザーはDYDXをステーキングすることで、ステーキング報酬を獲得できます。

取引報酬

ユーザーは、レイヤ2取引所での取引活動を通じて獲得した報酬を表示できます。取引の報酬は、エポックスケジュールに従い、28日ごとに提供されます。

ポートフォリオ＆請求DYDX

ユーザーは、DYDXの保有、請求可能DYDX、ステーク済みのDYDX、および出金可能DYDXの集計ビューを確認できます。

ユーザーは、現在流通しているDYDXトークンの供給および毎日の提供を確認できます。ユーザーは利用可能なすべてのDYDX報酬を請求できます。DYDXトークンは、2021年9月8日午後3時（協定世界時：UTC）頃以降に移動可能になります。

🚧制限

$ethDYDX、$wethDYDX、およびdYdX v3の使用に関する制限。

$ethDYDXおよび$wethDYDXは、米国およびその他の禁止されている管轄区域ではご利用いただけません。お客様が米国その他の禁止地域に居住しているか、法人化している、または本社を置く場合、$ethDYDXおよび$wethDYDXの提供の受け取りや$ethDYDXおよび$wethDYDXの取引は許可されていません。

📑割り当て

$ethDYDXトークンの割り当て。

割り当て

2021年8月3日、15:00:00 UTCに合計1,000,000,000$ethDYDXが鋳造され、そこから5年間アクセス可能となり始めました。 $ethDYDXの総供給量の最初の5年間の割り当ては以下のとおりです。

コミュニティへの50.0％（500,000,000$ethDYDX）は以下：
- レイヤ2プロトコルで特定の取引マイルストーンを達成した過去のユーザーへの遡及マイニング報酬として7.5％（75,000,000$ethDYDX）、
dYdX Trading Inc.の過去の投資家への27.7％（277,295,070$ethDYDX）、
dYdX Trading Inc.またはdYdX Foundationの創設者、従業員、アドバイザー、コンサルタントへの15.3％（152,704,930$ethDYDX）、および
dYdX Trading Inc.またはdYdX Foundationの将来の従業員およびコンサルタントへの7.0％（70,000,000万$ethDYDX）。

$ethDYDXの立ち上げ以来、最初の割り当てに変更が生じたガバナンス提案がいくつかあります。現在、割り当てには以下のものが含まれます。

コミュニティへの50.0％（500,000,000$ethDYDX）は以下：
- - エポック30：1,054,795$ethDYDX
    エポック31：527,398$ethDYDX
    エポック32：0$ethDYDX
- dYdXレイヤー2プロトコルで特定の取引マイルストーンをを達成した過去のユーザーへの遡及マイニング報酬として5.0％（50,309,197 $ethDYDX）、
  - エポック0後、未請求の24,690,803$ethDYDXが遡及マイニング報酬プログラムからコミュニティトレジャリーに送金されました。
- - エポック30：383,562$ethDYDX
    エポック31：191,781$ethDYDX
    エポック32：0$ethDYDX
dYdX Trading Inc.の過去の投資家への27.7％（277,295,070$ethDYDX）、
dYdX Trading Inc.またはdYdX Foundationの創設者、従業員、アドバイザー、コンサルタントへの15.3％（152,704,930$ethDYDX）、および
dYdX Trading Inc.またはdYdX Foundationの将来の従業員およびコンサルタントへの7.0％（7,000万$ethDYDX）。

コミュニティの割り当ては上記のように設定されていますが、$ethDYDX保有者は今後のコミュニティの割り当ての使用方法について、ガバナンスを通じて完全な管理を保有しています。

$ethDYDXの流動化供給曲線

2021年9月8日、トークンの最初の転送制限が解除されました。

以下のグラフは、インフレーションのない総流動化供給量を示しています。

よくある質問

$ethDYDXの割り当てを変更することはできますか？

a. 2023年11月21日、15:00 UTC（エポック30開始時）に、報酬を以下の値に削減する。

 i. Trading: 1,054,795
 ii. LP: 383,562

b. 2023年12月19日、15:00 UTC（エポック31開始時）に、報酬を以下の値に削減する。

 i.Trading: 527,398
 ii.LP: 191,781

c. 2024年1月161日、15:00 UTC（エポック32開始時）に、報酬を以下の値に削減する。

 i.Trading: 0
 ii.LP: 0

新しい$ethDYDXトークンは作成できますか？

ローンチから5年後、年間最大パーペチュアルインフレ率が2%になると、$ethDYDXの供給量が増加します。 2026年7月14日15:00:00 UTCから、dYdXガバナンスは、365日ごとに1回のマイニングを許可し、年間インフレ率2%まで、マイニングされる新しい$ethDYDXの最大供給量を決定できます。 2026年7月14日15:00:00 UTCから、dYdXガバナンスは、365日ごとに1回のマイニングを許可し、年間インフレ率2%まで、マイニングされる新しい$ethDYDXの最大供給量を決定できます。

投資家、既存および将来の従業員、コンサルタントに発行される$ethDYDXのロックアップとは何ですか？

$ethDYDXトークンの初期割り当ての一部は、dYdX Trading Inc.の過去の投資家、dYdX Trading Inc.またはdYdX Foundationの創設者、従業員、アドバイザー、コンサルタント、およびdYdX Trading Inc.またはdYdX Foundationの将来の従業員およびコンサルタントのために確保されています。

修正に従い、トークンは以下のように転送制限から解除されます。

2023年12月1日に30％。
2024年1月1日から2024年6月1日までの月間分割払いで40％。
2024年7月1日から2025年6月1日までの月間分割払いで20％。および、
2025年7月1日から2026年6月1日までの月間分割払いで10％。

上記の日付はすべてUTC時間帯を参照するものと解釈されることに注意してください。

dYdX Trading Inc.とdYdX Foundationのさまざまな創設者、従業員、アドバイザー、コンサルタントも、修正で規定される移動制限スケジュールを遵守するものとします。

すべての従業員やコンサルタントにも、さまざまな権利確定スケジュールが適用され、結果として$ethDYDXに対する権利を失ってしまう場合があります。従業員またはコンサルタントによる$ethDYDXの受け取りは、現在または将来的にも、dYdXプロトコルに関するサービスまたはその他のプロトコルに利益をもたらす可能性のあるサービスの提供に基づくものではありません。代わりに、従業員とコンサルタントは、dYdX Trading Inc.またはdYdX Foundation、または他の関係者のみに利益をもたらすサービスに対して$ethDYDXを受け取ることができます。

$ethDYDXのロックアップにかかわらず、dYdX Trading Inc.またはdYdX Foundationの投資家、および元従業員またはコンサルタントは、$ethDYDXを使用して、dYdXプロトコルに関する提案の作成、投票権の委任、またはdYdXプロトコルに関する提案投票をすることができます。dYdX Trading Inc.またはdYdX Foundationの現在の従業員およびコンサルタントは、当初は提案や投票への参加はできませんが、将来的には可能になります。dYdXトレーディングまたはdYdX Foundationの現在の従業員およびコンサルタントは、投票の結果に影響を与えることを試みずに投票権を委任できます。

すべての投資家は、dYdX財団との契約により施行される移動制限を遵守する必要があります。dYdXトレーディングとdYdX財団はウォレットアドレスを追跡し、その制限に違反して移動されたかどうかを判断します。

dYdX Foundationでは、これらの要件を遵守しない投資家に対して法的措置をとることを表明しています。

⏳エポック

エポックシステムの概要

すべての報酬およびステーキング契約は、エポックと呼ばれる28日間サイクルで運営されます。新しいエポックは、現在のエポックが終了すると自動的に開始されます。

各エポックの終了時に、以下のことが発生します。

終了エポックの流動性ステーキングプールにおいて請求された出金は、出金される可能性があります。
終了エポックの安全ステーキングプールにおいて請求された出金は、出金される可能性があります。

よくある質問

ブラックアウトウィンドウとは何ですか？

🪙報酬基金

報酬基金の概要

報酬

📊取引報酬

取引報酬プログラムの概要。

FAQ

取引報酬の対象となったのは、どのような方々ですか？

dYdX v3のすべてのトレーダーは、取引報酬として$ethDYDXを受け取る資格がありました。

ステーキングプール

選択およびガバナンス

リソース

外部リンク

📑割り当て

$ethDYDXトークンの割り当て。

割り当て

コミュニティへの50.0％（500,000,000$ethDYDX）は以下：
- 取引報酬の計算式に基づく25.0％（250,000,000$
- レイヤ2プロトコルで特定の取引マイルストーンを達成した過去のユーザーへの遡及マイニング報酬として7.5％（75,000,000$ethDYDX）、
- に基づく7.5％（75,000,000$ethDYDX）、
- への5.0％（50,000,000$ethDYDX）、
- に$USDCをステーキングするユーザーへの2.5％（25,000,000$ethDYDX）、
- に$ethDYDXをステーキングするユーザーへの2.5％（25,000,000$ethDYDX）、
dYdX Trading Inc.の過去の投資家への27.7％（277,295,070$ethDYDX）、
dYdX Trading Inc.またはdYdX Foundationの創設者、従業員、アドバイザー、コンサルタントへの15.3％（152,704,930$ethDYDX）、および
dYdX Trading Inc.またはdYdX Foundationの将来の従業員およびコンサルタントへの7.0％（70,000,000万$ethDYDX）。

$ethDYDXの立ち上げ以来、最初の割り当てに変更が生じたガバナンス提案がいくつかあります。現在、割り当てには以下のものが含まれます。

コミュニティへの50.0％（500,000,000$ethDYDX）は以下：
- に基づく14.5％（144,693,506$ethDYDX）、
  - とでは、dYdXコミュニティは取引報酬を合計230万$ethDYDX削減することを投票で決定しました。（DIP 16から958,904$ethDYDX、DIP 20から1,294,520$ethDYDX）。230万$ethDYDXは、報酬基金に計上され、によってdYdXコミュニティが利用できるようになります。
  - では、dYdXコミュニティは取引報酬をdYdX v3上のエポック30-32から⅓に削減し、以下の値にすることを投票で決定しました。
    エポック30：1,054,795$ethDYDX
    エポック31：527,398$ethDYDX
    エポック32：0$ethDYDX
- dYdXレイヤー2プロトコルで特定の取引マイルストーンをを達成した過去のユーザーへの遡及マイニング報酬として5.0％（50,309,197 $ethDYDX）、
  - エポック0後、未請求の24,690,803$ethDYDXが遡及マイニング報酬プログラムからコミュニティトレジャリーに送金されました。
- に基づく3.3%（32,794,525$ethDYDX）、
  - において、dYdXコミュニティは流動性プロバイダー報酬をエポックあたり1,150,685$ethDYDXから、50%削減のエポックあたり575,343$ethDYDXに変更することを投票で決定しました。余ったエポックあたり575,342$ethDYDXは報酬基金に計上され、によってdYdXコミュニティが利用できるようになります。
  - では、dYdXコミュニティは流動性プロバイダー報酬をdYdX v3上のエポック30-32から⅓に削減し、以下の値にすることを投票で決定しました。
    エポック30：383,562$ethDYDX
    エポック31：191,781$ethDYDX
    エポック32：0$ethDYDX
- へ26.1%（261,133,225$ethDYDX）、
- に$USDCをステーキングするユーザーへの0.6％（5,779,608$ethDYDX）、
  - において、dYdXコミュニティは$USDCのステーキングに関連する報酬を0に設定することをしました。これまで$USDCステーカーに配布された383,562$ethDYDXは報酬基金に加算され、によってdYdXコミュニティが利用できるようになります。
- に$ethDYDXをステーキングするユーザーへの0.5％（5,289,939$ethDYDX）、
  - において、dYdXコミュニティは$ethDYDXのステーキングに関連する報酬を0に設定することをしました。これまで$ethDYDXステーカーに配布された383,562$ethDYDXは、報酬基金に計上され、によってdYdXコミュニティが利用できるようになります。
dYdX Trading Inc.の過去の投資家への27.7％（277,295,070$ethDYDX）、
dYdX Trading Inc.またはdYdX Foundationの創設者、従業員、アドバイザー、コンサルタントへの15.3％（152,704,930$ethDYDX）、および
dYdX Trading Inc.またはdYdX Foundationの将来の従業員およびコンサルタントへの7.0％（7,000万$ethDYDX）。

$ethDYDXの流動化供給曲線

2021年9月8日、トークンの最初の転送制限が解除されました。

以下のグラフは、インフレーションのない総流動化供給量を示しています。

よくある質問

$ethDYDXの割り当てを変更することはできますか？

はい。dYdXコミュニティはを変更できます。これまでのところ、dYdXコミュニティはいくつかのガバナンス提案において、DYDXの排出量を削減することを投票で決定しています。

において、dYdXコミュニティは取引報酬を25％引き下げることをで決定しました。その結果、所定のエポックで配布される取引報酬は、エポック15において3,835,616$ethDYDXから2,876,712$ethDYDXに減少しました。残りの958,904$ethDYDXは、報酬基金に加算され、によってdYdXコミュニティが利用できるようになります。
において、dYdXコミュニティは$USDCのステーキングに関連する報酬を0に設定することをしました。これまで$USDCステーカーに配布された383,562$ethDYDXは報酬基金に加算され、によってdYdXコミュニティが利用できるようになります。
において、dYdXコミュニティは$ethDYDXのステーキングに関連する報酬を0に設定することをしました。これまで$DYDXステーカーに配布された383,562$ethDYDXは、報酬基金に計上され、によってdYdXコミュニティが利用できるようになります。
において、dYdXコミュニティは、流動性プロバイダー報酬を、エポックあたり1,150,685$ethDYDXから、50%削減のエポックあたり575,343$ethDYDXに変更することをしました。余ったエポックあたり575,342$ethDYDXは報酬基金に計上され、によってdYdXコミュニティが利用できるようになります。
において、dYdXコミュニティは取引報酬およびLP報酬をdYdX v3上のエポック30-32から⅓に削減しすることを以下のように投票で決定しました。

a. 2023年11月21日、15:00 UTC（エポック30開始時）に、報酬を以下の値に削減する。

 i. Trading: 1,054,795
 ii. LP: 383,562

b. 2023年12月19日、15:00 UTC（エポック31開始時）に、報酬を以下の値に削減する。

 i.Trading: 527,398
 ii.LP: 191,781

c. 2024年1月161日、15:00 UTC（エポック32開始時）に、報酬を以下の値に削減する。

 i.Trading: 0
 ii.LP: 0

新しい$ethDYDXトークンは作成できますか？

投資家、既存および将来の従業員、コンサルタントに発行される$ethDYDXのロックアップとは何ですか？

2023年1月25日、dYdX Foundationは、投資家$ethDYDXトークンの初期リリース日を2023年12月1日に延期する修正を。この修正では、初期ロック解除日以降の段階的なロック解除スケジュールは変更されませんでした。

修正に従い、トークンは以下のように転送制限から解除されます。

2023年12月1日に30％。
2024年1月1日から2024年6月1日までの月間分割払いで40％。
2024年7月1日から2025年6月1日までの月間分割払いで20％。および、
2025年7月1日から2026年6月1日までの月間分割払いで10％。

上記の日付はすべてUTC時間帯を参照するものと解釈されることに注意してください。

dYdX Foundationでは、これらの要件を遵守しない投資家に対して法的措置をとることを表明しています。

🏗️アーキテクチャ

ガバナンスアーキテクチャのハイレベルな概要

概要

$ethDYDX、$stkDYDX、および$wethDYDX（「ガバナンストークン」）は、dYdX v3の変更について提案および投票する権利を保有者に付与します。dYdXのガバナンスは、AAVEガバナンスコントラクトに基づいており、ガバナンストークンの保有に基づいた投票をサポートします。

提案は、提案の種類に基づき、所定のしきい値および賛成票の割合にて審査を通過する必要があります。

ガバナンストークンの投票および提案権限により、ガバナンストークン保有者は、ガバナンストークン提案に提案および投票できます。ガバナンストークンの保有者は、そのような権限を他のイーサリアムアドレスに委任する場合があることにご注意ください。

dYdXガバナンスの中核には、以下のように8つのスマートコントラクトがあります。

$ethDYDX、$stkDYDX、および$wethDYDXトークンコントラクト：時間的に異なるブロックにおける各アドレスの投票権に関するスナップショットを保持しています。
セーフティモジュールのコントラクト：$ethDYDXトークンをステークし、ポジションをトークン化し、報酬を獲得するためのロジックが含まれています。セーフティモジュールにステークされたトークンは、完全なガバナンス権を保有します。
ガバナーコントラクト：提案を追跡し、タイムロックでのスマートコントラクトを通じて提案を実行できます。
タイムロックコントラクト：ガバナンス投票で選択されたトランザクションにおけるキューの追加や、キャンセル、実行ができます。提案での機能は、タイムロックコントラクトによって開始されます。遅延および猶予期間の満了前に、キューに追加されたトランザクションを実行できます。
優先タイムロックコントラクト：タイムロックコントラクトと同じですが、優先度コントローラーが優先期間（タイムロックの遅延終了の7日前）以内にトランザクションを執行することが可能になります。

dYdXのオンチェーン・ガバナンスでは、以下のことを可能にします。

承認された実行管理者コントラクトによって実行される提案への投票
提案の開始時に保有されているトークンのスナップショット
投票権および提案権の個別委任
提案、定足数、および投票差分権限を含むガバナンス基準値の設定
投票のカウント方法の変更（ガバナーコントラクトの「ガバナンス戦略」スマートコントラクトアドレスの変更によって）

提案の種類

提案の期間および実行に影響を与えるパラメータが異なる4種類の提案があります。例えば、ガバナンスのコンセンサスに影響を与える重要な提案では、投票時間の増加や投票差の増大を必要とするものの、プロトコルパラメータのみに影響を与える提案では、投票時間の短縮および迅速な実行が可能となります。実行管理者は、各種類の提案について検証する必要があります。

短いタイムロックでの実行管理者

短いタイムロックでの執行管理者は以下の事象を管理します。

流動性モジュール、セーフティモジュール、Merkleディストリビューターモジュールなどのインセンティブコントラクト
報酬およびコミュニティ基金における資金
新しいトークンを発行する
セーフティモジュールを除くすべてのプロキシコントラクト
Starkプロキシコントラクトにおける監視者の役割

Starkwareの優先タイムロックの執行管理者

Starkwareの優先度タイムロック実行者は、StarkExパーペチュアルエクスチェンジコントラクトを管理し、dYdX v3を構成する提案を実行します。 Starkwareは、「優先度コントローラー」の役割を保持しており、7日間の優先期間で提案の実行をトリガーできます。 Starkwareは、「優先度コントローラー」の役割を保持しており、7日間の優先期間で提案の実行をトリガーできます。

長いタイムロックでの実行管理者

長いタイムロックでの実行管理者は、ガバナンスのコンセンサスに影響を与えるdYdX v3の一部を一般的に変更する提案を実行できます。

Merkle-pauserの実行管理者

Merkle-pauserの実行管理者は、Merkleルートをフリーズする提案を実行できます。これは各ユーザーの累積報酬残高によって定期的に更新され、提案されたルートが適切でないか悪意がある場合に、新しい報酬を時間の経過に応じてユーザーに提供できるようにします。また、スタークプロキシコントラクトによる強制取引リクエストを拒否することもできます。

最初のタイムロックでのパラメータは、以下のとおりです。

dYdXコミュニティトレジャリー支出提案の構築に関するテクニカルガイド

ethDYDXをコミュニティトレジャリーから宛先アドレスに送り込む方法に関する技術的な、ステップバイステップガイド。

Reverieは、dYdX_ガバナンスコントラクト_リポジトリに、$ethDYDXをプルリクエスト（PR）を通じてコミュニティトレジャリーから送り込むガバナンス提案を提出するための、包括的な技術的ガイドをまとめました。

予備要件

プルリクエスト（PR）の完了に先立ち、以下のステップを完了する必要があります：

**宛先アドレス：**宛先アドレスは、事前に生成する必要があります。宛先アドレスがマルチシグの場合、マルチシグウォレットを作成する必要があります。
**GitHub口座：**リポジトリをフォークするためのGitHubアカウントです。
**送金額（オプション）：**希望される場合、リクエストされた送金額は、PRに先駆けて確立されています。ただし、概金額を使用する場合、承認前に最終ステップとして設定できます。
**DIP IPFSハッシュ（オプション）：**金額がわかっている場合、DIPは最終的に決定され、IPFSにプッシュし、ハッシュを生成する必要があります。ただし、金額が確定していない場合は、承認前の最終段階として設定することが可能です。

提案の構築

2. リポジトリをクローンし、[username]を自分自身に変更してください。

git clone https://github.com/[username]/governance-contracts.git

3. 構成変数

src/config/index.tsに、テストのために使用されるconfigSchema定数に2つの新しい変数を追加します。以下のコードブロックで、**「PROPOSAL_NAME」と「PROPOSAL」**フィールドを、送信する提案の名前に変更します。

src/config/index.ts
...
const configSchema = {
	...
	FUND_PROPOSAL_NAME_PROPOSAL_ID: parseInteger({ default: null }),
	TEST_PROPOSAL_NAME_WITH_PROPOSAL: parseInteger({ default: true }),
};
...

src/deploy-config/base-config.tsに、config定数に宛先アドレスと金額を新しい変数として追加します：

src/deploy-config/base-config.ts
....
const config = {
	....
	
	PROPOSAL_NAME_ADDRESS = '0x...',
	PROPOSAL_FUNDING_AMOUNT = '10000000000000000000',
};
...

注：金額は、ERC20標準あたり10 ^ 18に乗じる必要があります。金額がまだわからない場合、一時金額を使用できます（例： 10 → 10000000000000000000）

src/lib/constants.tsに、他のリポジトリで承認されたDIPを参照するIPFSハッシュ変数を追加します：

src/lib/constants.ts
...
// Add a link to where the hash can be found
export const DIP_NUMBER_IPFS_HASH = '0x0000000000000000000000000000000000000000000000000000000000000000';

注：DIPがまだ公開されていない場合は、テスト用に仮の値（例：‘0x0000000000000000000000000000000000000000000000000000000000000000’)\を使用することができます。

4.提案コード

_src/migrations_で、proposal → proposal-name.tsにちなんで名前を付けた新しいファイルを作成し、以下のコードを入力します：

a. 上部に必要なインポートを追加します：

src/migrations/proposal-name.ts
import { SignerWithAddress } from '@nomiclabs/hardhat-ethers/signers';
import {
  DydxGovernor__factory,
} from '../../types';
import { getDeployConfig } from '../deploy-config';
import { getDeployerSigner } from '../deploy-config/get-deployer-address';
import { getHre } from '../hre';
import { log } from '../lib/logging';
import { waitForTx } from '../lib/util';
import { Proposal } from '../types';

b. インポート以下の提案名を使用して新しい関数を作成し、以下のコードを2つのユニークな変数で追加します：

destinationAddress → これは、資金を受け取るアドレスです
deployConfig.PROPOSAL_FUNDING_AMOUNT → これは、私たちが以前に作成した変数です。これは、送金する金額を決定します

src/migrations/proposal-name.ts
export async function createProposalNameProposal({
  proposalIpfsHashHex,
  dydxTokenAddress,
  governorAddress,
  shortTimelockAddress,
  communityTreasuryAddress,
  destinationAddress, // This is the address that will receive the funding
  signer,
}: {
  proposalIpfsHashHex: string,
  dydxTokenAddress: string,
  governorAddress: string,
  shortTimelockAddress: string,
  communityTreasuryAddress: string,
  destinationAddress: string,
  signer?: SignerWithAddress,
}) {
  const hre = getHre();
  const deployConfig = getDeployConfig();
  const deployer = signer || await getDeployerSigner();
  const deployerAddress = deployer.address;
  log(`Creating proposal with proposer ${deployerAddress}.\n`);
  const governor = await new DydxGovernor__factory(deployer).attach(governorAddress);
  const proposalId = await governor.getProposalsCount();
  const proposal: Proposal = [
    shortTimelockAddress,
    [communityTreasuryAddress],
    ['0'],
    ['transfer(address,address,uint256)'],
    [hre.ethers.utils.defaultAbiCoder.encode(
      ['address', 'address', 'uint256'],
      [dydxTokenAddress, destinationAddress, deployConfig.PROPOSAL_FUNDING_AMOUNT],
    )],
    [false],
    proposalIpfsHashHex,
  ];
  await waitForTx(await governor.create(...proposal));
  return {
    proposalId,
  };
}

5. デプロイメントタスク

提案が作成されると、提案を送信するために必要なトランザクションとコールデータを生成するデプロイメントを書くことができます。

_tasks/deployment_で、提案コード → proposal-name.tsに使用する同じ名前の新しいファイルを作成し、以下のコードで入力します：

a. 以下の変数で必要なインポートを追加します：

DIP_NUMBER_IPFS_HASH → これは、lib/constantsに追加する変数です

createProposalNameProposal → これは、/src/migrations/proposal-nameで作成した関数です

tasks/deployment/proposal-name.ts
import { types } from 'hardhat/config';
import mainnetAddresses from '../../src/deployed-addresses/mainnet.json';
import { hardhatTask } from '../../src/hre';
import { DIP_NUMBER_IPFS_HASH } from '../../src/lib/constants';
import { createProposalNameProposal } from '../../src/migrations/proposal-name';

b. hardhatタスクを作成し、タスクの開始\行に提案情報を入力しますdeploy:proposal-name:のproposal-nameに置き換え、「Proposal Description」の簡単な説明に置き換えます。

最後の行は、提案コードからインポートした関数を呼び出すため、その調整が必要です。

tasks/deployment/proposal-name.ts
hardhatTask('deploy:proposal-name', 'Proposal Description.')
  .addParam('proposalIpfsHashHex', 'IPFS hash for the uploaded DIP describing the proposal', DIP_NUMBER_IPFS_HASH, types.string)
  .addParam('dydxTokenAddress', 'Address of the deployed DYDX token contract', mainnetAddresses.dydxToken, types.string)
  .addParam('governorAddress', 'Address of the deployed DydxGovernor contract', mainnetAddresses.governor, types.string)
  .addParam('shortTimelockAddress', 'Address of the deployed short timelock Executor contract', mainnetAddresses.shortTimelock, types.string)
  .addParam('communityTreasuryAddress', 'Address of the deployed community treasury contract', mainnetAddresses.communityTreasury, types.string)
  .setAction(async (args) => {
    await createProposalNameProposal(args);
  });

6. テストの構築

コードをデプロイメントする準備ができたので、提案を中心にいくつかのテストを構築します。テストは、ローカルとメインネットフォークを使用して、オンチェーンで実行される提案をシミュレートします。

a. 提案テストの追加

test/migrationsに、proposal name → proposal-name.tsで新しいファイルをもう一度追加し、以下のコードを含めます：

提案関数を含め、必要なインポートを追加します：

createProposalNameProposal → これは、/src/migrations/proposal-nameで作成した関数です。\

MOCK_PROPOSAL_IPFS_HASH → テストのためにモックハッシュを使用します。

test/migrations/proposal-name.ts
import BNJS from 'bignumber.js';
import { BigNumber, BigNumberish } from 'ethers';
import config from '../../src/config';
import { getDeployConfig } from '../../src/deploy-config';
import { getDeployerSigner } from '../../src/deploy-config/get-deployer-address';
import { log } from '../../src/lib/logging';
import { waitForTx } from '../../src/lib/util';
import { impersonateAndFundAccount } from '../../src/migrations/helpers/impersonate-account';
import { createProposalNameProposal } from '../../src/migrations/proposal-name';
import {
  DydxGovernor__factory,
  DydxToken__factory,
  Treasury__factory,
} from '../../types';
import { advanceBlock, increaseTimeAndMine } from '../helpers/evm';
const MOCK_PROPOSAL_IPFS_HASH = (
  '0x0000000000000000000000000000000000000000000000000000000000000000'
);

テスト関数を以下のステップで追加します：
- fundProposalNameViaProposal → この関数を作成し、提案名に一致する名前を変更します。
- destinationAddress → 宛先名にマッチするようにラベル付けします。
- deployConfig.PROPOSAL_FUNDING_AMOUNT → これは、base-configファイルからの変数に置き換えられます。
- FUND_PROPOSAL_NAME_PROPOSAL_ID → これは、_config/index.ts_で作成した変数です。
- createProposalNameProposal → 上記の関数を使用するためにインポートしました。
- fundProposalNameViaNoProposal → この関数を作成し、提案名に一致する名前を変更します。

\以下のコードを通じて、これらの変数すべてを提案名と既存の変数に置き換えます。

test/migrations/proposal-name.ts
export async function fundProposalNameViaProposal({
  dydxTokenAddress,
  governorAddress,
  shortTimelockAddress,
  communityTreasuryAddress,
  destinationAddress,
}: {
  dydxTokenAddress: string,
  governorAddress: string,
  shortTimelockAddress: string,
  communityTreasuryAddress: string,
  destinationAddress: string,
}): Promise<void> {
  const deployConfig = getDeployConfig();
  const deployer = await getDeployerSigner();
  const dydxToken = new DydxToken__factory(deployer).attach(dydxTokenAddress);
  const governor = new DydxGovernor__factory(deployer).attach(governorAddress);
  await fundCommunityTreasuryFromFoundationIfNecessary({
    dydxTokenAddress,
    communityTreasuryAddress,
    minTreasuryBalance: deployConfig.PROPOSAL_FUNDING_AMOUNT,
  });
  // Pick a voter with enough tokens to meet the quorum requirement.
  const voterAddress = deployConfig.TOKEN_ALLOCATIONS.DYDX_TRADING.ADDRESS;
  const voter = await impersonateAndFundAccount(voterAddress);
  const voterBalance = await dydxToken.balanceOf(voterAddress);
  if (voterBalance.lt(new BNJS('2e25').toFixed())) {
    throw new Error('Not enough votes to pass the proposal.');
  }
  // Vote on an existing proposal (can be used with mainnet forking).
  let proposalId: BigNumberish;
  if (config.FUND_PROPOSAL_NAME_PROPOSAL_ID !== null) {
    proposalId = config.FUND_PROPOSAL_NAME_PROPOSAL_ID;
  } else {
    log('Creating proposal');
    ({ proposalId } = await createProposalNameProposal({
      proposalIpfsHashHex: MOCK_PROPOSAL_IPFS_HASH,
      dydxTokenAddress,
      governorAddress,
      shortTimelockAddress,
      communityTreasuryAddress,
      destinationAddress,
      signer: voter,
    }));
    log('Waiting for voting to begin');
    for (let i = 0; i < deployConfig.VOTING_DELAY_BLOCKS + 1; i++) {
      if (i > 0 && i % 2000 === 0) {
        log('mining', i);
      }
      await advanceBlock();
    }
  }
  let proposalState = await governor.getProposalState(proposalId);
  if (proposalState !== 2) {
    throw new Error('Expected proposal to be in the voting phase.');
  }
  log('Submitting vote');
  await waitForTx(await governor.connect(voter).submitVote(proposalId, true));
  log('Waiting for voting to end');
  let minedCount = 0;
  for (; ;) {
    for (let i = 0; i < 2000; i++) {
      await advanceBlock();
      minedCount++;
    }
    log('mining', minedCount);
    proposalState = await governor.getProposalState(proposalId);
    if (proposalState !== 2) {
      break;
    }
  }
  if (proposalState !== 4) {
    throw new Error(`Expected proposal to have succeeded but state was ${proposalState}`);
  }
  log('Queueing the proposal');
  await waitForTx(await governor.queue(proposalId));
  const delaySeconds = deployConfig.SHORT_TIMELOCK_CONFIG.DELAY;
  await increaseTimeAndMine(delaySeconds);
  log('Executing the proposal');
  await waitForTx(await governor.execute(proposalId));
  log('Proposal executed');
  log('\n=== FUNDING PROPOSAL COMPLETE ===\n');
}
export async function fundProposalNameNoProposal({
  dydxTokenAddress,
  shortTimelockAddress,
  communityTreasuryAddress,
  destinationAddress,
}: {
  dydxTokenAddress: string,
  shortTimelockAddress: string,
  communityTreasuryAddress: string,
  destinationAddress: string,
}): Promise<void> {
  const deployConfig = getDeployConfig();
  const mockShortTimelock = await impersonateAndFundAccount(shortTimelockAddress);
  const communityTreasury = new Treasury__factory(mockShortTimelock).attach(
    communityTreasuryAddress,
  );
  await fundCommunityTreasuryFromFoundationIfNecessary({
    dydxTokenAddress,
    communityTreasuryAddress,
    minTreasuryBalance: deployConfig.PROPSAL_FUNDING_AMOUNT,
  });
  await waitForTx(
    await communityTreasury.transfer(
      dydxTokenAddress,
      destinationAddress,
      deployConfig.PROPOSAL_FUNDING_AMOUNT,
    ),
  );
  log('\n=== PROPOSAL FUNDING COMPLETE ===\n');
}
async function fundCommunityTreasuryFromFoundationIfNecessary({
  dydxTokenAddress,
  communityTreasuryAddress,
  minTreasuryBalance,
}: {
  dydxTokenAddress: string,
  communityTreasuryAddress: string,
  minTreasuryBalance: string,
}): Promise<void> {
  const deployConfig = getDeployConfig();
  const mockFoundation = await impersonateAndFundAccount(deployConfig.TOKEN_ALLOCATIONS.DYDX_FOUNDATION.ADDRESS);
  const dydxToken = new DydxToken__factory(mockFoundation).attach(dydxTokenAddress);
  const communityTreasuryBalance: BigNumber = await dydxToken.balanceOf(communityTreasuryAddress);
  if (communityTreasuryBalance.lt(minTreasuryBalance)) {
    // Transfer necessary funds to the treasury.
    await waitForTx(
      await dydxToken.transfer(
        communityTreasuryAddress,
        minTreasuryBalance,
      ),
    );
  }
}

b. テストスクリプトにテスト関数を追加する

test/migrations/deploy-contracts-for-test.tsに、上記の関数を追加します：

作成した関数をインポートする

test/migrations/deploy-contracts-for-test.ts
...
import { fundProposalNameNoProposal, fundProposalNameViaProposal } from './proposal-name-proposal';

一般的なテスト関数 → executeProposalNameProposalForTestを作成し、両方の関数にテストを追加し、提案に一致する名前を置き換えます。
また、これまで作成した設定変数TEST_PROPOSAL_NAME_TRUST_WITH_PROPOSALと、deployConfigからPROPOSAL_NAME_ADDRESSを呼び出します。

...
export async function executeProposalNameProposalForTest(
  deployedContracts: AllDeployedContracts,
) {
  const deployConfig = getDeployConfig();
  if (config.TEST_PROPOSAL_NAME_TRUST_WITH_PROPOSAL) {
    await fundProposalNameViaProposal({
      dydxTokenAddress: deployedContracts.dydxToken.address,
      governorAddress: deployedContracts.governor.address,
      shortTimelockAddress: deployedContracts.shortTimelock.address,
      communityTreasuryAddress: deployedContracts.communityTreasury.address,
      destinationAddress: deployConfig.PROPOSAL_NAME_ADDRESS,
    });
  } else {
    await fundProposalNameNoProposal({
      dydxTokenAddress: deployedContracts.dydxToken.address,
      shortTimelockAddress: deployedContracts.shortTimelock.address,
      communityTreasuryAddress: deployedContracts.communityTreasury.address,
      destinationAddress: deployConfig.PROPOSAL_NAME_ADDRESS,
    });
  }
}
...
// put this above the configureForTest function

c. テストヘルパーにコントラクトを追加する

test/helpers/get-deployed-contracts-for-test.tsに、上記の関数を追加し、メインネットフォークテストでテストが実行されるようにします。

executeProposalNameProposalForTest関数をマイグレーションファイルからインポートします。

test/helpers/get-deployed-contracts-for-test.ts
...
import {
  configureForTest,
  deployContractsForTest,
  executeSafetyModuleRecoveryProposalsForTest,
  executeStarkProxyProposalForTest,
  executeGrantsProgramProposalForTest,
  executeGrantsProgramv15ProposalForTest,
  executeWindDownBorrowingPoolProposalForTest,
  executeUpdateMerkleDistributorRewardsParametersProposalForTest,
  executeWindDownSafetyModuleProposalForTest,
  executeProposalNameProposalForTest,
} from '../migrations/deploy-contracts-for-test';

getDeployedContractsForTest()関数に関数を追加します:

test/helpers/get-deployed-contracts-for-test.ts
async function getDeployedContractsForTest(): Promise<AllDeployedContracts> {
  if (!config.isHardhat()) {
    return getAllContracts();
  }
  let deployedContracts: AllDeployedContracts;
  if (config.FORK_MAINNET) {
    deployedContracts = await getAllContracts();
  } else {
    deployedContracts = await deployContractsForTest();
    // Execute the proposals which have already been executed on mainnet.
    //
    // The proposals will be executed when running on a local test network,
    // but will not be executed when running on a mainnet fork.
    await executeSafetyModuleRecoveryProposalsForTest(deployedContracts);
    await executeStarkProxyProposalForTest(deployedContracts);
    await executeGrantsProgramProposalForTest(deployedContracts);
    await executeGrantsProgramv15ProposalForTest(deployedContracts);
    await executeWindDownBorrowingPoolProposalForTest(deployedContracts);
    await executeUpdateMerkleDistributorRewardsParametersProposalForTest(deployedContracts);
    await executeWindDownSafetyModuleProposalForTest(deployedContracts);
  }
  await executeProposalNameProposalForTest(deployedContracts);
  // Execute the proposals which have not yet been executed on mainnet.
  await configureForTest(deployedContracts);
  return deployedContracts;
}

d. 最終テストファイル

最後に、モック提案の後、IPFSハッシュとマルチシグの残高のテストを追加し、すべてが予想通りに終了するようにします。

test/miscに、「proposal name labelled → proposal-name-proposal.spec.ts（提案名ラベル付き → 提案名-提案.spec.ts）」と書かれた新しいファイルを追加し、これらの2つのテストを記入します。

IPFSハッシュは、DIP_NUMBER_IPFS_HASHを通じてlibからインポートします。
ProposalNameIdを使用して、次のproposalId番号をハードコードします。
提案ハッシュは、定数ハッシュでチェックします。
PROPOSAL_NAME_ADDRESSをチェックし、PROPOSAL_FUNDING_AMOUNTの残高が予想されているかどうか確認します。

注：このアドレスにdYdXがすでに存在する場合、テストに合格する残高にハードコードする必要があります。

test/misc/proposal-name-proposal.spec.ts
import { expect } from 'chai';
import { DIP_NUMBER_IPFS_HASH } from '../../src/lib/constants';
import { describeContract, TestContext } from '../helpers/describe-contract';
function init() {}
describeContract('proposal-name', init, (ctx: TestContext) => {
  it('Proposal IPFS hash is correct', async () => {
    const ProposalNameId = #;
    const proposal = await ctx.governor.getProposalById(ProposalNameId);
    expect(proposal.ipfsHash).to.equal(DIP_NUMBER_IPFS_HASH);
  });
  it('Destination receives tokens from the community treasury', async () => {
    const balance = await ctx.dydxToken.balanceOf(ctx.config.PROPOSAL_NAME_ADDRESS);
    expect(balance).to.equal(ctx.config.PROPOSAL_FUNDING_AMOUNT);
  });
});

7. PRの送信

これらのコード変更がすべて行われ、ローカルに保存されたら、フォークされたリポジトリにコミットし、dYdXリポジトリにPRを開くことができます。

a. コマンドラインを通じて変更をコミットする

git add .
git commit -m 'funding proposal upload'
git push

b.dYdXリポジトリにPRを送信する

c. リポジトリマネージャーからのレビューと承認を待つ

💼提案ライフサイクル

dYdX改善提案（DIP）ライフサイクルの概要

提案ステージ

以下では、コンセプトの開始および定義から実際の実装までのdYdX v3ガバナンスプロセスがどのように進むかを説明する、あらかじめ準備した草案を概説します。これらのプロセスは、dYdXコミュニティからのフィードバックに応じて変更される場合があります。

以下のフローチャートは、提案を審査する最初の提案ステージです。

0.フォーラムディスカッション

1.（オフチェーン）DRCの作成

少なくとも、DRCには以下のものを含める必要があります。

DRCの短い、簡潔なタイトル
提案の短い、簡潔な説明
DRCの理論的根拠（例：存在理由）
フォーラムポストのタイトルには、DRC：DRCの短いタイトルが含まれる必要があります。例：DRC：新マーケットリクエスト
コミュニティのメンバーがオフチェーンの改善の投票のために使用できるコミュニティ調査

2.DRCディスカッションおよびフィードバック

ガバナンスフォーラムに掲載されると、DRCをさらに改善するため、すべての質問やコメントに対処し、考慮に入れなければなりません。

3。 DRCスナップショット投票

スナップショットでの投票には2つの目的があります：1つは将来におけるオンチェーンDIPのセンチメントのシグナリング、もう1つはオフチェーン制御された変数についての拘束力ある投票です。

オフチェーンDRCで非常に大まかな合意が得られると、1万ガバナンストークン以上の提案権を持つコミュニティメンバーはスナップショットでDRCに対してオフチェーン投票を作成できます。当社では、通常の勤務時間中に可視性を高めるために、dYdXコミュニティに対して月曜日にスナップショット投票を行うことを推奨しています。

スナップショットは、ユーザーがセンチメントオフチェーンを伝えることができるシンプルな投票インターフェースです。スナップショット投票は、投票に使用されるアドレスの投票権に基づいて加重されます。

センチメントのシグナリングに関連するスナップショット投票では、提案者は以下を提供する必要があります：

DRCの詳細、
投票システム、
投票期間（投票の開始日から終了日までの4日間を設定）、
投票遅延 - 6,570ブロック（13.2秒のブロックタイムに基づくと約1日）先のスナップショットブロック番号。スナップショットブロック番号は、投票権を有するコミュニティメンバーの状態をロックします。スナップショットブロック番号の以前からトークンを保有するトークン保有者には、投票する資格があります。ガバナンストークン保有者は、各アドレスの投票権のスナップショット以前に、投票遅延によりトークンの取得、投票権の委任、ウォレット間のトークンの移動に必要な時間が付与されます。ウォレット間の移動は、$ethDYDXと$wethDYDXにのみ適用されることにご注意ください。

オンチェーンでのスマートコントラクトコールが必要でない意思決定の場合、特に取引および流動性プロバイダーの報酬公式の変更については、スナップショットの投票は拘束力を有する最終投票とみなされます。提案者は上記の要件を含め、以下の内容の提供が必要です：

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

スナップショットの投票の結果、以下の条件を満たす場合、dYdX Trading Inc.は提案された変更を実行します。

最小クォーラム（少なくとも100万ガバナンストークン）、最小クォーラムは意思決定の分散化に貢献し、一方的な意思決定から保護します。また、
最小投票差（少なくとも67％が提案に賛成していなければなりません）も同様です。最小投票差は、賛否が大きく割れる提案をふるいにかけ、さらなる議論が必要な場合を判断する助けとなります。

dYdX Trading Inc.はスナップショットの投票で決定された変更について、最長1エポック（28日間）の実行猶予期間を有します。

注：提案および投票は署名済みメッセージとしてIPFSに保存され、コモンウェルスポータルを介して入手できます。

4.（オンチェーン）DIPの作成

ラフコンセンサスに達すると、提案の種類について十分な提案権を保有するコミュニティのメンバーによって、オンチェーンDIPが提出される可能性があります。スマートコントラクト呼び出しを通じてオンチェーンDIPが開始されます。提案は、スナップショットでのオフチェーンDIP投票の賛成結果に基づく必要があり、提案ごとに最大10アクションまで、1つまたは複数のアクションで構成できます。

DIPの作成は、アカウントに必要な保有/委任された最小トークンの数が対象となります。提案作成時に、タイムロックでの実行管理者を指定する必要があります。初期のパラメータは以下のとおりです（ガバナンスによって変更できます）。

パラメータ

説明

短いタイムロックでの実行管理者

Merkle-Pauserの実行管理者

長いタイムロックでの実行管理者

Starkwareの実行管理者

提案のしきい値

提案作成に保有/委任された最小トークン

総供給量の0.5％

総供給量の2％

総供給量の0.5％

5.（オンチェーン）DIPの投票

オンチェーンDIPが作成された後、提案は投票遅延によって定義された期間に保留中の状態に入ります。現在、6,570ブロックまたは約1日間（ブロックごとに13.2秒）です。言い換えれば、DIP作成から1日後にユーザーのスナップショットが記録され、その時点で、提案はアクティブ状態に移行します。

投票遅延後、投票期間がアクティブになります。投票期間は、提案の種類によって異なります。

以下のグラフは、DIP状態フローチャートを示しています。

DIPがオンチェーンで作成された後、投票遅延、投票期間、最小投票数、および最小投票差が対象となります。初期のパラメータは以下のとおりです。

パラメータ

説明

短いタイムロックでの実行管理者

Merkle-Pauserの実行管理者

長いタイムロックでの実行管理者

Starkwareの実行管理者

投票遅延（投票開始までの待機期間）

提案の送信後、提案の投票前に待機するイーサリアムブロック数

6,570ブロック

投票期間*

提案が投票可能である場合の投票期間

4日間

2日間

10日間

4日間

最小クォーラム

DIP提案が審査を通過する場合の最小賛成票

総供給量の2％

総供給量の1％

総供給量の10％

総供給量の2％

投票差

DIP提案が通るために必要な賛成・反対の差

総供給量の0.5％

総供給量の10％

総供給量の0.5％

*13.2秒のブロックタイムに基づくタイミング。

投票遅延はガバナンスによってのみ変更できますが、最小限および最大限の遅延（包含）の間の値に限ります。投票期間、最小クォーラム、投票差は変更できません。

6.提案のキュー追加および実行

DIPが通過すると、任意のアドレスがキューメソッドを呼び出すことで提案をタイムロックのキューに移動できるようになります。DIPは、審査通過した場合にのみキューに追加することができます。

パラメータ

説明

短いタイムロックでの実行管理者

Merkle-Pauserの実行管理者

長いタイムロックでの実行管理者

Starkwareの実行管理者

タイムロック遅延*

提案が通過してキューに入った後、実行までのタイムロックによる遅延（待機期間）

2日間

0日間

7日間

2〜9日間

実行猶予期間*

提案が実行可能になるまでの期間ががあり、その間に実行する必要があります。

7日間

最小タイムロック遅延期間*

提案実行までの最小遅延時間（キュー追加後）

1日間

0日間

5日間

4日間

最大タイムロック遅延期間*

提案執行までの最大遅延時間（キュー追加後）

7日間

1日間

21日間

*13.2秒のブロックタイムに基づくタイミング。

投票期間が終了し、提案が成功すると、誰でもタイムロックの遅延を開始するためにキューを呼び出すことができます。

Starkwareの優先タイムロックの執行管理者は、9日間のタイムロック遅延のうち7日間を優先期間とします。これは、9日間経過以降は誰でも提案を執行できますが、2〜9日間（優先期間）の間はStarkwareが提案を執行するオプションを有していることを意味します。

実際に稼働すると以下のようになります。

0～2日目：誰も実行できません
2～9日目：Starkwareのみ実行できます
9日目：誰でも実行できます

7.（オプション）提案のキャンセル

DIPライフサイクルのいずれの時点でも、提案者はDIPをキャンセルできます。現在のブロックで十分なプロポジションパワーがない場合、提案は執行前に誰でもキャンセルできます。

FAQ

投票遅延の目的は何ですか？

投票遅延とは、提案が送信された後、投票が開始されるまで待機する必要がある期間を指します。この期間は、イーサリアムのブロック数で計算されます。

投票権は、提案が提出される前または提案の投票遅延中に完全にアドレスに委任する必要があります。

現在、投票遅延は6,570ブロックに設定されており、約1日間です。提案作成時に、現在のブロック番号にこの値が追加されます。

将来的に、dYdXガバナンスは投票遅延を増加または減少させることを投票で決定する可能性があります。投票遅延の増加には明確な利点がありますが、日和見主義的なエッジケースによる悪用など、潜在的な悪影響をもたらしてしまう可能性があります。

提案のしきい値の目的は何ですか？

$ethDYDXおよび$wethDYDXは自由に取引可能な資産であるため、マーケット購入を通じて誰でもガバナンスの買収ができるようになってしまいます。とはいえ、悪意のある投票を強制的に通過させようとすると、短いタイムロックの場合には最小500万ガバナンストークン、長いタイムロックの場合には2,000万ガバナンストークンが必要になります。完全に不可能ではないかもしれませんが、この金額は、価格の変動を考慮すると、攻撃による純利益よりも法外に高額となり、より多くのコストがかかってしまいます。

グループが何らかの形で悪意のある買収を行った場合、タイムロックの遅延により、影響を受けた関係者はプロトコルから資産を出金する時間が与えられます。これは、プロトコルをフォークする機会であり、残りの善良な関係者によって実行される可能性が高いパスとなります。

🗳️選択プロセス

投票プロセスの概要

dYdX v3は、ガバナンストークンの保有者と委任者によって管理およびアップグレードされます。

提案権および投票権

各ガバナンストークンと関連付けられた2つの権限があります。

提案権により、提案の作成および維持ができるようになります。
投票権は、既存の提案に賛成または反対の投票を行うために使用されます。

ガバナンストークンの保有者は、所定のブロックにおける所有および委任されたトークンの合計に比例してガバナンス権限を受け取ります。

提案権 = $ethDYDXトークンからの提案権 +

$wethDYDXトークンからの提案権 +

$stkDYDXトークンからの提案権 +

委任者として受け取った$ethDYDXトークンからの提案権 +

委任者として受け取った$wethDYDXトークンからの提案権 +

委任者として受け取った$stkDYDXトークンからの提案権 -

委任された$ethDYDXからの提案権 -

委任された$wethDYDXからの提案権 -

委任された$stkDYDXからの提案権

投票権 = $ethDYDXトークンからの投票権 +

$wethDYDXトークンからの投票権 +

$stkDYDXトークンからの投票権 +

委任者として受け取った$ethDYDXトークンからの投票権 +

委任者として受け取った$wethDYDXトークンからの投票権 +

委任者として受け取った$stkDYDXトークンからの投票権 -

委任された$ethDYDXからの投票権 -

委任された$wethDYDXからの投票権 -

委任された$stkDYDXからの投票権

FAQ

投票するにはどうすればよいですか？

dYdXガバナンスに参加するには、ガバナンストークンを所有しているか、委任される必要があります。トランザクション費用をカバーするには、ETHが必要です。

トークンを保有している、またはトークンを委任されており、アクティブな提案がある場合は、dYdXガバナンスで投票する準備が整っています。

投票するには、提案ページに移動し、アクティブな提案をクリックします。

どのように委任しますか？

dYdXガバナンスでは、保有者は選択したアドレスに投票権を委任できます。誰でもガバナンストークンを所有することなく、委任を受け取ることで、dYdXガバナンスに参加できます。ユーザーは一度に1つのアドレスに委任することができ、委任者の投票カウントに追加された投票数は、ユーザーの口座におけるガバナンストークンの残高に相当します。送信者が再度委任をするか、またはガバナンストークンを譲渡するまで、投票権は現在のブロック以降に委任されます。

トークン保有者は、ガバナンスポータルを通じて、またはプログラムにより、トークンに関連するガバナンス権限の1つまたは両方について、委任することを選択できます。委任された権限を受け取ったユーザーは、委任された権限を別の委任者に譲渡することはできません。

トークン保有者は、提案権および投票権を異なるアドレスに委任することができます。ただし、部分的に委任することはできず、権限は100％または0％のいずれかとなります。

トークンをウォレットアドレスに委任する方法：

「委任」をクリック
委任したい権限の種類を選択
投票権および/または提案権を委任したい第三者のウォレットアドレスを入力します。権限を委任しても、トークンは譲渡されません

ガバナンストークンの委任および委任を解除する場合、ユーザーはイーサリアムのガス代（手数料）を負担する必要があります。

投票した後に、自分の投票内容を変更することはできますか？

投票がオンチェーンで実行されると、投票内容の変更はできません。

投票の進行中にガバナンストークンを譲渡することはできますか？

はい。

自分の投票にトークンを追加することはできますか？

DIPがオンチェーンで提出されると、現在のトークン保有者のスナップショットが取得されます。ユーザーは、スタートブロックの前にガバナンストークンを所有する必要があります。

テクニカル概要

ガバナンスアーキテクチャおよびスマートコントラクトの概要。

ガバナンスアーキテクチャの概要

dYdXのオンチェーン・ガバナンスは以下の機能をサポートしています。

提案の作成および選択
提案の開始時に保有しているトークンのスナップショット
選択権および提案権に関する個別の委任
提案数、定足数、選択の差異基準を含むガバナンス基準の設定
投票のカウント方法を決定する「ガバナンス戦略V2」スマートコントラクトの置き換え
以下の内容を許可する複数の実行管理者コントラクトの構成：
- 1. ショートタイムロックの実行管理者による迅速なプロトコルのアップグレードおよび資金の配分。
- 1. ロングタイムロックの実行管理者によるガバナンスのアップグレード。

dYdXガバナンスをサポートするスマートコントラクトは7つあります。

DydxTokenコントラクト：アドレスが有する選択権や任意のブロック番号での提案権に関するクエリをサポートするスナップショットを維持します。選択権と提案権に関する個別の委任をサポートします。
ラップイーサリアムDydxTokenコントラクト：アドレスが有する投票権や任意のブロック番号での提案権に関するクエリをサポートするスナップショットを維持します。選択権と提案権に関する個別の委任をサポートします。
**DydxGovernorコントラクト：**提案を追跡し、実行管理者のスマートコントラクトを通じて提案を実行することができます。
実行管理者コントラクト：ガバナンスによって選択されたトランザクションのキュー、キャンセル、実行ができます。提案が承認されると、提案で指定された実行管理者コントラクトによって提案内の関数呼び出しが実行される可能性があります。キューされたトランザクションは、実行管理者コントラクトに定められている期間内に実行することが可能です。
******優先タイムロック**コントラクト：タイムロックコントラクトと同じですが、優先度コントローラーが優先期間（タイムロックの遅延終了の7日前）以内にトランザクションを執行することが可能になります。
ガバナンス戦略V2コントラクト：投票数カウントのロジックが含まれています。現在、$ethDYDXトークン、$wethDYDXトークン、$stkDYDXからの投票数をカウントしています。ロングタイムロックによりアップグレードできます。
セーフティモジュールのコントラクト：$ethDYDXトークンのステーク、ステークされたポジションのトークン化、報酬の獲得のためのロジックが含まれており、投票権、提案権、およびアンダーライングトークンの委任に関する機能を保持します。

|コントラクト | アドレス| ------------------------------------ | ------------------------------------------ | | DydxToken | 0x92D6C1e31e14520e676a687F0a93788B716BEff5 || ラップイーサリアムDydxToken | 0x46b2DeAe6eFf3011008EA27EA36b7c27255ddFA9 || DydxGovernor | 0x7E9B1672616FF6D6629Ef2879419aaE79A9018D2 || ショートタイムロックの執行管理者 | 0x64c7d40c07EFAbec2AafdC243bF59eaF2195c6dc ||ロングタイムロックの執行管理者 | 0xEcaE9BF44A21d00E2350a42127A377Bf5856d84B || Merkle-Pauserタイムロックの執行管理者 | 0xd98e7A71BacB6F11438A8271dDB2EFd7f9361F52 || Starkwareの優先タイムロックの執行管理者 | 0xa306989BA6BcacdECCf3C0614FfF2B8C668e3CaE || 報酬基金 | 0x639192D54431F8c816368D3FB4107Bc168d0E871 || 報酬基金ブリッジ | 0x8d0051943D4c72aF12D638c6b7253C71929A910A | | コミュニティ基金 | 0xE710CEd57456D3A16152c32835B5FB4E72D9eA5b || コミュニティ基金ブリッジ | 0x5D8541e3078BE7c2D773185aD8C8b9ED5105E08c | | セーフティモジュール | 0x65f7BA4Ec257AF7c55fd5854E5f6356bBd0fb8EC || ガバナンス戦略V2 | 0xc2f5F3505910Da80F0592a3Cc023881C50b16505 || 報酬基金ベスター | 0xb9431E19B29B952d9358025f680077C3Fd37292f || コミュニティ基金ベスター | 0x08a90Fe0741B7DeF03fB290cc7B273F1855767D8 || Merkleディストリビューター | 0x01d3348601968aB85b4bb028979006eac235a588 || Chainlinkアダプター | 0x99B0599952a4FD2d1A1561Fa4C010827EaD30354 || 流動性ステーキング | 0x5Aa653A076c1dbB47cec8C1B4d152444CAD91941 || 請求プロキシ | 0x0fd829C3365A225FB9226e75c97c3A114bD3199e || StarkExヘルパーガバナー | 0x0db9b3F7Dd83e29C9bece8E5e1089bA4369E694a || StarkExリムーバーガバナーV2 | 0xFCAac0F14deA11eDe11Afcb875f29130e1ad5ec0 || 報酬基金のプロキシ管理者 | 0x40D6992cbd03E0DC1c2DE9606D29Cb245E737a5d || コミュニティ基金のプロキシ管理者 | 0x9d51599A6b10f562619D8ef2EFDcA1B68aE80D03 || セーフティモジュールのプロキシ管理者 | 0x6aaD0BCfbD91963Cf2c8FB042091fd411FB05b3C || Merkleディストリビューターのプロキシ管理者 | 0x6C5cd3aD7A16Ae207D221908E6b997d9B0DcD7b0 | | 流動性ステーキングプロキシ管理者 | 0xAc5D8bCD13da463bea96c75f9085c4e40037F790 || StarkProxy [0] | 0x0b2B08AC98a1568A34208121c26F4F41a9e0FbB6 || StarkProxy [1] | 0x3e6E9EFb0A677a24F47093a22044dc5451A028cF || StarkProxy [2] | 0xCB7fa3a2F47b62293Cc2E1a4C7752fC72E49FCe2 || StarkProxy [3] | 0x16BEC2D9A010e7D8b2D576d17893C52Ddbfe4C06 | | StarkProxy [4] | 0x531F3BE462F10386D01FBeD7fAD1d20A61Ce7874 || StarkProxyのプロキシ管理者 [0] | 0xE16718eace44e0CB06b9cd164490A69A6425D1e3 || StarkProxyのプロキシ管理者 [1] | 0x78e899e576C3565C3219dbC9Ea5042A9DBed36d3 || StarkProxyのプロキシ管理者 [2] | 0x15774D4555fEfD57C9Fc8b11C8beba993eafcc13 || StarkProxyのプロキシ管理者 [3] | 0x4d9460e5C958f46a1Fe129954A069a37972f16EA || StarkProxyのプロキシ管理者 [4] | 0xfa45DCDbEc82C94082d283B62506320DB8632054 |

オープンソースコードおよび監査済みコントラクト

コアガバナンスコントラクト

DydxToken

DydxTokenコントラクトはAaveにインスパイアされました。dYdXチームによってマイナーな変更が行われました。

ABI

ラップイーサリアムDydxToken

ラップイーサリアムDydxTokenコントラクトは、DydxTokenのラップバージョンです。ユーザーは、wethDYDXスマートコントラクトとインタラクションして、wethDYDXを取得できます。

ABI

DydxGovernor

DydxGovernorコントラクトはAaveにインスパイアされました。dYdXによってマイナーな変更が行われました。

ガバナンス戦略V2

ABI

実行管理者

実行管理者コントラクトはAaveにインスパイアされました。dYdXによってマイナーな変更が行われました。

ABI

DYDXのインセンティブコントラクト

Merkleディストリビュータ

Merkleディストリビューターのスマートコントラクトは、Merkleの残高ツリーに従って$ethDYDXトークン報酬を配布します。各ユーザーの累積報酬残高によりツリーを定期的に更新できることで、時間の経過に伴い新しい報酬をユーザーに提供できます。

提案されているMerkleルートをオラクルコントラクトによって返される最新の値に設定することで、更新が実行されます。提案されているMerkleルートは、待機期間が経過した後でアクティブにできます。待機期間中、提案されたルートが間違っているか悪意がある場合、dYdXガバナンスにはMerkleルートを凍結する機会があります。ShortTimelockExecutorでは、ルートの更新の一時停止を解除することができます。

ABI

安全モジュール

セーフティモジュールは、プロトコルのセキュリティに向けて$ethDYDXをステークするユーザーに$ethDYDX報酬を提供するステーキングプールです。

流動性モジュール

流動性モジュールは、ステーキングおよび借入のためのスマートコントラクトの集合体であり、dYdXレイヤ2取引所でのマーケット作成目的の$USDC資金の割り当てを促進します。

ステーカーは、$USDCをステーキングすることで$ethDYDX報酬を獲得します。ステークされた資金はレピュテーションに基づき、無担保で事前に承認された特定のパートナーによって借り入れされる場合があります。資金はL2取引所でのみ使用できます。これはStarkExパーペチュアル取引所コントラクトと相互に適用されるStarkProxyコントラクトを通じて実施されます。

StarkProxy

資金調達コントラクト

ショートタイムロックでは、ガバナンスで承認されたアクションのみ実行できます。

2つの基金ベスターと基金コントラクトがあります。

各基金はガバナンスにより管理されているため、資金を任意のアドレスに移動したり、任意ののアドレスがいずれかの基金にある資金を使用することを承認したりすることができます。たとえば、ガバナンスは報酬プログラムにトークンの承認制限を設定する必要があります。

各基金ベスターは、対応する基金に関して5年間（2021年8月3日～2026年8月3日）にわたりリニアにトークンを保有します。ベスターコントラクトは配備時に不変であるため、dYdXコミュニティはベスターコントラクトの受取人を以下のアドレスに設定することに投票しました。

周辺コントラクト

Chainlink Oracle-Powered Rewards（取引および流動性プロバイダーに関する報酬）

このシステムの目標は、オラクル署名者の分散型ネットワークを通じて、dYdXレイヤ2取引所を利用してトレーダーが獲得したethDYDXトークンの報酬を計算および公開することです。配布プログラムの開始以来、各ユーザーが獲得した累積報酬を含む報酬はMerkleツリーに保存されます。各エポック、MerkleルートはMerkleDistributorV1スマートコントラクトで更新され、前回のエポックで獲得した報酬が反映されます。

当社はChainlinkオラクルシステムと統合しており、報酬データをオンチェーンで掲載します。IPNSを使用して、ChainlinkがMerkleツリーの構築に使用する取引データを掲載します。IPNSを使用することで、以前のエポックと同じIPNSリンクの下に最新のエポックの取引データを掲載できます。つまり、データの場所は変更されません。

生の取引データから適切な報酬を計算した後、ChainlinkはMerkleの報酬ツリーをIPFSに掲載します。Merkleツリーのデータを有するIPFS CIDは、そのエポックの報酬に関するMerkleツリーと共にMerkleディストリビューターコントラクトに保存されます。

以下のフローチャートは、Chainlink Oracle-Powered Rewardsのシステムアーキテクチャを示しています。

その他の資産

用語集

主要なガバナンス関連用語の概要。

$**ethDYDX：**dYdX v3のガバナンスと安全性の基盤を構成しているイーサリアムベースのdYdXエコシステムのネイティブアセット。 $ethDYDXは、ユーザーの投票権または提案権の重みを指定するERC-20トークンです。

$wethDYDX：$wethDYDXスマートコントラクトとインタラクションして得られる$ethDYDXのラップバージョン。 $wethDYDXは、ユーザーの投票権または提案権の重みを指定するERC-20トークンです。

**dYdX v3：**dYdXのレイヤ2パーペチュアルプロトコル。

**dYdX Foundation：**スイスのツークに本部を置く独立した基金として設立され、将来に向けてdYdXプロトコルの普及、推進を行います。

$ethDYDXトークンコントラクト：時間的に異なるブロックにおける各アドレスの投票権に関するスナップショットを保持しています。

$wethDYDXトークンコントラクト：時間的に異なるブロックにおける各アドレスの投票権に関するスナップショットを保持しています。

**DIP：**dYdXの改善提案はオンチェーンでの提案となります。

DRC：dYdXのコメントリクエストはオフチェーンの提案であり、ガバナンスの改善プロセスにおける最初のステップです。

**クォーラム：**選択が承認されるには、DYDXトークンの肯定的な最小クォーラムを達成することが必要です。クォーラムの目的は、承認された方法だけが適切な選択権者の参加を確保できるようにすることです。

**エポック：**その他のすべてのコントラクトは、エポックと呼ばれる28日間のサイクルで動作します。

**実行猶予期間：**選択後にDIP提案が実行可能になる期間で、その期間中に実行される必要があります。

ガバナンス戦略V2コントラクト：提案および投票に関するユーザーの相対的な権限を測定するロジックが含まれています。

ガバナーコントラクト：提案を追跡し、タイムロックでのスマートコントラクトを通じて提案を実行できます。

**ロングタイムロックでの実行管理者：**ロングタイムロックでの実行管理者は、ガバナンスのコンセンサスに影響を与えるプロトコルの一部について一般的に変更する提案を実行できます。

**Merkle-pauserの実行管理者：**Merkle-pauserの実行管理者は、Merkleルートをフリーズする提案を実行できます。これは各ユーザーの累積報酬残高と共に定期的に更新され、提案されたルートが適切でないか悪意がある場合には、新しい報酬を時間の経過に応じてユーザーに提供できるようにします。

**セーフティプール：**プロトコルを債務超過から保護する責任があるコンポーネントです。

ステークされたdYdXコントラクト：DYDXトークンをステークし、ポジションをトークン化し、報酬を獲得するためのロジックが含まれています。

**ショートタイムロックでの実行管理者：**ショートタイムロックでの実行管理者は、迅速な介入を必要とする報酬やインセンティブに関するコントラクト、またはコミュニティ基金に対する一般的な変更の提案を実行できます。

**Starkwareの実行管理者：**Starkwareの実行管理者は、現在Starkwareからの介入を必要とするプロトコルの一部に対する一般的な変更の提案を実行できます。

タイムロックコントラクト：ガバナンスによって選択されたトランザクションのキュー、キャンセル、実行ができます。提案におけるこのような機能は、タイムロックコントラクトによって開始されます。キューされたトランザクションは遅延後および猶予期間が経過しない間は実行できます。

**タイムロックでの遅延：**提案が承認され、キューされた後、DIP提案が実行されるまでの遅延。

**提案の基準値：**多数のスパム提案がシステムで作成されることを防ぐために、提案の前にアドレスが一定数の選択権を獲得しておく必要があります。

**提案権：**提案の作成および維持にアクセスできるトークンステーク。

**選択権：**既存の提案の選択または反対に使用される権利。

**選択遅延：**提案が作成可能になった後、選択可能になるまでの期間。少なくとも1ブロックの承認が必要で、ガバナンスは多数のトークンを借りたり、選択の提案をしたり、1ブロックすべてを選択したりする可能性があるフラッシュローン攻撃から保護されます。

**選択期間：**DIP提案が実行されると、DYDXのコミュニティメンバーは選択期間終了までに選択を行う必要があります。これはイーサリアムブロックで提案の選択が行われる期間です。

**提案の基準値：**DIP提案の作成に必要で保有/委任されている最小トークン。

**選択差：**DIPの提案が通過するためには、賛成と反対の間に差があることが必要です。

🏛️ガバナンスガイド

ガバナンスプロセスDRCの作成、スナップショット投票の作成、DIPの作成、スナップショット投票への投票、DIPへの投票、DIPのキューイング、DIPの実行に関するステップ・バイ・ステップの概要

dYdX Foundationは、dYdXコミュニティがdYdXのガバナンスプロセスを理解するための支援を目的として、このガイドを作成しました。このガイドでは、以下の内容についてステップ・バイ・ステップで概説しています。

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

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

要約：

背景：

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

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

説明：

DIP 2への適用：

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

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

- DRCの簡潔で短いタイトル
- 提案の簡潔で短い説明
- DRCの合理的理由（例：なぜ？）
- フォーラムポストのタイトルにはDRC：[DRCの短いタイトルを挿入]（例えば、DRC：新しいマーケットリクエスト）を含めなければなりません。
- コミュニティのメンバーがオフチェーンの改善の投票のために使用できるコミュニティ調査

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

説明：

DIP 2への適用：

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

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

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

スナップショット投票への投票方法：

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

スナップショット投票の作成方法：

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

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

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

拘束力のあるスナップショット投票の要件

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

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

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

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

説明：

DIP 2への適用：

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

DIPの作成方法：

DIPステータス：

WIP - まだ開発中のDIP。
提案済み - オンチェーン提案の準備ができているDIP。
承認済み - dYdXコミュニティによる実装が承認されたDIP。
実装済み - メインネットにリリースされたDIP。
拒否 - 拒否されたDIP。

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

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

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

要約：

背景：

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

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

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

説明：

DIP 3への適用：

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

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

新しいウォレットでDIPを作成します。デプロイメントプロセスでは環境変数としてシードフレーズを入力する必要があるため、オンチェーンDIPの作成にはワンオフウォレットを使用することを推奨します。
- ショートタイムロック：総供給量の0.5％（提案権：5M）
- Starkwareの実行管理者：総供給量の0.5％（提案権：5M）
- ロングタイムロックの実行管理者：総供給量の2.0％（提案権：20M）
- Merkle Pauserの実行管理者：総供給量の0.5％（提案権：5M）

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

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

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

提案されたスマートコントラクトの実装をドラフトします。

新しいファイル（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は2021年11月1日、ブロック13532376で作成されました。将来の6,570ブロックの場合、DIPのステータスは「保留」です。

ethDYDXの保有者は、DIPがブロック13538946で「アクティブ」状態に移行したときに投票することができました。

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

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

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

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

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

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