The Hyperliquid order book is a per-asset onchain central limit book. Resting orders, fills, cancels, and liquidations are HyperCore actions, and HyperBFT commits each one with one-block finality. Margin is checked twice, on open and on match, so the queue you see is already risk-checked chain state.
A rest sits on one asset's book after the opening margin check, and a fill is a committed match. Inside one consensus batch, cancels sort ahead of new GTC and IOC orders, and if maintenance later breaks, the first close is a market order onto that same book. How Hyperliquid works covers HyperCore and HyperEVM, and the trader-facing path is how those book actions run.
How the Hyperliquid order book works
A central limit order book, or CLOB, is a list of bids and asks at discrete prices, and HyperCore is Hyperliquid's onchain trading environment that keeps one of those books per asset. Matching uses price-time priority: best price first, and at one price the earlier rest first. Independent coverage of that matching claim is that matching happens on-chain, not on a centralized server (source: Stacked Markets, Hyperliquid order book CLOB mechanics). A later architecture write-up states the rule the fill uses: "Orders are matched strictly according to price-time priority" (source: RocknBlock, How Hyperliquid works). The generic picture of bids, asks, and walking the spread is in what an order book is, and Hyperliquid's claim is the location of the match: a committed HyperCore action, with one-block finality from HyperBFT.
How a resting order is added
A resting Hyperliquid order is a limit that survived the open margin check and now sits on that asset's book at a tick and lot the engine will accept. Tick size is the price increment the asset lists, and lot size is the size increment. HyperCore as the onchain book holds those books, so your BTC bid stays on the BTC book after the opening margin check passes. HyperCore stores a rest on the asset it names, which is why a BTC bid stays off the ETH queue.
Margin is tested on open and again on the resting side at each match, because oracle prices can move while the bid sits there. The HyperCore order-book docs say this keeps the margining system consistent despite oracle price fluctuations after the resting order is placed (source: Hyperliquid Docs, HyperCore order book). You can watch a bid as working and still fail a later match if equity no longer covers the rest, because the book re-checks instead of forgetting the rest.
An order is added only where price is an integer multiple of tick size and size is an integer multiple of lot size, so resting between ticks is dropped. Lot and tick tables move with listings, so the live increment is the one that matters.
Isolated versus cross is a rest decision: isolated margin lets you allocate collateral toward one position and keep that liquidation path off the rest of the account. The clearinghouse docs describe this as disassociating the liquidation risk of that position from all other positions (source: Hyperliquid Docs, Clearinghouse). Cross is the default, and a BTC rest in cross shares the same perps margin pile as your other cross perps. Spot balances sit in a parallel clearinghouse, so a spot HYPE rest is separate from BTC perp collateral.
Suppose you have room for a 0.1 BTC bid at a listed tick. The open check consumes initial margin at your chosen leverage, then the bid rests on the BTC book in price-time order behind anyone who arrived earlier at that same price. If the rest failed the margin check, there was no queue position.
How fills match and become final
A fill is a HyperCore match that HyperBFT has already committed. HyperBFT is the consensus that writes HyperCore actions into a block, and best price is filled first, with earlier rests filled first at one price. Your bid is hit when an aggressive sell walks into your level, and that fill is the committed action. HyperBFT consensus is the source of that one-block finality.
Hyperliquid is its own layer 1, so a HyperCore fill is final at the HyperBFT block that committed it, and waiting on an Ethereum explorer is the wrong chain. A HyperEVM contract call is a different action on the same committed list, and it still leaves the book fill on HyperCore rather than turning it into an Ethereum rollup settlement. If you bridged in from Ethereum, that source-chain wait was the deposit.
Book flow on initialized ledgers is gasless in the native-token spec's sense, and that still leaves a trading fee. Fees are based on your rolling 14 day volume and are assessed at the end of each day in UTC (source: Hyperliquid Docs, Fees). A fill can skip network gas and still post a maker or taker rate. A committed fill is chain state, so reversing it is a chain question.
How cancels sort in a batch
A cancel is a book action, and inside one consensus batch it is sorted ahead of new GTC and IOC before the proposer's sequence breaks remaining ties. GTC means good-till-canceled: the order rests until it is filled or canceled. IOC means immediate-or-cancel: any unfilled remainder is dropped at once.
The mempool is semantically aware of HyperCore book actions, which is the Hyperliquid-specific layer on top of ordinary price-time. Within a consensus batch, non-GTC and non-IOC actions go first, then cancels, then actions that send at least one GTC or IOC, and within each category they stay in the order the block proposer sent them.
| Sort in one consensus batch | What lands there |
|---|---|
| Non-GTC and non-IOC actions | First |
| Cancels | Second |
| Actions that send at least one GTC or IOC | Third |
| Ties inside a category | The proposer's sequence |
A cancel can empty a rest before a same-batch GTC is even eligible. Modifies are categorized according to the new order they place, so a reshape that re-enters as GTC is sorted with the new GTC group, and cancel-before-GTC protection needs a cancel. Price-time on the book still applies after the batch sort has decided which actions are eligible.
Self-crossing is its own cancel path: "Trades between the same address cancel the resting order instead of causing a fill" (source: Hyperliquid Docs, Self-trade prevention).
That sort is intra-batch, so if your cancel lands in a later block than the taker's GTC, the resting bid may already have been matched, because across blocks the book is just price-time on whatever is still resting. Same batch versus later block, and cancel versus modify, are the two timings that matter.
Suppose you cancel a resting bid in the same consensus batch as a new GTC: the cancel is eligible first, and a modify that comes back as GTC waits with the GTC group.
Order types the book accepts
The trader-facing types that sit on this book are limit, market, GTC, IOC, and post-only ALO, plus reduce-only as a constraint. Chase and TWAP are extra workflows on top of those primitives, and they leave price-time in place.
A limit executes at the selected limit or better, and a market executes immediately at the current market. GTC is an order that rests on the order book until it is filled or canceled (source: Hyperliquid Docs, Order types). IOC cancels any unfilled remainder at once. Post-only ALO, add-liquidity-only, is added to the book as a resting order only, and reduce-only cuts a current position instead of flipping into the other side.
Stop market, stop limit, take market, and take limit are trigger wrappers that activate when a selected trigger is reached, with long and short trigger sides defined against mid. Attached take-profit and stop-loss on an open position use a different index: the mark price is used to trigger TP/SL orders (source: Hyperliquid Docs, Take profit and stop loss). Scale drops multiple limits across a range, and triggered size still has to clear tick, lot, and margin.
ALO is the maker-intent switch, so if you want to rest and not take, ALO is the instruction that refuses an immediate cross. IOC is the opposite intent: take what is there and drop the rest. GTC is the patient rest, and reduce-only is how you close without accidentally doubling. Mixing them without reading the time-in-force is how a resting order becomes a take, or a close becomes a reverse.
Chase is a post-only limit that re-prices toward the best bid or ask, and the docs are explicit that those orders run in the browser tab where they are created, with a cap of 5 active at once. TWAP, time-weighted average price, slices a larger order across time. Both still resolve into book actions, and they leave price-time in place without a private matching lane.
How liquidation uses the same book
When equity falls through maintenance, the first close attempt is a market order onto the same book, with no CEX-style clearance fee on that pass. Maintenance is currently half of initial at max leverage. Hyperliquid BTC max leverage is 40x as of August 20, 2026, from live metaAndAssetCtxs, and older 50x figures are stale. That 40x is native Hyperliquid BTC, separate from BloFin's HYPEUSDT at 75x. Max leverage depends on the asset, and the liquidations page still frames the published range as 3-40x. A BTC rest at 40x has a different maintenance ratio than a 3x asset, because maintenance is half of initial at that asset's max.
The close uses mark: liquidations use the mark price, which combines external CEX prices with Hyperliquid's book state (source: Hyperliquid Docs, Liquidations). Mark can sit away from the touch during a spike, which is how a maintenance breach can arrive faster than a UI refresh. Funding, mark, and isolated versus cross as trading concepts are in perpetuals versus futures, and those checks still sit onchain, on this book.
Leverage is only checked upon opening a position. Afterwards, the user is responsible for monitoring the leverage usage to avoid liquidation (source: Hyperliquid Docs, Margining). Turning a 40x BTC down to 10x after you are already in leaves the original open check in place. Isolated can add or remove margin after the fact, and cross uses account value against open notional.
If the book close leaves you above maintenance, remaining collateral stays with you. If equity keeps falling through two-thirds of maintenance without a successful book close, a backstop liquidation moves the position into the liquidator vault. Positions larger than 100,000 USDC send only 20% as a market liquidation order. After a block with any partial liquidation for that user, a 30 second cooldown starts, and during that window later market liquidation orders for that user are for the entire position. Positions under 100,000 USDC skip the 20% slice, and ordinary account hygiene, including securing a crypto account, still applies.
The engine that matched your GTC is the engine that will try to close you if maintenance breaks.
Depth, queue, and live throughput
Depth on this venue is still bids and asks at a price, and a large take still walks the book. Liquidity and market depth is the generic frame for how size at a level absorbs a take. A thin level still moves and a thick level still absorbs, and queue position at a price is still time priority among rests that survived the batch sort. The depth you are reading is chain state on a per-asset book.
HIP-2 Hyperliquidity can sit on that same spot USDC book as extra onchain quotes, and it is currently only available on spot pairs against USDC (source: HIP-2: Hyperliquidity). Active makers can sit beside it at any time.
Throughput and co-located latency on the docs are live measurements, not consensus constants, so they belong with a date. As of August 20, 2026 the About page still says HyperCore currently supports 200,000 orders per second, with throughput constantly improving as the software is further optimized (source: Hyperliquid Docs, About Hyperliquid). That is a project measurement, and it is no promise that one rest will clear in a particular number of microseconds.
Co-located latency is the same class of measurement. For an order placed from a geographically co-located client, end-to-end latency has a median 0.2 seconds and 99th percentile 0.9 seconds (source: Hyperliquid Docs, HyperCore overview). End-to-end here is duration between sending the request and receiving the committed response. If you sit outside that co-located setup, that median is someone else's number, and if the software changes next month the figure can move, so date it.
Throughput and latency are article-time, while price-time, cancel-before-GTC, and book-first liquidation are protocol rules until the docs change them.
HIP-3 perps vs HIP-4 outcome books
Builder-deployed HIP-3 perps inherit this matching path, while HIP-4 outcome books merge Yes and No and generalize price-time into price-side-time.
HIP-3 listings still rest, match, cancel, and liquidate on HyperCore. The listing party and the oracle are what change, and the book stays familiar: per-asset price-time, same-batch cancel sort, book-first close. A builder-deployed metal perp still uses this matching path. The stake lockup, the slash, and the 183-day floor belong with HIP-3 builder-deployed perps.
HIP-4 is the book-path exception that still sits on HyperCore. Outcome Yes and No tokens for the same event share liquidity by merging those two books. Under the merged book, price-time priority generalizes to price-side-time priority (source: HIP-4: Outcome markets). At the same merged price, resting sells sort before resting buy duals. Perps and spot stay per-asset, and HIP-4 merges two sides of one outcome. Bounded settlement sits in HIP-4 outcome markets. The docs index still labels HIP-4 deployer actions as testnet-only (source: Hyperliquid Docs, llms.txt).
A perp can still be this book, and a Yes token can be this environment with a different priority rule. The distinction is which book you are actually on.
Where this book sits if you already hold HYPE
If you already hold HYPE on BloFin, you are on a centralized listing. Hyperliquid remains a competing venue, and BloFin operates its own books, so weigh that split before you treat a CEX fill as a HyperCore rest.
A rest is a per-asset HyperCore order that cleared the open margin check and now sits in price-time. A fill is a committed match with one-block finality from HyperBFT. A same-batch cancel can land in an earlier category than a new GTC, and a modify is sorted with the order it becomes. A liquidation starts as a market order onto the same book, on mark, with native BTC max leverage at 40x as of August 20, 2026. HIP-3 inherits the path, HIP-4 merges a different pair of books, and live 200,000 orders per second plus 0.2s / 0.9s co-located latency are dated measurements.
BloFin HYPEUSDT is live at 75x, listed December 19, 2024 11:30 UTC, and HYPE/USDT is live, listed May 30, 2025 13:30 UTC. Those instrument IDs are BloFin ledger lines, so they skip HyperCore fills, this cancel-before-GTC sort, and HyperCore's perps clearinghouse. Native Hyperliquid HYPE perp max leverage was 10x on metaAndAssetCtxs on August 20, 2026. HYPERUSDT on the same venue is Hyperlane, a different listing, so a ticker collision is not a book collision.
Gasless flow still leaves a posted maker or taker fee, and a CEX HYPE listing is a different instrument from this book. If you want the architecture again, start with the parent hub. If you want the environment without the trader path, start with HyperCore. If you want a contract, you wanted HyperEVM, with HYPE as gas.
Frequently asked questions
If my self-cross cancel fired, would I see it in the trade feed or pay a fee?
No. When two sides of the same address would otherwise match, the resting side is canceled with no fee deducted, and that cancel stays out of the trade feed. On many CEXs the same behavior is labeled expire-maker, and your aggressive order can keep walking into liquidity behind the canceled rest, up to your limit, with no self-fill to rebate.
Does a Hyperliquid fill wait for an Ethereum confirmation?
No. Hyperliquid is its own layer 1, so a HyperCore fill is final at the HyperBFT block that committed it, and waiting on an Ethereum explorer is the wrong chain. A HyperEVM contract call is a different action on the same committed list, and it still leaves the book fill on HyperCore rather than turning it into an Ethereum rollup settlement. If you bridged in from Ethereum, that source-chain wait was the deposit.
If I attach TP/SL to a parent GTC that only partly fills, do the children still post?
Only in one case. Take-profit and stop-loss opened from the order form have a fixed size equal to the parent and stay untriggered while that parent is working. Cancel a partly filled parent yourself and the children are fully canceled, so you place new exits on the stub. If the parent is partly filled then canceled for insufficient margin, the children are placed as if fully filled, and full fill at placement posts them immediately. That is the one-cancels-the-other (OCO) rule.
If I raise HIP-2 seeded bid levels, does the token's genesis supply go up?
It goes the other way. Each extra seeded bid level has to be funded with price times size in USDC, and for a fixed number of orders in the range, raising seeded levels cuts Hyperliquidity's genesis supply. The strategy still only quotes HIP-1 spot against USDC, updates on blocks at least 3 seconds apart, and targets a 0.3% spread, with active makers able to sit beside it at any time.
How does a TWAP actually hit this book?
It is sliced into suborders. Official intervals are a minimum of 30 seconds, each suborder is capped at 3% slippage, running time can be set from 5 minutes to 7 days, and the docs put a 100 USD minimum on total order size. A 10,000 USD order over 1 hour is their worked split into about 121 suborders of about 83 USD every 30 seconds, and if too many slices miss because the spread is wide, the TWAP can finish short of the full size.
Is BloFin's 75x HYPE listing the same as Hyperliquid HYPE leverage?
No. BloFin HYPEUSDT is a CEX instrument at 75x. Native Hyperliquid HYPE perp max leverage was 10x on metaAndAssetCtxs on August 20, 2026, and native BTC was 40x. A BloFin HYPE fill skips this book's cancel sort and book-first liquidation. HYPERUSDT on BloFin is Hyperlane, a different listing, so buying HYPER leaves you off the Hyperliquid HYPE book.
If the book-first close fails, does auto-deleveraging take the other side?
Auto-deleveraging is the solvency backstop after book-first and after the liquidator vault. If account value or isolated position value goes negative, opposite-side users are ranked by unrealized pnl and leverage used, and those positions are closed at the previous mark against the underwater account so the platform has no bad debt. Backstop-liquidated positions have no special treatment in that queue, and a trader with no open positions stays outside that socialization under that invariant.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated August 2026. Primary sources include the Hyperliquid documentation on the HyperCore order book, order types, fees, margining, liquidations, HIP-4, and self-trade prevention, plus Stacked Markets' CLOB mechanics note and RocknBlock's architecture write-up. Protocol facts independently verified against cited sources current as of August 2026.
This article is educational and general in nature, not financial or investment advice. Cryptocurrencies like HYPE carry real risks, including price volatility, liquidation, venue risk, and the chance of losing funds. Nothing here is a recommendation to buy, sell, hold, or trade on HyperCore or on BloFin. Do your own research, and consider speaking with a licensed professional before making financial decisions. BloFin does not provide investment advice.