清算指標の使い方

清算指標の符号と分布を読み、よくある二つの読み違いを避けて、戦略に組み込む。

急落のあと、清算履歴に深いマイナスのバーが出た。本当に多くのロングが清算されたのか、それともこの銘柄の数値がもともとマイナス寄りなのか。清算指標は Binance だけを読み、0 も均衡点ではありません。この二点で、そのバーの読み方が決まります。価格帯ごとの清算マップを見ているなら、それは別のモデル推定です。清算マップの読み方を参照してください。

清算指標とは？

清算指標とは、一定期間にショートとロングのどちらが多く強制決済されたかを示す標準化された値で、Binance の公開強制決済フィードだけを使います。清算とは、レバレッジをかけたポジションを取引所が強制的に決済することで、ロングが清算されると売り注文、ショートなら買い注文が出ます。Blave は 5 分ごとに銘柄別の両側の清算数量（コイン数）を合計し、三段階で計算します。

数値に上限・下限はなく、符号がどちら側の清算が多かったかを表します。

分布は非対称で、下側（ロング清算）の裾が上側より深くなります。以下は Blave が Binance の強制決済フィードから独自に計算した分位点です。1 時間足、timeframe 24h、期間 2024-09-15～2026-09-14、1 時間ごとに 1 値（n = 17,520）。

最も重要な二点：Binance のサンプルだけ、0 は均衡ではない

清算指標は Binance だけで、しかもサンプル

清算の概要・履歴とマップページの 24 時間清算バーは、Binance の強制決済フィードだけを使います。Binance は 1 銘柄につき 1 秒最大 1 件しか配信せず、同じ 1 秒の他の清算は送られません。つまりサンプルであり、大きな相場では過小になります。

単位はコイン数なので、銘柄をまたいで生の清算量を比べることはできません。比べるなら標準化後の数値を使います。フィードが止まっている間は、その期間に清算がなかったように見え、欠損は表示されません。

0 は多空の均衡を意味しない

0 より大きければショートの清算がロングより多く、0 より小さければロングの清算が多い状態です。ただし標準化で分子から平均を引かないため、長期的にロングの清算が多い銘柄は数値が系統的にマイナス寄りになり、0 はその銘柄の「普段の水準」ではありません。

上の測定期間（1 時間足、timeframe 24h）で 0 を上回った時間の割合は、上の表のとおりです。同じ 0 でも、BTC ではほぼ中央値ですが、DOGE ではすでに大半の時間よりショート清算寄りです。

清算データで戦略をどう作る？

現在、清算データを使う公式戦略はないため、以下の三つの使い方はすべて例示で、バックテストしていません。コード中のしきい値は上で測定した分位点を出発点として借りたもので、パラメータスキャンの結果ではありません。実際に使う前に必ず自分でバックテストしてください。

1. 非対称なしきい値：清算が集中した期間に印を付ける

最も直接的なのは、数値が分布の両端に入った期間に印を付ける方法です。下側の裾が深いので、両側に同じ絶対値のしきい値を使わないでください。BTC なら p1 は約 −3.8、p99 は約 +3.3 です。

LONG_FLUSH_TH  = -3.8   # 例示：BTC 1h × 24h の p1 付近
SHORT_FLUSH_TH = 3.3    # 例示：BTC 1h × 24h の p99 付近

liq = fetch_liquidation(SYMBOL, INTERVAL, START, END, hdrs, timeframe='24h')
df['LIQ'] = liq['alpha']
long_flush  = df['LIQ'] <= LONG_FLUSH_TH    # ロング清算の集中
short_flush = df['LIQ'] >= SHORT_FLUSH_TH   # ショート清算の集中

印を付けたあとどう取引するかは自分で研究してください。清算が集中したあとに価格が反転するのか継続するのか、Blave は検証していません。分位点は銘柄によっても違い、ETH、SOL、DOGE の p1 はいずれも BTC より深いので、銘柄を変えたら計算し直します。

2. 0 ではなく、その銘柄自身の分位点をしきい値にする

0 は均衡点ではないので、「0 より大きければショート清算が多い」という書き方は、DOGE のように長期的にマイナス寄りの銘柄では歪みます。代わりにその銘柄の過去一定期間の分位点をしきい値にすると、長期的な偏りの影響を受けにくくなります。

# 例示：過去 180 日の分位点をしきい値に。窓の長さはスキャンしていない
lo = df['LIQ'].rolling('180D').quantile(0.01)
hi = df['LIQ'].rolling('180D').quantile(0.99)
extreme = (df['LIQ'] <= lo) | (df['LIQ'] >= hi)

窓が短すぎると、しきい値が最近の相場につられて動きます。また、その銘柄のデータ開始からおおむね 30 日間のウォームアップ期間（BTC、ETH は 2023-01-31 以前）を窓に含めないでください。その期間は標準偏差のサンプルが少なすぎ、見かけの極端値が出ます。

3. リスク管理：清算が集中している間は新規エントリーを控える

より保守的な使い方は、既存戦略のエントリー条件に加えるものです。数値がどちらかの端に入っている間は新規ポジションを持ちません。使い方 1 の二つのしきい値を流用し、compute_entry は元の戦略のエントリー条件に置き換えてください。

# 例示：数値がどちらかの端にあるときはエントリーしない
flush = (df['LIQ'] <= LONG_FLUSH_TH) | (df['LIQ'] >= SHORT_FLUSH_TH)
entry = compute_entry(df) & ~flush

この組み合わせはバックテストしておらず、清算の集中を避けると成績が改善するかも検証していません。「清算の波が来たばかり」を新規エントリーを止める条件にしているだけです。

timeframe と足の周期はどう選ぶ？

清算指標の設定は二つです。timeframe は純清算量を合計する窓で、15min、1h、4h、8h、24h、3d から選べ、既定は 24h。足の周期（period）は値を取る頻度を決め、5min、15min、1h、4h、8h、1d から選べます。数値はいつも 5 分刻みで計算してから、各足の最後の値を取ります。timeframe を変えると分布も変わります。同じ期間を timeframe 1h（1 時間足）で測ると次のとおりです。

24h と比べると、1h は両端が狭く、中央値はどの銘柄も 0.00、0 を上回る割合も半分に近くなります。しきい値は timeframe に合わせて計算し直し、一方の数値をもう一方に流用しないでください。15min、4h、8h、3d は本文では測定していません。

Studio ではどこで見る？

どの指標と組み合わせる？

以下は組み合わせの考え方で、検証済みの結論ではありません。

API や Blave Agent でデータを取るときの注意点は？

清算指標のエンドポイントは GET /liquidation/get_alpha で、パラメータは symbol、period、timeframe（既定 24h）と開始・終了日（start_date、end_date）。Blave Agent では fetch_liquidation に対応します。確定した足だけを返し、項目は timestamp、alpha、stat。1 年を超える期間は自動で短縮されます。データは最も古い銘柄（BTC、ETH）で 2023-01-01 からで、それ以前の値は 0。その他の銘柄はそれより遅いことがあります。30 日標準偏差にはウォームアップが必要なので、意味のある値はデータ開始からおおむね 30 日後以降です（BTC、ETH は 2023-01-31 ごろ）。

get_alpha の stat オブジェクトは最新の値を説明しますが、名前と中身は完全には一致しません。

清算マップ、マップ変化、取引所別集計のエンドポイントとフィールドは清算マップの読み方を参照してください。