Hyperliquid
Hyperliquid connects onchain order books with spot balances and perpetual positions
Updated ยทHyperliquid is a layer 1 blockchain whose trading engine matches spot and perpetual orders and updates account balances and positions. Spot trades exchange assets, while perpetuals create derivative exposure backed by collateral. Submission sends an instruction; fills show execution, while account state records the resulting balances and positions.
Spot purchases and perpetual positions change different balances
A spot purchase credits the purchased asset and spends the quoted asset, with fees affecting the balance changes. A perpetual trade changes a derivatives position. Perpetual contracts have no scheduled expiry and use funding payments to help track their underlying market. Buying a perpetual can open or increase a long position or reduce an existing short. It does not deliver the underlying asset into a spot balance.
The selected market also determines its collateral requirements and trading rules. Builder-deployed perpetual markets use the HyperCore trading infrastructure, while their deployers define contract specifications and operate their price oracles. A familiar asset label does not establish identical collateral, leverage limits, or market operation across contracts.
Available buying power also depends on account mode. Unified accounts combine spot balances with collateral for cross positions denominated in the same asset. Standard accounts keep spot and perpetual balances separate, including separate perpetual exchange balances. Portfolio margin uses eligible assets across a combined portfolio, subject to account eligibility requirements and supply and borrowing caps. Orders can automatically borrow against eligible collateral when the settlement balance is insufficient, and borrowed amounts accrue interest. A total wallet balance therefore does not, by itself, establish capacity for every order.
HyperCore executes trades while HyperEVM supports applications
HyperCore contains the native spot and perpetual order books. HyperEVM provides an Ethereum-compatible environment for smart contracts on the same blockchain. Both share HyperBFT consensus, which determines the agreed transaction history. A wallet interface, an automated trading client, or a supported application can provide access to trading without becoming the matching engine itself.
HYPE also has functions beyond a trading position: it pays HyperEVM gas and supports delegated staking within HyperCore. Staking balances have withdrawal conditions distinct from spendable trading balances. Vault applications provide another participation path, where a contract or authorized trading agent manages activity. Their accounting, permissions, and withdrawal rules require separate attention from an individually placed order.
Order instructions divide price control from execution urgency
A limit order specifies the worst acceptable execution price, while a market order seeks immediate execution against available liquidity. Book depth determines how much can trade at each price. A market order can encounter several price levels, and liquidity constraints can prevent the requested quantity from executing.
Instructions for an unfilled remainder
Orders that may remain on the book
Good til canceled orders can leave an unfilled remainder resting for later execution. Post-only orders must enter as resting liquidity; an order that would immediately match instead fails its post-only condition. These instructions suit different execution intentions even when the chosen limit price initially looks similar.
Orders limited to immediate liquidity
Immediate or cancel orders attempt execution immediately and cancel any unfilled remainder. Partial execution still changes the account.
Instructions tied to a position or trigger
Reduce-only restricts an order to decreasing existing exposure. Stop and take-profit instructions activate under their specified trigger conditions, after which execution still depends on the chosen order form. A trigger reaching its threshold does not establish the final execution price or guarantee a complete fill.
How does an order reach the book?
A client submits a signed trading instruction, and the chain processes it against the selected market and account requirements. The instruction identifies the instrument, side, price, size, and execution options. Prices and quantities must satisfy the market's permitted increments. Perpetual orders also face margin checks before they can open exposure.
HyperCore matches orders using price-time priority. Better-priced orders receive priority, followed by earlier orders at the same price. A submitted instruction therefore does not reserve the liquidity visible when a trader first inspected the book. Other processed orders can change available liquidity before matching occurs.
The clearinghouse maintains perpetual positions and checks collateral. It checks new orders and rechecks the resting side when matching occurs.
Does an accepted order mean a completed trade?
An accepted order may remain open without executing any quantity, so acceptance alone does not establish a completed trade. Trading responses distinguish resting orders, fills, and errors. Even a successful API response can contain an order-level rejection. The relevant result belongs to the individual instruction rather than the connection carrying it.
Open-order records describe outstanding instructions; fill records describe executed trades. A partially filled order can appear in both histories because its executed quantity and remaining quantity have different states. Cancellation ends the remaining instruction without reversing earlier fills. An order identifier connects these records, while the position or balance shows their economic effect.
A missing confirmation leaves execution uncertain. Sending another order before resolving that uncertainty can create additional exposure.
A margin rejection before a smaller retry
Consider a hypothetical attempt to open a perpetual position when the account lacks enough available margin for the requested size. Compare the original order with a smaller order using the same market, side, limit price, and execution instruction. Only the requested quantity changes. The smaller request must still satisfy minimum order size, quantity increments, and the applicable margin rules.
Edit the draft quantity before signing another instruction. Reducing size can lower the margin requirement; it does not guarantee acceptance when other constraints apply. The sequence below assumes the first request received an explicit margin rejection, rather than an ambiguous timeout.
| Stage | Trading action | Observable record | Order conditions and outcomes |
|---|---|---|---|
| Original submission | Request the intended perpetual size | Order response identifies insufficient margin | That request does not open a position |
| Rejection review | Inspect current exposure and usable collateral | Account state establishes available capacity | Confirm the rejection belongs to this request |
| Quantity revision | Edit the draft to a smaller size | The unsigned order retains its other terms | Size must satisfy both margin and market requirements |
| New submission | Sign and submit the revised instruction | A new response reports rejection, resting, or execution | Acceptance still does not guarantee a fill |
| Account reconciliation | Compare fills, remaining orders, and position state | Executed quantity explains the position change | Any unfilled remainder retains its reported status |
| The retry succeeds only to the extent its records confirm execution; another rejection leaves the revised request unexecuted. | |||
This adjustment reduces the requested exposure without transferring additional collateral. Repeatedly submitting the original quantity leaves the missing margin prerequisite unresolved.
Why can account value change after execution?
Account value can change after execution because open perpetual exposure responds to mark prices and can pay or receive funding. Trading fees also affect balances. The execution price records an actual fill; the mark price supports valuation and margin calculations. Those prices serve different purposes and need not match.
Displayed entry price summarizes position history. Increasing a position changes its average entry price, while reducing it leaves the entry price of the remaining position unchanged. Underlying accounting follows trades and margin, or balances for spot. Reconciliation therefore starts with executed size and price, then accounts for fees, transfers, and applicable funding payments. A profit-and-loss display alone does not describe every account movement.
Funding rates concern the cost or receipt associated with holding perpetual exposure. They do not establish whether an order filled.
Cross margin and isolated margin allocate collateral differently
Cross margin shares collateral among the positions covered by the account's margin arrangement. A loss on one position can therefore reduce capacity elsewhere within that arrangement. Isolated margin assigns collateral to a particular position, so its liquidation does not consume collateral allocated to other isolated or cross positions. Some markets permit only isolated margin and restrict collateral removal.
Perpetual positions become subject to liquidation when the applicable account equity falls below maintenance margin. An order's initial acceptance does not protect an open position from later losses. Position size, collateral, mark price, and the applicable margin tier determine the continuing requirement. Larger positions can encounter different leverage constraints, so one leverage ceiling does not describe every trade.
Moving collateral away also faces margin requirements. A displayed balance can include value the account must retain against existing exposure.
Wallet permissions and visible trading history
A signed instruction authorizes an action, while an approved API wallet can sign permitted actions on an account's behalf. The signing wallet and the account holding positions can therefore differ. Account queries need the actual trading account address; querying an agent address can return empty results even when its associated account has activity.
Onchain order and trade records also create privacy consequences. Activity associated with an address remains observable without the owner's real-world name appearing beside it. Publicly connecting an identity to that address can connect it to trading history. This transparency helps inspect execution, but it does not provide anonymity or prevent losses from authorized trading activity.
Resting orders and pooled swaps offer different execution choices
An order book matches explicit bids and offers, which lets a trader leave an instruction at a chosen price. A pooled automated market maker calculates swaps against liquidity supplied to its contracts. Both depend on available liquidity, but their execution records and outstanding commitments differ. A resting order can remain active while waiting for a counterparty; a completed pool swap records an asset exchange.
Within the order book, choosing immediate execution accepts the available liquidity within the order's constraints. Choosing a resting limit order accepts uncertainty about whether and when counterparties will trade. Spot ownership and perpetual exposure then add a separate decision: the former changes asset holdings, while the latter carries continuing margin and funding obligations.
Hyperliquid: questions and answers
Why does a cancellation report that the order is missing?
A cancellation can report a missing order because the order never existed, already filled, or already canceled. The cancellation error alone does not identify which explanation applies. Order history and fill records distinguish these outcomes, especially when matching and cancellation requests occur close together.
Does every limit order receive maker pricing?
A limit order can pay taker fees when it immediately matches resting liquidity. Its remaining quantity can later execute as maker liquidity if it rests first. Fees therefore follow how each fill executes, together with the applicable market schedule and account tier, rather than the limit-order label alone.
Which price activates a take-profit or stop-loss order?
The mark price activates take-profit and stop-loss orders. A last-traded price reaching the same level does not necessarily satisfy that condition. After activation, a limit instruction still needs matching liquidity within its price constraint, while a market instruction remains subject to its execution protection.
Will a time-weighted order always finish its requested quantity?
A time-weighted average price order can finish its scheduled duration without executing the full requested quantity. Its smaller orders face liquidity and slippage constraints. Missed execution can leave it behind schedule, and later attempts to catch up remain constrained rather than guaranteeing completion.
How do attached stop orders behave after a partially filled parent order is canceled?
Manually canceling a partially filled parent order also cancels its attached take-profit and stop-loss orders. Protection for the resulting position therefore requires separate position orders. Cancellation for insufficient margin follows different handling: after a partial fill, the attached orders enter the placement path used when the parent fully fills.
Is HYPE on HyperEVM interchangeable with a HyperCore spot balance?
HYPE balances on HyperEVM and HyperCore occupy different parts of the same blockchain's state. Moving between them requires the supported transfer mechanism, and that transfer incurs gas in HYPE on its originating side. Support for receiving HYPE on one side does not establish support for receiving it on the other.
Why might a reduce-only instruction fail after another trade?
A reduce-only instruction can fail when the resulting account position means it would increase exposure instead of reducing it. An intervening trade may already have reduced, closed, or reversed the position. The remaining position determines whether the instruction still satisfies its reduce-only constraint.
Do browser-based chase orders continue after their tab closes?
Chase orders run in the browser tab where they originate, so closing that tab stops their repricing process. This differs from an ordinary resting order the chain already holds. The status of any last submitted order remains a separate question from whether the browser continues adjusting its price.