HyperliquidのPortfolio Margin（BLP）を読み解く
/ 14 min read
Table of Contents
調査時点: 2026-08-14（JST）
根拠の扱い: 本稿では、Hyperliquid公式Docsで直接確認できる仕様と、
hl-nodeをradare2で静的解析して確認した実装語彙を分けて記す。後者は、実行時の到達性や計算式を証明するものではない。
Hyperliquidの無期限先物に関して「BLP」と呼ばれることがある機能の公式名称は、**Portfolio Margin（PM）**である。PMは、spotとcross marginのperpを同じアカウント内でまとめて評価し、資本効率を高める仕組みだ。
ただし、これは担保を増やさず無制限にレバレッジを上げられる機能ではない。担保価格、LTV、借入・供給cap、借入利息、perpのmaintenance marginが、ひとつのポートフォリオの状態として相互に作用する。本稿はその境界と、静的解析でどこまで確認できるかを整理する。
概要（TL;DR）
- PMでは、spot残高とcross margin perpポジションを一体で証拠金評価する。sub-accountはPMでも別々に扱われ、isolatedポジションは統合対象ではない。公式Portfolio Margin仕様
- HYPEとBTCは公式Docs上でLTV 50%の適格担保である。残高が不足した注文では自動借入が起こり得るが、借入残高はPM内の取引にしか使えず、capや利息の制約を受ける。Portfolio Margin FAQ
- 清算リスクはPortfolio Margin Ratio（PMR）で評価される。公式Docsには
> 0.95と≥ 95%の両方の表記があるため、本稿では95%を危険域として扱い、境界値をハードコードしない。 hl-nodeにはUserPortfolioMarginActionやuserSetAbstractionなどの語彙が存在する。しかし、strip済みバイナリの静的解析だけでは、PMRの計算経路、HTTP handler、署名・L1実行までを断定できない。
BLPは何を指すのか
PMはcross marginをspotへ拡張する、と捉えると分かりやすい。通常のcross marginでも、同じmargin poolにあるポジションは担保を共有する。PMではさらに、対象アカウントのspot残高とcross margin perpをまとめて評価する。MarginingとPortfolio Marginを突き合わせると、概念上の違いは次のように整理できる。
| 観点 | 通常のcross margin | Portfolio Margin |
|---|---|---|
| 評価の中心 | cross marginポジションの共通担保 | spot残高とcross margin perpの統合ポートフォリオ |
| DEXをまたぐ扱い | standard abstractionではDEXごとに分かれる | 同じ担保系統のcross marginをまとめて扱う |
| spot残高 | 通常はperpのcross証拠金とは別の扱い | ポートフォリオの担保・損益評価に含まれる |
| isolatedポジション | cross poolから分離される | PMの統合評価にも含めない |
PMは「ウォレット内の全資産を何でも相殺する」意味ではない。sub-accountはPMでも別々に扱われるため、master accountの担保が暗黙にsub-accountへ流用されるわけではない。また、すべてのHIP-3 DEXはPMの枠組みに含まれる一方、すべてのHIP-3担保資産がborrowableとは限らない。公式仕様
HyperliquidのAccount abstraction modesでは、PMは「最も資本効率が高い」モードとして説明されている。これは効率の説明であって、リスクが小さいという意味ではない。以降の借入とPMRを同時に見る必要がある。
担保・自動借入・carry trade
LTVが作る買付余力
PMでは適格担保にLTV（Loan-to-Value）が設定される。公式Docs上ではHYPEとBTCはいずれも50%であり、spotまたはperpの注文で残高が不足すると、次の上限まで自動借入が行われ得る。Portfolio Margin FAQ
borrowable_amount = token_balance × borrow_oracle_price × LTVたとえばHYPEを10,000枚、価格を40 USDC、LTVを50%と置くと、説明上の借入可能額は200,000 USDCとなる。
10,000 × 40 × 0.5 = 200,000 USDCこれは注文可能額の保証ではない。既存の借入、health factor、perpのmaintenance requirement、oracle価格、borrow/supply capが実際の余力を左右する。特に借入残高は、withdrawや別アカウントへのtransferに使える自由なUSDCではなく、PM内でspot/perpを取引するための購買力である。
capと利息は「借りられる」こととは別の制約
借入・供給にはglobal capとuser capがある。borrow capが埋まる、または既存の供給がすべて貸し出されると、PMの自動借入による保護は借入可能額の範囲に制限される。公式FAQは、この場合にmargin用のquote assetを追加する必要があり得ると説明している。
借入には継続的に利息が発生する。反対に、取引に使われていない借入可能資産には利回りが付く仕組みがある。金利、cap、利用率はいずれも変動し得るため、記事中のLTVや式だけから固定的な資本効率を見積もるべきではない。Portfolio Margin
carry tradeでは何が相殺され、何が残るか
PMが想定する代表例のひとつが、spot保有とperp shortを組み合わせるcarry tradeだ。
spot: +1 BTCperp: -1 BTC-USDC--------------------価格方向のPnLは概ね相殺残る要素: funding、借入利息、basis、oracle、PMRspotとperpの価格方向のPnLは、PMの会計上で相殺される。しかし、funding、borrow interest、spot/perp間の価格差、oracleの更新順序は残る。たとえば担保価値が上がる局面でも、perp側の損失や追加取引のために借入が増えればPMRが悪化し得る。「hedgeされているから清算されない」とは言えない、というのが重要な点だ。公式のcarry trade説明
PMRと清算
PMRは、PMアカウント全体の清算リスクを表す比率である。公式仕様では、borrowable tokenごとのmaintenance requirementとliquidation valueの比率のうち最大のものとして定義される。
portfolio_margin_ratio = max_borrowable_token( portfolio_maintenance_requirement(token) / portfolio_liquidation_value(token) )分子には、DEXごとのcross maintenance marginと借入に対応する要求額が含まれる。分母には、ポートフォリオ残高とLTV・capを反映した担保価値が入る。さらにborrow_oracle_priceは、spot、perp mark、perp oracleなどを組み合わせた値として公式ページに定義される。単一のspot価格だけからPMRを正確に再現できるとは限らない。PMRの公式式
PMRを悪化させる代表的な要因として、公式FAQは次を挙げる。
- perpポジションのunrealized negative PnL
- spot担保価格の下落
- available balanceのwithdrawまたはtransfer
- outstanding borrowへの利息の累積
清算可能となる境界について、公式PMページではportfolio_margin_ratio > 0.95、FAQのadvanced technical detailsではPMR ≥ 95%と書かれている。FAQ内にもPMR > 95%という表記があり、表現は一様ではない。したがって、実装上の境界をこの記事だけから断定せず、95%を危険域として余裕を持って監視するのが妥当だろう。
また、清算域に入った後は、oracle price updateの順序によってperpポジションとspot collateralのどちらが先に処理されるかが変わり得る。清算順序を決定的なシナリオとして期待しないことも、公式Docsが明記する重要な前提である。Portfolio Margin FAQ
hl-nodeの静的解析で分かること／分からないこと
ここからは静的解析で確認した範囲である。対象はstrip済みのRust製hl-nodeバイナリで、radare2による文字列、section、限定的な逆アセンブルを確認した。大規模なstrip済みバイナリでは、型名や文字列が見つかっても、対応する処理全体を復元できるとは限らない。
| 観測したもの | 静的解析で言えること | 言えないこと |
|---|---|---|
UserPortfolioMarginAction、UserSetAbstractionAction |
PM・account abstractionに関わる型/serialization語彙がバイナリに含まれる | どのHTTP requestやstate transitionがその型を使うか |
userPortfolioMargin、userSetAbstraction、agentSetAbstraction |
action tagのliteralが実行コードからunnamed helperへ渡される断片がある | 署名、/exchange送信、L1 action、CoreWriterとの対応 |
Use market orders to repay borrows when portfolio health would fall below LTV |
borrow healthとLTVに関連するユーザー向け文言が存在する | 発火条件、閾値、呼出し元、実行時到達性 |
| PM関連のfield/type語彙 | portfolioMarginEnabledやportfolioMarginRatioの名前を含むデータモデル語彙がある |
PMRの数式、計算順、現在のmainnetパラメータ |
この表が示すのは「実装語彙と、文字列を扱うコード断片の存在」までである。完全解析が時間内に完走しないほど大規模で、関数名もstripされている。文字列が.rodataにある、あるいはpointer/lengthとしてhelperへ渡されることから、HTTP handler、内部state、清算request、CoreWriterの実行経路までを逆算することはできない。
逆に言えば、公式Docsは外部仕様を示し、静的解析は関連する実装語彙が実際のバイナリに含まれることを補助的に示す。両者は役割が異なる。公式仕様をバイナリ文字列だけで再証明した、とも、バイナリの存在だけで現在のmainnet挙動を確定した、とも扱わない。
運用前の確認リスト
以下は取引判断を示すものではなく、PMを理解・監視する際の確認観点である。
- アカウントの境界: master accountとsub-account、crossとisolatedを混同していないか。
- 有効化条件: FAQでは、有効化前にopen position、open order、active TWAP orderがないことを求めている。account value上限はPMページとFAQで異なる記載があるため、固定値として実装しない。
- 借入の用途: borrowable balanceをwithdraw/transfer可能な残高と見なしていないか。
- capと利用率: global/user cap、borrow capの利用率、供給がすべて貸し出されている状態を確認しているか。
- PMRと利息: unrealized PnL、担保価格、借入利息を別々ではなく、同じポートフォリオのリスク要因として見ているか。
- 仕様の更新: LTV、cap、金利、API表示は変更され得る。実際に利用する時点の公式DocsとUI/APIを確認しているか。
参考資料と免責
- Portfolio margin — Hyperliquid Docs
- Portfolio margin FAQ — Hyperliquid Docs
- Margining — Hyperliquid Docs
- Account abstraction modes — Hyperliquid Docs
本稿は、特定の取引、借入、レバレッジ、清算回避を推奨するものではない。Hyperliquidの仕様、LTV、cap、金利、API、実装は更新され得る。実際の利用前には、対象時点の公式Docsと表示されるアカウント状態を確認してほしい。