こんにちは、よだかです。
ここ最近、xStocksとHyperliquidを横断して価格差を観測する研究を進めています。
もともとの発想はかなり単純でした。
Solana上でもxStocksが取引されている。
HyperliquidにもxStocksの現物市場がある。
さらに、同じ株式を参照する無期限先物もある。それなら、それぞれの価格を並べれば何か見えるのでは？
というものです。
ただ、実際に観測機を作ろうとすると、一つ問題が出てきました。
「価格を比較する」と言っても、そもそも何を価格として比較するのか。
今回は、この部分をかなり細かく監査していました。
結果として、今回やったことは、
仮説を言語化する
↓
その仮説を確認するための観測経路を決める
↓
その経路で本当に仮説を検証できるのか監査する
↓
合っていない部分を修正・分離する
↓
観測仕様を固定する
という作業になりました。
まだ価格差の有無を結論づける段階ではありません。
今回は、
「何を見るか」より先に、「何を見れば、その仮説を検証したことになるのか」を整理した話
です。
xStocksの観測範囲をHyperliquidまで広げる
xStocksについては、以前の記事でSolana側の市場構造を整理しました。
最初に見ていたのは、JupiterやKaminoなど、Solana上でxStocksがどのように売買・利用されているかです。
-
-
🛠️開発記録#555(2026/8/28)トークン化株式はどこで歪むのか｜xStocksの市場構造を分解して観測を始めた話
続きを見る
そこから研究を進めていく中で、
Solana側のxStocksと、Hyperliquid側のxStocksには価格差があるのか。
Hyperliquid内部でも、現物と無期限先物の間に価格差があるのか。
どちらかが先に動き、もう一方が追随することはあるのか。
という方向へ関心が広がりました。
ちょうどHyperliquidについては、別研究で使っていた観測機を共通基盤として切り出したところでした。
-
-
🛠️開発記録#557(2026/8/31)仮説ごとの観測機から共通基盤へ｜Hyperliquid observerを切り出した話
続きを見る
そこで今回は、その観測基盤とxStocks研究を接続することにしました。
ただし、ここですぐに価格比較を始めたわけではありません。
まず、
何を調べたいのかを分ける
ところから始めました。
仮説を4つに分ける
現在は、xStocks × Hyperliquidで見たい現象を大きく4つに分けています。
H1｜Jupiterで取得できる見積価格とHyperCore現物の価格差
一つ目は、
Jupiter Swap V2で取得できるxStockの見積価格
↔ HyperCore上のxStock現物
の比較です。
主な対象は、
- NVDAx
- MUx
です。
SKHYxについても観測しますが、Jupiter側で安定して見積価格を取得できるかという点も含めた補助観測としています。
H2｜HyperCore現物と同一原資産の無期限先物の価格差
二つ目はHyperliquid内部の比較です。
HyperCore上のxStock現物
↔ 同じ株式を原資産とするXYZ無期限先物
を見ます。
対象は、
- NVDAx
- MUx
- SKHYx
です。
こちらはJupiterとは独立しています。
Jupiter側で見積価格を取得できなかったとしても、H2の観測には影響しません。
H3｜SolanaとHyperliquidの先行・追随関係
三つ目は、
Solana側が先に動くのか。
Hyperliquid側が先に動くのか。
という価格発見の仮説です。
当初はH1とかなり近いものとして扱えると思っていました。
しかし、監査した結果、現在はH1から切り離しています。
状態としては、
保留・未検証
です。
H4｜米国株市場が閉まっている時間帯の価格形成
四つ目は、取引時間に関する仮説です。
xStocksやクリプト市場は24時間動きますが、その価値の参照元となる米国株式市場には取引時間があります。
そのため、
米国株市場が閉まっている時間帯では、価格形成や流動性の構造が変わるのではないか。
という仮説も考えています。
ただし、これも今回の24時間観測では扱いません。
H3と同じく、
保留・未検証
としています。
「xStocks × Hyperliquidで現在見ている4つの仮説」
仮説を分けると、必要な観測経路も変わる
今回、一番重要だったのはここです。
H1とH3は、一見するとどちらも、
SolanaとHyperliquidの価格を比較する
話に見えます。
しかし、実際に確認したいものは違います。
H1で知りたいのは、
Jupiterという入口からxStockを取得しようとしたとき、提示される見積価格とHyperCore現物にどれくらい差があるのか。
ということです。
一方、H3で知りたいのは、
Solana上の市場とHyperliquidのどちらが先に価格変化を起こしたのか。
ということです。
似ていますが、同じではありません。
この二つを混ぜると、
データは取れているのに、そのデータから言えないことまで言ってしまう
可能性があります。
Jupiterの見積価格は「Solana市場そのものの価格」ではない
そこで、Solana側の観測経路として使おうとしていたJupiterを改めて確認しました。
現在利用しているJupiter Swap V2の/orderは、単一のDEXの価格だけを返す仕組みではありません。
複数の経路をまとめ、その時点でユーザーが利用できる取引経路の中から見積もりを返す仕組みになっています。
つまり、ここから取得した値を単純に、
Solanaの価格
と呼んでしまうと少し意味がずれます。
今回のH1で観測しているのは、より正確には、
Jupiterを入口として、その時点でユーザーが取得できる最良執行の見積価格
です。
この違いが、今回かなり重要でした。
H1とH3の観測経路を分ける
この整理から、H1とH3を別々の観測経路に分けました。
H1では、
Jupiter Swap V2で得られる見積価格
↕
HyperCore現物
を比較します。
これは現在の観測機で確認できます。
一方、H3で知りたいのは、
Solana上の個別市場
↕
Hyperliquid
のどちらが先に価格形成しているか
という話です。
Jupiterの見積価格には複数の経路やRFQ（見積依頼方式）が含まれます。
そのため、
Jupiterの見積価格が先に動いた
↓
Solana市場がHyperliquidを先行した
とは、そのまま言えません。
本当にH3を調べるのであれば、将来的にはSolana上の個別市場を直接観測する必要があります。
そこで今回は、
H1とH3では同じ観測経路を使わない
ことにしました。
「同じ価格比較に見えても、H1とH3では見ているものが違う」
観測機能を増やすより、「言ってよいこと」を減らす
この変更は、観測機能を増やしたというより、
現在の観測機から言ってよいことの範囲を狭くした
修正です。
最初は、
JupiterとHyperliquidを取れば、価格差も先行・追随も見られるのでは？
と考えていました。
しかし、実際にデータの意味を確認すると、そこまでは言えませんでした。
だからH3を切り離しました。
これは以前整理した、
見えているものを丁寧に観測し、見えていないものを無理に断定しない
という考え方にもかなり近いです。
観測できることと、そこから推測したくなることは別です。
今回も、まずは観測できる範囲まで仮説を戻しました。
古いJupiter経路も、そのまま使わない
Jupiterについては、もう一つ見直した点があります。
既存研究では、旧来のJupiter V1 / Metis系の経路も触っていました。
ただ、今回のH1で知りたいのは、
現在Jupiterを入口としてユーザーが取得できる見積価格
です。
そのため、旧経路を今回の主要な観測値として使うのは適切ではないと判断しました。
そこでH1では、
Jupiter Swap V2 /orderを見積取得専用で利用する
形に変更しました。
ここだけを見ると、単なるAPIの更新にも見えます。
ただ、今回の目的からすると、
新しいAPIだから使った
のではなく、
自分が測りたいものと、取得するデータの意味を合わせた
という方が正確です。
「見積価格が取れない」ことも観測する
Jupiter Swap V2を試している途中で、もう一つ気になることがありました。
NVDAxでは比較的安定して見積価格を取得できます。
一方、MUxやSKHYxでは、取得できないことがあります。
最初は、
APIの不具合か。
データ処理の失敗か。
呼び出し回数の制限か。
といったことを疑いました。
しかし実際には、
Quote not available from market maker
という状態が返っていました。
つまり、
観測機が失敗したのではなく、その時点ではマーケットメーカーから見積価格が提示されなかった
ということです。
そこで今回は、
- 見積価格を取得できた
- マーケットメーカーから見積価格を取得できなかった
という二つの状態を分離して保存するようにしました。
これは実装としては小さな変更です。
ただし、観測の意味はかなり変わります。
「価格が取れなかった」を単なる欠損として捨てれば、
価格差が何bpsあるか
しか見えません。
一方で取得可否そのものを保存すれば、
そもそも、その経路から価格を取得できる状態がどの程度存在するのか
も観測できます。
今回のH1では、
価格差だけでなく、見積価格の取得可能性そのものもデータ
として扱うことにしました。
「見積価格がない＝観測失敗、ではない」
名前が似ていても、同じものとは限らない
もう一つ確認したのが、比較する資産の対応関係です。
トークン化株式や無期限先物を並べていると、tickerが似ているだけで同じ原資産に見えることがあります。
ただし実際には、
- 個別株
- ETF
- 株価指数
- ADS
- ラップ資産
など、似た名前でも経済的な中身が違う場合があります。
そこでH2では、
tickerが似ているものではなく、同じ原資産を参照していると確認できる組み合わせだけ
を比較対象にしました。
その結果、現在はNVDA、MU、SKHYを中心に観測しています。
価格差を計算する以前に、
そもそも比較してよい二つなのか
を確認する必要があります。
ここを間違えると、その後どれだけ精密に計算しても意味がありません。
数量の意味もそろえる
xStocks固有の処理として、数量の正規化も必要でした。
xStocksには乗数やラップ資産の仕組みがあります。
そのため、Solana側で取得した生の数量と、HyperCore側で取引されている数量を、そのまま並べればよいわけではありません。
今回は、
同じ経済的な保有量を表すように数量をそろえてから比較する
ようにしています。
これも特別な技術ではありません。
ただし、ここを間違えると、
価格差があるように見える
という結果そのものが壊れます。
派手ではありませんが、観測の前提として必要な処理です。
「価格を比較する前に、比較対象をそろえる」
技術的には、特別なことをしているわけではない
今回の実装については、一度CODEXにも読み取り専用で監査させました。
HTTPやWebSocketから市場データを取得する。
データベースへ保存する。
板情報から一定数量を取引した場合の価格を計算する。
時刻を合わせる。
価格差を計算する。
こうした処理自体は、一般的な市場データ処理の範囲です。
新しいアルゴリズムを作ったわけでも、特殊な裁定検出技術を実装したわけでもありません。
今回のポイントは、そこではありませんでした。
むしろ、
自分が確認したい仮説は何なのか。
↓
今取得しているデータは、本当にその仮説を測っているのか。
↓
測れていないなら、観測経路か仮説のどちらを直すのか。
という観測設計の方でした。
普通のAPIを使っていても、数字が返ってきたからといって、その数字が自分の欲しい意味を持っているとは限りません。
今回、一番大きかったのはこの部分だと思います。
データが細かければ、それだけで検証精度が上がるわけでもない
もう一つ、24時間観測後の解析に向けて決めていることがあります。
一定間隔で価格を比較していると、一つの価格差が長く続いただけでも比較データは大量にできます。
たとえば、一つの価格差が60秒続き、その間に60件の比較データができたとしても、
60回の独立した現象が発生したわけではありません。
そのため、
比較データの件数
＝
独立した現象の発生回数
とは扱わないことにしています。
24時間観測が終わった後は、
- 価格差の大きさ
- 継続時間
- 一連の発生区間
- 発生頻度
といった形に整理してから評価します。
この辺りは、前回の記事で整理した、
高頻度なら細かいほど良いわけではなく、自分が確認したい現象に対して必要十分な観測粒度を選ぶ
という話ともつながっています。
-
-
🛠️開発記録#558(2026/9/1) 高頻度なら細かいほどいい？｜個人botterの「必要十分な観測粒度」を具体例で考える話
続きを見る
観測できる数字を増やすこと自体を目的にしない。
何を判断するためのデータなのかを先に決める。
今回も基本的な考え方は同じです。
180秒の短時間試験を通して、24時間観測へ
ここまで観測仕様を整理した上で、Phase 1Aの観測機へJupiter Swap V2を組み込みました。
単体試験は30件通過。
その後、180秒の短時間試験を実施しました。
そこで、
- Jupiterからの見積取得
- HyperliquidのHTTP / WebSocketデータ取得
- 正規化後の見積価格・板情報
- 見積価格を取得できなかった状態
- どのルーターが使われたかの記録
などが想定通り保存されることを確認しました。
短時間試験も問題なく通過しています。
そこで観測仕様を固定し、現在は24時間の基準観測を実行しています。
この記事を書いている時点では、まだ観測は終了していません。
したがって、
edge_confirmed = false
のままです。
今回は、まだ「取れるか？」を見ない
今回の24時間観測では、意図的に多くの項目を外しています。
今回は扱わないものとして、
- SolanaとHyperliquidの先行・追随
- 米国株市場の取引時間による違い
- 手数料
- 実際の約定
- ブリッジ
- 注文執行までの遅延
- 損益
- 売買戦略
などがあります。
今やっているのは、まだ、
「見えるか？」
の段階です。
まず、
比較可能な状態がどの程度あるのか。
価格差らしきものが存在するのか。
それがどの程度の大きさで、どれくらい続くのか。
を見ます。
そこを通ったものだけ、次に、
「取れるか？」
を確認します。
これは前回の記事で整理した一次選別、
価格差の大きさ × 継続時間 × 発生頻度
の考え方ともつながっています。
市場現象が見えたことと、その現象を実際のbotで利益に変えられることは別です。
今はまだ、その一つ前にいます。
「今回のPhase 1Aの位置」
今回作ったのは、「仮説を検証するための観測機」
振り返ると、最初は、
xStocksとHyperliquidの価格を並べてみよう
くらいのところから始まっています。
しかし、実際に進めていくと、
その価格は何を表しているのか。
そのデータから先行・追随まで言えるのか。
見積価格がないときは単なるエラーなのか。
そもそも同じ原資産を比較しているのか。
数量の意味はそろっているのか。
と、一つずつ確認する必要がありました。
その結果、
仮説そのものと、その仮説を確認する観測経路を分けて考える
ようになりました。
なので、今作っているものを「価格差検出bot」と呼ぶのはまだ早いです。
現時点では、
仮説を検証するための観測機
です。
そして、その観測機を動かす前に、
観測経路そのものを監査しました。
24時間の基準観測が終われば、次はようやく、
実際に何が見えたのか。
を確認できます。
結果については、次の開発記録でまとめる予定です。
現在地
- Phase 1Aの観測仕様：固定済み
- H1：Jupiter Swap V2の見積価格 ↔ HyperCore現物
- H2：HyperCore現物 ↔ XYZの同一原資産無期限先物
- H3：保留・未検証
- H4：保留・未検証
- 単体試験：30件通過
- 180秒の短時間試験：通過
- 24時間の基準観測：実行中
edge_confirmed = false
まだ結果は出ていません。
今回は、
「何を見るか」より先に、「何を見れば、その仮説を検証したことになるのか」を詰めた。
そんな開発記録です。
それでは、また。
参考・一次情報
今回、仕様確認に利用した一次情報は最低限、以下です。
- Jupiter Developers：Swap V2 / Order and Execute
- Hyperliquid Docs：WebSocket Subscriptions
- xStocks公式：HyperliquidへのxStocks展開に関する発表