Hyperliquid matches spot and perpetual orders on its own blockchain

Spot purchases and perpetual positions change different account records

A spot trade exchanges assets, while a perpetual trade changes a derivative position backed by collateral. Perpetual futures provide long or short exposure without an expiry date. Holding that exposure involves margin requirements and funding payments. A spot purchase and a perpetual long therefore create different obligations, even when both concern the same underlying asset. HyperCore provides order books for both forms of trading.

The instruction also determines which execution conditions matter. A limit order permits execution at its stated price or better. An immediate-or-cancel instruction cancels any quantity that cannot execute immediately. A good-til-canceled order can leave a remainder on the book. Selecting a limit price controls acceptable execution prices; it does not establish when another order will match.

Does an accepted order mean the trade has finished?

An accepted order can rest on the book without executing any of its requested quantity. The exchange response distinguishes resting orders, fills and errors within the returned order results. An application must inspect those results rather than treating a successful request response as proof of execution. A resting response includes an order identifier; a filled response includes executed size and average price.

View image file

Order status and fill history answer different questions. Status describes the order’s condition. Fills record the trades that occurred, including execution price and size. A canceled order can still have earlier fills.

Price priority meets margin checks inside HyperCore

HyperCore matches orders using price-time priority. Better-priced orders receive priority, followed by earlier orders at the same price. Each market also specifies permitted price and size increments. An order must respect these increments before its position in the queue matters. Displayed liquidity describes the book at a particular moment; competing orders and cancellations can change it before another instruction executes.

Perpetual orders also interact with the clearinghouse, which manages positions and margin checks. The protocol checks margin when opening an order and checks the resting side again during matching. A previously accepted order can therefore fail a later margin check. Oracle price changes can alter account conditions while an order waits. Price compatibility alone does not establish that both sides remain eligible to trade.

A limit order moves from submission to a recorded position

Consider an account with sufficient eligible collateral and no position in its selected perpetual market. The holder wants to open a position while retaining control over any unfilled remainder. The account’s margin mode and the market’s permitted order increments establish the prerequisites.

The holder submits a good-til-canceled limit order with a chosen direction, size and price. Compatible liquidity can fill it immediately; otherwise, eligible quantity can rest on the book. The response reports the initial outcome.

Stage	Protocol action	Observable record	Execution boundary
Submission	Evaluates the signed order	Submitted direction, size and limit price	Acceptance does not guarantee a fill
Matching	Executes eligible quantity against compatible orders	Fill price and executed size	Liquidity and margin constrain execution
Account update	Records the position resulting from execution	Position size and account state	An unfilled remainder may still be open

If only part executes, the account holds a position while the remaining order can still trade. Until cancellation takes effect, another fill can increase the position; there is no fixed cancellation deadline for this good-til-canceled order.

A cancellation request addresses the unfilled remainder. It cannot erase an earlier fill.

View image file

Completion requires checking the final order status, accumulated fills and resulting position together. If the remainder is canceled, the filled position remains. An absent open order alone cannot distinguish a complete fill from cancellation.

Balances reflect more than the execution price

Price times executed size gives the trade’s notional value. The resulting account balance also depends on its starting balance, fees and position accounting. Maker and taker treatment depends on how an order executes. Spot and perpetual trades have separate fee schedules, while account activity and applicable discounts affect the rate. An order’s chosen label alone does not establish every fee that its fills incur.

Perpetual funding payments pass between the long and short sides of a contract. Funding affects the cost of holding a position separately from execution fees. Changes in unrealized profit or loss also affect account equity while a position remains open. Consequently, a later account value need not equal the value immediately after the trade.

Fill records identify executed quantity, price and charged fees. Position records describe the remaining exposure. Match the account and market across these records, then interpret balances according to the account mode. Standard mode separates spot and perpetual balances. Unified account and portfolio margin can use eligible spot balances as perpetual collateral.

Margin mode determines which collateral supports a position

Cross margin shares collateral across eligible positions; isolated margin assigns collateral to an individual position. The sharing boundary depends on account mode and collateral compatibility, especially across multiple perpetual exchanges. Some markets restrict the available margin modes. A position becomes subject to liquidation when its supporting equity falls below maintenance requirements. Completing an opening trade therefore begins an ongoing collateral obligation. Isolating margin limits which collateral supports that position; it does not prevent liquidation.

HyperEVM adds smart contracts alongside the trading engine

HyperCore actions inherit one-block finality from HyperBFT consensus. That describes finalization after inclusion, without promising a submission-to-fill duration. HyperEVM runs smart contracts within the same blockchain, with HYPE serving as its native gas token. Contract execution and order-book matching remain distinct operations. Their shared consensus does not establish the safety of every application or guarantee liquidity for every order.

View image file