Hyper liquid separates pending actions from failures before a retry changes account state.

The Normal Path and Its Recovery Boundary

A normal order path begins with a signed request and an order-specific response. The response can report a resting order with an order ID, an immediate fill with executed size and average price or an error for the submitted entry. A transport-level success isn’t enough because an order error can appear inside an otherwise successful API response. Preserve the returned order ID or optional client order ID before deciding what follows.

A bounded recovery starts when the response is missing, delayed or inconsistent with the account. Query the original order, associated fills and relevant balance. A live record calls for waiting or cancellation. A terminal rejection permits adjustment, while an unexplained financial effect requires reconciliation before any replacement.

When Does Waiting Beat a Retry?

Waiting beats a retry while the recorded state remains capable of producing the requested effect. An open order was placed successfully and may still rest or fill later. A withdrawal marked pending also remains in progress. Neither state becomes a failure merely because the interface hasn’t yet shown the intended balance or destination result.

Open full-size image

Time-in-force determines what can remain live. An immediate-or-cancel order cancels any unfilled portion instead of leaving that portion on the book. A Good Til Cancel order can continue resting until it fills or gets canceled. The original setting therefore changes whether an absent full fill means “still open” or “finished with an unfilled remainder.”

A stale screen doesn’t alter the underlying state. Refresh the evidence instead of creating a second request.

Order Responses, Fills and Balances

An order response answers whether the submitted instruction rested, filled immediately or failed validation. Order status then tracks the instruction itself. Fill records answer a different question: what quantity traded, at which price and with which recorded fee. The account balance or position shows the financial consequence, but it can’t replace the fill record when price, quantity or fee details matter.

A triggered status isn’t the same as a completed fill. Likewise, a canceled order can have earlier fills even though its remaining quantity no longer rests. Match records by order ID and compare the original size with executed size. For a spot action, reconcile the relevant token balances. For a perpetual action, reconcile the position, margin state and fees tied to the fills.

Conflicting records narrow the next step. A fill without a refreshed screen points to display lag. An open order without a fill supports waiting or cancellation. A rejected order without fills supports correction. A balance change without a matching record means the investigation isn’t finished.

Which Failures Need a Changed Input?

A deterministic rejection needs a changed input rather than an identical retry. The returned error identifies the failed condition. Common order checks cover permitted price increments, minimum order value, available spot balance or margin, reduce-only direction, post-only behavior, trigger price validity and market liquidity.

• Price validation requires a price compatible with the market’s tick and reference-price constraints.
• Size or value validation requires an order meeting the applicable minimum shown by the error.
• Balance or margin rejection requires reducing the order or making sufficient balance or margin available before resubmission.
• Post-only rejection means the order would have matched immediately instead of resting.
• Reduce-only rejection means the submitted order would increase or reverse the position.

Liquidity and open-interest conditions can change, but a rejection remains terminal for the submitted order. Wait for conditions to change or revise the request. Any later retry is a new action; it doesn’t alter the failed submission’s state.

Partial Execution Before Cancellation

A canceled status applies to the order’s unexecuted remainder. It doesn’t reverse fills recorded before cancellation. Add the fills associated with the order ID, compare their combined size with the original order and include their fees when reconciling the account. Only the unfilled quantity remains available for a later decision.

A cancel error doesn’t necessarily mean the order is still active. The missing-order response can cover an order never placed, already canceled or already filled. Query order status and fills to distinguish those outcomes. Sending another cancel may be harmless to exposure, but it doesn’t resolve what happened and can obscure the recovery log.

Stream Gaps Without False Failures

A WebSocket gap can separate related evidence across feeds. Order updates describe status changes, fill updates describe executions and non-funding ledger updates cover events such as deposits, withdrawals and transfers. Streaming fill and funding subscriptions identify the first message as a snapshot and later messages as live updates. A reconnect can therefore repeat history an application already stored.

Recovery after a gap starts with a fresh snapshot of open orders and recent fills. Merge those records by stable identifiers before processing later stream messages. An order ID links status to fills, while a trade ID distinguishes individual executions. This prevents a repeated snapshot from becoming a duplicate fill in local accounting.

A missing stream event is a data-consumption problem until account queries establish otherwise. It isn’t proof the underlying action failed.

---

A Time-Sensitive Acceptance Rule

Every variable in this worked example is hypothetical: requested size S, limit price P, client order ID C, replacement ID C2, executed size X, fill price E and recorded fee R. The order uses Good Til Cancel. Completion requires a fill linked to the order plus a matching position or balance change. Time matters, but no invented timeout overrides the returned state.

Open full-size image

1. Prepare the signed request with client order ID C and retain its fields. Before submitting it, check whether the relevant balance or margin can support S at P.
2. The exchange returns order ID O with a resting result. A status query reports O as open and no fill references it. Keep waiting or cancel O before considering C2.
3. If a fill later records X at E with fee R, the traded notional is E multiplied by X. Reconciliation uses that fill and its account effect before considering any remainder.
4. If the submission instead returns a terminal tick-size error without a resting or filled result, P uses an invalid increment. Adjust P to an accepted increment, sign a new request and use C2 for the replacement.

The boundary comes from observable state. An open order supports waiting, while a terminal input rejection supports adjustment and retry. A canceled order with fills first requires reconciliation because the executed portion can’t be submitted again as though nothing happened.

How Do Transfer States Change the Decision?

A transfer state changes the response because source debit and destination credit may not appear together. Transfers from HyperCore to HyperEVM queue until a HyperEVM block is built. Transfers in the opposite direction are processed after that EVM block within the same L1 block. A queued transfer therefore supports waiting and destination verification rather than another source submission.

A Send action and a withdrawal also have different destinations. Send moves assets to another account on the same blockchain, while withdrawal targets another blockchain through its supported route. A pending withdrawal calls for the displayed processing estimate. A completed status calls for checking the recorded destination, while a failed status permits route-specific recovery only after confirming the source balance and destination details.

Open full-size image

A wrong action type isn’t a timing problem. More waiting can’t turn an internal Send into an external withdrawal.

Stop Conditions for a Known Account State

A stop condition protects the last state the records actually establish. Stop submitting when the destination is wrong, required compatibility is absent, a rejection remains unexplained or order and balance records still conflict. When an order ID is unknown, verify the account address and identifier before drawing a conclusion.

Recovery resumes after the missing dependency is corrected and every earlier fill, fee or transfer effect is reconciled. The next request then becomes a deliberate new action rather than an accidental duplicate. The next request can use the reconciled position, balance and destination state without carrying an unresolved assumption forward.