Hyper liquid is an order workflow for deliberate confirmation
Posted:
Hyper liquid is a perpetual-futures order workflow where the trader selects a market, direction, size, leverage, margin mode, order type, price behavior, and optional exit instructions before submitting the order ticket. A marketable order changes HyperCore state through a fill; a non-marketable limit order becomes a resting order, while an invalid request is rejected. Wallet setup determines which address authorizes those actions, so checking the connected EVM address and enabling trading must precede every ticket decision.
Following the order ticket from market selection to confirmation
The Hyper liquid order ticket turns one trading intention into a fixed sequence of fields. Start with the intended perpetual market, choose long or short, set cross or isolated margin and leverage, then select the order type before entering size, price, trigger conditions, or attached exits.
Each choice changes the action sent to HyperCore. A market order requests an immediate match, a limit order defines the worst acceptable price, and a trigger order waits for a specified mark-price condition. The preview then brings those instructions together, allowing the side, notional value, estimated liquidation price, margin requirement, and fee treatment to be read as one proposed action.
Before pressing Confirm, use this short decision checklist:
- The selected perpetual and long-or-short direction match the intended exposure.
- The size clears the $10 minimum notional without exceeding available margin.
- Cross or isolated margin matches the intended collateral boundary.
- The order type expresses immediate execution, resting liquidity, or a future trigger.
- Reduce Only is enabled when the action must close rather than enlarge a position.
Confirmation is the last comparison between the proposed order and the intended account state. A valid signature proves authorization; it does not guarantee a fill, because price, liquidity, time in force, and margin checks still determine the outcome.
Establishing one address and the trading permission
Wallet setup gives the interface an EVM address and a path for signing trading actions. An email login sends a 6-digit code through Privy and creates one blockchain address, while Rabby, MetaMask, WalletConnect, and Coinbase Wallet connect an address the trader already controls.
A standard EVM address contains 42 characters: the 0x prefix followed by 40 hexadecimal digits. Matching that address with the intended account matters because balances, positions, open orders, and trade history belong to the address rather than the browser profile or wallet brand.
The Connect action exposes the public address to the interface. Enable Trading then requests a gasless signature costing 0 ETH, which authorizes the trading path without moving collateral. Connection and trading permission are separate states, so a visible balance does not by itself prove that the browser session is ready to submit orders.
Moving collateral into the perps balance
Perpetual collateral must be available in the perps balance before an order passes its margin check. The native Hyper liquid bridge path accepts USDC from Arbitrum, where ETH pays the deposit transaction's network gas; placing trades after credit does not consume Arbitrum gas.
The native Arbitrum deposit minimum is 5 USDC. A smaller transfer is not credited immediately, while an email account can send additional USDC so the combined deposit reaches the threshold. A bridge deposit is credited after more than two-thirds of the validator staking power has signed it.
USDC held in the spot balance is distinct from USDC in the perps balance and must be transferred to the latter before it serves as perpetual collateral. Cross-margin losses also reduce available balance because incoming USDC supports existing cross positions first. A later native withdrawal to Arbitrum deducts 1 USDC and requires no ETH from the withdrawing account.
Choosing among market, limit, trigger, scale, and TWAP orders
The order-type menu determines whether execution is immediate, price-bounded, conditional, distributed, or spread across a range. HyperCore defines 8 primary choices: Market, Limit, Stop Market, Stop Limit, Take Market, Take Limit, Scale, and time-weighted average price, abbreviated TWAP.
A Market order crosses available book liquidity immediately, whereas a Limit order fills only at its selected price or better. For a long entry, a Stop Market trigger sits above the mid price and a Take Market trigger sits below it; the directions reverse for a short entry. Stop Limit and Take Limit add a separate limit price after the trigger condition is met.
Scale creates multiple limit orders across a selected range. TWAP releases a suborder every 30 seconds, constrains each slice to 3% maximum slippage, and limits a catch-up slice to 3 times the normal suborder size. Falling behind schedule does not remove those constraints, so a TWAP can finish with part of its target unfilled.
Position-level take-profit and stop-loss orders use the mark price as their trigger. Market TP/SL instructions carry a 10% slippage tolerance, while limit TP/SL instructions exchange execution certainty for a firm price boundary. TradingView chart controls also allow existing position-level triggers to be moved, provided the new level would not execute immediately.
Setting size, leverage, margin mode, and Reduce Only
Position sizing translates collateral and leverage into perpetual exposure. Each contract unit represents 1 unit of the underlying spot asset, and the ticket derives position size from the selected leverage multiplied by committed collateral.
Cross margin draws from the account's shared cross balance, so unrealized profit and loss across cross positions affect the same collateral pool. Isolated margin assigns collateral to one position and supports later additions or removals. The maintenance-margin fraction is one-half of the initial-margin fraction at maximum leverage, while transfers that remove margin must leave at least 10% of total open notional or the applicable initial-margin requirement, whichever is greater.
Reduce Only changes the permitted state transition. A closing order with that option cannot enlarge the current position or open one in the opposite direction; HyperCore rejects it when execution would increase exposure. That makes Reduce Only the relevant confirmation field for a manual close, a staged exit, or an order placed against a position whose size could change before execution.
Matching price precision to time in force
Price precision and time in force decide whether a limit instruction is valid and how long it remains actionable. Perpetual prices accept up to 5 significant figures and no more than 6 minus the asset's size-decimal setting in decimal places; integer prices remain valid regardless of significant-figure count.
Spot markets use a corresponding maximum of 8 minus the asset's size-decimal setting, while order sizes themselves are rounded to that asset-specific number of decimals. The interface therefore rejects a numerically reasonable price or size when it falls between the permitted tick or lot increments.
Limit orders have 3 principal time-in-force choices. Good Til Cancel, or GTC, rests until filled or canceled; Add Liquidity Only, or ALO, rests as a post-only order and is rejected if it would match immediately; Immediate or Cancel, or IOC, fills available liquidity at once and cancels any unmatched remainder. Resting orders then follow price-time priority.
What changes when the confirmation action is submitted?
The Hyper liquid confirmation action submits an authenticated instruction to HyperCore; it does not promise that every order becomes a trade. A marketable order that passes validation matches against the book, updates the position and margin balance, records a fill, and applies the relevant trading fee. A passive limit order instead enters the book after an opening margin check, with another margin check performed when matching occurs.
The first Enable Trading signature establishes the signing path, so routine order entry does not require the master wallet to display a separate network transaction for every ticket. Hiding the interface's confirmation modal with Don't show this again removes that preview step, not the underlying authorization or protocol validation. The follow-on topic is treated in Hyper liquid 101.
Under the agent-wallet model, a master account can approve 1 unnamed agent and up to 3 named agents, with 2 additional named agents allowed per subaccount. Agents sign actions but do not replace the master address for balance queries. HyperCore retains the 100 highest nonces per signer, and valid nonce timestamps fall between 2 days before and 1 day after the block timestamp.
Once accepted through HyperBFT, the action receives one-block finality. A trigger instruction remains conditional until its mark-price rule is met, so the observable state after confirmation is an open trigger rather than an immediate position change.
Reading the result in positions, open orders, and trade history
Order verification separates accepted instructions from completed executions. The Positions area shows filled perpetual exposure, Open Orders contains resting and conditional instructions, and Trade History records executed quantities and prices; an empty Positions row therefore does not prove that a submitted limit order disappeared.
Explicit order states include open, filled, canceled, triggered, and rejected, with more specific cancellation or rejection labels for margin, minimum notional, invalid trigger price, post-only crossing, and unavailable liquidity. Partial execution updates the position by the filled amount while leaving the unfilled quantity open when the chosen time in force permits it.
Order IDs provide the cleanest link between a ticket and its recorded status, and API users can supply a 16-byte hexadecimal client order ID. Displayed entry price and unrealized or closed PNL are frontend calculations; HyperCore's fundamental accounting state consists of balances, margin, and trades. That distinction explains why verification starts with the fill and position records rather than a chart annotation.
Clearing a wallet connection loop without changing accounts
The Hyper liquid connection loop occurs when the browser repeatedly requests Establish Connection, the extension fails to answer, or signing never completes. Recovery begins with the existing address: ensure the extension is enabled, perform a hard refresh with Ctrl+Shift+R on Windows or Cmd+Shift+R on macOS, clear the site cache, then disconnect and reconnect the wallet.
For an Arbitrum deposit session, switch the wallet to another EVM network and back to Arbitrum before reconnecting. A persistent MetaMask compatibility issue can be isolated by loading the same key into Rabby; because the EVM address remains identical, HyperCore positions, orders, balances, and history remain attached to the same account.
Reinstallation belongs at the end of the sequence. Confirm that the recovery phrase or private key is available before removing an extension, since the browser copy is replaceable while the signing credential controls access to the address. After reconnecting, compare the full address and repeat Enable Trading only when the interface requests that permission.
Traders who benefit from explicit order controls
The explicit-control workflow suits traders who can state the desired account change before touching Confirm. Immediate exposure maps to Market or IOC, maker-only placement maps to ALO, durable passive interest maps to GTC, scheduled execution maps to TWAP, and closure without reversal maps to Reduce Only.
Order selection also determines whether a fill receives maker or taker treatment. Fee tiers use rolling 14-day weighted volume, and spot volume contributes at 2 times its nominal amount to that calculation. The decision remains order-specific: read the side, state transition, execution constraint, and resulting record together, then confirm only when all four describe the same intended action.
Things people ask
Can a hardware wallet authorize the web order ticket?
Yes, a hardware wallet can authorize the order ticket when paired with a compatible browser wallet. Ledger and Trezor devices work through connectors such as Rabby or MetaMask, keeping the signing key on the device. If Trezor reports a forbidden keypath, the relevant recovery setting is Safety Checks in Trezor Suite, changed from Strict to Prompt before reconnecting.
Does canceling a partially filled parent order preserve its attached TP/SL orders?
Canceling a partially filled parent order also cancels its attached TP/SL children, so the filled portion no longer has those exits attached. The exception is a partial parent order canceled for insufficient margin; its children are placed as though the parent filled. After a manual cancellation, create new position-level TP/SL instructions for the actual remaining size.
When is a post-only order rejected instead of resting?
A post-only order is rejected when its price would match immediately against an existing order. Add Liquidity Only is designed to enter the book as resting liquidity, so crossing the best opposing price conflicts with that instruction. Move the limit away from the crossing price or choose IOC or GTC when immediate execution is acceptable.
Can a subaccount sign orders with its own seed phrase?
No, a HyperCore subaccount does not have a separate private key or seed phrase. Its master account signs actions on its behalf, either directly or through an approved agent wallet, while the request identifies the subaccount address as the target. Account queries must use the master or subaccount address rather than the agent's signing address.
Is the displayed entry price part of HyperCore accounting?
No, displayed entry price and PNL are frontend calculations provided for interpreting trades. HyperCore's accounting relies on balances, margin, positions, and fills. Opening trades update the weighted entry price, while closing trades retain the prior entry price for the remaining position, which is why fill records are the primary evidence of execution.
Where does a maker rebate appear after an order fills?
A maker rebate is paid continuously into the trading wallet as qualifying maker fills settle. Only liquidity-resting execution receives maker treatment; a marketable order receives taker treatment even when entered through a limit ticket. The applicable rate follows the account's rolling 14-day weighted volume, including volume attributed through its subaccounts.