Hyper liquid

Hyper liquid actions must be verified through order status, fills, balances and destination records.

Hyper liquid is an on-chain platform for spot and perpetual trading, with general-purpose smart contracts running alongside its trading engine. A submitted action isn’t the same as a completed result. Order status shows whether an instruction remains active. Fills show what traded, account state reveals the financial effect and transfer records show where funds moved. Reconcile those records before repeating an action or treating an exit as complete.

· updated

One Action Can Produce Several Account Records

A signed instruction identifies an action and authorizes the chain to process it. Its consequences depend on the instruction type. An order may rest, fill, fill partly or fail a validation check. A transfer can change balances within one state component or across two components, while a bridge withdrawal continues through additional stages after funds leave the trading balance.

HyperCore records orders, cancellations, trades and liquidations with one-block finality inherited from HyperBFT. Finality fixes the accepted state transition, but it doesn’t turn every submitted order into a trade. A finalized resting order remains open until an eligible counterorder reaches it or a later event removes it.

The useful starting record is therefore the last confirmed account state, not the amount shown before signing. Compare the action identifier and status with any resulting fill. Then reconcile the updated position, spot balance or transfer ledger entry. This sequence separates a delayed display from a rejected action and prevents an unnecessary duplicate submission.

Acceptance, Execution and Finality Are Different States

Order status provides the shortest path from a request to its actual consequence. An open order was placed but hasn’t fully traded. A filled order has execution records, while a canceled or rejected order can’t be treated as a fill. Immediate-or-cancel instructions may execute only the available portion and cancel the rest. A Good Til Cancel order can remain active, so the absence of a full fill doesn’t establish failure.

Acceptance, Execution and Finality Are Different States: Order status provides the shortest path from a request to its actual consequence. An open order was placed but hasn’t fully traded. A filled order has execution records, while a canceled or rejected order can’t be treated as a fill.; Immediate-or-cancel instructions may execute only the available portion and cancel the rest. A Good Til Cancel order can remain active, so the absence of a full fill doesn’t establish failure.

Open full-size image

Reconciliation Starts With Orders, Fills and Balances

Reconciliation works from specific records rather than one portfolio total. Open orders show pending instructions, fills explain executed price and size and clearinghouse state shows the resulting exposure. Ledger updates cover deposits, withdrawals and internal transfers separately from trades.

Order Evidence

Order evidence begins with the order identifier or client order identifier. Its latest status distinguishes an active instruction from one filled, canceled or rejected. The original size and remaining size reveal whether the complete request is still outstanding.

Accepted But Open

An open status means the order exists on the book. It doesn’t prove any amount traded. Check fills bearing the same order identifier before updating a cost basis or expecting the position and balances to reflect an execution.

Partially Filled

A partial fill produces two meaningful facts: the executed portion is irreversible as a trade and the unfilled portion may remain open or be canceled. Reconciliation must add the recorded fills and compare that sum with the original order size.

Partially Filled: A partial fill produces two meaningful facts: the executed portion is irreversible as a trade and the unfilled portion may remain open or be canceled.; Reconciliation must add the recorded fills and compare that sum with the original order size.

Open full-size image

Account Evidence

Account evidence confirms what those fills changed. Perpetual records cover positions and margin, while spot records cover token totals and order holds. In Standard mode, their balances remain separate. Unified Account and Portfolio Margin expose balances and holds through spot clearinghouse state instead. A sound comparison uses records from the same address and a compatible time. If a fill appears after an earlier balance snapshot, refresh the state instead of forcing the older figures to agree.

Margin Rules Can Invalidate an Exit Plan

Margin mode determines which collateral supports a perpetual position. Cross margin shares collateral across cross positions, while isolated margin assigns collateral to one position. Closing one cross position can alter available margin for the others. An isolated close affects its assigned margin without drawing directly on unrelated isolated positions.

Account value and withdrawable balance aren’t interchangeable. Open exposure, unrealized profit or loss and margin requirements can restrict what may leave the account. If equity falls below maintenance requirements, liquidation can close exposure through the order book and may cancel related orders. That state change invalidates an exit plan based on the earlier position, so the remaining position and balance must be read again before another order is placed.

Spot and Perpetual Trades Have Different Account Effects

Spot trading exchanges token balances and may place part of a balance on hold for an open order. Perpetual trading changes a derivatives position, its margin and realized or unrealized profit and loss. Closing a perpetual position removes that exposure, but it doesn’t deliver the underlying spot asset. Reconciliation must follow the active account abstraction mode: Standard keeps spot and perpetual balances separate, Unified Account uses one balance per asset and pre-alpha Portfolio Margin combines eligible assets in one portfolio.

HyperCore and HyperEVM Share Consensus, Not One Balance

HyperCore and HyperEVM are components of the same blockchain secured by HyperBFT. HyperCore handles native order books and trading state. HyperEVM runs Ethereum Virtual Machine contracts and uses HYPE for gas. Their connection doesn’t merge their balances into a single interchangeable account record.

Core to EVM Transfers

Core-to-EVM transfers move a supported asset from its HyperCore balance into the corresponding HyperEVM state. The transfer is queued until an EVM block processes it. A deduction on the Core side should therefore be matched with the later EVM credit rather than mistaken for a completed external withdrawal.

EVM to Core Transfers

EVM-to-Core transfers are processed after the EVM block within the same L1 block. The source transaction, gas charge and resulting Core balance describe different parts of one operation. Unsupported transfer methods or an asset-specific destination used for the wrong token can cause loss, so the supported asset route must be established before signing. The observable result is the new balance in the intended state component.

Bridge Exits Continue After the Trading Balance Changes

A native bridge withdrawal moves USDC from the L1 to Arbitrum and has more stages than closing a position. The withdrawal first reduces the available L1 balance. Validators then authorize the corresponding bridge request before finalization distributes funds to the destination address.

A bridge withdrawal enters a dispute period before finalization. The source-side deduction can therefore precede the destination credit without indicating a second withdrawal is needed. Repeating the request from an outdated balance risks creating another valid exit instead of repairing the first one.

Bridge reconciliation pairs the withdrawal ledger entry with its destination, amount, fee and eventual destination-chain result. The current fee and completion time should be read from the live transaction flow because network conditions and configured charges can change. Completion belongs to the destination record, while the source ledger preserves how the exit began.

Incomplete Changes Need Bounded Recovery

A CoreWriter action originating in HyperEVM requires its account to exist on HyperCore before the EVM block is built. If the same block first transfers from EVM to Core and then sends the action, the transfer can be processed while the action is rejected. One prerequisite was missing even though part of the intended path succeeded.

Incomplete Changes Need Bounded Recovery: A CoreWriter action originating in HyperEVM requires its account to exist on HyperCore before the EVM block is built.; If the same block first transfers from EVM to Core and then sends the action, the transfer can be processed while the action is rejected.; One prerequisite was missing even though part of the intended path succeeded.

Open full-size image

The smallest recovery step is to preserve the completed transfer, wait until the Core account appears and retry only the rejected action. Resending the transfer would create a new state change. The following checks keep the recovery tied to observable records.

Decision Check Before Retry

  • Confirm the initiating address matches the account whose state is being read.
  • Verify the HyperCore account existed before the block carrying the action.
  • Find the completed transfer in the appropriate balance or ledger state.
  • Confirm no order, fill or position resulted from the rejected action.
  • Resubmit only the missing action after its prerequisite is visible.

A later accepted action should leave an execution record or visible state transition. If that evidence remains absent, stop rather than broadening the retry into unrelated transfers or orders.

A Clean Exit Ends With Matched Records

A complete trading exit leaves the intended position at zero, removes or accounts for related open orders and records any realized profit, loss, funding and fees. A balance transfer adds another requirement: the destination state must show the matching credit. A bridge exit isn’t complete until the destination-chain result is final.

Keep the action identifier, order or transfer status and before-and-after account records together. Those records expose a partial fill, a margin-driven cancellation or a transfer still moving between components. When every intended change has a matching record and no unintended order remains active, the latest account state becomes the reliable starting point for the next action.

What to know about Hyper liquid

Does Hyper Liquid Use One Fee Rate for Every Trade?

No, one universal fee rate doesn’t apply to every account and execution. The applicable charge can differ between spot and perpetual trading, maker and taker activity and account-specific fee tiers. A fill record identifies the fee and fee token actually charged. Use that recorded amount for reconciliation instead of calculating the result from a remembered headline rate.

How Long Does a Good Til Cancel Order Stay Open?

A Good Til Cancel order may remain open until it fills or a cancellation event removes it. The user can cancel it, while margin loss, liquidation, delisting or another protocol condition may also end it. Its latest order status and remaining size establish whether exposure is still pending; elapsed time alone doesn’t show completion.

When Are Perpetual Funding Payments Applied?

Perpetual funding payments are applied each hour on HyperCore. The rate’s sign determines which side pays, and the payment changes the account balance without representing a trade fill. Reconcile funding separately when a position spans an interval, especially if the closing balance differs from a calculation based only on entry price, exit price and trading fees.

Do I Need HYPE for Every Operation?

No, HYPE isn’t the payment mechanism for every HyperCore action. It is the native gas token for transactions on HyperEVM, including an EVM-side transfer that consumes gas. Trading fees, native balance transfers and bridge withdrawals follow their own fee mechanics. Check the selected action’s live cost before signing because a fee from one state doesn’t automatically fund another.

Is a reduce-only Order Guaranteed to Close the Entire Position?

No, reduce-only limits what an order may do but doesn’t guarantee a complete fill. The order can fill partly, remain open, be canceled or be rejected if it wouldn’t reduce the position. Confirm the executed size and read the updated position. A zero remaining order size doesn’t by itself prove the position reached zero.

Where Do Missed Account Updates Appear After a WebSocket Reconnect?

Missed updates can be recovered from the reconnect snapshot and the corresponding account information query. Streaming clients should treat the snapshot as a state checkpoint, then resume later events without applying old records twice. Open orders, fills, clearinghouse state and non-funding ledger updates cover different consequences, so a missing message may require more than one targeted query.

Are Subaccount Balances Included Under the Master Address?

No, a subaccount has its own address and account state. Querying only the master address can return a valid result that omits the subaccount’s orders, balances and positions. An API agent address can also produce an empty account view because it authorizes actions without owning the trading state. Reconciliation must use the actual master or subaccount address involved.

Why Can Available Balance Differ From Total Balance?

Available balance can be lower because open spot orders place funds on hold or perpetual positions consume margin. Transfer requirements may further restrict the amount marked withdrawable, even when the account still shows positive value. Compare holds, open orders, position notional and margin summaries before treating the difference as a missing transfer or an unrecorded fee.