Hyperliquid Portfolio Margin (BLP), explained

As of: 2026-08-14 (JST)

How evidence is handled: this post keeps two things apart — specification that can be confirmed directly in the official Hyperliquid Docs, and implementation vocabulary confirmed by statically analysing hl-node with radare2. The latter does not prove runtime reachability, nor any formula.

The feature people sometimes call “BLP” on Hyperliquid perps has an official name: Portfolio Margin (PM). PM evaluates spot balances and cross margin perps together inside one account, which raises capital efficiency.

What it is not is a way to raise leverage without limit and without adding collateral. Collateral prices, LTV, borrow and supply caps, borrow interest and perp maintenance margin all interact as the state of a single portfolio. This post maps out those boundaries, and how far static analysis can confirm them.

Overview (TL;DR)

• Under PM, spot balances and cross margin perp positions are margined as one unit. Sub-accounts stay separate under PM, and isolated positions are not part of the combined evaluation. Official Portfolio Margin spec
• HYPE and BTC are eligible collateral at LTV 50% in the official Docs. An order that outruns your balance can trigger an automatic borrow, but the borrowed balance is only usable for trading inside PM, and it is subject to caps and interest. Portfolio Margin FAQ
• Liquidation risk is measured by the Portfolio Margin Ratio (PMR). The official Docs write it both as > 0.95 and as ≥ 95%, so this post treats 95% as the danger zone without hard-coding the boundary.
• hl-node contains vocabulary such as UserPortfolioMarginAction and userSetAbstraction. But static analysis of a stripped binary, on its own, cannot establish the PMR computation path, the HTTP handler, or the signing and L1 execution path.

What “BLP” refers to

The easiest way in is to read PM as cross margin extended to spot. Even in ordinary cross margin, positions in the same margin pool share collateral. PM goes further, and evaluates the account’s spot balances together with its cross margin perps. Reading Margining against Portfolio Margin, the conceptual differences line up like this.

PM does not mean “everything in the wallet nets off against everything else”. Sub-accounts stay separate under PM as well, so a master account’s collateral is not implicitly diverted to a sub-account. And while every HIP-3 DEX falls inside the PM framework, not every HIP-3 collateral asset is borrowable. Official spec

In Account abstraction modes, PM is described as the “most capital efficient” mode. That is a statement about efficiency, not a statement that the risk is smaller. Borrowing and PMR, below, have to be read at the same time.

Collateral, automatic borrowing and the carry trade

The buying power LTV creates

Eligible collateral under PM is assigned an LTV (Loan-to-Value). In the official Docs, HYPE and BTC are both 50%, and when a spot or perp order outruns your balance, an automatic borrow can occur up to the following limit. Portfolio Margin FAQ

borrowable_amount = token_balance × borrow_oracle_price × LTV

Put 10,000 HYPE at a price of 40 USDC with an LTV of 50%, for instance, and the borrowable amount comes out, for the sake of illustration, at 200,000 USDC.

10,000 × 40 × 0.5 = 200,000 USDC

This is not a guarantee of how much you can order. Existing borrows, the health factor, perp maintenance requirements, oracle prices and borrow/supply caps all move the real headroom. In particular, a borrowed balance is not free USDC available to withdraw or transfer to another account; it is purchasing power for trading spot and perps inside PM.

Caps and interest are constraints separate from “can I borrow”

Borrowing and supply each have a global cap and a user cap. If the borrow cap fills up, or if the existing supply is all lent out, the protection PM’s automatic borrowing gives you is limited to the borrowable amount. The official FAQ explains that in this case you may need to add quote asset for margin.

Borrowing accrues interest continuously. In the other direction, there is a mechanism by which borrowable assets not being used for trading earn yield. Rates, caps and utilisation can all move, so a fixed capital efficiency should not be estimated from the LTV and the formula in this article alone. Portfolio Margin

In a carry trade, what cancels and what is left

One representative case PM has in mind is the carry trade, combining a spot holding with a perp short.

spot:  +1 BTC
perp:  -1 BTC-USDC
--------------------
directional PnL largely cancels out
what remains: funding, borrow interest, basis, oracle, PMR

The directional PnL of the spot and the perp cancels out in PM’s accounting. What stays behind is funding, borrow interest, the price gap between spot and perp, and the order in which oracles update. Even in a stretch where collateral value is rising, for example, PMR can deteriorate if borrowing grows because of losses on the perp leg or because of additional trades. The important point is that “I am hedged, therefore I will not be liquidated” does not follow. The official carry trade description

PMR and liquidation

PMR is the ratio that expresses liquidation risk for the PM account as a whole. The official spec defines it as the largest, across borrowable tokens, of the ratio between maintenance requirement and liquidation value.

portfolio_margin_ratio
  = max_borrowable_token(
      portfolio_maintenance_requirement(token)
      / portfolio_liquidation_value(token)
    )

The numerator includes per-DEX cross maintenance margin and the requirement corresponding to borrows. The denominator holds collateral value reflecting portfolio balances together with LTV and caps. On top of that, borrow_oracle_price is defined on the official page as a value combining prices such as spot, perp mark and perp oracle. A single spot price is not necessarily enough to reproduce PMR exactly. The official PMR formula

The official FAQ lists these as the typical things that push PMR the wrong way.

• unrealized negative PnL on perp positions
• a fall in the price of spot collateral
• withdrawing or transferring available balance
• interest accumulating on outstanding borrows

On the boundary at which liquidation becomes possible, the official PM page writes portfolio_margin_ratio > 0.95, while the advanced technical details in the FAQ write PMR ≥ 95%. The notation PMR > 95% also appears inside the FAQ, so the wording is not uniform. The reasonable course, then, is not to settle the implemented boundary from this article alone, but to treat 95% as the danger zone and to monitor it with room to spare.

Once inside the liquidation zone, the order of oracle price updates can also change whether the perp position or the spot collateral is processed first. Not expecting the liquidation order to be a deterministic scenario is another important premise the official Docs state explicitly. Portfolio Margin FAQ

What static analysis of hl-node shows, and what it does not

From here on is the range confirmed by static analysis. The subject is the stripped Rust hl-node binary, examined with radare2 for strings, sections and limited disassembly. In a large stripped binary, finding a type name or a string does not mean the whole corresponding routine can be recovered.

What this table shows goes no further than “implementation vocabulary exists, and so do code fragments that handle those strings”. The binary is large enough that a complete analysis did not run to the end within the time available, and function names are stripped as well. From the fact that a string sits in .rodata, or is passed to a helper as a pointer and length, you cannot work backwards to the HTTP handler, internal state, liquidation requests, or CoreWriter’s execution path.

Put the other way round: the official Docs give the external specification, and static analysis supplies supporting evidence that the related implementation vocabulary is actually present in the binary. The two play different roles. This is not the official spec re-proved from binary strings alone, and it is not current mainnet behaviour settled by the mere presence of those strings either.

A checklist before you use it

The list below is not a trading recommendation. It is a set of things to look at when trying to understand and monitor PM.

• Account boundaries: are master account and sub-account, or cross and isolated, being conflated?
• Enablement conditions: the FAQ requires no open positions, no open orders and no active TWAP orders before enabling. The account value cap is written differently on the PM page and in the FAQ, so do not implement it as a fixed value.
• What a borrow is for: is the borrowable balance being treated as a balance that can be withdrawn or transferred?
• Caps and utilisation: are global/user caps, borrow cap utilisation, and the state where supply is fully lent out being checked?
• PMR and interest: are unrealized PnL, collateral prices and borrow interest being read as risk factors of the same portfolio, rather than separately?
• Spec updates: LTV, caps, rates and API display are all subject to change. Are the official Docs and the UI/API being checked as of the moment you actually use it?

References and disclaimer

• Portfolio margin — Hyperliquid Docs
• Portfolio margin FAQ — Hyperliquid Docs
• Margining — Hyperliquid Docs
• Account abstraction modes — Hyperliquid Docs

This post does not recommend any particular trade, borrow, degree of leverage, or way of avoiding liquidation. Hyperliquid’s spec, LTVs, caps, rates, API and implementation are all subject to change. Before actually using it, check the official Docs as of that time and the account state shown to you.