Does a cancellation error prove the order never existed?

A missing-order cancellation error can mean the order was never placed, already canceled or already filled. The error alone cannot distinguish those outcomes. Its fill and historical status records determine whether execution occurred before the cancellation attempt.

Can a batch return one error instead of a result for every order?

A batch can return a single error when pre-validation rejects the entire payload. Applications must handle that response shape alongside individual order results. Assuming every response contains one entry per submitted order can misclassify the batch.

Is a triggered stop-limit order already a completed trade?

A triggered stop-limit order has activated its limit order; activation does not establish execution. Its limit price still constrains matching, so an activated order can remain unfilled. Completion requires actual fills, even when the trigger condition has already occurred.

Why do fill-history views group the same executions differently?

The fill query’s aggregation setting can explain different groupings of the same executions. With time aggregation enabled, a crossing order’s fills against multiple resting orders combine. Multiple fills against a resting order combine only within the same block. Compare executed quantity rather than the number of displayed rows.

Why can separate trading processes produce nonce errors?

Trading processes using the same signing wallet share its nonce tracking, even when they target different subaccounts. Competing processes can therefore reuse or conflict over nonces. A nonce identifies a signed action for replay protection; it is separate from an order ID used to track execution.

When can a network upgrade interrupt immediate execution?

Market orders do not fill during the post-only period of a network upgrade. That restriction also applies to TWAP suborders. Repeated immediate-execution attempts during that period cannot establish normal matching availability.

Could an expired action deadline explain a rejected API submission?

An action supporting the optional expiresAfter field is rejected after its specified deadline. This deadline concerns submission validity, rather than the resting lifetime of a GTC order. Applications using it need to distinguish an expired action from an order canceled after acceptance.

Hyper liquid

Hyper liquid order records distinguish rejected placement from partial execution

Hyper liquid order troubleshooting starts by separating a rejected submission from an order with completed fills. A rejection reason identifies the failed placement condition; fill records establish the quantity already traded. An absent open order alone cannot settle the distinction. Before retrying, reconcile its status, executed quantity and any remaining order against the intended trade. Then address the actual constraint, such as available margin, post-only pricing or liquidity within the order’s limit.

Last updated Tue, 15 Sep 2026

Reconcile the remainder before choosing a retry

Consider a limit order whose requested quantity exceeds the immediately available opposing liquidity at acceptable prices. Assuming it passes the placement checks, should its remainder wait or cancel? Keep the market, side, quantity and price limit unchanged when comparing the instructions. Good til canceled (GTC) permits an unfilled remainder to rest. Immediate or cancel (IOC) removes that remainder after immediate matching. These rules stay distinct even as available liquidity changes.

An IOC order cancels its unfilled quantity instead of leaving it on the order book. The executed portion remains a completed trade.

If fills cover the intended quantity, stop replacing that order.
If a GTC remainder remains open at an acceptable price, waiting preserves its chance to fill.
If an IOC remainder has canceled, base any replacement on the quantity still wanted.
If placement was rejected, correct the named constraint before submitting another order.
If the response is missing or ambiguous, reconcile order status and fills before retrying.

Changing only the time-in-force instruction changes whether continued waiting can produce another fill from that order. It does not create additional liquidity. A new submission for the original quantity could exceed the intended trade after a partial execution.

Why was an order rejected before it filled?

An order can fail placement because its price, value, balance or execution instruction violates the applicable trading rule. The returned reason narrows the diagnosis. A tick error concerns the permitted price increment. A minimum-notional error concerns order value. Insufficient spot balance and insufficient perpetual margin identify different funding constraints. Treating each rejection as a connection problem leaves its cause unchanged.

View image file

Post-only rejection has a specific meaning: the order would have matched immediately against the opposing book. Its instruction requires adding resting liquidity. Changing that instruction permits different execution behavior, while changing the price changes the trade’s terms. Neither adjustment is merely a technical reset. Oracle-price restrictions and open-interest limits can also reject orders, independently of whether the account holds funds.

Partial fills depend on price and available depth

Execution reaches only the opposing liquidity available at prices the order permits, with orders matching in price-time priority. A displayed quote does not establish sufficient quantity for the entire submission. Other orders can consume that liquidity before matching occurs. Orders already ahead at the same price also affect a resting order’s opportunity to execute.

A wider price limit permits more adverse execution prices; it does not promise a complete fill. Keeping the original limit preserves that price boundary, with a greater possibility of incomplete execution.

Partial fills depend on price and available depth: Execution reaches only the opposing liquidity available at prices the order permits, with orders matching in price-time priority.; A displayed quote does not establish sufficient quantity for the entire submission. Other orders can consume that liquidity before matching occurs.; Orders already ahead at the same price also affect a resting order’s opportunity to execute.

View image file

For a buy limit, eligible execution prices are at or below the limit. A sell limit permits execution at or above it. The eventual average reflects the prices and quantities actually executed. Comparing that average with the submitted limit alone misses how much remains unfilled.

Can a resting order disappear without finishing?

A resting order can cancel before completing its requested quantity, including when it no longer passes the margin check at matching. Perpetual orders undergo margin checks at placement and again on the resting side during matching. Acceptance therefore does not reserve an unconditional right to execute later. Price changes can alter the account’s ability to support the trade.

Historical statuses distinguish margin cancellation, reduce-only cancellation, liquidation-related cancellation and other causes. A canceled remainder does not reverse earlier fills. The remaining position or token balance still reflects those executions.

Margin and reduce-only errors need different corrections

A margin rejection concerns the account’s capacity to support exposure, while a reduce-only rejection concerns the direction of the proposed position change. Perpetual initial margin depends on position size, mark price and leverage. Available collateral must also match the applicable margin arrangement. Cross margin shares collateral within its supported scope; isolated margin confines collateral to the relevant position. Account mode affects sharing across markets.

View image file

Reduce-only prevents an order from increasing exposure. Removing the flag changes that protection and can permit an unintended position. The relevant comparison is between the order’s side and quantity and the position it would affect.

Position limits at the selected leverage can block an order separately from insufficient margin. A market-wide open-interest restriction is another distinct condition. More collateral does not automatically resolve either rejection. The error reason determines which constraint needs attention.

API responses need order-level interpretation

API troubleshooting requires the individual order outcome, rather than treating successful request delivery as proof of a completed trade. Placement responses distinguish resting orders, reported fills and errors. Compare the reported totalSz with the submitted quantity before treating an order as fully filled. Applications should retain the submitted parameters and returned identifiers alongside the response. An optional client order ID provides another identifier for tracking the intended order.

The order-status query accepts an order ID or client order ID. Fill records associate executed quantities and prices with order identifiers. A timeout leaves the submission outcome unresolved until those records clarify it. A fresh submission can create additional exposure if the earlier order already executed.

Replacement size should reflect completed fills and any still-active remainder. That reconciliation prevents an incomplete response from becoming an oversized trade.

Hyper liquid - your questions answered

Does a cancellation error prove the order never existed?: A missing-order cancellation error can mean the order was never placed, already canceled or already filled. The error alone cannot distinguish those outcomes. Its fill and historical status records determine whether execution occurred before the cancellation attempt.
Can a batch return one error instead of a result for every order?: A batch can return a single error when pre-validation rejects the entire payload. Applications must handle that response shape alongside individual order results. Assuming every response contains one entry per submitted order can misclassify the batch.
Is a triggered stop-limit order already a completed trade?: A triggered stop-limit order has activated its limit order; activation does not establish execution. Its limit price still constrains matching, so an activated order can remain unfilled. Completion requires actual fills, even when the trigger condition has already occurred.
Why do fill-history views group the same executions differently?: The fill query’s aggregation setting can explain different groupings of the same executions. With time aggregation enabled, a crossing order’s fills against multiple resting orders combine. Multiple fills against a resting order combine only within the same block. Compare executed quantity rather than the number of displayed rows.
Why can separate trading processes produce nonce errors?: Trading processes using the same signing wallet share its nonce tracking, even when they target different subaccounts. Competing processes can therefore reuse or conflict over nonces. A nonce identifies a signed action for replay protection; it is separate from an order ID used to track execution.
When can a network upgrade interrupt immediate execution?: Market orders do not fill during the post-only period of a network upgrade. That restriction also applies to TWAP suborders. Repeated immediate-execution attempts during that period cannot establish normal matching availability.
Could an expired action deadline explain a rejected API submission?: An action supporting the optional expiresAfter field is rejected after its specified deadline. This deadline concerns submission validity, rather than the resting lifetime of a GTC order. Applications using it need to distinguish an expired action from an order canceled after acceptance.