Hyperliquid
Hyperliquid order acceptance, fills and incomplete trades
Hyperliquid can accept an order that rests on its onchain order book without completing a trade. A fill records executed quantity; acceptance establishes placement in the relevant order state. Resting limit orders can remain open, while immediate-or-cancel orders discard any unfilled remainder. Before submitting a replacement, compare the order status with its fills, remaining quantity and account position. An incomplete trade may require waiting, adjusting the order or reconciling an uncertain response.
· last updated
A successful cancellation removes an order's unfilled remainder, while executed quantity continues to affect the account balance or position.
Market rules determine the account change
The selected market determines whether a fill changes token holdings or a margined position, so completion needs the corresponding account record. A spot order exchanges balances in the market's traded tokens. A perpetual order changes derivative exposure against margin. Its side can open exposure, reduce an existing position or reverse direction if the order permits it. Reduce-only restricts the order to reducing exposure. A position that changes while another order remains open can therefore change whether that outstanding order still qualifies to execute.
Before placement, the signer needs authority for the selected account, which needs sufficient available balance or margin. The order also needs valid price and quantity increments.
Resting, immediate and post-only execution
A good-til-canceled (GTC) limit order can match immediately at its limit price or better, then leave unfilled quantity resting. Resting means the order remains available for later matching. It does not establish a completion time. A limit buy sets the highest acceptable purchase price; a limit sell sets the lowest acceptable sale price.
Immediate or cancel (IOC) allows immediate partial execution and cancels the unfilled remainder. The Python SDK's market-order helpers use aggressive IOC limit orders with a slippage setting. Available liquidity within the permitted prices determines how much it can trade, so a market-order request does not establish that the entire requested quantity executed.
Post-only, also called add liquidity only (ALO), permits execution as a resting order. An order that would immediately match fails that placement condition. This setting suits an order intended to add liquidity, while an IOC order seeks immediate matches.
A time-weighted average price (TWAP) order spreads execution across scheduled suborders. Its remaining target quantity is distinct from a single resting order's remaining quantity. During a network upgrade's post-only phase, market orders and TWAP suborders do not fill, so an otherwise valid immediate execution attempt cannot produce the trades that would otherwise change the account's holdings or position.
Price-time priority and executable liquidity
An accepted order still needs eligible opposing orders, and its place in the matching queue affects which available quantity reaches it. HyperCore matches orders in price-time priority. A better price has priority; at the same price, earlier resting orders precede later ones. A chart touching a limit price does not demonstrate that enough opposing quantity reached a particular order. A displayed book also describes available orders at that moment, without reserving them for a later submission.
Acceptance messages and actual fill records
An API response can acknowledge a resting order without reporting any executed quantity, so the response's order result matters more than its outer success label. The exchange response distinguishes a resting result with an order ID from a filled result containing executed size and average price. An outer status of
ok
can also contain an order-level error. Signing the request authorizes its contents; sending it attempts submission. Neither action alone establishes a fill.
The order-status query identifies states such as
open,
filled,
canceled
and
rejected. An open state indicates successful placement. Fill records supply execution prices and quantities associated with the order. An order ID identifies the object that a status query should inspect; it does not certify completion. A reported fill quantity must still match the intended quantity before treating the whole trade as complete.
Partial fills and the position already created
A partial fill changes the account for the executed quantity, even when the original trading objective remains incomplete. Different opposing orders can contribute separate fills at different prices. For an unchanged order, the unfilled quantity equals its original quantity minus cumulative executed quantity. Any replacement quantity needs to reflect those existing fills.
The current position provides a separate account-level view of what remains open. Perpetual account records report position size and margin, while spot records report token balances. Under unified account and portfolio margin modes, the spot balance record supplies the trading account balance across spot and perpetuals. A fill price alone cannot explain every balance movement: execution fees, transfers and applicable funding payments can also affect the account. A canceled remainder can coexist with a position that the earlier fills created. Closing that position requires an executed opposing trade; removing its outstanding entry order does not close it.
Rejection causes and execution-time checks
A rejected order needs its reported cause resolved before a retry can work. Invalid parameters require correction; any balance or margin shortage must clear before resubmission. Price increments, size precision and minimum trade value apply to the selected market. The asset's metadata supplies its size precision. Insufficient spot balance and insufficient perpetual margin describe different funding constraints. A reduce-only rejection indicates that the proposed trade would violate the reduction rule. Post-only immediate-match rejection identifies an execution-setting conflict, rather than a shortage of funds.
HyperCore checks a resting perpetual order's margin again when it matches. Changes after placement can therefore leave an initially valid order unable to fill. Market rules can also reject orders because of open-interest limits, margin-tier limits or excessive distance from the oracle price. Resubmitting unchanged parameters does not remove those constraints.
Trigger activation and limit execution
A triggered stop or take-profit order has reached its activation condition, while its execution still follows the selected market or limit behavior.
The mark price triggers take-profit and stop-loss orders.
A triggered limit order can remain unfilled when opposing liquidity falls outside its limit. A market variant seeks execution within its slippage tolerance. The
triggered
status describes activation, so actual fills and the remaining position determine whether the intended exit occurred.
Cancellation confirmation before replacement
Cancellation removes outstanding quantity after it succeeds, while trades that already executed remain part of the account. A submitted cancellation request alone does not confirm that the order has stopped.
The cancellation response can report that an order was never placed, already canceled or already filled. That error does not distinguish those outcomes by itself. The matching order status and fill records resolve the difference. Replacing the original quantity while its remainder still rests can leave additional executable orders. Replacing it after further fills can also exceed the intended exposure. The replacement therefore needs the latest executed quantity and confirmed outstanding state, rather than the amount that the original order form displayed.
Attached take-profit and stop-loss orders add a related dependency. Manually canceling a partially filled parent cancels its attached children too. Cancellation of a partially filled parent for insufficient margin instead places those children.
Reconciliation after a missing response
A missing submission response leaves execution uncertain until current order and account records establish what happened to the request. A disconnected interface or interrupted data stream cannot establish rejection. Query the order status using its exchange order ID or an assigned client order ID. Supply the address of the account that owns the order. A missing-order response deserves further reconciliation with open orders, fills and account state before another submission assumes that nothing happened.
WebSocket order updates describe status changes, while user fill messages describe executions. After an interruption, fresh account queries can reconcile the local record with the exchange state. Repeated delivery of an existing fill must not inflate the executed quantity; the fill's trade ID helps identify that duplication. A new order request can create additional exposure if the earlier request executed during the interruption.
Can a wider limit resolve an incomplete immediate order?
A wider buy limit can admit more sell orders, increasing the quantity that an IOC order can fill immediately.
Consider a hypothetical buy of Q contract units from a flat position using an IOC limit order. Assume the account has valid signing authority and enough available margin for either price limit. All prices and quantities satisfy the selected market's rules. The resting sell orders stay unchanged throughout this comparison.
At the tighter limit, only F units are available, where F is smaller than Q. The order fills F units and cancels Q minus F. The account holds a long position of F units, with no remaining open quantity from that order.
For an alternative submission from the same flat starting account, change only the limit price. Suppose the wider limit admits enough additional sell orders to cover Q. The order fills Q units and leaves no remainder. Its individual fills may occur at different prices within that limit.
The wider limit permits a higher purchase price; it does not reserve the displayed liquidity. Actual matching can differ if resting orders change before execution.
Waiting, adjusting or stopping further execution
An open order can keep working, while a rejected or canceled order needs a new valid submission to attempt further execution. Waiting fits an active resting order when its price constraint still suits the intended trade. A TWAP can continue attempting its remaining target while its schedule remains active, although liquidity constraints can leave it short at the end. Adjusting price or quantity changes what a replacement can execute. Retrying after a known rejection requires confirming that its cause has cleared; retrying after an uncertain response first requires reconciliation.
Once cumulative fills account for the intended quantity and the current holdings or position agree, another submission would add a separate order. When the available records disagree, pause further execution until the discrepancy clears. Any partially opened perpetual position remains exposed to price movement and applicable funding rates after its entry order stops. An execution limit can prevent an unwanted price, but it cannot supply missing liquidity or guarantee that a time-sensitive trade finishes.
Key questions about Hyperliquid
Why can a batch request return one error for several orders?
Some batch errors occur during pre-validation and reject the entire payload. Invalid request contents can therefore produce one error instead of a separate result for every order. The integration needs to handle that whole-batch rejection distinctly from a response that contains individual order results.
Can closing the browser tab affect a Chase order?
A Chase order runs its repricing logic in the browser tab that created it. Closing that tab removes the running context for its automatic price adjustments. The underlying resting order has its own exchange state, so browser closure alone should not serve as confirmation that all outstanding quantity was canceled.
Does matching my own resting order produce a fill?
Matching against an order from the same address cancels the resting order through self-trade prevention. That cancellation deducts no trading fee and does not appear in the trade feed. It therefore supplies no executed quantity toward the intended trade, although other eligible opposing orders can still supply matches.
What does scheduledCancel mean for an API order?
The scheduledCancel status means the configured cancel-all deadline caused the order's cancellation. API integrations can schedule cancellation of the account's open orders as a dead man's switch. This is an intentional cancellation mechanism, so an order can stop because of that deadline even when its price and margin remain valid.
Should I add builderFee to the fee reported for a fill?
The fee field in a fill already includes any builderFee reported alongside it. Adding both fields would count that builder charge twice. The feeToken field identifies the token in which the fee was paid, which matters when reconciling execution costs with changes in the account's balances.