October 3, 2025

How Perp DEX’s Oracle Works

Pyth, Switchboard, Hyperliquidの価格フィードはどう動いているのか

Perp DEXにおいて、Oracleは心臓部。Mark priceの計算、funding rateの算出、liquidation threshold、TP/SLのトリガー。全部Oracleが出す価格データに依存している。Oracleが壊れたらプロトコルが壊れる。Oracleが操作されたらトレーダーの資金が抜かれる。2022年のMango Markets ( $117M)、2025年のKiloEx ($ 7.5M)。全部Oracleの話。

この記事ではSolana系Perp DEX（Drift, Jupiter Perps, Zeta）とHyperliquidのOracle設計を、中の仕組みから整理する。

Perp DEXにおけるOracleの役割

1. そもそもOracleとは

ブロックチェーンは外部データを自力で取得できない。スマートコントラクトは自分の状態と他のコントラクトの状態しか見えない。「BTC/USDTが今いくらか」はチェーン外の情報だから、誰かが持ち込む必要がある。

この「誰か」がOracle。BinanceやOKXのスポット価格を集約して、オンチェーンに書き込む。Perp DEXはこの価格を「真の価格」として扱って、funding rateやliquidationに使う。

問題は、この「真の価格」が本当に真かどうか。単一ソースに依存すれば操作は簡単だし、更新が遅れればレイテンシー・アービトラージの餌食になる。Oracle設計はセキュリティとパフォーマンスのトレードオフそのもの。

2. Push vs Pull

Oracle設計の最も基本的な分岐点。pullとpushがある。

Push型

Oracleネットワークが一定間隔でオンチェーンに価格を書き込む。Chainlinkの伝統的なモデルがこれ。

トランザクションコストはOracle側が負担する。プロトコルは最新のオンチェーン価格を読むだけ。だけど更新頻度はOracle側の経済性に制約される。Ethereum L1だと数分に1回が限界で、ガスが高騰するとさらに遅れる。Solanaでもネットワーク輻輳時に更新が詰まることがあった。Pythの旧Push型はこの問題で2024年6月に廃止された。

Pull型

プロトコル側（またはユーザー）がOracleに価格更新を要求する。Pythの現行モデル。

Pythnet appchan（SVM上の専用チェーン）でスロットごとに価格が集約されて、ユーザーがトランザクションに価格更新命令を含めることでオンチェーンに反映する。必要なときだけ更新するから効率的で、輻輳の影響を受けにくい。

Push vs Pull Oracle

実質的に、高頻度トレーディングが必要なPerp DEXではPull型が標準になりつつある。Solana上のPerp DEX（Drift, Jupiter Perps, Flash Trade, Zeta）はほぼ全てPyth Pull Oracleを使っている。

3. Pyth Network

アーキテクチャ

Pythは「ファーストパーティ」Oracleを標榜している。データソースが取引所やマーケットメイカー自身（Jump, Jane Street, Virtu, CBOE, Binance等）で、彼らが直接Pythnetに価格を送信する。Chainlinkのように第三者ノードオペレーターが中継するモデルとは根本的に違う。

Pyth Networkのデータフロー

集約メカニズム

各publisherが (price, confidence_interval) のペアを送信する。Pythnetは全publisherの加重メディアンを計算して集約価格とする。

p_{\text{agg}} = \text{weighted\_median}(\{p_i\}_{i=1}^{N})

confidence intervalも集約される。これが重要で、ボラティリティが高いときやデータソースが少ないときはconfidenceが広がる。プロトコル側はこのconfidenceを使って「価格の信頼度が低いときは取引を制限する」みたいな防御ロジックを組める。

Driftは実際にこれをやっている。Pyth/Switchboardのconfidence intervalが閾値を超えるとマーケット操作を制限する。

Pull型でもstaleness（鮮度）問題は存在する。ユーザーが古い価格更新を提出したり、そもそも価格更新を含めなかったりするケースがある。プロトコル側はstaleness thresholdを設定して、一定時間以上古い価格を拒否する。

# Driftでのstaleness check（概念コード）
MAX_ORACLE_STALENESS = 60  # seconds

def validate_oracle(oracle_price, oracle_timestamp, current_timestamp):
    staleness = current_timestamp - oracle_timestamp
    if staleness > MAX_ORACLE_STALENESS:
        raise OracleStaleError(f"Oracle is {staleness}s old")
    return oracle_price

4. Switchboard

SolanaにおけるPythの主な競合。Driftは冗長性のためにPythとSwitchboardの両方を使っている。

Switchboardはオープンなオラクルフレームワークで、誰でもデータフィードを作成できる。TEE（Trusted Execution Environment、IntelのSGX等）で計算を隔離して、ノードオペレーターが結果を改竄できないようにしている。

2025年にリリースされたSwitchboard Surgeは、高頻度アセット（BTC, ETH等）向けの超低レイテンシーフィードで、Pythとのガチンコ競争を仕掛けている。

PythとSwitchboardの設計思想の違いをざっくり言うと、Pythはファーストパーティ（データソース自身が直接送信）で信頼性を担保、Switchboardはオープンネットワーク + TEEで信頼性を担保。どっちが「正しい」かは一概には言えないけど、Solana Perp DEXの採用実績ではPythが圧倒的。

5. Hyperliquid

Hyperliquidは独自L1チェーン上で動いていて、Oracle設計もかなり独特。

Spot Oracle

バリデーターが直接CEXスポット価格を取得して、加重メディアンを計算する。外部Oracleプロトコル（Pyth, Chainlink等）を使わない。

p_{\text{oracle}} = \text{weighted\_median}(\text{Binance}, \text{OKX}, \text{Bybit}, \text{Gate}, \text{MEXC})

重みは Binance: 3, OKX: 2, Bybit: 2, Gate IO: 1, MEXC: 1。流動性に基づいた重み付け。約3秒ごとに更新される。

これが面白いのは、Oracle自体がコンセンサスに組み込まれていること。バリデーターがOracle更新をプロポーズして、他のバリデーターが検証する。外部プロトコルへの依存がゼロ。

Mark Price

Hyperliquidのmark priceは3つの入力のメディアン。

p_{\text{mark}} = \text{median}(A, B, C)

$A$ = Oracle price + 150秒EMA(Hyperliquid mid - Oracle price)。これはOracle priceを基準にしつつ、Hyperliquid自体のオーダーブックとの乖離をEMAで滑らかに反映する。

$B$ = median(best bid, best ask, last trade) on Hyperliquid。純粋なオーダーブックの中値。

$C$ = median of Binance, OKX, Bybit, Gate IO, MEXC perp mid prices。外部Perp DEXの価格。重みは spot oracle と同じ。

3つの入力がある場合はメディアン、2つしかない場合（一部のCEXがダウンしてるとか）は30秒EMAのHyperliquid mid priceを追加して安定化する。

def compute_mark_price(oracle_px, hl_mid, hl_bid, hl_ask, hl_last,
                       cex_perp_mids, ema_150s):
    # Component A: Oracle + EMA of basis
    A = oracle_px + ema_150s  # 150s EMA of (hl_mid - oracle_px)

    # Component B: Hyperliquid orderbook
    B = median(hl_bid, hl_ask, hl_last)

    # Component C: External perp mids (weighted median)
    C = weighted_median(cex_perp_mids, weights=[3, 2, 2, 1, 1])

    return median(A, B, C)

Hyperps（プレローンチ先物）

ここが一番面白い。Hyperpsは外部スポットOracleが存在しないトークン（まだCEXに上場してないやつ）のPerp。外部Oracleが使えないから、Oracle price自体をHyperp自身のmark priceの8時間指数加重移動平均（EMA）で代替する。

p_{\text{oracle}}(t) = \min\!\left[\sum_{i=0}^{1439} w_i \cdot p_{\text{mark}}(t - i\,\text{min}) \cdot \frac{1 - e^{-1/480}}{1 - e^{-3}},\; p_{\text{initial}} \cdot 4\right]

$w_i = e^{-i/480}$ で、直近の価格ほど重く、過去に行くほど指数的に減衰する。480分 = 8時間がEMAの特性時間。

mark priceは8時間EMAの3倍にキャップされて、oracle priceは1ヶ月平均mark priceの4倍にキャップされる。操作防止のセーフガード。

自己参照的なOracle。外部データなしでfunding rateが決まるから、価格のモメンタムが一方向に続くとfunding rateが急激に偏る。ロングが $50kで買って$ 60kにpush upすると、次の8時間はfundingがロングに激しくチャージされて、ショートポジションを取るインセンティブが生まれる。自己修正メカニズム。

6. Funding Rateの計算

OracleとMark priceの関係がfunding rateの計算に直結する。

Hyperliquidの場合

F = \bar{P} + \text{clamp}(r - \bar{P},\; -0.0005,\; 0.0005)

$\bar{P}$ は1時間のPremium Indexの平均（5秒ごとにサンプリング）。 $r = 0.01\%$ は固定金利。

Premium Indexは、

P = \frac{\max(0,\; p_{\text{impact\_bid}} - p_{\text{oracle}}) - \max(0,\; p_{\text{oracle}} - p_{\text{impact\_ask}})}{p_{\text{oracle}}}

$p_{\text{impact\_bid}}$ , $p_{\text{impact\_ask}}$ はimpact notional（BTCとETHは $20,000、他は$ 6,000）を約定させたときの平均執行価格。

これは8時間分のfunding rateを算出して、1時間ごとに1/8を支払う。Perpetual priceがOracle priceより高ければロングがショートに払い、低ければ逆。

Solana系（Drift）

Driftも基本的に同じ構造だけど、Oracle priceにPyth（メイン）+ Switchboard（フォールバック）を使う。DAMMのAMMカーブがOracle priceにペグされていて、AMMの中値がOracleからずれるとfunding rateが発生する。

7. Oracle攻撃ベクトル

Oracle操作による攻撃はDeFiエクスプロイトの13%（2025年）。知っておくべきパターンをまとめる。

Flash Loan + AMM Pool操作

古典的な攻撃。フラッシュローンで大量の資金を借りて、Uniswap等のAMMプールの価格を一時的に歪めて、その歪んだ価格をOracleとして使っているプロトコルから資金を抜く。全部1トランザクション内で完結する。

対策はシンプルで、AMMのスポット価格をOracleに使わないこと。Pyth/Chainlink/Switchboardのような外部集約Oracleを使えばこの攻撃は成立しない。2025年時点でまだ単一DEXプールをOracleにしてるプロトコルがあるのは信じられないけど、KiloExの$7.5Mはまさにこれ。

Mango Markets ($117M, 2022)

Avraham Eisenbergが実行した有名な攻撃。MNGO/USDのOracle priceを正面から操作した。

2つのアカウントで反対ポジションを取って、外部市場（FTX等）でMNGOを大量に買い上げてOracle priceを吊り上げ、含み益を担保にMango Marketsから$117M相当を借り出した。Oracle自体は正しく動いていたけど、元の市場が操作されたら意味がない。

Oracle操作とmarket manipulation（市場操作）は別の問題。Oracleが正確に市場を反映していても、市場自体が薄ければ操作できる。Hyperliquidがimpact notionalで加重平均を取るのは、この種の攻撃への防御。

レイテンシー・アービトラージ

Oracle更新がCEXの価格変動に遅れるとき、その遅延を利用してPerp DEXで有利な価格で約定させる。CEXでBTCが $60,000→$ 60,500に動いたのにOracleがまだ $60,000を指しているなら、DEXで$ 60,000近辺でロングを入れて、Oracle更新後に利食いする。

Pull型Oracleはこれを緩和するけど完全には解決しない。HyperliquidのMark priceが3成分のメディアンを使うのは、単一ソースのレイテンシーに依存しないため。

8. 各プロトコルのOracle比較

	Hyperliquid	Drift (Solana)	Jupiter Perps (Solana)
Oracleソース	バリデーター直接取得	Pyth + Switchboard	Pyth
更新頻度	約3秒	Pull型（トランザクションごと）	Pull型（トランザクションごと）
Mark Price	3成分メディアン	Oracle + DAMM mid	Oracle直接
外部依存	なし（CEX APIのみ）	Pyth/Switchboard	Pyth
プレローンチ	Hyperps（自己参照EMA）	N/A	N/A
Funding計算	8hr rate, 1hrごと1/8支払	1hrごと	1hrごと

Jupiter PerpsはPool型（LP vs Trader）で、Oracleから直接価格を取ってゼロスリッページで約定させる。Oracleへの依存度が最も高いモデル。

Driftはハイブリッド型で、DLOB（Decentralized Limit Order Book）+ DAMM（Dynamic AMM）+ JIT Auction。Oracle priceはDAMMのペグポイントと margin/liquidation計算に使われる。

Hyperliquidは一番CEXに近い。自前のバリデーターネットワークでOracle運用まで完結させている。外部Oracleプロトコルへの信頼を排除した代わりに、バリデーターセットへの信頼が必要。

9. Oracleの未来

2つの方向性が見える。（Oracle.comにはあまりいい未来が見えないけど）

1つはレイテンシーの極限追求。Switchboard SurgeやPythのPull Oracleが競っている領域。最終的にはCEXのAPI RTTがボトルネックになるから、物理的な限界がある。

もう1つはオラクルレスの方向。HyperliquidのHyperpsは外部データなしでPerp市場を運営できることを示した。Funding rateの自己参照メカニズムで価格を安定させる。既存のスポット市場がない新しいアセットでも先物市場を作れる。

どっちが「正しい」かはユースケース次第だと思う。流動性が高いメジャーアセットなら外部Oracleの方が信頼性が高い。まだスポット市場がないトークンならHyperps型が唯一の選択肢だと思う。

参考文献

Pyth Network Documentation: https://docs.pyth.network/
Hyperliquid Docs, Oracle: https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/oracle
Hyperliquid Docs, Robust Price Indices: https://hyperliquid.gitbook.io/hyperliquid-docs/trading/robust-price-indices
Hyperliquid Docs, Hyperps: https://hyperliquid.gitbook.io/hyperliquid-docs/trading/hyperps
Hyperliquid Docs, Funding: https://hyperliquid.gitbook.io/hyperliquid-docs/trading/funding
Drift Protocol Documentation: https://docs.drift.trade/
Switchboard Documentation: https://docs.switchboard.xyz/
Chainalysis, "Oracle Manipulation Attacks Rising" (2023)