Hyperliquid Leverage: Margin Tiers, Cross vs Isolated, and Liquidation Mechanics

Scope and the direct answer

On Hyperliquid, leverage is a per-position setting bounded by two things: the maximum leverage configured for that perpetual market, and the margin tier that applies to your notional position value. You can set leverage to any integer from 1 up to the market maximum, but the maximum itself is tiered — larger positions are pushed into lower-leverage tiers with higher maintenance margin requirements. There is no single 'Hyperliquid leverage' figure; figures like 40x or 50x that circulate online refer to specific markets at specific position sizes, and they change as tiers and listings change.

This article covers the mechanism (initial margin, maintenance margin, tiers), the difference between cross and isolated margin, and a runnable procedure for verifying limits and liquidation distance against live protocol data. It does not recommend a leverage level; sizing is your risk decision.

• Leverage setting: integer from 1 to the market's max leverage.
• Max leverage: depends on the asset and on the notional tier your position falls into.
• Maintenance margin: derived from the tier's maintenance margin rate, not from your chosen leverage.
• Cross vs isolated: changes which collateral can absorb losses and when liquidation fires.

Assumptions and prerequisites

The procedure below assumes you have a Hyperliquid account funded with USDC, a way to call the public info endpoint (any HTTP client works), and basic familiarity with perpetual futures terminology. You do not need an API key to read market metadata; you do need to treat any endpoint URL as configuration rather than something hard-coded, because public endpoints and rate limits vary by provider.

If you are choosing an RPC or API provider for a trading bot rather than reading metadata manually, the concrete endpoint decision belongs in RPC Assistant — see the guidance on the best Hyperliquid RPC provider and low-latency trading endpoints. This page stays on the protocol mechanics.

Mental model: initial margin, maintenance margin, and tiers

Initial margin is what you must post to open a position at your chosen leverage: at L-times leverage, initial margin is roughly notional divided by L. Maintenance margin is the minimum equity you must retain; if equity falls below it, the position becomes liquidatable. The two are not symmetric, and the gap between them is your buffer.

Hyperliquid uses a tiered maintenance margin formula of the form maintenance_margin = notional_position_value × maintenance_margin_rate − maintenance_deduction. The maintenance margin rate at a tier is half the initial margin rate implied by that tier's maximum leverage — for example, a tier capped at 20x implies a 5% initial margin rate and a 2.5% maintenance margin rate. The maintenance deduction exists so that total maintenance margin is continuous as position size crosses tier boundaries: each new tier adds margin at its own rate rather than retroactively repricing the whole position.

The practical consequence: as your notional grows, the maximum leverage available to you falls, and your maintenance requirement rises faster than a flat percentage would suggest. A position that is comfortable at one size can be pushed into a stricter tier by adding size alone, with no price move.

• Tier 0 has zero maintenance deduction.
• Each subsequent tier's deduction accounts for the lower rates applied to earlier tiers.
• Margin tables have IDs; for IDs below 50 the table is a single tier whose max leverage equals the ID.
• Maintenance margin rate depends on the tier, not on the asset — the asset determines which table applies.

Reading authoritative leverage limits from the info endpoint

The margin tier tables and per-asset maximum leverage are published in the protocol's meta info response, so you should read them rather than rely on third-party summaries. The following curl call fetches perpetual market metadata; substitute your provider's endpoint for RPC_URL. The response includes each asset's name, size decimals, and max leverage, plus margin table identifiers you can cross-reference against the published tier tables.

Run this before sizing any position, and re-run it after listings change. Treat the output as the source of truth for the market you are about to trade.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"type":"meta"}' \
  | python3 -c "import sys,json; d=json.load(sys.stdin); [print(a['name'], a.get('maxLeverage'), a.get('marginTableId')) for a in d['universe']]"

Expected verification result

A successful call returns a JSON object with a universe array. Each entry should show an asset name, a maxLeverage value, and a marginTableId where applicable. If maxLeverage is missing for an asset, that asset is likely delisted or not a perpetual — check the isDelisted flag before trading it.

Record the maxLeverage for your target market and the marginTableId. Then look up that table's tiers in the published margin tier documentation. Your effective maximum leverage is the max leverage of the tier your intended notional falls into, which may be lower than the headline maxLeverage for the asset.

• Asset present, maxLeverage numeric: market is live and the headline cap is known.
• marginTableId present: tiered schedule applies; check notional bands.
• isDelisted true: do not size a position against stale metadata.

Cross margin vs isolated margin and what each does to liquidation

In cross margin, your entire account equity backs your positions. Losses on one position can draw on collateral that would otherwise support another, which lowers the chance of a single-position liquidation but raises the chance that one bad position affects the whole account. In isolated margin, each position is assigned its own collateral; a liquidation is confined to that position's margin, and the rest of the account is insulated.

Liquidation price is therefore a function of margin mode, not just leverage. Under isolated margin, the liquidation price is driven by the position's own maintenance requirement and assigned collateral. Under cross margin, it depends on total account equity relative to aggregate maintenance margin, so adding an unrelated position can move your liquidation price even if the first position's size and entry are unchanged.

A useful diagnostic is to compute the distance from mark price to liquidation price as a percentage, then compare that to the market's recent volatility. A 2% buffer is not equivalent across assets.

• Isolated: liquidation contained to the position; simpler to reason about per-trade risk.
• Cross: capital-efficient but account-wide contagion; liquidation depends on aggregate equity.
• Switching modes changes liquidation price without changing entry price or size.

Computing effective leverage and liquidation distance in code

The following Python snippet reads your clearinghouse state and computes effective leverage and a rough liquidation distance per position. It uses placeholders for the endpoint and account address; it does not place orders. Effective leverage here is position notional divided by the margin actually committed, which can differ from the leverage integer you set because of unrealized PnL and fees.

Run it against a paper or small account first. The output is a diagnostic, not a guarantee: liquidation price also depends on funding accrual and on the exchange's liquidation engine behavior.

import json, urllib.request

RPC_URL = "RPC_URL"
ACCOUNT = "0xYOUR_ACCOUNT_ADDRESS"

req = urllib.request.Request(
    RPC_URL,
    data=json.dumps({"type": "clearinghouseState", "user": ACCOUNT}).encode(),
    headers={"Content-Type": "application/json"},
)
state = json.load(urllib.request.urlopen(req))

for p in state.get("assetPositions", []):
    pos = p["position"]
    szi = float(pos["szi"])
    entry = float(pos["entryPx"])
    liq = pos.get("liquidationPx")
    margin = float(pos["marginUsed"])
    notional = abs(szi) * entry
    eff_lev = notional / margin if margin else float("inf")
    dist = (abs(float(liq) - entry) / entry * 100) if liq else None
    print(pos["coin"], f"eff_lev={eff_lev:.2f}x", f"liq_dist={dist:.2f}%" if dist else "liq=n/a")

Diagnostic procedure and results table

Use this procedure to compare candidate position sizes before opening them. It produces a table you fill with values you actually observe; do not copy numbers from any article, including this one, because tiers and prices change.

Step 1: fetch meta and record maxLeverage and marginTableId for the market. Step 2: look up the tier band that contains your intended notional and record that tier's max leverage. Step 3: choose a leverage integer at or below that tier maximum. Step 4: compute initial margin as notional divided by chosen leverage. Step 5: compute maintenance margin using the tier formula. Step 6: compute the adverse price move that would take equity to maintenance margin. Step 7: repeat for one size up and one size down to see where tier boundaries bite.

Record results in a table like the one below. The columns are fixed; the values are yours to measure.

• | Market | Intended notional (USDC) | Tier max leverage | Chosen leverage | Initial margin | Maintenance margin | Adverse move to liquidation |
• | BTC | (measured) | (from meta + tiers) | (1..tier max) | notional / leverage | tier formula | (measured) |
• | ETH | (measured) | (from meta + tiers) | (1..tier max) | notional / leverage | tier formula | (measured) |

Troubleshooting common leverage and margin problems

Most leverage surprises on Hyperliquid come from four sources: stale metadata, tier boundaries, margin mode changes, and funding accrual. Work through them in that order.

If your order is rejected for insufficient margin, re-fetch meta and confirm the market's current max leverage and your tier — a listing update or a size increase can lower the cap. If your liquidation price looks wrong, confirm whether the position is cross or isolated; switching modes recomputes it. If your effective leverage drifts from your setting, check unrealized PnL and fees, which change margin used without changing position size. If a position liquidates earlier than your calculation predicted, check funding payments between your calculation and the event.

• Re-fetch meta after any listing or tier change.
• Confirm margin mode before comparing liquidation prices across sessions.
• Account for funding in multi-day holds.
• Verify the marginTableId maps to the tier table you used.

Limitations and tradeoffs

Tiered leverage protects the protocol but complicates position sizing: the leverage available to you is a function of size, so scaling in can silently reduce your maximum allowable leverage and raise your maintenance requirement. Cross margin is capital-efficient but makes account-level risk harder to isolate. Isolated margin is easier to reason about but ties up collateral per position.

The formulas here describe documented protocol behavior; they do not model liquidation engine details, insurance fund interactions, or market impact during fast moves. Any measurement you take is a snapshot. For production systems, treat metadata as cacheable but refreshable, and treat liquidation price as an estimate that the exchange computes authoritatively.

If you are building automated trading infrastructure, endpoint reliability and latency matter as much as the margin math. OnFinality's Hyperliquid RPC service and dedicated node options are the places to evaluate that layer; the concrete provider choice is an RPC Assistant question, not a protocol one.

Next steps

Once you can read meta and clearinghouse state reliably, the next useful steps are to automate the tier lookup so your sizing code always uses current limits, to log effective leverage and liquidation distance per fill, and to test margin mode changes on a small account before relying on them.

For the infrastructure side, review the Hyperliquid network page, compare RPC pricing, and read the low-latency trading endpoint guidance before committing a bot to a provider. If you need a dedicated node for consistent throughput, that option exists separately from shared RPC.

• Automate tier lookup in your sizing path.
• Log effective leverage and liquidation distance per position.
• Validate margin mode behavior on a small account.
• Choose infrastructure deliberately: /en/networks, /en/pricing/rpc, /en/dedicated-node.