Hyper liquid is a confirmation-to-fill workflow for checking executed orders

Last updated: 5 Aug 2026

Hyper liquid is a trading interface where the confirmation modal submits your chosen order, while account tables show whether HyperCore filled the submitted order, left a remainder open, or canceled the order. After clicking Place Order and confirming, compare the order's original size with its remaining size, then reconcile Open Orders, Positions, and Trade History. A submitted limit order may rest without a fill; a marketable order may fill immediately; and a partial fill creates both a recorded trade and a smaller open remainder.

In short: A 10 USDC minimum trade still must satisfy the selected market's tick and lot-size precision.

Follow the ticket from market selection to fill evidence

The Hyper liquid order ticket turns a trading intention into five checkable decisions. Each decision should agree with the confirmation modal and the account state that appears afterward.

Establish access and collateral. Use an Ethereum Virtual Machine wallet or email login, complete the 6-digit email code or Enable Trading signature, and confirm spendable collateral. An Arbitrum USDC deposit has a 5 USDC minimum, while the trading minimum is 10 USDC of notional.
Select the intended market. Check the asset ticker and whether the screen shows spot or perpetuals; a BTC perpetual order and a BTC spot order create different account changes.
Choose direction deliberately. Perpetuals present two directional actions, long and short, while spot uses buy and sell. The selected side must match the modal.
Set execution behavior. Pick market, limit, trigger, Scale, or TWAP, then add Reduce Only or a time-in-force rule where the ticket offers it.
Confirm and classify the outcome. Treat Open Orders as evidence of a resting remainder, Trade History as evidence of fills, and Positions or spot balances as evidence of the resulting exposure.

This sequence separates intent, submission, execution, and settlement state. It also catches the common mismatch where the correct size was entered on the wrong side or in the wrong market before confirmation.

Market, limit, and TWAP orders create different next states

Market, limit, and TWAP orders produce different evidence after confirmation because their matching instructions differ. A market order seeks immediate execution, a limit order trades only at its limit price or better, and a TWAP divides the parent size into timed suborders.

Time-in-force adds three durable limit-order behaviors. Good Til Cancel (GTC) permits an unfilled remainder to rest; Add Liquidity Only (ALO), also called post only, cancels rather than crossing immediately; Immediate or Cancel (IOC) removes any portion that does not fill at once. TWAP sends a suborder every 30 seconds, constrains each slice to 3% maximum slippage, and caps a catch-up slice at 3 times the normal suborder size. Therefore, a confirmed TWAP can remain incomplete even after its scheduled course ends.

The confirmation modal is the final specification of asset, direction, order type, size, price logic, and optional controls. Re-read the limit or trigger price, Reduce Only setting, attached take-profit or stop-loss instruction, and the displayed position effect before accepting it.

Price and size precision matter because HyperCore admits orders only on the market's tick and lot grid. HyperCore accepts prices with at most 5 significant figures, while decimal places cannot exceed 6 minus the asset's size decimals for perpetuals or 8 minus them for spot. Integer prices remain valid regardless of significant-figure count, and size must be rounded to the asset's published size decimals. A precision rejection changes no position, even though the user completed the confirmation step.

Accepted, open, and filled are separate order states

HyperCore order status distinguishes successful placement from actual execution. The open state means the order was placed successfully and still has size available; filled means the full executable size completed.

Other states explain why confirmation created no fill. A user cancellation produces canceled, an activated conditional order becomes triggered, and a placement failure becomes rejected. The more specific marginCanceled state means the system lacked sufficient margin when trying to fill. A trigger activation is therefore an intermediate event: the resulting market or limit instruction still needs its own execution evidence.

Reconcile Open Orders, Positions, and Trade History

Open Orders, Positions, and Trade History answer three different fill questions. Open Orders shows unfilled size still resting, Positions shows the net perpetual exposure after executions, and Trade History records the individual fills; spot traders replace the position check with the relevant token and quote balances.

A vanished open-order row alone does not identify the outcome, because a fill, cancellation, or rejection can all remove an order from that view. Match the asset, side, original size, remaining size, and order identifier across the available records. At the data layer, the account key is a 42-character hexadecimal address. The order identifier accepts an unsigned 64-bit value, while an optional client order ID is a 128-bit, 16-byte hexadecimal value. REST, WebSocket, and the official Python SDK expose these fields for automated reconciliation.

Partial fills leave a trade record and an open remainder

A partial fill splits one submitted order into executed size and remaining size. The fill record proves the completed quantity, while Open Orders retains the rest under the same order identity until later matching, cancellation, or its time-in-force rule removes it.

One crossing order may match several resting orders, so Trade History can show multiple rows with different prices for a single submission. Compare the sum of fill sizes with original size minus current remaining size; those quantities should reconcile. The data interface returns at most 2,000 recent fills, while time-bounded fill queries return at most 2,000 records per response and expose only the 10,000 most recent fills. Older high-activity periods therefore require previously stored records rather than a single later query.

How a fill changes a perpetual position

A perpetual fill changes signed position size, margin usage, and the frontend's entry-price calculation. An execution counts as opening when the absolute position grows, including adding long size to a long or short size to a short.

For an opening trade, the displayed entry price becomes a size-weighted average of the existing entry and the new trade price. A closing trade leaves the entry price unchanged while reducing exposure and recording closed profit or loss. Reduce Only constrains an order to shrink an existing position rather than create exposure in the opposite direction. Spot fills follow a simpler balance transition: a buy increases base-asset balance and decreases quote balance, while a sell reverses those movements.

Recover from an Enable Trading or signing loop

An Enable Trading or signing loop blocks submission before HyperCore creates an order, so no fill-state check will find a matching record. The initial Enable Trading action requests a gas-less signature; trading itself does not require an Arbitrum gas payment, although depositing USDC over Arbitrum requires ETH for gas.

Start by updating the wallet extension, then perform a hard refresh with Ctrl+Shift+R on Windows or Cmd+Shift+R on macOS. Disconnect and reconnect the wallet; if the prompt remains stuck, switch the wallet network to Ethereum and then back to Arbitrum before retrying. Rabby, MetaMask, WalletConnect, and Coinbase Wallet are supported onboarding options. Moving the same account to another compatible extension preserves its address, trades, and history, so the verification records remain attached to the account rather than the browser session (see Hyper liquid 101 ).

Edge cases where confirmation produces no fill

Post-confirmation edge cases follow explicit matching and validation rules. An ALO order is rejected when its price would immediately take liquidity, an IOC order cancels its unmatched remainder, and a Reduce Only order is canceled or rejected when it cannot reduce the position.

Self-trade prevention cancels the resting order when the same address would trade against itself; it charges no fee and adds no trade to the public feed. Invalid price precision produces tickRejected, while insufficient trade notional produces minTradeNtlRejected. Conditional orders add another distinction: TradingView chart placement and the ticket use mark price for take-profit and stop-loss triggers, while the eventual fill comes from the order book. Market TP/SL orders use a default 10% slippage tolerance, so trigger price and fill price are separate values.

Within each block, HyperCore sorts actions into 3 groups: actions that do not send GTC or IOC orders, cancellations, and then actions that send at least one GTC or IOC order. That ordering explains why a fast cancellation and a new matching instruction may not resolve in the visual sequence expected from mouse clicks. The durable answer comes from final order status plus recorded fills, not from the confirmation toast.

Questions and answers about Hyper liquid

Can I close the browser after a GTC order appears in Open Orders?

Yes. Once a GTC order appears as open in HyperCore, it rests independently of the browser session until it fills, is canceled, or another rule removes it. Reopening the interface with the same account should restore the order view. Match the order identifier and remaining size before treating a refreshed screen as a new submission.

Does a triggered take-profit or stop-loss status prove the closing trade filled?

No. A triggered status means the mark price activated the take-profit or stop-loss instruction; the resulting market or limit order still has to match against the book. Confirm the closing quantity in Trade History and the reduced exposure in Positions. A trigger price and a fill price describe two separate events.

Which identifier should an automated fill checker store?

Store the protocol order ID and retain the client order ID when one was supplied. The order ID is an unsigned 64-bit value, while the optional client order ID is a 128-bit hexadecimal value. Either can support an order-status query, but keeping both makes it easier to correlate a local submission with HyperCore records.

Why was my post-only order rejected immediately after confirmation?

The ALO price would have matched resting liquidity immediately. Add Liquidity Only orders are allowed to join the book as maker liquidity, so HyperCore rejects an instruction that would cross the spread on arrival. Re-entering the order at a non-marketable limit price lets it rest, although later execution still depends on another order reaching that price.

Can an unmatched IOC remainder stay open?

No. Immediate or Cancel keeps only the quantity that matches immediately and cancels the remainder instead of placing it in Open Orders. A partially matched IOC therefore produces one or more fill records plus a canceled balance. Compare total fill size with the submitted size to determine how much executed before cancellation.

Why is my position size different from the order size I confirmed?

Position size represents net exposure, not a copy of the latest order. A partial fill changes it only by the executed quantity, a closing order offsets existing exposure, and Reduce Only prevents an oversize instruction from opening the opposite side. Reconcile the prior position, fill direction, and cumulative filled size before comparing the final position with the submitted amount.