こんにちは、よだかです。
ここしばらく、CEXとHyperliquidを横断して価格の乖離と収束を観測する研究を続けています。
これまでの検証では、
「CEXとHyperliquidの価格が一定以上離れたあと、再び近づいていく」
という現象自体はかなり見えてきました。
ただし、これはまだ、
「その価格差を実際にbotで取れる」
ことを意味しません。
以前の記事でも、観測できた市場構造と、実際に利益へ変換できるedgeは分けて考える必要があると整理しました。
-
-
🛠️開発記録#554(2026/8/27)AIと進めていたアルゴ研究を一度止めて、研究そのものを監査した話
続きを見る
さらに前回は、CEXとHyperliquidの時間差を細かく調べようとしたときに、
精度は高ければ高いほどいいわけではない。
必要な精度は、見たい現象から逆算した方がいい。
という話を書きました。
-
-
🛠️開発記録#556(2026/8/29)botの精度は高ければ高いほどいい？｜CEX–DEXのtimestamp同期で「必要十分」を考えた話
続きを見る
今回は、その「必要十分」をもう少し具体的な実装まで落としてみた話です。
新しい市場現象を見つけた、という回ではありません。
むしろ、
個人botterとして、どの程度まで細かく観測できれば十分なのか。
どこから先は追わなくていいのか。
を、実際の観測データと実装を使って考えました。
5秒では粗すぎたので、HyperliquidのBBOを取ることにした
もともとCEX–Hyperliquidの横断観測では、Hyperliquid側の板情報として l2Book を使っていました。
l2Book は、最良買い気配・最良売り気配だけでなく、その後ろに並んでいる複数の価格帯まで含む板情報です。
WebSocketで受け取っているので、当初はかなり細かい時間粒度で板の変化を追えるものだと思っていました。
ところが、高頻度データを24時間ほど集めて実際の受信間隔を確認すると、私の観測環境では l2Book の中央値が約5.39秒でした。
これは、
「5.39秒ごとにこちらからデータを取りに行っていた」
という意味ではありません。
WebSocketで待ち受けていたにもかかわらず、実際にこちらへ届いた l2Book メッセージ同士の間隔が、今回の観測では中央値で約5.39秒だった、という意味です。
ここで初めて、
WebSocketを使っているからといって、必要な時間粒度でデータが届くとは限らない
ことが分かりました。
l2Book は複数の価格帯を含む板のスナップショットです。
一方で今回知りたいのは、
Binanceが動いた100ms後、250ms後、500ms後、1秒後に、Hyperliquidとの価格差がどれくらい残っているのか
です。
この問いに対して、5秒程度の間隔では粗すぎます。
例えば実際にはHyperliquidが500ms後にはすでに追随していたとしても、次の l2Book が数秒後まで届かなければ、その途中の動きはこちらからは見えません。
そこで、
板全体ではなく、一番手前の価格だけを見るBBOなら、もっと細かく更新されるのではないか
と考えました。
BBOは Best Bid and Offer、つまり最良買い気配と最良売り気配です。
簡単に言えば、
「今、一番高く買いたい価格」と「今、一番安く売りたい価格」
を中心に見るデータです。
l2Book が板の奥まで含むのに対して、BBOが見るのは基本的に板の一番手前です。
現在の研究では、まずBinanceとHyperliquidの価格差が時間とともにどう縮むのかを見たいので、板の深い部分よりも、
その時点の最良気配を、できるだけ細かく追えること
の方が重要です。
そこでHyperliquidのBBOを追加して、実際の受信頻度を測ってみました。
30分観測した結果、BBOの受信間隔は、
median：約0.134秒
p95：約0.609秒
p99：約1.062秒
でした。
つまり、
l2Book：中央値 約5.39秒
BBO：中央値 約0.134秒
となり、BBOの方が時間方向にはかなり細かく観測できました。
WebSocket自体を高速化したわけではありません。
同じHyperliquidのWebSocketでも、
どの種類のデータを購読するかによって、実際にこちらへ届く更新頻度が大きく違った
ということです。
そして今回、
「板全体を見る
l2Bookよりも、最良気配だけを見るBBOの方が今回の研究目的には向いているのではないか」
という仮説を立てて試したところ、実際にその通りになりました。
もちろん、
BBOは速いけれど、
l2Bookとは違う価格を見ている
のであれば困ります。
そこで同じ30分間について、BBOと l2Book のbest bid / best ask / midも比較しました。
比較できた335件では、最大差は0bpsでした。
つまり少なくとも今回の短時間検証では、
l2Bookで見ていた板の一番手前と同じ価格を、BBOではより細かい時間粒度で観測できていた
と考えられます。
これでようやく、
Binanceが動いたあと、100ms・250ms・500ms・1秒といった時間幅で、Hyperliquidとの価格差がどう変化するのか
を調べられる状態になりました。
「約100msで観測できる」とは、100msごとに価格を取りに行くことではない
ここは少し注意が必要です。
先ほど、
BBOの受信間隔の中央値は約0.134秒だった
と書きました。
これは、
100msごとにこちらからHyperliquidへ価格を問い合わせている
という意味ではありません。
今回使っているのはWebSocketです。
WebSocketでは、こちらが決めた一定間隔で価格を取りに行くのではなく、Hyperliquid側からBBOの更新メッセージが送られてきたときに、それをこちらが受信します。
つまり、
BBOメッセージを受信
↓
次のBBOメッセージを受信
↓
その間隔を測る
という形です。
30分間の受信間隔を並べたところ、その中央値が約0.134秒だった、ということです。
そのため、受信間隔は常に同じではありません。
短いときもあれば、長いときもあります。
また、
BBOメッセージが届いた = 価格が変わった
とも限りません。
例えば、
Best Bid：100ドル、数量1BTC
↓
Best Bid：100ドル、数量5BTC
のように、価格は同じままで、その価格帯に並んでいる注文量だけが変化することもあります。
この場合、BBOの状態は更新されていますが、mid価格は変わりません。
したがって今回確認できたのは、
Hyperliquidの価格が常に100msごとに動いている
ということではありません。
正確には、
HyperliquidのBBO状態を、従来使っていた
l2Bookよりかなり細かい時間粒度で受信できるようになった
ということです。
今回の研究では、これで十分です。
欲しいのは、
100msごとに必ず新しい価格があること
ではなく、
100ms〜数秒程度で消える可能性のある価格差を観測できるだけの時間解像度
だからです。
今回の l2Book → BBO の変更は、
「より高度なデータを取った」
というより、
研究したい現象の時間幅に合わせて、観測に使うデータの種類を選び直した
という方が近いと思います。
BinanceとHyperliquidは「同じPCで受信した時間」で並べている
では、
「Binanceが動いた100ms後」
という時間差を、何を基準に測っているのか。
現在の観測では、BinanceとHyperliquidのWebSocketメッセージを受信した直後に、
time.monotonic_ns()
というPC内部の時計を記録しています。
これは、時刻そのものを見るための時計というより、
ある出来事から次の出来事まで、どれだけ時間が経ったか
を測るための時計です。
BinanceとHyperliquidのcollectorは同じPython process内で動いているため、同じ時計を使って、
Binanceのデータを受信
↓
その150ms後にHyperliquidのデータを受信
といった形で比較できます。
つまり現在見ているのは、
自分のPCでは、BinanceとHyperliquidの価格状態がどのような順序・時間差で届いたのか
です。
一方で、これは、
「BinanceとHyperliquidの取引所内部の時計を完全に同期した」
という意味ではありません。
実際には、
- 取引所内部でeventが発生した時刻
- ネットワークを通って私のPCへ届くまでの時間
- matching engine内部の処理時間
などもあります。
そのため現時点では、これを「市場内部の真のlead-lag」とは扱っていません。
あくまで、
同じローカル観測機から見た受信順序と時間差
です。
前回の記事では「必要な時間精度を研究目的から逆算する」という話を書きました。
今回はその考えを実際の観測機に落とし込み、
100ms〜数秒程度の価格差の変化を調べるために、まず同じPC上の受信時間を基準に比較する
という方法を採用しています。
ここから、BinanceとHyperliquidの間に残る価格差が、
何bpsあり、
何ms・何秒残り、
どのくらいの頻度で発生するのか
を見ていきます。ここは前回の記事で考えていたtimestampの問題を、実際の観測機へ落とし込んだ部分でもあります。
そもそもBinance→Hyperliquidの追随自体は新しい話ではない
今回の目的を整理するときに、ここも重要でした。
BinanceとHyperliquidのlead-lag、つまりどちらの価格変化が先に現れやすいかというテーマ自体には既存研究があります。
例えばArrakis Financeは、Binance Futures、Hyperliquid、Lighterの29銘柄を対象に、非同期な時系列を扱えるHayashi–Yoshida系の推定方法を使ってcross-venue lead-lagを調べています。その分析では29銘柄すべてでBinanceがHyperliquidを先行する結果が報告されています。
2026年の別のpreprintでも、BTC perpetualについてvenue levelではBinanceがHyperliquidを先行する結果が報告されています。
ただし、これらと私の方法は同じではありません。
既存研究ではtrade tapeやvenue event timeなどを使って、より直接的にprice discoveryやlead-lagを推定しています。
一方、私は現時点では、
自分のPCが受信したBBOを同じローカル時計で並べる
ところから始めています。
そのため今回の観測でBinance→Hyperliquidらしい方向性が見えたとしても、それ自体を新しい発見として扱うつもりはありません。
むしろ、
既存研究でも知られている方向性を、自分の観測機でもある程度再現できるか
という「物差しの校正」に近い位置づけです。
細かく取れる≠全部保存する
そして今回、別のところで派手に事故りました。
BBOを追加して5分だけ試験観測したところ、
約500MB
までストレージが増えました。
単純計算すると、このまま24時間回せば100GBを軽く超えるペースです。
最初は、
「高頻度WebSocketを取っているのだから、データが大きくなるのは仕方ないのか？」
とも考えました。
しかし中身を調べると、主因はraw dataそのものではありませんでした。
雑にまとめると、高頻度データそのものが異常に巨大だったのではなく、同じ分析用データを生成過程の複数段階で重複して永続保存していたことが主因でした。
具体的な処理として、common timelineという、BinanceとHyperliquidのeventを同じ時間軸へ並べた中間生成物を、
live segment
＋
final timeline
として、ほぼ同じ内容を非圧縮で二重保存していました。
修正前の5分runでは、約515MBのうち約504MBがcommon timelineでした。
そこで、
common timelineをgzip圧縮
実行中だけ必要なlive segmentをfinalize後に削除
sort用のtemporary dataも削除
という形へ直しました。
すると30分runでは、最終的に残ったデータが約62.5MB。
単純比例では約3GB/24h程度まで落ちました。
ここで改めて感じたのが、
細かく観測することと、細かいデータをすべて何層にも保存することは別
ということです。
金融データ基盤でも「目的に応じた粒度」は普通に使われている
このあたりを調べてみると、既存のmarket data基盤でも似た考え方があります。
例えば金融のリアルタイムデータ基盤で使われるkdb+/tickでは、tickerplantがincoming dataをrecovery用にlogへ残しながら、当日データはreal-time databaseで扱い、履歴側へ送る構成が一般的です。つまり「入力を残すこと」と「すべての処理途中の状態を永久保存すること」は分けられています。
Databentoも、MBO（Market by Order / L3）、MBP-10（L2）、MBP-1（L1）など目的に応じて複数の粒度を提供しており、より粗いschemaの多くは高粒度なsourceから派生させる設計になっています。
学術向けorder book dataのLOBSTERも、NASDAQのmessage dataから、利用者が指定したticker・期間・必要な板の深さに応じてorder bookを再構築する仕組みです。
もちろん、私の個人研究基盤とこれらを同列に扱うつもりはありません。
ただ、
最も細かいデータを取れるからといって、あらゆる表現・あらゆる粒度を永久保存する必要はない
という設計思想は参考になります。
今の私の基盤でも、
元の生データは圧縮して残し、再生成できる途中の加工データは必要以上に保存しない。研究判断に直接使う派生データは成果物として残す
くらいに整理していくのがよさそうです。
昨日はHyperliquid用observerを別プロジェクトでも再利用できるよう切り出しましたが、今回のcross-venue研究では、その共有observerへ全面的に置き換えるのではなく、既存研究との互換性を優先して現在のcollectorへBBOだけを追加しました。
-
-
🛠️開発記録#557(2026/8/31)仮説ごとの観測機から共通基盤へ｜Hyperliquid observerを切り出した話
続きを見る
ここでも「何でも統合する」より、目的に応じて必要な部分だけ使う方がよさそうです。
個人botterとして、どこまで細かく見るのか
そして今回、一番整理したかったのがここです。
観測機を細かくし始めると、
もっと速く
もっと細かく
もっと正確に
と際限なく進められます。
でも、仮に100ms未満にしか価格差が残っていないなら、その領域を個人botterとして本当に追うのか？
という問題があります。
専用server、ネットワーク最適化、実装言語の変更、より高度なorder book reconstructionなど、技術的には次の階段があります。
ただし、市場側に取れそうなものが残っている証拠もないのに、先回りしてそこへ投資する意味は薄いです。
そこで今は、個人botterとしての暫定的な研究投資基準をこんな感じで置いています。
| 残存時間 | 現時点の扱い |
|---|---|
| 100ms未満 | 原則として追わない。純粋な速度競争へ入るなら撤退候補 |
| 100〜300ms | 強い残差・頻度が確認できる場合だけ追加投資を検討 |
| 300ms〜1秒 | 個人でも観測・実装改善を検討する価値がある領域 |
| 1秒以上 | 次の「取れるか？」検証へ積極的に進めたい領域 |
もちろん、この数字に絶対的な意味があるわけではありません。
299msなら取れず、301msなら取れる、という話ではないです。
最終的には、自分のbotの実測latencyや、取引所のfee、slippageなどで上書きする必要があります。
ただ、
どこから先は研究設備への追加投資を止めるのか
というデフォルトの物差しとしては使えそうです。
まず見るのは「bps × duration × frequency」
時間だけ見ても意味がありません。
例えば、
5bpsの価格差がある
としても、5msで消えるなら私にはほぼ関係ありません。
反対に、
1bpsしかない
としても、数秒残り、それが高頻度で起きるなら別の評価になります。
そこで現在、一次screenとして見ようとしているのが、
bps × duration × frequency
です。
日本語にすると、
何bps残るか × 何秒残るか × どのくらいの頻度で起きるか
です。
まずここで、個人botterとして調べる価値がある時間スケールなのかを選別します。
そして、ここを通ったものだけ次へ進めます。
次は、
available size（実際に約定できそうな量）
fee（手数料）
slippage（滑り）
execution latency（注文までの遅延）
fill probability（実際に約定する確率）
です。
つまり、
見えるか？
の次に、
取れるか？
を見る。
以前、別の歪み回帰研究でも「歪みが戻るように見える」ことと、実際の執行でEVが正になることを分けて考え、後者が通らなかったため研究を凍結したことがありました。
今回も基本的な考え方は同じです。
30分だけ見ると、100ms未満で縮む価格差も多そうだった
今回の30分検証では、まだサンプル数は少ないものの、少し気になる結果が出ました。
今回見ているのは、例えばこんな動きです。
Binanceの価格が動いた時点で、Hyperliquidとの価格差が4bpsあった
↓
その後、価格差が2bps以下まで縮むのに何msかかったか
最初に観測した価格差の半分以下まで縮むことを、ここでは「50%減衰」と呼んでいます。
30分間では、Binanceのmid価格が0.25bps以上動いたケースが95件ありました。
そのうち35件では、BinanceとHyperliquidの価格差が観測開始時の半分以下まで縮みました。その35件について、半分以下になるまでの時間の中央値は約58msでした。
Binanceが0.5bps以上動いたケースは13件とかなり少なく、そのうち7件で価格差が半分以下まで縮みました。こちらの中央値は約45msでした。
数字だけを見ると、
「価格差は50ms前後で消えてしまうのでは？」
とも読めます。
ただし、まだそう結論する段階ではありません。
まず、この45〜58msは「取引機会が残っていた時間」ではありません。
測っているのはあくまで、
最初に観測したBinanceとHyperliquidの価格差が、半分以下まで縮むのにかかった時間
です。
例えば最初に4bps離れていて、50ms後に2bpsまで縮んだとしても、その時点で2bpsの価格差はまだ残っています。
逆に、最初の価格差自体が小さければ、半分になったところで取引対象として意味がない可能性もあります。
さらに、この数字には手数料、slippage（注文時の価格の滑り）、実際の約定速度なども入っていません。
そして何より、サンプル数がまだ少なすぎます。
5分だけ行った直前の試験では、0.5bps以上のBinanceの価格変化について、価格差が半分になるまでの中央値が約0.8秒という結果も出ていました。
5分と30分だけでもかなり数字が変わっています。
そのため、今の段階で知りたいのは「半減時間は何msだったか」という一点ではありません。
むしろ、
最初に何bps離れていたのか
100ms後には何bps残っているのか
250ms、500ms、1秒後にはどうなっているのか
そうしたケースがどのくらいの頻度で起きるのか
という分布です。
そこで現在はBTCについて、
Binance bookTicker
Hyperliquid BBO
Hyperliquid l2Book
を使った24時間観測を開始しています。
まずは、
何bpsの価格差が、何ms・何秒残るケースが、どのくらいの頻度で存在するのか
を確認します。
その結果を見てから、個人botterとして次の検証へ進む価値があるのか、それとも速度競争になりすぎるのでここで止めるのかを判断する予定です。
「もっと細かく見れば何かある」は、研究継続の理由にしない
今回、自分の中でかなり重要だったのはここです。
もし24時間観測した結果、
意味のありそうな残差は100ms未満でほぼ消える
のであれば、
「もっと高性能なサーバーを使えば見えるかもしれない」
「Rustで書き直せば取れるかもしれない」
「もっと低遅延のインフラを使えば何とかなるかもしれない」
と無限に先へ進むのではなく、
このテーマは個人botterとして取る対象ではない
と止める。
逆に、
500ms後にも数bps残るeventが一定頻度ある
1秒後にも残る条件がある
のであれば、そのとき初めて、
板の厚さは？
fee後は？
自分の注文latencyは？
約定するのか？
へ進みます。
市場が要求していない技術を、先回りして勉強・実装しない。
壁が見えたら、その壁を越えるための技術だけ一段上げる。
それでも経済性が通らなければ捨てる。
今のところ、この進め方が自分には合っていそうです。
必要十分なのは「観測精度」だけではなかった
前回は主にtimestampについて、
必要十分な精度はどこか
を考えました。
今回はそこから少し広がって、
必要十分な観測粒度
必要十分な保存データ
必要十分な分析
必要十分な実装投資
まで同じ話なのだと思うようになりました。
細かく観測できること自体は強いです。
でも、
観測できるものを全部保存する
分析できるものを全部分析する
実装できるところまで全部高速化する
必要はありません。
研究目的から逆算して、
ここまで見えれば次の判断ができる
というところで一旦止める。
現在の私にとっては、それがBBOを使った100ms〜数秒程度のresidual観測です。
ここから先は24時間データを市場に取らせて、
bps × duration × frequency
の分布を見ます。
結果次第では次へ進む。
結果次第では、ここで捨てる。
今回やったことは新しいedgeを見つけたことではありません。
むしろ、
edgeがあるかどうかを、個人botterとして追う価値のある時間スケールで判断できる測定器を作った
という方が近いです。
研究では「もっと見えるようにする」ことも大切ですが、
どこまで見えれば十分なのかを決める
ことも同じくらい大切なのかもしれません。
そんなことを考えながら、現在は24時間観測中です。
結果が出たら、また続きをまとめます。
それでは、また。
参考にした論文・一次情報
今回の記事では、CEX–Hyperliquid間のlead-lag研究、高頻度データの扱い、order bookの観測粒度について、以下の論文・公式資料を参考にしました。
1. Arrakis Finance｜Why Hyperliquid Lags Binance: Perp DEX Lead-Lag Analysis
Arrakis Financeによるオリジナル分析です。査読論文ではありませんが、実際のperpetual futuresのtrade tapeを使った一次分析として参考になります。
Hyperliquid、Binance Futures USDT-M、Lighterの3市場について、共通して取引される29銘柄を16日間分析しています。非同期に発生する取引データを扱うため、Hoffmann・Rosenbaum・Yoshida（2013）を参考にしたmodified Hayashi–Yoshida lead-lag estimatorを使用しています。
分析結果では29銘柄すべてでBinanceがHyperliquidを先行し、Hyperliquidとのlagは多くの銘柄で600〜800ms程度、BTCでは800ms付近にピークが報告されています。
今回の私の方法はtrade tapeのvenue timestampを直接比較するものではなく、同じPCで受信したmarket dataをlocal monotonic clockで並べる方法なので、同じ分析ではありません。
Arrakis Finance｜Why Hyperliquid Lags Binance
2. Lim, B. C. (2026)｜Binance Leads, but Some Wallets Anticipate: Wallet-Level Cross-Venue Informed Flow in BTC Perpetual Futures
BinanceとHyperliquidのBTC perpetual futuresを直接比較した2026年のpreprintです。査読済み論文ではありません。
2026年5月25日〜6月22日のorder-book dataをvenue event timeで整列し、lead-lag cross-correlation、Hasbrouck information share、wallet-level markoutなどを用いてprice discoveryを分析しています。
venue levelでは、検証したすべてのprice-discovery windowでBinanceがHyperliquidを先行したと報告しています。一方で、Hyperliquid上にはBinanceの後続価格変化に先行するような一部walletも観測されており、「venue全体が追随側でも、その中の全participantが追随側とは限らない」という点も扱っています。
DOI: 10.2139/ssrn.6993378
SSRN｜Binance Leads, but Some Wallets Anticipate
3. Hoffmann, Rosenbaum & Yoshida (2013)｜Estimation of the lead-lag parameter from non-synchronous data
非同期に観測される2つの金融時系列からlead-lag parameterを推定する方法を扱った査読論文です。
Arrakis Financeが使用しているlead-lag分析の方法論的な元になっている研究で、modified Hayashi–Yoshida covariation estimatorを用いて、ランダムかつ非同期にsamplingされた2系列のlead-lagを推定しています。
「取引所Aと取引所Bではevent発生時刻が揃っていない」という高頻度market data特有の問題を扱う上での基礎資料として参考になります。
Bernoulli, 19(2), 426–461.
DOI: 10.3150/11-BEJ407
arXiv｜Estimation of the lead-lag parameter from non-synchronous data
Market data基盤・保存設計の参考資料
以下は学術論文というより、実際のmarket data基盤やデータサービスを提供している組織の公式技術資料です。
4. KX｜kdb+/tick architecture
金融のリアルタイムmarket data処理で長く使われているkdb+/tickの公式アーキテクチャ資料です。
典型構成では、
- tickerplantがincoming dataを受信・logへ記録
- RDB（Real-Time Database）が当日分をmemory上で保持
- RTE（Real-Time Engine）が必要なstreaming analyticsを実行
- HDB（Historical Database）が履歴データを保持
というように役割が分離されています。
今回の記事で書いた「入力データを残すこと」と「処理途中のあらゆる表現をすべて永続保存することは別」という考え方を整理する際に参考にしました。
なお、KXが「中間生成物はすべて捨てるべき」と主張しているわけではありません。ここでは、log・memory上の処理・派生計算・履歴保存の役割を分離したreference architectureとして参照しています。
5. Databento｜Market data schemas and data formats
Databentoの公式market data仕様です。
order book dataを粒度に応じて、
- MBO：Market by Order / L3
- MBP-10：Market by Price / L2
- MBP-1：Top of Book / L1
などに分類しています。
特に参考になったのは、Databentoが可能な場合には最もgranularなsourceを取得し、MBP、BBO、Trades、OHLCVなど、より粗いschemaをそこから派生させている点です。
つまり「用途ごとに別々の粗いデータをすべて独立取得・保存する」のではなく、より高粒度なsourceから目的に必要なrepresentationを生成する設計です。
今回の「canonicalなrawを残し、再生成可能な中間表現をどこまで永続化するか考える」という議論の参考にしました。
Databento｜Schemas and data formats
6. Huang & Polak (2011)｜LOBSTER: Limit Order Book Reconstruction System
NASDAQのHistorical TotalView-ITCH message dataからlimit order bookを再構築するLOBSTERについての原著technical reportです。
LOBSTERではexchange messageを順番に処理し、order submission、cancel、executionなどをorder IDで追跡しながらorder bookを再構築します。
利用者はticker・期間・必要なbook depthを指定でき、LOBSTERは内部ではbookを再構築しつつ、要求されたlevelに応じたデータをoutputします。
今回の「観測可能な全情報を常に同じ粒度で保存する必要はなく、研究目的に必要なdepth・representationを選択できる」という考え方の参考例です。
DOI: 10.2139/ssrn.1977207
SSRN｜LOBSTER: Limit Order Book Reconstruction System
LOBSTER公式のreconstruction説明では、NASDAQ ITCHからfull bookを再構築した上で、利用者が指定したlevelに応じて保存するoutput範囲を変える仕組みも説明されています。
今回の実装仕様を確認するための公式資料
7. Hyperliquid公式｜WebSocket Subscriptions
今回使用している bbo と l2Book の公式仕様です。
bbo はbest bid / best offerがblock上で変化した場合に送信されるstreamです。
一方 l2Book は複数のprice levelを含むorder book snapshotで、公式型定義では「前回pushから少なくとも0.5秒経過したblockごとにpushされるsnapshot feed」とされています。
今回私のPCで l2Book の受信間隔中央値が約5.39秒だったのは公式の固定周期ではなく、あくまで実際の観測結果です。BBOについても「100ms固定更新」ではなく、今回のrunで受信間隔中央値が約0.1秒だった、という意味です。
Hyperliquid Docs｜WebSocket Subscriptions
8. Binance公式｜Individual Symbol Book Ticker Streams
今回Binance側で使用している btcusdt@bookTicker の公式仕様です。
指定symbolについてbest bid / best askの価格と数量が変化した場合にreal-timeでpushされます。payloadにはbest bid price / quantity、best ask price / quantity、event time、transaction time、order book update IDなどが含まれます。
Binance Developer Docs｜Individual Symbol Book Ticker Streams
9. Python公式｜time.monotonic_ns()
今回、BinanceとHyperliquidの「自分のPCでの受信順序」を比較するために使っているlocal clockの仕様確認に使用しています。
Pythonの time.monotonic() はシステム時刻の変更によって後戻りしないmonotonic clockで、monotonic_ns() は同じ時計をnanosecond整数で取得します。
ただし基準となる絶対時刻には意味がなく、2回のcallの差分を時間間隔として利用するものです。
そのため今回の測定は「両取引所の時計を完全同期したもの」ではなく、「同じ観測機でどちらを先に受信したか」を比較するものとして扱っています。
Python Documentation｜time.monotonic_ns()
より低遅延なorder book観測へ進む場合の参考
10. Hyperliquid公式｜Optimizing latency
現状よりさらに低遅延・高粒度な観測が必要になった場合の公式資料です。
Hyperliquidはlatency-sensitive trader向けに、non-validating nodeを動かし、node outputからローカルでorder bookやexchange stateを構築する方法を案内しています。公式資料では、この方法はAPIより高速かつgranularなデータを得られると説明されています。
今回の記事ではまだここまで進んでいません。
むしろ、現在のpublic BBOで bps × duration × frequency を確認し、それでも個人botterとして追う価値があると判断できた場合に初めて検討する「次の階段」として位置づけています。