dYdX v4｜Cosmos SDK 独自チェーンと機関 Perps

dYdX は2017年創業の老舗デリバティブ（Perps）プロトコルで、2023年に v3（Ethereum L2 StarkEx（StarkWare 提供の Ethereum L2 スケーリング技術）上）から v4（Cosmos SDK（Cosmos エコシステムでのチェーン構築フレームワーク）独自チェーン）へ大きく移行した（出典: dYdX 公式 Docs、Cosmos SDK Docs）。

ただし、いきなり「v4」の話から入ると、なぜこの移行が必要だったのかが見えにくい。本記事ではまず dYdX の創業から各バージョン（v1/v2/v3）の歩みを整理し、その上で「なぜわざわざ独自チェーンに行ったか」「機関採用にどんな影響があったか」を、自社で機関向け Perps を組む事業者の参考として読み解いていく。

目次

1. なぜ事業者が dYdX v4 を理解する必要があるのか
2. dYdX とは｜創業からの歩みと各バージョン
3. v3 から v4 への移行の背景
4. Cosmos SDK 独自チェーンの設計
5. orderbook 型 Perps の機関親和性
6. Hyperliquid との比較
7. 自社で機関向け Perps を組む際の参考点
8. まとめ

1. なぜ事業者が dYdX v4 を理解する必要があるのか

「機関向けに本格的な orderbook 型 Perps を組む」という事業ニーズの代表的な参考設計。dYdX は2017年から運用される老舗で、多くの試行錯誤を経た知見が蓄積している。なぜ最終的に独自チェーン（v4）という重い選択に至ったかは、それ以前の各バージョンで何にぶつかってきたかを追うと理解しやすい。

2. dYdX とは｜創業からの歩みと各バージョン

dYdX とは

dYdX は、Antonio Juliano 氏が2017年に創業した、分散型デリバティブ（とりわけ無期限先物＝Perpetuals／Perps）を提供するプロトコルである。Coinbase や Uber でのエンジニア経験を持つ Juliano 氏が立ち上げ、DeFi 黎明期から継続して運用されてきた数少ない「老舗」Perps プロジェクトのひとつ（出典: dYdX 公式 Docs）。

「v4」だけを見ると突然 Cosmos の独自チェーンが出てくるように見えるが、実際には v1 → v2 → v3 → v4 と、その時々のブロックチェーン技術の制約と向き合いながら基盤を載せ替えてきた歴史がある。ここではそのバージョンの変遷を整理する。

v1 / v2｜Ethereum L1 時代（2017〜2020年）

初期の dYdX は、Ethereum メインネット（L1）上のスマートコントラクトとして構築されていた。提供していたのは主に以下の機能である。

• マージン取引（証拠金取引）: 借り入れを使ったレバレッジ取引
• Lending（貸借）: 資産の貸し出し・借り入れによる金利市場
• Perpetuals（無期限先物）: 後年 dYdX の主軸となる Perps の提供開始

この時代は完全にオンチェーンで完結する設計だったが、Ethereum L1 で全注文・全約定を処理するため、ガス代の高さと処理遅延が大きなボトルネックだった。中央集権取引所（CEX）並みの板取引（orderbook）の操作感を、L1 上でそのまま再現するのは現実的でなかった。

v3｜StarkEx（ZK-rollup L2）への移行（2021年〜）

このスケーリング問題を解決するため、dYdX は2021年に v3 で StarkWare の StarkEx（ZK-rollup ベースの Ethereum L2 スケーリング技術）上へ移行した。これにより Perps DEX として大きく成長する（出典: dYdX 公式 Docs、StarkWare 公式）。

v3 の設計上のポイントは、オフチェーンの orderbook ＋ オンチェーンの決済というハイブリッド構成だった。

• オフチェーン orderbook / マッチング: 注文の板管理と約定マッチングは、dYdX Trading 社が運用するオフチェーンのエンジンが担当。これにより CEX 並みの高速な板取引が可能になった
• オンチェーン決済（StarkEx L2）: 約定後の残高・ポジションの確定は L2 上で行い、最終的に Ethereum L1 のセキュリティに依拠
• ユーザー資産: Ethereum 側に紐づく形で保管

v3 は技術的にも商業的にも成功した一方で、構造上いくつかの論点を抱えていた。

• 中央集権的な orderbook 運用: 板とマッチングを dYdX Trading 社が運用しており、「分散型」を掲げる Perps DEX としては中央集権性が論点となった
• 手数料収益の帰属: 取引手数料の収益も、トークン保有者ではなく運営チーム側に帰属する構造だった
• 規制適応の制約: StarkEx という特定 L2 基盤に依存し、運営主体やマッチング運用が一元的だったため、規制環境への適応の自由度が限られた

なぜ v4 で独自チェーン（Cosmos SDK）へ進んだのか

これら v3 の課題——中央集権的な orderbook 運用・収益分配の偏り・規制適応の制約——を根本から解決するため、dYdX は次の v4 で「他人の L2 に乗る」のをやめ、Cosmos SDK を使った 完全分散の独自チェーン（dYdX Chain） を自前で構築する道を選んだ。

つまり v3 → v4 の移行は、単なる技術的なアップグレードではなく、「中央集権的に運用していた板・マッチング・収益を、チェーンとバリデータ・トークン保有者へ分散させる」という構造転換だった。次章以降で、この v4 の設計を具体的に見ていく。

3. v3 から v4 への移行の背景

v3（StarkEx）の制約

• Ethereum L2 上で動作
• StarkEx のホワイトリストに依存
• ユーザー資産の Ethereum 上保管
• 取引手数料収益が dYdX チームに帰属

v4（Cosmos SDK 独自チェーン）

• 独自チェーン（dYdX Chain）として稼働
• バリデータが取引を処理
• 取引手数料収益が DYDX をステーキングしたステーカー（委任者）とバリデータに分配（単に保有しているだけでは対象外で、ステーキングが分配の前提）
• 完全な分散化

移行の動機

• 収益のステーカー還元: v3 はチーム集中、v4 は DYDX をステーキングしたステーカーとバリデータへ分配（保有のみでは対象外）
• 規制ジャクション選択の余地: バリデータの地理分散により、運営主体や設置先となるジャクションを選びやすい構造になり得る（ただし日本機関が利用する場合は別途論点があり、各社で要確認）
• 機能拡張の自由度: Ethereum L2 の制約を抜ける

4. Cosmos SDK 独自チェーンの設計

Cosmos SDK とは

ブロックチェーンを構築するためのフレームワーク。Cosmos エコシステムで使われる。dYdX v4 はこれを使って独自チェーンを構築。

特徴

• 専用ブロックチェーン: dYdX 専用なので、他のアプリと処理時間を奪い合わない
• 高速ブロック生成: 1秒以下のブロック時間で CEX 並みの応答性
• orderbook の効率実装: 各バリデータが in-memory（オフチェーン、コンセンサスには非コミット）の orderbook を保持してマッチングを行い、約定結果のみをオンチェーンで確定する。板そのものはオンチェーンには載らない

5. orderbook 型 Perps の機関親和性

orderbook が機関に好まれる理由

• CEX 並みの UX: 機関は CEX の取引画面に慣れている
• 指値注文（Limit Order）: AMM の成行のみと違い、希望価格指定可能
• MEV 攻撃に強い: バッチ約定でサンドイッチ攻撃を回避

vAMM/GLP との比較

• vAMM: 流動性は数式、機関が大口取引すると価格インパクト大
• GLP: LP がカウンターパーティ、機関の取引相手として規模に限界
• orderbook: マッチング型、機関向けの大口取引に対応

dYdX v4 の方が、本格的な機関採用に向く。

6. Hyperliquid との比較

dYdX は機関親和性を狙う設計、Hyperliquid は個人 UX を狙う設計。

両者の最も本質的なアーキテクチャ差は orderbook の置き場所にある。dYdX v4 の板は各バリデータの in-memory mempool 上にあり、コンセンサスにはコミットされない（オンチェーンで確定するのは約定のみ）。一方 Hyperliquid の HyperCore は全注文・キャンセル・約定をオンチェーンに記録する真のフルオンチェーン板で、この設計思想の違いが両者を分ける核となる。

なお KYC については、dYdX v4・Hyperliquid とも KYC 自体は要求せず、対象外地域をフロントエンドでジオブロックする方式で、規制スタンスは大きく違わない。

出典: dYdX 公式 Docs、Hyperliquid 公式 Docs、両者の取引高比較は DefiLlama Derivatives を参照。

7. 自社で機関向け Perps を組む際の参考点

独自チェーンを組む選択肢

• 自社で Cosmos SDK / 独自 L1 を立ち上げる → 6-12人月、運用コスト大
• L2（Arbitrum、Optimism）上に Perps プロトコル → 短期、L2 制約あり
• 既存独自チェーン（dYdX v4 等）に乗る → 即時、独自経済設計は不可

orderbook 実装

• フルオンチェーン板（Hyperliquid HyperCore 型）: 全注文・約定をオンチェーンに記録、規模に応じて TPS が問題
• バリデータ in-memory 板 ＋ オンチェーン約定（dYdX v4 型）: 板はバリデータの mempool 上（オフチェーン）、約定のみオンチェーン確定
• ハイブリッド（運営オフチェーン matching + onchain settlement）: 軽量だが分散化弱

規制対応

• 機関向け permissioned 設計: KYC 統合、許可制
• 海外設立で規制軽減: ただし日本機関の利用には別途論点

8. まとめ

3つの要点:

1. dYdX v4 = Cosmos SDK 独自チェーン上の orderbook 型 Perps
2. 機関親和性が orderbook の強み
3. 自社で機関向け Perps を組む参考設計として価値

詳しくは Perps funding rate と Hyperliquidとは？ を参照。

関連記事

機関向け Perps の設計判断を、隣接する Perps 設計選択と接続するための記事を整理しました。

• Perps funding rate メカニズム — orderbook 型でも funding rate は機能。本記事の前提となるメカニズム
• vAMM の仕組み — 本記事 4章「vAMM/GLP との比較」の対象設計を、機関親和性の観点から深掘り
• GMX GLP モデル — orderbook 型が機関向けに有利な背景となる、GLP 型の構造的限界の事例研究
• Hyperliquidとは？ — 本記事 5章で比較対象。同じ orderbook 型でも個人 UX 寄りの設計差
• Monad Parallel EVM L1 — Cosmos SDK 以外の独自 L1 選択肢として、機関向け Perps 基盤として検討対象

本記事は XTELA JAPAN 株式会社が作成しました。 Perps 開発のご相談は無料技術相談からお問い合わせください。