HyperCore is Hyperliquid's onchain perpetual order book and onchain spot order book: 2 books whose matching, margin, cancels, trades, and liquidations sit in the same HyperBFT-committed list, with one-block finality. A venue that matches offchain still shows bids and asks in the interface while the matcher runs on a private server, then writes settlement later.
Independent coverage of that split is that on most venues, on-chain means settlement is recorded on a ledger while matching happens off-chain on a private server (source: Bitsgap, HyperCore explained). HyperCore puts the book itself in chain state, so a fill is the committed write. How Hyperliquid works covers HyperCore and HyperEVM at hub level, and matching, margin, and finality are the rest of this book's job.
What HyperCore is
HyperCore is the onchain trading environment that holds those two books, one perpetual book and one spot book. Each asset has its own book in chain state. A fill, a cancel, and a liquidation are the same class of HyperCore action: they enter one committed list under HyperBFT, which is Hyperliquid's consensus, the process that agrees on one order of transactions.
| Onchain HyperCore | Offchain matcher | |
|---|---|---|
| Book location | Chain state | Private server |
| Fill | Committed list | Later settlement |
| Cancel vs new GTC | Cancels sort first | Operator policy |
| Margin check | On open and on match | Often internal |
The generic picture of bids and asks is in what an order book is. HyperCore's claim is the location of the match: chain state, with one-block finality from HyperBFT. A CEX-looking price-time book and a fully onchain matcher are the same product.
How matching runs inside a Hyperliquid block
Matching on HyperCore is a price-time central limit book in chain state. Best price fills first, and at one price the earlier rest fills first. Hyperliquid's trading note describes that book as working in essentially the same way as centralized exchanges, with the match itself fully on-chain (source: Hyperliquid Docs, Trading order book).
HyperCore state includes an order book for each asset. Orders match in price-time priority. Margin checks run when a new order opens, and again for the resting side at each match, so a bid that passed the open check can still fail later if oracle prices have moved. The mempool and consensus logic are semantically aware of transactions that interact with HyperCore order books. Within each consensus batch, actions sort as non-GTC and non-IOC actions 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 (source: Hyperliquid Docs, HyperCore order book). 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.
That batch sort sits on top of ordinary price-time. Price-time still decides who is filled at a given level once those orders are actually on the book. The Hyperliquid-specific layer is the order of operations inside the batch. Trader-facing order types, queue position as a tactic, and live throughput figures sit in how the Hyperliquid book works for a trader. The engine fact to keep is the order of operations inside the batch.
Modifies are classified according to the new order they place, so a reshape that re-enters as GTC is sorted with the new GTC group. Cancel-before-GTC protection needs a cancel. A modify is a different classification from a cancel.
Suppose you rest a GTC bid, then send a cancel in the same consensus batch as a taker's new GTC. Cancels sort before that new GTC is even eligible, so the resting bid can be gone before the aggressive order is processed. The cancel won the batch category. If matching ran on a private server, that cancel would be a message to an operator. Here it is a HyperCore action in the same committed list as the taker's GTC.
Gasless book flow and trading fees
Book flow on HyperCore is gasless in the sense the native-token spec describes for initialized ledgers. That is a separate fact from a zero trading fee. The official schedule still posts taker and maker rates on a rolling 14-day volume, so a fill can skip network gas and still cost a trading fee.
The HIP-1 spec is the sentence that keeps the two bills apart. "Further trades and transfers to initialized ledgers are gas free within the standard Hyperliquid fill rate conditions." (source: HIP-1: Native token standard) The docs state that gaslessness. They do not give a causal story beyond stating it, so there is no extra signed-transaction theory to glue on.
Fees are based on your rolling 14 day volume and are assessed at the end of each day in UTC. Base perpetual taker at tier 0 is 0.045% on that table, with a separate spot schedule, and HIP-3 perps sit in the same user tier, with no second global rate card (source: Hyperliquid Docs, Fees). Independent coverage restates the same split: HyperCore offers gasless trading, so you pay trading fees, not network gas fees (source: CoinGecko Learn, Hyperliquid bridges).
A HyperEVM contract call still burns HYPE as gas. A deposit onto Hyperliquid still pays source-chain gas. Neither of those bills is the HyperCore trading fee, and the trading fee is not erased because the book action did not consume HYPE as gas. If you are comparing venues, CEX versus DEX fee and custody shapes is the generic frame. The HyperCore-specific fact is only this: gasless book flow and a posted taker schedule are both on the record at once.
Network gas for initialized book flow can be zero under the spec, and the trading fee is still the trading fee.
How margin and liquidations run on HyperCore
Margin and liquidations on HyperCore are the same class of chain action as the order itself. The perps clearinghouse is execution state, and a breach of maintenance is first sent to the book as a market order. The clearinghouse is the component that tracks perps margin state for each address, including balance and positions.
Deposits are first credited to cross margin. Isolated margin is supported as a way to ring-fence one position's liquidation from the rest. Spot has a parallel clearinghouse for balances and holds (source: Hyperliquid Docs, Clearinghouse). A HyperCore account is therefore not one pile: perps margin, spot tokens, and later a staking account are different ledgers on the same book environment.
Maintenance is a published ratio. The maintenance margin is currently set to half of the initial margin at max leverage. Max leverage depends on the asset. Isolated positions use the same maintenance logic on that position's own margin and notional, while cross looks at account value against total open notional (source: Hyperliquid Docs, Margining). That ratio is a protocol setting, not BloFin's HYPEUSDT listing.
When account equity drops below maintenance, positions are first attempted to be entirely closed by sending market orders to the book. Unlike CEXs there is no clearance fee on liquidations. Max leverage on that path varies from 3-40x depending on the asset (source: Hyperliquid Docs, Liquidations). If that 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 inside HLP, Hyperliquid's protocol liquidity vault. Mark price, not a single instantaneous book price, is what that path uses. Funding, mark, and isolated versus cross as trading concepts are in perpetuals versus futures. Those checks sit onchain, in HyperCore.
An order lives on the per-asset book. A cancel is the same book, earlier in the batch. A trade is a fill on that book. A liquidation is a market order onto that book. Ordinary account hygiene, including securing a crypto account, still applies, because an onchain path is not a safety rating.
Suppose maintenance breaks on a perp you are holding. The first close attempt is a market order onto the same book that matched your GTC. If that close gets you back above maintenance, remaining collateral stays with you. If equity keeps falling through two-thirds of maintenance, the backstop path moves the position into the liquidator vault. HyperCore names book-first liquidation as protocol logic.
What one-block finality means for a fill
One-block finality here means a committed fill, cancel, or liquidation is already in HyperBFT's one order of transactions. A hosted matcher can still reshuffle an acknowledged fill before settlement. HyperCore's fill is already in the committed list. Throughput and co-located latency figures on the overview page move with the software, so they are measurements, not consensus constants.
A core design principle is full decentralization with one consistent order of transactions achieved through HyperBFT consensus (source: Hyperliquid Docs, HyperCore overview). Live order-rate and co-located latency figures on that overview are measurements that move, so they stay dated or they belong with the trader-facing book and with HyperBFT depth.
Finality in this sense is the committed list the matching engine already ran. An offchain matcher can acknowledge your order, match it internally, and still leave settlement as a later write. HyperCore's fill is the write. HyperBFT internals, validator operations, and live latency methodology are a different job than this book's finality claim, and they sit downstream of the architecture hub.
The book can feel like a centralized exchange in price-time terms, and the fill can still be chain state at the next committed block. That is the same comparative axis, now applied to time. If a fill is in the committed list, reversing it is a chain question, not a customer-support credit.
How HIP-3 builder perps use this book
Builder-deployed HIP-3 perps inherit this HyperCore book. They share the same trading-action surface as validator-operated perps. The lockup, the slash, and the 183-day floor belong with the HIP-3 product, not with matching mechanics.
What they inherit is margining, order books, cancel sort, and book-first liquidations. The API to trade HIP-3 perps is unified with other HyperCore actions (source: HIP-3: Builder-deployed perpetuals). A builder listing can still be its own dex with independent margining, which means a blow-up on that dex is not automatically the same margin account as validator-operated BTC. Inheritance is the engine. Independence is the listing. The unified API is the practical tell: the same cancel-before-GTC sort and the same book-first liquidation path apply, so you are not learning a second matcher when the ticker looks exotic.
Suppose you see a metal perp or a custom index. The exotic part is who listed it and who posted the oracle. The familiar part is this book: price-time matching, the same batch sort, and book-first liquidation. The product that secures that listing, including the current official 500,000 HYPE mainnet stake and the spec's expected-to-decrease hedge, is HIP-3 builder-deployed perps. HIP-3 is permissionless listing on HyperCore.
HyperCore vs HyperEVM
HyperCore is the book environment. HyperEVM is the contract environment. Both read the same committed list. A contract on HyperEVM can observe latest HyperCore state when its block is built, and that is shared state, not a second chain.
Read precompiles exist so an EVM call can query perps positions, spot balances, vault equity, staking delegations, oracle prices, and the L1 block number. The values are guaranteed to match the latest HyperCore state at the time the EVM block is constructed (source: Hyperliquid Docs, Interacting with HyperCore). That sentence is a consistency guarantee at block-construction time. It is not a claim that a HyperEVM send is a HyperCore order, and it is not the CoreWriter delay the architecture guide already walked. Encoding, precompiles as a developer surface, and dual-block gas limits sit in how the HyperEVM works. How Ethereum smart contracts work is the account-and-map version of the EVM job, which HyperEVM deliberately resembles without turning HyperCore into Solidity.
Suppose you get a book fill, then later call a contract. The fill is a HyperCore action. The call burns HYPE as gas on HyperEVM. Shared state means one committed list and one validator set. It does not mean one balance, and it does not mean the book is an AMM pool hiding inside a contract. If you came for matching, you are still on HyperCore. If you came for a general-purpose contract, you wanted the other environment, with HYPE in the gas tank.
Where HyperCore fits if you already hold HYPE
If you already hold HYPE on BloFin, you are on a centralized listing. HyperCore remains a competing venue, not a product BloFin operates. Weigh that split before you treat a CEX fill as onchain matching.
HyperCore is two onchain books, perp and spot, whose matching is price-time and whose mempool is semantically aware of cancels versus new GTC and IOC. Margin and liquidations are execution state on that same book, with maintenance first closed through the book. One-block finality is HyperBFT's committed list applied to those actions. HIP-3 inherits the book. HyperEVM shares the list and does not replace the matcher.
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. They are not HyperCore fills, they do not run this cancel-before-GTC sort, and they do not use HyperCore's perps clearinghouse. HYPERUSDT on the same venue is Hyperlane, a different listing, so a ticker collision is not a book collision.
You do not need to memorize the batch-sort numbering. You need the location of the engine, the two-line invoice of gasless flow versus a posted taker fee, and the honesty that 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 trader-facing queue and order types, start with the book-for-a-trader guide. If you want a contract, start with HyperEVM and keep HYPE for gas.
Frequently asked questions
If a HyperCore perp is liquidated, does the protocol also take my spot HYPE?
No. A perp book-close or backstop uses perps margin, not the spot clearinghouse's token balances, so spot HYPE can sit untouched while a BTC perp is being closed. That is why a "withdrawal failed" screen is often a wallet that summed the wrong ledger into one number. Moving spot onto perps margin is a deposit-style credit, not an automatic borrow from the spot book. Staking later is a third ledger on the same environment, which is another way a UI can show HYPE while none of it is isolated collateral on the perp that just breached.
If I modify a resting order, does it keep cancel priority in the batch?
No. Modifies are categorized according to the new order they place, so a modify that becomes a GTC or IOC is sorted with those new orders, not with the cancel category. A cancel of the old rest is the action that sits in the cancel bucket. Cancel-before-GTC protection needs a cancel, not a reshape that re-enters as a new GTC in the same batch. Price-time on the book still applies after the batch sort has decided which actions are eligible.
What happens if a book liquidation only partly closes the position?
Positions larger than 100,000 USDC send only 20% as a market liquidation order. After a block where any of that user's positions is partially liquidated, a 30 second cooldown starts, and during that cooldown later market liquidation orders for the same user cover the entire remaining position, not another 20% slice. Under 100,000 USDC that 20% haircut does not apply, so the first book attempt can be the whole position. Testnet uses a 10,000 USDC threshold so the same throttle is easier to hit in testing. This is a size throttle on the book-first pass.
Does HYPE sitting on BloFin count as HIP-3 deployer stake?
No. A CEX HYPE balance cannot be delegated as Hyperliquid deployer collateral and cannot be slashed by Hyperliquid validators for a bad builder oracle. Listing a builder perp is a Hyperliquid staking action on that venue's lockup, not a flag on an exchange instrument ID. Custody on BloFin is still BloFin custody, and the native lockup is still the native lockup.
Do HyperCore prices and sizes have to sit on tick and lot?
Yes. Orders are added where price is an integer multiple of tick size and size is an integer multiple of lot size, which is the same constraint a centralized book uses, except the constraint is enforced in HyperCore state, not in an operator's matching box. That is why an AMM habit of any decimal fails here: the engine will not rest an order between ticks. Lot and tick tables for a given asset move with listings, so read the live increment instead of baking one size as a constant.
When an isolated position is backstop liquidated, does the rest of the account go with it?
No. Isolated backstop transfers that isolated position and its isolated margin to the liquidator and leaves cross margin and other positions untouched. Cross backstop is the wider path: the trader's cross positions and cross margin all move, and if there are no isolated positions left the trader can end up at zero account equity. During backstop, maintenance margin is not returned, because the liquidator vault keeps a buffer so those takeovers stay profitable on average.
Where does backstop liquidation profit go on HyperCore?
Into HLP's liquidator-vault strategy, which the docs describe as a community pnl stream, not an exchange-operator account. On most venues that backstop profit stays with the operator or with privileged market makers who internalize the flow, and HyperCore routes that stream into HLP instead. None of that is a promise that you keep a profitable residual, and none of it is BloFin absorbing a HyperCore liquidation. Mark-price distance from book price in a spike is still how a maintenance breach can arrive faster than a UI refresh.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated August 2026. Primary sources include the Hyperliquid documentation on HyperCore, the order book, fees, HIP-1, HIP-3, margining, liquidations, and HyperEVM interaction, plus Bitsgap's HyperCore explainer and CoinGecko Learn. 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.