こんにちは、ぼっちbotterよだかです。
今日はDeFi研究で見ている Ethena × Hyperliquid の観測軸を整理し、実装側にも反映したので、それについてまとめます。
-
-
🛠️開発記録#523(2026/4/24)観測チェック&今週の振り返り＆来週の計画
続きを見る
1. 今日の目的
今日は、DeFi研究で見ている Ethena × Hyperliquid の観測軸を整理し、実装側にも反映しました。
これまでの主な見方は、Ethena側のUSDe供給ショックが、Hyperliquid側のBTC/ETH perp市場に何らかの反応を引き起こすか、というものでした。具体的には、usde_supply_zscore_24obs の上下10%を供給ショックとして扱い、その後のHyperliquid側の mark_px、open_interest_usd、funding_rate、volume_24h_usd の変化を見ていました。
ただし、ここまでの確認では、供給ショック単体を主トリガーとして扱うには弱い結果でした。価格方向についてはかなり弱く、OIについても一時的に反応らしきものは見えたものの、サンプルを伸ばすと安定しませんでした。特に、既存の供給ショック定義は「実際の供給増減」ではなく、24観測窓の中での相対的な極端値を拾うものであり、positive shock が必ずしも供給増加を意味しない点も確認しました。
そこで今回は、供給ショック単体を見るのではなく、Ethena側の状態をもう少し広く分類する方針に切り替えました。
中心に置いたのは、次の2つです。
USDe supply の24観測変化方向coverage proxy ratio の24観測変化方向
coverage_proxy_ratio は、次の式で定義しました。
coverage_proxy_ratio = collateral_total_backing_usd / usde_supply
これは公式なcoverage指標ではなく、研究用のproxyです。
この比率の変化方向とUSDe supplyの変化方向を組み合わせて、Ethena側の初期レジームを作りました。
今回の作業の目的は、次の段階でHyperliquid側の open_interest_usd、funding_rate、volume_24h_usd を見るために、Ethena側の説明変数を整理することです。
価格方向は主対象ではなく、参考値として扱う方針にしました。
今日の作業は、大きく分けると以下です。
1. 既存の供給ショック定義と分析結果を整理2. coverage proxy / backing gap proxy を追加3. supply_state / coverage_state を作成4. supply × coverage proxy による4つのEthena初期レジームを定義5. レジーム品質診断を実行6. 定期実行と morning-check に state / regime label の更新確認を組み込み
結果として、Ethena側の状態を次の4分類で追えるようにしました。
expansion_coverage_improvingexpansion_coverage_deterioratingcontraction_coverage_improvingcontraction_coverage_deteriorating
加えて、分類不能な行は mixed_unclear として扱います。今回のデータでは、mixed_unclear は主に24観測差分を作るための先頭24観測欠損に由来していました。
この状態で1週間ほど追加観測し、ethena_regime の分布、run length、coverage由来のチラつき、mixed_unclear の増加有無を確認します。その後、同じ品質診断を再実行し、次にHyperliquid側のOI・Funding・Volume反応を見るか、先にレジーム定義へneutralや閾値を入れるかを判断します。
2. 供給ショック定義の再確認
まず、これまで使っていた「供給ショック」という定義を確認しました。
既存実装では、主に usde_supply_zscore_24obs を使っていました。これは、USDe supply の24観測窓における rolling z-score です。現在の定期実行は1時間ごとなので、24観測はおおむね24時間に相当します。ただし、厳密には「24時間差分」ではなく「24観測前との比較」です。
既存の供給ショック定義は、ざっくり書くと以下です。
positive_shock: usde_supply_zscore_24obs が上位10%に入るnegative_shock: usde_supply_zscore_24obs が下位10%に入る
この定義で見ていたのは、「USDe supply が実際に増えたか減ったか」ではありません。
24観測窓の中で、現在の supply 水準が相対的にどれくらい極端な位置にあるかです。
当初は、positive_shock という名前から、供給増加イベントのように見えていました。しかし実際には、今回のデータ期間では supply が全体的に減少・停滞していたため、上位10%に入っていても、絶対的には供給増加ではないケースがありました。
つまり、既存の positive_shock / negative_shock は、以下のように理解するべきでした。
positive_shock / negative_shock: usde_supply_zscore_24obs の分位に基づく局所的な極端値意味しないもの: 実際の supply expansion / contraction 絶対的な供給増加・供給減少
この点を踏まえると、「Ethena供給ショックがHyperliquid側に影響するか」という問い自体も、少し修正が必要でした。
実際に見ていたのは、
usde_supply_zscore_24obs の局所的な極端値のあと、Hyperliquid側の価格・OI・Funding・Volumeがどう動くか
であって、
USDe supply が実際に増減したあと、Hyperliquid側がどう反応するか
ではありませんでした。
そのため、供給ショック定義を usde_supply_diff_6obs / usde_supply_diff_24obs ベースでも再確認しました。
考え方は以下です。
supply_expansion: usde_supply_diff_6obs または usde_supply_diff_24obs > 0supply_contraction: usde_supply_diff_6obs または usde_supply_diff_24obs < 0
これにより、z-score上の相対的な極端値ではなく、実際の供給増減に近い形で見直しました。
その結果、供給ショック単体を主トリガーとして扱うには弱い、という整理になりました。
特に価格方向については弱く、mark_px に安定した同方向反応は見えませんでした。
OIについては、初期の短いデータでは6時間後に反応らしきものが見えましたが、データを伸ばすと弱まりました。usde_supply_diff_6obs ベースでは一部でOI 6h反応が残ったものの、クラスタ調整後にはかなり弱くなりました。
ここでいうクラスタ調整とは、連続して出ている同種イベントを別々の独立イベントとして扱わず、一定時間内の同じ局面としてまとめることです。
たとえば、1時間ごとに以下のように出た場合、
10:00 supply_contraction11:00 supply_contraction12:00 supply_contraction
これを3件の独立イベントとして扱うのではなく、
10:00〜12:00 の supply_contraction 局面
として扱う、ということです。
この処理を入れると、見かけ上のイベント数は減ります。
そして、前回強そうに見えていたOI反応も弱まりました。
この時点で、供給ショックについては次のように整理しました。
否定寄り: 供給ショック単体で Hyperliquid BTC/ETH の価格方向を予測する弱いが保留: 供給変化が Hyperliquid OI に短期的な情報を持つ補助タグとして残す: usde_supply_zscore_24obs の極端値 usde_supply_diff_6obs / 24obs ベースの supply expansion / contraction
つまり、供給ショックは完全に捨てるのではなく、主トリガーからは下げました。
今後の扱いとしては、
供給ショック = 主トリガーではなく補助イベントタグ
です。
これにより、研究の主軸は、
供給ショックが起きたかどうか
から、
Ethena側がどのような状態にあるか
へ移りました。
具体的には、USDe supply の変化方向と coverage proxy の変化方向を組み合わせて、Ethena側の状態を分類する方針に切り替えました。
3. 既存データで見えたこと
既存データを使って、まずは supply shock 起点で Hyperliquid 側の反応を見ました。
対象にしたHyperliquid側の指標は、主に以下です。
mark_pxopen_interest_usdfunding_ratevolume_24h_usd
それぞれの意味は次のように整理しています。
mark_px: Hyperliquid上のマーク価格。 ここではBTC/ETH perpの価格変化を見るための参考指標。open_interest_usd: Hyperliquid上の未決済建玉をUSD換算した値。 市場参加者がどれくらいポジションを持っているかを見るための指標。funding_rate: perp市場の資金調達率。 ロング側・ショート側の需要の偏りや、ポジション維持コストを見るための指標。volume_24h_usd: 直近24時間の取引量をUSD換算した値。 市場活動量を見るための指標。 ただし24h rolling値なので、短期イベント直後の反応としては扱いに注意が必要。
当初の見方は、Ethena側のUSDe supplyに局所的なショックが出たあと、Hyperliquid側のBTC/ETH perp市場に何らかの反応が出るか、というものでした。
結果として、mark_px には安定した反応は見えませんでした。
供給ショック後にBTC/ETH価格が一貫して同方向に動く、という見方は弱まりました。
open_interest_usd については、最初の短いデータでは6時間後に反応らしきものが見えていました。
ただし、データ期間を伸ばすとその反応は弱まりました。既存の usde_supply_zscore_24obs ベースでは、OI 6h の方向一致はランダムに近い水準まで落ちました。
その後、供給ショック定義を usde_supply_diff_6obs / usde_supply_diff_24obs ベースでも見直しました。
この場合、usde_supply_diff_6obs では OI 6h に少し反応らしきものが残りました。ただし、連続イベントをクラスタとしてまとめると、その反応もかなり弱まりました。
ここから、OIについては次のように扱うことにしました。
完全には捨てないただし、supply shock単体の主トリガーとしては弱い今後はEthena状態レジームごとの差を見る対象にする
funding_rate については、一部の窓で反応っぽい動きがありました。
ただし、6h / 24h / 72h の間で一貫しているとは言いにくく、単独で主仮説にするほどの材料はありませんでした。
volume_24h_usd については、比較的動きが出ていました。
ただし、これは直近24時間のローリング出来高です。したがって、イベント後の短期反応というより、既に続いている市場活動量や市場環境を拾っている可能性があります。
この時点での整理は以下です。
価格方向: supply shock単体では弱いOI: 一部反応らしきものはあるが安定しない 今後も見る対象には残すFunding: 一部で反応らしき動きはあるが一貫性は未確認Volume: 動きはある ただし24h rolling指標なので解釈注意
この結果から、次の仮説にそのまま進むのは避けました。
USDe supply shockが起きたら、Hyperliquid側の価格やOIが一定方向に動く
代わりに、見る対象を次のように変えました。
supply shock単体↓Ethena側の状態分類
つまり、単発の供給ショックをイベントとして見るのではなく、Ethena側がどの状態にあるときに、Hyperliquid側の OI / Funding / Volume がどう違うかを見る方針にしました。
この切り替えの理由は、既存データで supply shock 単体の反応が安定しなかったことと、VolumeやOIのような市場活動量側にはまだ見る余地が残っていたことです。
この段階で、価格方向は主対象から外しました。
今後の主対象は、Hyperliquid側の open_interest_usd、funding_rate、volume_24h_usd です。価格は参考値として扱います。
4. supply shock単体からEthenaレジームへ見る軸を移した理由
ここまでの確認で、supply shock 単体を主トリガーにする見方は弱まりました。
理由は大きく3つあります。
1. 既存のpositive_shock / negative_shockは、実際の供給増減そのものではなかった2. mark_pxへの安定した反応が見えなかった3. OI / Funding / Volumeには見る余地があるが、supply shock単体では整理しにくかった
まず、既存の positive_shock / negative_shock は、usde_supply_zscore_24obs の上下10%で定義されていました。
これは24観測窓の中での相対的な極端値であって、実際の供給増加・供給減少をそのまま表すものではありません。
そのため、positive_shock という名前であっても、実際にはUSDe supplyが増えているとは限りませんでした。
このまま「供給増加イベント」として扱うと、定義と解釈がずれます。
次に、Hyperliquid側の mark_px には安定した反応が見えませんでした。
ここでいう mark_px は、BTC/ETH perpのマーク価格です。
供給ショック後に価格が一定方向へ動く、という見方は既存データでは支持されませんでした。
一方で、open_interest_usd、funding_rate、volume_24h_usd は、完全に見る価値がなくなったわけではありません。
open_interest_usd は未決済建玉のUSD換算値です。
市場参加者がどれくらいポジションを持っているかを見る指標です。
funding_rate はperp市場の資金調達率です。
ロング側・ショート側の需要の偏りや、ポジション維持コストを見るために使います。
volume_24h_usd は直近24時間の取引量です。
市場活動量を見る指標ですが、24h rolling値なので、短期イベントの反応としてそのまま解釈するには注意が必要です。
これらは、価格方向よりも「市場活動量」「ポジション量」「perp側の需要の偏り」を見るための指標です。
そのため、次の問いに切り替えることにしました。
供給ショックが起きたかどうか↓Ethena側がどの状態にあるか
つまり、単発イベントとしての supply shock を見るのではなく、Ethena側の状態を分類し、その状態ごとにHyperliquid側の OI / Funding / Volume の反応が違うかを見る方向へ移しました。
今回使うEthena側の分類軸は、次の2つです。
USDe supply の24観測変化方向coverage_proxy_ratio の24観測変化方向
USDe supply の24観測変化方向 は、USDe supply が24観測前より増えているか、減っているかを見ます。
現在の定期実行は1時間ごとなので、24観測はおおむね24時間に相当します。ただし厳密には「24時間前」ではなく「24観測前」です。
coverage_proxy_ratio は、次の式で定義しました。
coverage_proxy_ratio = collateral_total_backing_usd / usde_supply
これは公式なcoverage指標ではなく、研究用proxyです。
この比率が24観測前より上がっていれば coverage_improving、下がっていれば coverage_deteriorating としました。
この2軸を組み合わせることで、Ethena側の状態を次の4分類にしました。
expansion_coverage_improvingexpansion_coverage_deterioratingcontraction_coverage_improvingcontraction_coverage_deteriorating
この分類で見たいことは、価格方向を直接当てることではありません。
見たいのは、次のような差です。
expansion_coverage_improving のとき、HLのOIやVolumeが増えやすいかexpansion_coverage_deteriorating のとき、FundingやVolumeの反応が違うかcontraction_coverage_improving と contraction_coverage_deteriorating で、HL側のOI / Funding / Volumeの変化に差があるか
ここでの「〜のとき」は、Hyperliquid側の状態ではなく、Ethena側の状態を指します。
つまり、その時刻のEthena側が supply × coverage proxy のどの組み合わせに分類されているか、という意味です。
この切り替えにより、供給ショックは主トリガーではなく補助タグとして残す扱いにしました。
今後は、まずEthena側の初期レジームを継続観測に載せます。
そのうえで、レジームごとにHyperliquid側の open_interest_usd、funding_rate、volume_24h_usd の動きが違うかを見に行きます。
5. coverage proxy / backing gap proxy の定義
供給ショック単体からEthenaレジームを見る方針に切り替えるために、まずEthena側の状態を表すためのproxyを追加しました。
今回追加した主な指標は次の2つです。
coverage_proxy_ratiobacking_supply_gap_usd_proxy
ただし、最終的にレジーム分類の主軸として使ったのは coverage_proxy_ratio です。backing_supply_gap_usd_proxy は補助表示として残しましたが、レジーム分類には使っていません。
coverage_proxy_ratio
coverage_proxy_ratio は、次の式で定義しました。
coverage_proxy_ratio = collateral_total_backing_usd / usde_supply
これは、USDe supply に対して、Ethena側の collateral_total_backing_usd がどの程度あるかを見るための研究用proxyです。
意味としては、
collateral_total_backing_usd が usde_supply に対して相対的に増えているか、減っているか
を見ます。
ただし、これは公式な担保率や正式なcoverage指標ではありません。
今回の研究では、あくまで既存の観測データから作れる proxy として扱います。
この値そのものの水準で、
coverage_highcoverage_low
のような分類は作りませんでした。
理由は、現時点では coverage_proxy_ratio の水準そのものが、どの程度の意味を持つかを判断していないためです。
また、coverage_proxy_ratio > 1.0 のような基準で分類することも避けました。
今回使ったのは、水準ではなく変化方向です。
coverage_proxy_ratio_diff_24obs > 0 → coverage_improvingcoverage_proxy_ratio_diff_24obs < 0 → coverage_deteriorating
つまり、24観測前と比べて coverage proxy が改善しているか、悪化しているかだけを見ています。
現在の定期実行は1時間ごとなので、24観測はおおむね24時間に相当します。
ただし厳密には、24時間前ではなく24観測前との差分です。
backing_supply_gap_usd_proxy
もう1つ追加したのが、backing_supply_gap_usd_proxy です。
定義は次の通りです。
backing_supply_gap_usd_proxy = collateral_total_backing_usd - usde_supply
これは、collateral_total_backing_usd と usde_supply の差額をUSD建てで見るためのproxyです。
たとえば、最新値では backing_supply_gap_usd_proxy がプラスであれば、proxy上は collateral_total_backing_usd が usde_supply を上回っていることになります。
ただし、これは既存の collateral_gap_usd とは別の定義です。
既存の collateral_gap_usd は、次のように定義されていました。
collateral_gap_usd = collateral_total_backing_usd - collateral_sum_usd
一方で、今回作った backing_supply_gap_usd_proxy は、
collateral_total_backing_usd - usde_supply
です。
見ている差分が違うため、collateral_gap_usd を backing_supply_gap_usd_proxy の代用にはしませんでした。
coverage と gap を分けた理由
一度は、coverage と gap の両方をレジーム分類に使うことも考えました。
ただし、この2つはどちらも同じ2つの系列から作られています。
collateral_total_backing_usdusde_supply
違いは、比率で見るか、差額で見るかです。
coverage_proxy_ratio = collateral_total_backing_usd / usde_supplybacking_supply_gap_usd_proxy = collateral_total_backing_usd - usde_supply
そのため、両方をレジーム分類の主軸に入れると、同じ情報を二重に使う可能性があります。
ここでは、次のように役割を分けました。
coverage_proxy_ratio: レジーム分類の主軸に使うbacking_supply_gap_usd_proxy: 人間が単位感を確認するための補助表示に使う
つまり、レジーム分類では coverage_state は作りますが、backing_state は作りません。
この判断により、レジーム分類は次の2軸だけに絞りました。
supply_statecoverage_state
この定義で確認したい仮説
この時点で、仮説の見方も整理しました。
まず、弱めた仮説はこれです。
USDe supply shock 単体で、Hyperliquid側の価格やOIが一定方向に動く
この見方は、既存データでは安定しませんでした。
一方で、新しく見たい仮説は次です。
USDe supply の増減方向と coverage proxy の改善/悪化方向の組み合わせによって、Hyperliquid側の OI / Funding / Volume の変化が違う可能性がある
つまり、単発イベントではなく、状態条件を見る方向に変えました。
比較すると、次のようになります。
| 見方 | 使う定義 | 主に見たいもの | 現時点の扱い |
|---|---|---|---|
| 供給ショック単体 | usde_supply_zscore_24obs 上下10% | 価格・OI・Funding・Volumeのイベント後反応 | 主軸から下げる |
| 実供給変化 | usde_supply_diff_6obs / 24obs | supply expansion / contraction後の反応 | 補助タグ候補 |
| Ethenaレジーム | supply_state × coverage_state | OI・Funding・Volumeの状態別反応 | 次の主な観測軸 |
| coverage proxy | collateral_total_backing_usd / usde_supply | Ethena側の相対的なbacking状態 | レジーム分類に使用 |
| backing gap proxy | collateral_total_backing_usd - usde_supply | 差額の単位感・補助確認 | 分類には使わない |
この整理により、今回の主軸は明確になりました。
今後は、
USDe supply の24観測変化方向coverage_proxy_ratio の24観測変化方向
を組み合わせた初期レジームを使い、Hyperliquid側の open_interest_usd、funding_rate、volume_24h_usd の違いを見ます。
6. supply_state / coverage_state の定義
Ethena側の初期レジームを作る前段として、まず supply_state と coverage_state を定義しました。
今回使うレジームは、直接 usde_supply や coverage_proxy_ratio の水準を見るのではなく、それぞれの24観測変化方向を見ます。
使う入力は次の2つです。
usde_supply_diff_24obscoverage_proxy_ratio_diff_24obs
現在の定期実行は1時間ごとなので、24観測はおおむね24時間に相当します。
ただし、これは厳密には「24時間前との差分」ではなく、「24観測前との差分」です。
supply_state
supply_state は、USDe supply が24観測前より増えているか、減っているかを見るための状態ラベルです。
定義は次の通りです。
if usde_supply_diff_24obs > 0: supply_state = "supply_expanding"elif usde_supply_diff_24obs < 0: supply_state = "supply_contracting"elif usde_supply_diff_24obs == 0: supply_state = "supply_flat"else: supply_state = "supply_unknown"
意味としてはこうです。
supply_expanding: USDe supply が24観測前より増えているsupply_contracting: USDe supply が24観測前より減っているsupply_flat: USDe supply が24観測前と同じsupply_unknown: 差分が欠損している、または判定できない
今回のデータでは、supply_contracting が多く出ていました。
具体的には、開発の時点で次のような分布でした。
supply_contracting: 176supply_expanding: 22supply_unknown: 24
supply_unknown の24件は、24観測差分を作るための先頭欠損に由来するものです。
ここから分かるのは、今回の観測期間ではUSDe supplyが減少寄りの状態に偏っていたということです。
そのため、後続分析で expansion 系レジームを見るには、追加観測でサンプルが増えるかを確認する必要があります。
coverage_state
coverage_state は、coverage_proxy_ratio が24観測前より改善しているか、悪化しているかを見るための状態ラベルです。
入力は次の値です。
coverage_proxy_ratio_diff_24obs
定義は次の通りです。
if coverage_proxy_ratio_diff_24obs > 0: coverage_state = "coverage_improving"elif coverage_proxy_ratio_diff_24obs < 0: coverage_state = "coverage_deteriorating"elif coverage_proxy_ratio_diff_24obs == 0: coverage_state = "coverage_flat"else: coverage_state = "coverage_unknown"
意味としてはこうです。
coverage_improving: coverage_proxy_ratio が24観測前より上がっているcoverage_deteriorating: coverage_proxy_ratio が24観測前より下がっているcoverage_flat: coverage_proxy_ratio が24観測前と同じcoverage_unknown: 差分が欠損している、または判定できない
ここでの coverage_proxy_ratio は、前章で定義した通り、
coverage_proxy_ratio = collateral_total_backing_usd / usde_supply
です。
今回のデータでは、Step 3の時点で次のような分布でした。
coverage_deteriorating: 115coverage_improving: 83coverage_unknown: 24
supply_state と違い、coverage_state は改善側と悪化側の両方に分かれていました。
そのため、同じ supply_contracting の中でも、
supply_contracting + coverage_improvingsupply_contracting + coverage_deteriorating
を分けて見る余地が出ました。
今回は符号ベースで分類した
今回の supply_state と coverage_state は、どちらも符号ベースで分類しています。
つまり、
diff > 0diff < 0diff == 0missing
だけで分けています。
この段階では、最小変化幅や閾値は入れていません。
たとえば、coverage_proxy_ratio_diff_24obs がごく小さなプラスでも coverage_improving になります。
ごく小さなマイナスでも coverage_deteriorating になります。
この仕様には利点と弱点があります。
利点は、定義が単純で、後から解釈しやすいことです。
弱点は、微小な変化でも状態が切り替わるため、ラベルがチラつく可能性があることです。
この点は、後でレジーム品質診断として確認しました。
backing_state は作らなかった
今回、backing_supply_gap_usd_proxy も作成しましたが、そこから backing_state は作りませんでした。
理由は、coverage_proxy_ratio と backing_supply_gap_usd_proxy が同じ2つの系列から作られているためです。
coverage_proxy_ratio = collateral_total_backing_usd / usde_supplybacking_supply_gap_usd_proxy = collateral_total_backing_usd - usde_supply
どちらも元になる系列は同じです。
collateral_total_backing_usdusde_supply
そのため、両方をレジーム分類の主軸に入れると、同じ情報を二重に使う可能性があります。
今回の分類では、次の方針にしました。
coverage_state: レジーム分類に使うbacking_supply_gap_usd_proxy: 補助表示として使うbacking_state: 作らない
backing_supply_gap_usd_proxy は、差額をUSD建てで把握するための補助指標として残します。
ただし、レジーム判定には使いません。
state_reason も出力した
後から分類理由を確認できるように、state_reason も出力しました。
これは、supply_state と coverage_state の元になった符号を記録するための診断用ラベルです。
例としては、次のような形です。
positive/positivepositive/negativenegative/positivenegative/negativemissing/missing
実装上は、state_reason を使うことで、どの状態がどの入力符号から作られたのかを確認できます。
Step 3時点では、state_reason の件数は次のようになっていました。
negative/negative: 107negative/positive: 69missing/missing: 24positive/positive: 14positive/negative: 8
これは、次章で定義する4つのEthena初期レジームと対応しています。
negative/negative → contraction_coverage_deterioratingnegative/positive → contraction_coverage_improvingpositive/positive → expansion_coverage_improvingpositive/negative → expansion_coverage_deteriorating
この段階で、Ethena側の状態分類に使う入力はかなり絞れました。
使うもの: usde_supply_diff_24obs coverage_proxy_ratio_diff_24obs使わないもの: backing_supply_gap_usd_proxy backing_state coverage high / low coverage_proxy_ratio > 1.0 のような水準判定 閾値最適化
この状態をもとに、次に ethena_regime を定義しました。
7. 4つのEthena初期レジーム
supply_state と coverage_state を組み合わせて、Ethena側の初期レジームを定義しました。
今回のレジームは、次の2軸だけで決まります。
USDe supply の24観測変化方向coverage_proxy_ratio の24観測変化方向
使っている入力は次の2つです。
usde_supply_diff_24obscoverage_proxy_ratio_diff_24obs
ここでは、backing_supply_gap_usd_proxy は使っていません。
また、coverage_proxy_ratio の水準そのものも使っていません。
つまり、今回のレジームは、
供給が増えているか / 減っているかcoverage proxy が改善しているか / 悪化しているか
の組み合わせです。
定義したレジームは次の4つです。
expansion_coverage_improvingexpansion_coverage_deterioratingcontraction_coverage_improvingcontraction_coverage_deteriorating
分類できない行は mixed_unclear として扱います。
expansion_coverage_improving
条件は次の通りです。
usde_supply_diff_24obs > 0coverage_proxy_ratio_diff_24obs > 0
これは、USDe supply が24観測前より増えていて、同時に coverage_proxy_ratio も24観測前より上がっている状態です。
テキストで書くと、
USDe供給が増えているかつcollateral_total_backing_usd / usde_supply の比率も改善している
局面です。
このレジームについて今後見たいのは、Hyperliquid側で open_interest_usd や volume_24h_usd が増えやすいかです。
また、funding_rate にも他のレジームと違う反応が出るかを確認します。
ただし、この段階では expansion_coverage_improving を「健全な拡大」や「risk-on」とは呼びません。
あくまで、供給増加とcoverage proxy改善が同時に出ている状態です。
今回のデータでは、このレジームは14行でした。
expansion_coverage_improving: 14
サンプル数はまだ少ないため、追加観測で増えるかを確認します。
expansion_coverage_deteriorating
条件は次の通りです。
usde_supply_diff_24obs > 0coverage_proxy_ratio_diff_24obs < 0
これは、USDe supply が24観測前より増えている一方で、coverage_proxy_ratio は24観測前より下がっている状態です。
テキストで書くと、
USDe供給は増えているしかしcollateral_total_backing_usd / usde_supply の比率は悪化している
局面です。
このレジームでは、供給は増えているものの、coverage proxy の変化方向は逆です。
そのため、expansion_coverage_improving と比較して、Hyperliquid側の open_interest_usd、funding_rate、volume_24h_usd の反応が違うかを見ます。
ここでも、「不健全な拡大」「stress」「危険局面」のような名前は使いません。
現時点で言えるのは、供給増加とcoverage proxy悪化が同時に出ているということだけです。
今回のデータでは、このレジームは9〜10行程度でした。
実装タイミングによって行数は少し増えていますが、まだサンプル数は少ないです。
expansion_coverage_deteriorating: 8〜10
このレジームも、追加観測でサンプルが増えるかを見ます。
contraction_coverage_improving
条件は次の通りです。
usde_supply_diff_24obs < 0coverage_proxy_ratio_diff_24obs > 0
これは、USDe supply が24観測前より減っている一方で、coverage_proxy_ratio は24観測前より上がっている状態です。
テキストで書くと、
USDe供給は減っているしかしcollateral_total_backing_usd / usde_supply の比率は改善している
局面です。
このレジームでは、USDe supply は縮小しています。
ただし、coverage proxy は改善しています。
この場合、coverage proxy の改善は、担保側が増えたことによるものかもしれません。
あるいは、supplyが減ったことで分母が小さくなり、相対的に比率が改善しているだけかもしれません。
このレジームを解釈するときは、そこを分ける必要があります。
今回の定義だけでは、改善の原因までは分かりません。
今後は、この状態のあとに、Hyperliquid側で open_interest_usd が減りやすいのか、funding_rate がどう変化するのか、volume_24h_usd が落ち着くのかを見ます。
今回のデータでは、このレジームは69〜71行程度でした。
contraction_coverage_improving: 69〜71
今回の観測期間では、供給縮小側のサンプルが多いため、このレジームは比較的件数があります。
contraction_coverage_deteriorating
条件は次の通りです。
usde_supply_diff_24obs < 0coverage_proxy_ratio_diff_24obs < 0
これは、USDe supply が24観測前より減っていて、同時に coverage_proxy_ratio も24観測前より下がっている状態です。
テキストで書くと、
USDe供給が減っているかつcollateral_total_backing_usd / usde_supply の比率も悪化している
局面です。
このレジームでは、供給縮小とcoverage proxy悪化が同時に出ています。
ただし、これもまだ「stress」とは呼びません。coverage_proxy_ratio は研究用proxyであり、符号ベースの変化方向だけを見ているためです。
この状態のあとに、Hyperliquid側で open_interest_usd が減りやすいか、funding_rate が弱まりやすいか、volume_24h_usd に変化が出るかを確認します。
今回のデータでは、このレジームが最も多く出ていました。
contraction_coverage_deteriorating: 107
供給縮小側に偏っていた今回の期間では、このレジームと contraction_coverage_improving が中心になっています。
mixed_unclear
上の4つに分類できない行は、mixed_unclear としました。
主な理由は次の通りです。
usde_supply_diff_24obs が欠損しているcoverage_proxy_ratio_diff_24obs が欠損しているsupply_state または coverage_state が unknown / flat になっている
今回のデータでは、mixed_unclear は24行でした。
mixed_unclear: 24
これは、24観測差分を作るための先頭24観測欠損に由来していました。
後半に mixed_unclear が散発しているわけではありませんでした。
そのため、現時点ではデータjoinやstate生成が壊れているというより、24obs差分の仕様通りの欠損として扱っています。
4分類の整理
4つの初期レジームを表にすると、次のようになります。
| Ethena初期レジーム | USDe supply | coverage proxy | 条件 |
|---|---|---|---|
expansion_coverage_improving | 増加 | 改善 | usde_supply_diff_24obs > 0 かつ coverage_proxy_ratio_diff_24obs > 0 |
expansion_coverage_deteriorating | 増加 | 悪化 | usde_supply_diff_24obs > 0 かつ coverage_proxy_ratio_diff_24obs < 0 |
contraction_coverage_improving | 減少 | 改善 | usde_supply_diff_24obs < 0 かつ coverage_proxy_ratio_diff_24obs > 0 |
contraction_coverage_deteriorating | 減少 | 悪化 | usde_supply_diff_24obs < 0 かつ coverage_proxy_ratio_diff_24obs < 0 |
この4分類は、Ethena側の状態を切るための初期ラベルです。
今回の目的は、このラベルごとにHyperliquid側の open_interest_usd、funding_rate、volume_24h_usd の変化が違うかを見ることです。
今後の確認対象は、主に次の問いです。
expansion_coverage_improving の後に、HL側のOIやVolumeは増えやすいかexpansion_coverage_deteriorating は、他のexpansion系とFundingやVolumeの反応が違うかcontraction_coverage_improving と contraction_coverage_deteriorating で、HL側のOI / Funding / Volumeに差があるか
価格方向は主対象ではありません。
価格は参考値として扱います。
8. レジーム品質診断の結果
ethena_regime を作ったあと、そのままHyperliquid側の反応を見るのではなく、まずレジーム分類そのものの品質を確認しました。
ここで確認したかったのは、次の点です。
このラベルが後続分析のグルーピング単位として雑すぎないか符号ベース分類によって短時間でチラつきすぎていないかmixed_unclear が後半にも発生していないかどの入力がレジーム切り替わりの主因になっているか
今回の品質診断では、ethena_regime_labels_latest.csv を使い、レジームごとの件数、run length、transition、sign flip、mixed_unclear の発生状況を確認しました。
レジーム件数
診断時点のデータは、2026-04-20T05:11:15Z から 2026-04-29T05:20:45Z までの223行でした。
レジーム件数は次の通りです。
contraction_coverage_deteriorating: 107contraction_coverage_improving: 69mixed_unclear: 24expansion_coverage_improving: 14expansion_coverage_deteriorating: 9
今回のデータ期間では、contraction 系が多く出ています。
つまり、USDe supply は24観測前比較で減少している時間帯が多かった、ということです。
一方で、expansion 系はまだ少ないです。
expansion_coverage_improving: 14expansion_coverage_deteriorating: 9
このため、現時点で expansion 系の挙動について強く見るにはサンプルが足りません。
追加観測でこの2つの件数が増えるかを確認します。
mixed_unclear の確認
mixed_unclear は24行でした。
mixed_unclear_count: 24mixed_unclear_ratio: 0.108
発生時刻は、2026-04-20T05:11:15Z から 2026-04-20T23:05:24Z まででした。
first_mixed_unclear_timestamp: 2026-04-20T05:11:15Zlast_mixed_unclear_timestamp: 2026-04-20T23:05:24Zonly_initial_missing_block: true
理由はすべて次の通りです。
supply_unknown;coverage_unknown: 24
これは、usde_supply_diff_24obs と coverage_proxy_ratio_diff_24obs を作るための先頭24観測欠損に由来するものです。
後半に mixed_unclear が散発しているわけではありませんでした。
この結果から、少なくとも今回の範囲では、state生成やregime生成が途中で欠損して壊れているわけではないと判断しました。
run length の確認
次に、同じ ethena_regime が連続している区間をrunとして確認しました。
全体のrun診断は次の通りです。
total_runs: 38average_run_length: 5.87 obsmedian_run_length: 3.00 obsmax_run_length: 42 obs
1観測だけで終わるrunもありました。
one_obs_run_count: 8one_obs_run_ratio: 0.211le2_obs_run_count: 15le2_obs_run_ratio: 0.395le3_obs_run_count: 21le3_obs_run_ratio: 0.553
つまり、全runのうち21.1%は1観測だけで終わっています。
2観測以下で終わるrunは39.5%です。
これは、符号ベース分類がある程度チラついていることを示しています。
ただし、中央値は3観測、平均は5.87観測でした。
全体が毎時ランダムに切り替わっている状態ではありません。
レジーム別には、次のような結果でした。
contraction_coverage_deteriorating: runs 17, median 3, mean 6.29, max 42contraction_coverage_improving: runs 17, median 3, mean 4.06, max 12expansion_coverage_deteriorating: runs 2, median 4.5, mean 4.5, max 6expansion_coverage_improving: runs 1, length 14mixed_unclear: runs 1, length 24
contraction_coverage_deteriorating は最大42観測続いています。
一方で、contraction_coverage_improving は最大12観測でした。
今回の期間では、contraction系2レジームの切り替わりを中心に見る必要があります。
transition の確認
レジームの遷移を見ると、最も多かったのは contraction 系2レジーム間の往復でした。
contraction_coverage_deteriorating -> contraction_coverage_improving: 17contraction_coverage_improving -> contraction_coverage_deteriorating: 16
この往復だけで、transitionの大半を占めています。
これは、USDe supply が supply_contracting のまま、coverage_state だけが coverage_improving と coverage_deteriorating の間で切り替わっている状態を示しています。
つまり、今回のレジーム切り替わりは、supply側ではなくcoverage側で起きている可能性が高いです。
sign flip の確認
その見方は、sign flip diagnostics でも確認できました。
supply_diff_sign_flip_count: 1coverage_diff_sign_flip_count: 36
usde_supply_diff_24obs の符号反転は1回だけでした。
一方で、coverage_proxy_ratio_diff_24obs の符号反転は36回でした。
regime変化の原因を分けると、次のようになりました。
supply_only: 0coverage_only: 35both: 1unknown_or_missing: 1
つまり、レジーム変化の主因はほぼ coverage_state 側でした。
これは、現在の ethena_regime が、今回のデータ期間においては主に coverage_proxy_ratio_diff_24obs の符号変化によって動いていることを示しています。
この結果は、今後の観測で確認したい点を明確にしました。
coverage_state のチラつきが一時的なものか追加観測後も coverage_only 遷移が多いままかcoverage_proxy_ratio_diff_24obs に neutral / 最小変化幅を入れる必要があるか
現時点の判定
今回のレジーム品質診断は、Green / Yellow / Red の3段階で見ることにしました。
ここでの意味は次の通りです。
Green: このまま追加観測へ進めるYellow: 注意付きで追加観測へ進める 追加観測後に同じ診断を再実行し、必要なら定義修正を検討するRed: 追加観測前に state / regime 定義を修正する
今回の結果は、Yellow寄りと判断しました。
理由は次の通りです。
Redではない理由: mixed_unclear が先頭欠損に限定されている median run length が1ではなく3 average run length が5.87 obsある データ生成やjoinが壊れている様子はないGreenではない理由: 1 obs run ratio が21.1% <=2 obs run ratio が39.5% coverage_only 遷移が35回 contraction系2レジームの往復が多い
つまり、定義は壊れていません。
ただし、coverage側の符号反転でレジームがややチラついています。
そのため、今すぐ coverage_state に閾値やneutral状態を入れるのではなく、まずはこの定義のまま追加観測に載せる方針にしました。
次に確認すること
この品質診断を踏まえて、次は1週間ほど追加観測します。
追加観測中に見る点は次の通りです。
regime label が最新データまで更新されているかmixed_unclear が先頭24観測以外で増えないかcoverage_only 遷移が引き続き多いかshort run比率が悪化しないかexpansion系レジームのサンプルが増えるか
1週間後に、同じ report_ethena_regime_quality.py を再実行します。
その結果で、次のどちらへ進むかを判断します。
このまま regime別 Hyperliquid OI / Funding / Volume response inventory に進むcoverage_state に neutral / 最小変化幅を入れる
ここでの判断材料は、追加観測後のrun length、transition、sign flip、mixed_unclear の発生状況です。
9. 定期実行と morning-check への組み込み
最後に、今回追加した state / regime label 生成を定期実行に組み込みました。
ここまでの作業で、以下のファイルが生成されるようになっています。
ethena_state_labels_latest.csvethena_regime_labels_latest.csv
ethena_state_labels_latest.csv には、supply_state、coverage_state、state_reason が入ります。
ethena_regime_labels_latest.csv には、ethena_regime と regime_reason が入ります。
今回見たいのは、Ethena側の状態ラベルが1週間の追加観測中に壊れずに更新されるかです。
そのため、手動実行だけではなく、既存の定期実行フローにも state / regime label 生成を追加しました。
run_all.py に state / regime label 生成を追加
既存の run_all.py は、もともと次の流れで動いていました。
collect_ethenacollect_hyperliquidnormalize_databuild_featuresevent_study
今回、ここに以下の2ステップを追加しました。
ethena_state_labelsethena_regime_labels
これにより、定期実行のたびに次の流れになります。
collect_ethenacollect_hyperliquidnormalize_databuild_featuresethena_state_labelsethena_regime_labelsevent_study
この段階では、report_ethena_regime_quality.py は run_all.py に入れていません。
理由は、品質診断レポートを毎時更新する必要はないためです。
今回の追加観測では、毎回必要なのは state / regime label の更新です。
品質診断は、1週間後に手動で再実行します。
check_status.py に確認項目を追加
次に、既存の稼働状況チェックコマンドでも、今回追加した state / regime label を確認できるようにしました。
普段使っているコマンドはこれです。
make morning-check
このコマンドで、以下のファイル存在確認が出るようになりました。
- ethena_state_labels_latest.csv: ok- ethena_regime_labels_latest.csv: ok
さらに、行数も確認できます。
- ethena_state_label_rows: 226- ethena_regime_label_rows: 226
この時点で、state label と regime label が生成されているかは確認できます。
ただし、最初の表示では、追加観測中に見たい情報が少し埋もれていました。
そこで、check_status.py に専用の監視セクションを追加しました。
ethena regime monitoring セクション
追加後の make morning-check では、次のセクションが出るようになりました。
[status] ethena regime monitoring- regime_label_fresh: True- regime_label_lag_minutes: 0.1- latest_ethena_regime: contraction_coverage_improving- mixed_unclear_count: 24- mixed_unclear_ratio: 0.106- mixed_unclear_latest_timestamp: 2026-04-20T23:05:24Z- initial_mixed_unclear_block_count: 24- mixed_unclear_after_initial_block: False- regime_monitoring_status: ok
ここで見たいのは、主に以下です。
regime_label_freshregime_label_lag_minuteslatest_ethena_regimemixed_unclear_countmixed_unclear_after_initial_blockregime_monitoring_status
それぞれの意味は次の通りです。
regime_label_fresh: 最新観測に対してregime labelが更新されているかregime_label_lag_minutes: 最新観測時刻と最新regime label時刻の差latest_ethena_regime: 最新時点のEthena初期レジームmixed_unclear_count: mixed_unclear の総数mixed_unclear_after_initial_block: 先頭24観測欠損以外で mixed_unclear が発生しているかregime_monitoring_status: regime label更新と mixed_unclear 状態の簡易ステータス
今回の確認では、次の状態でした。
regime_label_fresh: Trueregime_label_lag_minutes: 0.1latest_ethena_regime: contraction_coverage_improvingmixed_unclear_count: 24mixed_unclear_after_initial_block: Falseregime_monitoring_status: ok
つまり、state / regime label は最新観測に追随しており、mixed_unclear も先頭24観測由来のまま増えていませんでした。
morning-check で見るべき項目
今後1週間の追加観測中は、毎回すべての出力を細かく見る必要はありません。
主に見るのは、次のセクションです。
[status] ethena regime monitoring
ここで、以下が維持されているかを確認します。
regime_label_fresh: Trueregime_label_lag_minutes が大きくなっていないmixed_unclear_after_initial_block: Falseregime_monitoring_status: ok
この4点が維持されていれば、追加観測中のラベル生成はひとまず正常に動いていると見ます。
逆に、次のような状態になった場合は確認が必要です。
regime_label_fresh: Falseregime_label_lag_minutes が大きいmixed_unclear_after_initial_block: Trueregime_monitoring_status が ok ではない
この場合、定期実行・feature生成・state生成・regime生成のどこかで止まっている可能性があります。
現時点の実行状況
直近の make morning-check では、以下のように確認できました。
[status] files- normalized_metrics_latest.csv: ok- feature_metrics_latest.csv: ok- ethena_state_labels_latest.csv: ok- ethena_regime_labels_latest.csv: ok- shock_events_latest.csv: ok- event_study_results_latest.csv: ok
行数も更新されています。
- ethena_state_label_rows: 226- ethena_regime_label_rows: 226
最新時刻も、Ethenaの最新観測とregime labelが揃っています。
latest_observed_at_by_source: ethena: 2026-04-29T07:55:40Z hyperliquid: 2026-04-29T07:55:43Zlatest_state_label_timestamp: 2026-04-29T07:55:40Zlatest_regime_label_timestamp: 2026-04-29T07:55:40Z
この状態で、追加観測に入れる前提は整いました。
ここから1週間の扱い
ここからは、今の定義を変更せずに1週間ほど追加観測します。
見る対象は、まだHyperliquid側の反応ではありません。
まずは、Ethena側の初期レジームが追加データでも壊れずに生成されるかを確認します。
1週間後に、次のスクリプトを再実行します。
python yield-observer/scripts/report_ethena_regime_quality.py --db yield-observer/observer.db
そこで再確認するのは、以下です。
regime分布が大きく崩れていないかmixed_unclear が先頭欠損以外で増えていないかrun length が維持されているかcoverage_only 遷移が相変わらず多いかexpansion系レジームのサンプルが増えているか
その結果を見て、次に進む方向を決めます。
候補は大きく2つです。
1. 現在の初期レジーム定義のまま、Hyperliquid側の OI / Funding / Volume response inventory に進む2. coverage_state に neutral / 最小変化幅を入れるなど、state定義を修正する
現時点では、後者を先に決めません。
まずは、現在の定義のまま追加観測し、同じ品質診断を再実行します。
10. 次に確認すること
今回の作業で、Ethena側の初期レジームを定義し、定期実行にも組み込みました。
次にやることは、すぐにHyperliquid側の反応を見ることではありません。
まずは、現在のレジーム定義をそのまま1週間ほど追加観測に載せます。
ここで確認するのは、主に次の点です。
1. regime label が定期実行で更新され続けるか2. mixed_unclear が先頭24観測欠損以外で増えないか3. coverage_state のチラつきが追加データでも続くか4. expansion系レジームのサンプルが増えるか5. 1週間後に同じ品質診断を再実行して、レジーム定義を維持するか修正するか判断する
まず見るのは morning-check
追加観測中は、make morning-check で状態を確認します。
見る箇所は、主にこのセクションです。
[status] ethena regime monitoring
ここで確認する項目は次の通りです。
regime_label_freshregime_label_lag_minuteslatest_ethena_regimemixed_unclear_countmixed_unclear_after_initial_blockregime_monitoring_status
現時点では、次のように出ています。
regime_label_fresh: Trueregime_label_lag_minutes: 0.1latest_ethena_regime: contraction_coverage_improvingmixed_unclear_count: 24mixed_unclear_after_initial_block: Falseregime_monitoring_status: ok
この状態であれば、regime label は最新データに追随しており、mixed_unclear も先頭24観測欠損由来のまま増えていません。
追加観測中に見るべき異常は、次のようなものです。
regime_label_fresh: Falseregime_label_lag_minutes が大きくなるmixed_unclear_after_initial_block: Trueregime_monitoring_status が ok ではない
これらが出た場合は、収集、feature生成、state生成、regime生成のどこかを確認します。
1週間後に再実行する品質診断
1週間ほど追加観測したら、同じ品質診断を再実行します。
実行するコマンドは次です。
python yield-observer/scripts/report_ethena_regime_quality.py --db yield-observer/observer.db
ここで見るのは、前回と同じです。
regime countsrun lengthshort run ratiotransition matrixsign flip diagnosticsmixed_unclear diagnostics
特に確認したいのは、以下です。
mixed_unclear が後半に増えていないか1 obs / <=2 obs run 比率が悪化していないかcoverage_only 遷移が引き続き多いかcontraction系2レジームの往復が続いているかexpansion系レジームのサンプルが増えているか
今回の品質診断では、coverage_proxy_ratio_diff_24obs の符号反転が多く、レジーム変化の主因はほぼcoverage側でした。
supply_diff_sign_flip_count: 1coverage_diff_sign_flip_count: 36regime_change_cause_counts: supply_only: 0 coverage_only: 35 both: 1 unknown_or_missing: 1
追加観測後も同じ傾向が続く場合、coverage_state が符号ベースでは敏感すぎる可能性があります。
その場合は、次に coverage_state へ neutral / 最小変化幅を入れるか検討します。
追加観測後の分岐
1週間後の再診断後、判断は大きく2つです。
A. 現在のレジーム定義を維持して、HL response inventory に進むB. coverage_state の定義を修正する
Aに進む条件は、現在の定義が追加データでも極端に崩れていない場合です。
具体的には、
mixed_unclear が先頭欠損以外で増えていないrun length が極端に短くなっていないshort run ratio が悪化していないcoverage_only 遷移が許容できる範囲に収まっているexpansion系サンプルが多少増えている
この場合、次に見るのは、レジーム別のHyperliquid側の反応です。
regime別 Hyperliquid OI / Funding / Volume response inventory
ここで見る対象は、あくまで次の3つです。
open_interest_usdfunding_ratevolume_24h_usd
価格方向は参考値として扱います。
Bに進む条件は、追加観測後もチラつきが強い場合です。
たとえば、
1 obs run が多い<=2 obs run 比率が高いcoverage_only 遷移が多すぎるtransition がゼロ近辺の coverage diff 符号反転に集中している
この場合は、coverage_state に neutral / 最小変化幅を入れる候補を検討します。
ただし、その場合もいきなり最適化はしません。
まずは、どの程度の小さなdiffがレジーム切り替えを起こしているかを確認し、閾値候補を診断します。
supply shock の扱い
供給ショックは、このまま完全に捨てるわけではありません。
ただし、主トリガーではなく補助タグとして扱います。
現時点での整理は次の通りです。
主軸: ethena_regime = supply_state × coverage_state補助タグ: supply_zscore_extreme supply_expansion_6h / 24h supply_contraction_6h / 24h
供給ショック単体では安定した反応が見えませんでした。
そのため、今後は単独イベントとしてではなく、レジーム条件と重ねて見る候補として残します。
たとえば、今後見るとしたら、
contraction_coverage_deteriorating の中でも supply_zscore_extreme が出ている時だけHL側が動くかexpansion_coverage_improving の中で supply_expansion_24h が強い時にOIが増えやすいか
のような形です。
ただし、これはまだ先の段階です。
まずはEthenaレジームそのものが追加観測でも使えるかを確認します。
次の分析で見る問い
追加観測後にレジーム定義を維持できると判断した場合、次に見る問いは次のようになります。
expansion_coverage_improving のあと、HLのOIやVolumeは増えやすいかexpansion_coverage_deteriorating は、expansion_coverage_improving と比べてFundingやVolumeの反応が違うかcontraction_coverage_improving と contraction_coverage_deteriorating で、HL側のOI / Funding / Volumeに差があるか
ここでいう「〜のあと」は、Ethena側がそのレジームに分類された時刻を基準に、その後のHyperliquid側の変化を見るという意味です。
対象はBTC/ETHのHyperliquid perpです。
見る指標は、
open_interest_usd: 未決済建玉のUSD換算値funding_rate: perp市場の資金調達率volume_24h_usd: 直近24時間の取引量
です。
volume_24h_usd は24h rolling指標なので、短期イベント反応というより、市場活動量の参考指標として扱います。
今後の進め方
次の1週間は、定義を変更しません。
やることはシンプルです。
定期実行を回すmorning-check で regime monitoring を確認するmixed_unclear が増えていないか見るregime label が最新データに追随しているか見る1週間後に regime quality diagnostics を再実行する
その結果を見て、次のどちらかを選びます。
レジーム定義を維持してHL response inventoryへ進むcoverage_stateの定義を修正して再観測する
今日の作業では、供給ショック単体からEthenaレジーム観測へ軸を移し、そのための定義・実装・監視導線を作りました。
次は、定義を変えずに追加データを貯め、同じ診断を再実行します。
まとめ
今日は、DeFi研究におけるEthena × Hyperliquid の観測軸を整理しました。
これまで見ていた usde_supply_zscore_24obs ベースの供給ショックは、実際の供給増減そのものではなく、24観測窓内での相対的な極端値でした。既存データでは、供給ショック単体でHyperliquid側の価格やOIに安定した反応が出ているとは言いにくかったため、主軸を supply shock から supply × coverage proxy の初期レジームへ移しました。
今回定義したEthena初期レジームは、次の4つです。
expansion_coverage_improving expansion_coverage_deteriorating contraction_coverage_improving contraction_coverage_deteriorating
これらは、USDe supply の24観測変化方向と、coverage_proxy_ratio = collateral_total_backing_usd / usde_supply の24観測変化方向を組み合わせた機械的な分類です。
品質診断では、mixed_unclear は先頭24観測欠損に限定されており、データ生成やjoinが壊れている様子はありませんでした。一方で、レジーム切り替わりの主因はほぼ coverage_state 側であり、coverage_proxy_ratio_diff_24obs の符号反転によるチラつきは残っています。
このため、現時点の判断はYellow寄りです。
定義は壊れていないが、強い分析に進む前に追加観測で同じ品質診断を再実行する、という扱いです。
次の1週間は、今回の定義を変更せずに定期実行へ載せます。make morning-check では、ethena regime monitoring を確認し、regime label の更新遅れや mixed_unclear の後半発生がないかを見ます。
1週間後に report_ethena_regime_quality.py を再実行し、レジーム分布、run length、coverage_only 遷移、mixed_unclear の発生状況を確認します。その結果を見て、現在のレジーム定義のままHyperliquid側の OI / Funding / Volume response inventory へ進むか、先に coverage_state に neutral / 最小変化幅を入れるかを判断します。