オンチェーンデリバティブDEX比較 — Hyperliquid・dYdX・GMX・Vertex・Drift

はじめに

オンチェーンデリバティブ市場は2025-2026年にかけて急速に成長し、CEXの永久先物取引高の約10%に迫る規模に到達しています。中でも永久先物（Perpetual Futures / Perps）は最も人気の高いデリバティブ商品で、有効期限のないレバレッジ取引を可能にします。

本記事では、主要なオンチェーンデリバティブDEXをアーキテクチャ・手数料・清算メカニズム・API/ボット開発の観点から徹底比較します。

永久先物（Perps）の基本

ファンディングレート

永久先物には有効期限がないため、ファンディングレート（資金調達率）でスポット価格への収束を維持します。

【ファンディングレートの仕組み】

先物価格 > スポット価格（プレミアム）の場合:
  ロング（買い手）→ ショート（売り手）に支払い
  → ロングを持つコストが上がり、先物価格が下落方向に

先物価格 < スポット価格（ディスカウント）の場合:
  ショート（売り手）→ ロング（買い手）に支払い
  → ショートを持つコストが上がり、先物価格が上昇方向に

典型的なファンディング間隔:
  CEX: 8時間ごと
  Hyperliquid: 1時間ごと
  dYdX v4: 1時間ごと
  GMX v2: 1時間ごと

オンチェーンPerpsのアーキテクチャ分類

主要プロトコル詳細

1. Hyperliquid

独自L1チェーン上で完全オンチェーンのオーダーブックを運営する、最も急成長しているPerps DEXです。

基本データ

アーキテクチャ

【Hyperliquid のアーキテクチャ】

ユーザー ─→ Arbitrum (入金) ─→ Hyperliquid L1
                                    │
                                    ├── Matching Engine（マッチングエンジン）
                                    │    └── 完全オンチェーンオーダーブック
                                    │
                                    ├── Clearinghouse（クリアリングハウス）
                                    │    ├── 証拠金管理
                                    │    ├── 清算エンジン
                                    │    └── 保険基金
                                    │
                                    ├── HLP（Hyperliquidity Provider）
                                    │    └── プロトコル所有のマーケットメイキング
                                    │
                                    └── HyperEVM
                                         └── EVM互換スマートコントラクト

API（Python SDK）

from hyperliquid.info import Info
from hyperliquid.exchange import Exchange
from hyperliquid.utils import constants
import eth_account

# 初期化
secret_key = "0x..."  # プライベートキー
account = eth_account.Account.from_key(secret_key)
info = Info(constants.MAINNET_API_URL)
exchange = Exchange(account, constants.MAINNET_API_URL)

# 市場データ取得
meta = info.meta()
for asset in meta["universe"][:5]:
    print(f"{asset['name']}: 最大レバ {asset['maxLeverage']}x")

# ポジション情報
user_state = info.user_state(account.address)
for position in user_state["assetPositions"]:
    pos = position["position"]
    print(f"{pos['coin']}: {pos['szi']} @ {pos['entryPx']}")

# 指値注文
order_result = exchange.order(
    coin="ETH",
    is_buy=True,
    sz=0.1,           # 0.1 ETH
    limit_px=3000.0,  # $3,000
    order_type={"limit": {"tif": "Gtc"}},  # Good-til-Cancel
)
print(f"注文ID: {order_result['response']['data']['statuses']}")

# 成行注文（即時執行）
market_order = exchange.order(
    coin="BTC",
    is_buy=True,
    sz=0.01,
    limit_px=None,
    order_type={"limit": {"tif": "Ioc"}},  # Immediate-or-Cancel
)

2. dYdX v4

Cosmos SDKベースの独自アプリケーションチェーンで運営される、分散型デリバティブ取引所です。

基本データ

v3 → v4 の進化

オーダーブックの仕組み

【dYdX v4 のオーダーブック処理】

1. ユーザーが注文を送信
2. バリデータのメモリ内でオーダーブックを管理
   ├── 指値注文: メモリに保存
   ├── 成行注文: 即時マッチング
   └── マッチ結果のみブロックに記録

特徴:
- オーダーブック自体はオンチェーンに記録されない
  （バリデータのメモリ内でのみ管理）
- マッチング結果（約定）のみがブロックチェーンに記録
- これにより高スループットを実現

API

from dydx_v4_client import NodeClient, Wallet
from dydx_v4_client.indexer.rest import IndexerClient

# インデクサーAPI（市場データ）
indexer = IndexerClient(host="https://indexer.dydx.trade")

# 市場情報取得
markets = indexer.markets.get_perpetual_markets()
for symbol, data in list(markets["markets"].items())[:3]:
    print(f"{symbol}: 価格=${data['oraclePrice']}, "
          f"OI=${data['openInterest']}, "
          f"24h Vol=${data['volume24H']}")

# オーダーブック取得
orderbook = indexer.markets.get_perpetual_market_orderbook("BTC-USD")
best_bid = orderbook["bids"][0]
best_ask = orderbook["asks"][0]
print(f"BTC-USD: Bid={best_bid['price']} Ask={best_ask['price']}")

# 注文送信（概念コード）
wallet = Wallet.from_mnemonic("your mnemonic here")
node_client = NodeClient.connect("dydx-mainnet-full-grpc")
tx = await node_client.place_order(
    wallet=wallet,
    order={
        "subaccount_id": 0,
        "market_id": "BTC-USD",
        "side": "BUY",
        "price": 90000,
        "size": 0.01,
        "time_in_force": "GTT",
        "good_til_block": current_block + 20,
    }
)

3. GMX v2

Arbitrum/Avalanche上で運営される、プール型の分散型デリバティブ取引所です。

基本データ

GM プールモデル（v2）

【GMX v2 の GM プール構造】

GM Pool（例: ETH/USD Market）
├── ロングトークン: ETH（50%）
├── ショートトークン: USDC（50%）
│
├── トレーダーのロングポジション
│   → ETH価格上昇時: プールからトレーダーに支払い
│   → ETH価格下落時: トレーダーからプールに支払い
│
└── トレーダーのショートポジション
    → ETH価格下落時: プールからトレーダーに支払い
    → ETH価格上昇時: トレーダーからプールに支払い

LP（GM トークン保有者）の収益:
  + 取引手数料（開/閉ポジション手数料）
  + ファンディングレート
  + 借入手数料
  - トレーダーのPnL（トレーダーが勝つとLPの損失）

手数料構造

4. Vertex Protocol

Arbitrum上のハイブリッドDEXで、オーダーブックとAMMを組み合わせたユニークなアーキテクチャを持ちます。

基本データ

ハイブリッドアーキテクチャ

【Vertex のハイブリッドモデル】

ユーザー注文
    │
    ▼
Sequencer（オフチェーン）
    │
    ├── Orderbook Engine
    │   └── メイカー/テイカー注文のマッチング
    │
    ├── AMM（バックストップ流動性）
    │   └── オーダーブックで約定しない場合の流動性提供
    │
    └── 約定結果 → Arbitrum L1 に記録

特徴:
- オーダーブックの効率性 + AMMの流動性を両立
- Sequencerによる高速マッチング（<5ms）
- クロスマージン対応

クロスマージンとポートフォリオマージン

【クロスマージン vs 分離マージン】

分離マージン（Isolated）:
  BTC ロング: 証拠金 $1,000 / PnL +$500
  ETH ショート: 証拠金 $1,000 / PnL -$800
  → 各ポジションが独立、ETHポジションは清算リスクあり

クロスマージン（Cross）:
  全証拠金: $2,000
  BTC ロング: PnL +$500
  ETH ショート: PnL -$800
  未実現PnL合計: -$300
  利用可能証拠金: $2,000 - $300 = $1,700
  → ポートフォリオ全体で証拠金を共有

Vertexの優位性:
  - スポット + Perps + マネーマーケットが統合
  - スポットポジションも証拠金として利用可能

5. Drift Protocol（Solana）

Solana上で運営されるデリバティブDEXで、vAMMとDLOB（Decentralized Limit Orderbook）を組み合わせています。

基本データ

vAMM + DLOBの仕組み

【Drift の価格決定メカニズム】

1. DLOB（分散型指値注文台帳）
   ├── ユーザーの指値注文をキーパーネットワークで管理
   ├── マッチング条件を満たすと約定
   └── オンチェーンで決済

2. vAMM（仮想AMM）
   ├── 実際のトークンプールは持たない
   ├── オラクル価格 + 仮想曲線で価格決定
   ├── DLOBで約定しない注文のバックストップ
   └── 資金調達率で価格収束を維持

3. JIT（Just-in-Time）流動性
   ├── マーケットメイカーが成行注文に対して即時流動性を提供
   └── DLOBやvAMMより良い価格で約定可能

Drift SDK

from driftpy.drift_client import DriftClient
from driftpy.accounts import get_perp_market_account
from solders.keypair import Keypair
from anchorpy import Wallet

# 初期化
keypair = Keypair.from_base58_string("your_secret_key")
wallet = Wallet(keypair)
drift_client = DriftClient(
    connection=connection,
    wallet=wallet,
    env="mainnet"
)
await drift_client.subscribe()

# 市場データ取得
perp_market = await get_perp_market_account(
    drift_client.program,
    market_index=0  # SOL-PERP
)
print(f"SOL-PERP OI: {perp_market.amm.base_asset_amount_with_amm}")

# 永久先物注文
from driftpy.types import OrderParams, OrderType, PositionDirection

order_params = OrderParams(
    order_type=OrderType.Limit(),
    market_index=0,  # SOL-PERP
    direction=PositionDirection.Long(),
    base_asset_amount=1_000_000_000,  # 1 SOL
    price=150_000_000,  # $150
)
await drift_client.place_perp_order(order_params)

6. Synthetix Perps（v3）

合成資産プロトコルSynthetixのPerps市場。Base/Optimismで稼働しています。

基本データ

特徴

【Synthetix Perps の仕組み】

SNXステーカー（LPの役割）
    │
    ├── SNXを担保として預入
    ├── 合成資産（snxUSD）を発行
    └── トレーダーのカウンターパーティとして機能

トレーダー:
    ├── snxUSD を証拠金として使用
    ├── オラクル価格で即時約定（スリッページなし）
    └── ファンディングレートでコスト発生

メリット:
  - 無限の流動性（オラクル価格で常に約定）
  - ゼロスリッページ
  - 暗号通貨以外のアセット（FX、コモディティ）も取引可能

デメリット:
  - オラクルリスク（価格操作の可能性）
  - SNXステーカーへのリスク集中
  - OI上限が必要

総合比較表

清算メカニズムの比較

清算プロセス

【一般的な清算フロー】

1. マージン率が維持証拠金率を下回る
   維持証拠金率: 通常 3-6.25%（プロトコルにより異なる）

2. 清算の発動
   ├── Hyperliquid: バリデータが自動清算
   ├── dYdX: バリデータが自動清算
   ├── GMX: キーパーネットワークが清算
   ├── Vertex: Sequencerが清算
   └── Drift: キーパーが清算（報酬あり）

3. 保険基金
   清算時の損失がユーザーの証拠金を超えた場合:
   → 保険基金から補填
   → 保険基金が枯渇した場合: ADL（自動デレバレッジ）

保険基金と ADL

清算ボット開発

Hyperliquid清算モニタリング

import asyncio
import json
import websockets
from dataclasses import dataclass

@dataclass
class LiquidationEvent:
    user: str
    coin: str
    side: str
    size: float
    price: float
    timestamp: int

async def monitor_liquidations():
    """Hyperliquidの清算イベントをリアルタイム監視"""
    uri = "wss://api.hyperliquid.xyz/ws"

    async with websockets.connect(uri) as ws:
        # 清算イベントを購読
        subscribe_msg = {
            "method": "subscribe",
            "subscription": {"type": "liquidations"}
        }
        await ws.send(json.dumps(subscribe_msg))

        async for message in ws:
            data = json.loads(message)
            if data.get("channel") == "liquidations":
                for liq in data["data"]:
                    event = LiquidationEvent(
                        user=liq["user"],
                        coin=liq["coin"],
                        side=liq["side"],
                        size=float(liq["sz"]),
                        price=float(liq["px"]),
                        timestamp=liq["time"],
                    )
                    print(f"清算: {event.coin} {event.side} "
                          f"{event.size} @ ${event.price}")

                    # 大規模清算後の価格反転を狙う戦略
                    if event.size * event.price > 100_000:
                        print(f"  → 大規模清算検出: "
                              f"${event.size * event.price:,.0f}")

GMX v2 清算ボット

from web3 import Web3
from eth_abi import decode

# GMX v2 清算可能ポジションの監視
GMX_READER = "0x..."  # GMX Reader contract
DATASTORE = "0x..."   # GMX DataStore contract

w3 = Web3(Web3.HTTPProvider("https://arb1.arbitrum.io/rpc"))

def check_liquidatable_positions(market: str) -> list:
    """清算可能なポジションを取得"""
    reader = w3.eth.contract(address=GMX_READER, abi=READER_ABI)

    # アクティブポジションを取得
    positions = reader.functions.getAccountPositions(
        DATASTORE,
        market,
        0,  # start
        100,  # count
    ).call()

    liquidatable = []
    for pos in positions:
        # ポジションの健全性チェック
        is_liquidatable = reader.functions.isPositionLiquidatable(
            DATASTORE,
            pos,
        ).call()

        if is_liquidatable:
            liquidatable.append(pos)

    return liquidatable

ファンディングレート裁定戦略

CEX-DEX ファンディングアービトラージ

import ccxt
from hyperliquid.info import Info

async def funding_rate_arbitrage():
    """
    CEXとDEXのファンディングレート差を利用した裁定

    戦略:
      - ファンディングが高い方でショート
      - ファンディングが低い方でロング
      → 差額を収益として受け取る
    """
    # CEX（Binance）のファンディングレート
    binance = ccxt.binance()
    binance_funding = binance.fetch_funding_rate("BTC/USDT:USDT")
    binance_rate = binance_funding["fundingRate"]

    # Hyperliquidのファンディングレート
    info = Info("https://api.hyperliquid.xyz")
    hl_meta = info.meta_and_asset_ctxs()
    btc_ctx = next(
        ctx for ctx in hl_meta[1]
        if ctx["coin"] == "BTC"
    )
    hl_rate = float(btc_ctx["funding"])

    spread = abs(binance_rate - hl_rate)
    annual_yield = spread * 3 * 365 * 100  # 8h funding × 3 × 365日

    print(f"Binance Funding: {binance_rate:.6f}")
    print(f"Hyperliquid Funding: {hl_rate:.6f}")
    print(f"Spread: {spread:.6f}")
    print(f"年率換算: {annual_yield:.2f}%")

    if spread > 0.0005:  # 0.05%以上のスプレッド
        if binance_rate > hl_rate:
            print("→ Binanceでショート、Hyperliquidでロング")
        else:
            print("→ Hyperliquidでショート、Binanceでロング")

        return {
            "strategy": "funding_arb",
            "spread": spread,
            "annual_yield_pct": annual_yield,
            "long_venue": "Hyperliquid" if binance_rate > hl_rate else "Binance",
            "short_venue": "Binance" if binance_rate > hl_rate else "Hyperliquid",
        }

    print("→ スプレッド不十分、見送り")
    return None

API/SDK 比較表

プロトコル選択ガイド

ユースケース別推奨

リスク比較

まとめと2026年の展望

オンチェーンデリバティブDEXは急速に進化しており、CEXとの機能差は縮小し続けています。

2026年の主要トレンド

1. アプリチェーン化: HyperliquidとdYdX v4に続き、専用チェーンでの運営がトレンドに
2. クロスマージンの標準化: ポジション全体で証拠金を共有するモデルが主流に
3. RWA Perps: 株式指数、コモディティ、FXの永久先物がオンチェーンで取引可能に
4. インスティテューショナル参入: KYC対応のオンチェーンPerpsが登場
5. MEV保護: バッチオークション、暗号化メモリプール等の対策が進化

ボット開発者にとっては、Hyperliquidの高速APIとGMX v2のキーパーネットワークが最も魅力的なエントリーポイントです。ファンディングレート裁定やクロスDEX裁定は、比較的低リスクで安定した収益を得られる戦略として注目されています。