Inside Hyperliquid's HLP Vault: How It Actually Earns Yield
How Hyperliquid's HLP vault turns liquidation absorption and market-making spread into yield — and the tail risk depositors rarely see coming.
{"excerpt":"How Hyperliquid's HLP vault turns liquidation absorption and market-making spread into yield — and the tail risk depositors rarely see coming.","tags":["Hyperliquid","HLP vault","DeFi yield","perpetuals","market making"],"cover":"orbit","content":"HLP stands for Hyperliquidity Provider, and despite the name most people find it through, it's not a yield farm. It's the balance sheet that Hyperliquid's perpetuals exchange leans on whenever the order book can't absorb a liquidation cleanly. Deposit into HLP and you're not staking a token or providing a stablecoin pair — you're underwriting the exchange's own risk engine, and getting paid a variable cut of its trading PnL for doing it.\n\nThat distinction matters because it changes what kind of returns to expect and what kind of drawdowns are possible. This piece walks through the actual mechanics: where the money comes from, what happens during a liquidation cascade, and a real incident that shows the tail risk most explainers skip past.\n\n## What HLP actually does\n\nHyperliquid runs a fully on-chain central limit order book (HyperCore) rather than an AMM. Someone still has to quote both sides of that book and someone still has to take over positions when a trader gets liquidated and the market can't fill the closing order at a fair price. On most centralized exchanges that's an internal desk plus an insurance fund. On Hyperliquid, that role is HLP — a protocol-owned vault, funded by depositors, that runs two jobs simultaneously:\n\n1. Passive market making — HLP posts resting bids and asks across a big chunk of Hyperliquid's perp markets, capturing spread and maker rebates the way any professional quoting desk does.\n2. Liquidation backstop — when a trader's margin ratio breaches maintenance and the liquidation engine can't close the position through normal order flow fast enough, the remaining size gets assigned to HLP at the bankruptcy price (or the best available price on the book), not at a price HLP chose.\n\nThat second job is the part depositors underprice. You're not just providing liquidity, you're the counterparty of last resort for every over-leveraged trader on the exchange, at the exact moment the market is moving hardest against them. If you already run automated inventory strategies, this is structurally the same problem our Hyperliquid market maker builds solve for private desks — except HLP does it at protocol scale with other people's capital.\n\n## Where the yield actually comes from\n\nHLP's PnL is the sum of a few streams, and they don't all move in the same direction:\n\n- Spread capture — the bid-ask edge on resting quotes across dozens of markets, compounding continuously.\n- Maker rebates and fee share — a slice of taker fees routed back to the vault for providing depth.\n- Funding payments — HLP inherits whatever funding exposure its net positions carry, which can be a tailwind or a drag depending on which side it's stuck holding.\n- Liquidation absorption PnL — this is the volatile one. Sometimes HLP inherits a position near the mark price and closes it out for a small profit over the next few minutes. Sometimes it inherits a position deep underwater, in a market that's still moving, and has to eat the slippage getting flat.\n\nThe first three streams are steady, low-variance income, similar in character to what a market-making desk generates on any venue. The fourth is where the real variance — and the real yield premium — lives. Depositors are effectively selling insurance against violent, correlated liquidation events, and the premium for that shows up as smoother-than-expected APY in calm markets and sharp drawdowns in volatile ones.\n\n### A worked example\n\nSay a trader is 20x long ETH-PERP with $50,000 of margin, controlling roughly $1,000,000 of notional. ETH drops 5% in a fast move. Their margin ratio breaches maintenance, and the liquidation engine starts closing the position on the book. In a liquid market, most of that $1,000,000 gets absorbed by other resting orders and arbitrageurs within seconds — HLP might only inherit the last $150,000 of size that couldn't get filled at a reasonable price, and it closes that out a few ticks worse than the mark, a manageable, almost mechanical cost.\n\nNow run the same scenario in a thin, low-cap perp market during a coordinated move. There's no depth behind the liquidation, so HLP doesn't inherit $150,000 of a well-understood asset — it inherits the entire remaining position, in a market still moving against it, with no natural buyers on the other side. That gap between "HLP absorbs the tail end of an orderly liquidation" and "HLP becomes the entire other side of a squeeze" is the whole risk model in one sentence. It's the same asymmetry that separates a well-tuned liquidation bot service from a naive one — sizing and market depth determine whether you're picking up scraps or holding the bag.\n\n## The risk depositors don't price in\n\nIn March 2025, a trader opened a large short on JELLYJELLY, a low-liquidity meme perp, then coordinated spot buying to spike the underlying price and force their own short into liquidation. Because the market was thin, HLP inherited the resulting short position rather than an orderly partial fill. As JELLYJELLY kept climbing, HLP's unrealized loss on that single inherited position reportedly pushed past $10 million — a meaningful hit to a vault meant to be diversified across the whole exchange. Hyperliquid's validators intervened, delisted the market, and settled the position, which capped the damage but also showed that the backstop's tail risk isn't purely market risk — it's exploitable through low-liquidity listings, and the fix required off-book governance action, not code.\n\nThat's the structural lesson: HLP's risk isn't evenly spread across "crypto goes up or down." It's concentrated in whichever market has the thinnest book and the most exploitable liquidation mechanics at any given moment, which is a very different risk profile than it looks like from the APY number alone. It's worth reading how this compares to GMX's GLP model, which faces a similar counterparty-of-last-resort problem but with AMM-style pricing instead of an order book, and to dYdX v4's insurance fund design, which caps its own exposure very differently.\n\n## Lockups and correlation risk\n\nHLP deposits aren't instantly liquid — withdrawals queue and settle after a lockup window, which is standard for a vault that needs to hold positions through volatility rather than get run on mid-crisis. The catch is that every depositor shares the same book at the same time. There's no way to be exposed to "just the calm markets" — if HLP is on the wrong side of a squeeze in one obscure perp, every depositor's share value moves, regardless of which market they thought they were funding. Anyone building on top of Hyperliquid's execution layer, whether that's HyperCore or HyperEVM, should treat HLP the same way: as protocol infrastructure with real tail exposure, not a stablecoin-adjacent yield product.\n\nIf you're weighing whether to run your own quoting and liquidation-absorption logic instead of routing capital through a shared vault, it's worth talking through the tradeoffs with a team that builds this infrastructure for a living — start with our Hyperliquid market maker development service."}
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article