Hyper liquid

Step-by-step guides

Hyper liquid is the USDC checkpoint before order confirmation

Hyper liquid is the decision checkpoint between funded USDC and a submitted perpetual order: confirm the collateral available, contract, side, size, leverage, margin mode, instruction and price before approving the ticket. Once confirmed, HyperCore either matches the order, records an eligible unfilled quantity on its order book, or rejects the instruction without opening a position. Immediate verification then distinguishes a completed fill from a resting order and confirms how much USDC remains available.

Posted:

The short version: It is a perpetuals order workflow: check USDC, pick side, size, leverage, and type, confirm the order, check fill or rest status.

Unified USDC versus Standard perps balances

Unified account mode and Standard mode decide which USDC balance feeds the perpetual ticket. Hyper liquid uses Unified mode by default in its principal web interface, so one USDC balance supports spot activity and cross-margin positions; Standard mode separates spot and perpetual balances, requiring an internal transfer before perps collateral becomes available.

Both models settle on HyperCore rather than moving ERC-20 tokens for each trade. Unified mode removes the spot-to-perps transfer step, while Standard mode makes allocation explicit and can be preferable when an operation keeps trading buckets apart. Unified and portfolio-margin accounts share a protocol ceiling of 50,000 user actions per day, while Standard mode has no matching account-mode ceiling. For a manual order, inspect account mode, selected subaccount and available USDC together; a correct wallet total in the wrong balance does not fund the ticket.

Funding checks before the order ticket opens

USDC funding on Arbitrum needs native Circle-issued USDC and enough ETH for the deposit transaction. The production Arbitrum chain ID is 42161, the token uses 6 decimal places, and the native bridge credits deposits from 5 USDC upward.

Amounts below 5 USDC are not credited, so the transaction value itself must clear the floor; adding network gas does not increase credited collateral. Rabby, MetaMask, WalletConnect and Coinbase Wallet all provide EVM connections, although the visible address must match the account intended for trading.

After connection, Enable Trading requests a gasless signature and authorizes an agent wallet to submit HyperCore actions. An email login takes a different route: a 6-digit code opens the account associated with the generated address. Before building the order, check that the balance is shown as available USDC inside the selected account, not merely as USDC held on Arbitrum or another EVM network.

When deposited USDC is not available collateral

Available USDC equals the balance left after the margin system accounts for positions, unrealized profit or loss, and working orders. Cross-margin losses consume a later deposit immediately because the shared account must support the existing portfolio before it funds another order.

Open orders also reserve initial margin, while an isolated position keeps its assigned collateral inside that asset. A transfer or withdrawal must leave the larger of the initial-margin requirement or 10% of total open notional, so the displayed withdrawable amount can sit below the account total. Inspect positions and open orders before treating a lower available balance as a funding failure; canceling an unwanted entry releases its reserved margin, whereas an existing position still retains the collateral its leverage requires.

Side, size and leverage describe different commitments

The side chooses directional exposure, size sets the quantity of the underlying asset, and leverage sets the initial-margin fraction; changing one does not substitute for checking the others. A long has positive exposure, a short has negative exposure, and each linear perpetual unit represents 1 unit of its referenced spot asset.

Leverage accepts integer settings from 1x through the asset's configured maximum. Required initial margin equals notional value divided by selected leverage, so doubling leverage halves that initial requirement while leaving notional exposure unchanged. The ticket's notional is price multiplied by size, not the number typed into the USDC collateral field.

Funding settles every 1 hour and follows the position's side and notional, so the displayed funding rate belongs in the pre-confirmation review even though it does not alter the order quantity. Maximum leverage is contract-specific and, for large positions, margin tiers can reduce it; read the limit attached to the selected market rather than carrying a BTC setting into ETH, SOL or HYPE.

Market, limit and time-in-force instructions

Order instructions determine whether HyperCore seeks an immediate match, waits at a chosen price, or cancels unmatched quantity. Market and limit identify the execution rule; Good Til Cancel, Add Liquidity Only and Immediate or Cancel define the limit order's time in force.

Instruction When it executes Unmatched quantity Main failure mode
Market Against available book liquidity immediately Does not become a resting limit order No liquidity at acceptable prices
Limit with GTC At the limit price or better Rests until filled or canceled Market never reaches the limit
Limit with ALO Only after resting as maker liquidity Rests when accepted Crossing price cancels at entry
Limit with IOC Immediately at the limit price or better Cancels at once No match inside the limit

Trigger orders add an activation price before one of these outcomes. Stop Market and Stop Limit activate on one side of the mid-price condition, while Take Market and Take Limit use the opposite condition; the resulting market or limit instruction then faces normal book liquidity.

A TWAP sends suborders every 30 seconds, caps each slice at 3% slippage and limits a catch-up slice to 3 times the normal size. Those constants make TWAP a separate execution plan, not a synonym for dragging the ordinary size slider.

Cross margin or isolated margin before confirmation

Margin mode decides which collateral absorbs movement after the order becomes a position. Cross margin, the default, shares account collateral across all cross positions, while isolated margin confines the assigned collateral and liquidation calculation to one asset.

Choose the mode before approving the entry because the consequence appears after execution, not in the fill price. Isolated positions permit margin additions and removals after opening; cross positions draw from the shared USDC pool, including unrealized gains that qualify as initial margin for new positions. Some contracts are isolated-only, and their collateral cannot be removed directly while the position stays open.

Maintenance margin is one-half of the initial-margin fraction at maximum leverage. That fixed relationship explains why increasing leverage narrows the distance between initial collateral and the liquidation threshold, even though the order confirmation still shows the same notional size. If the intent is to ring-fence one BTC or ETH position, verify the mode label beside that contract rather than inferring it from the broader account setting.

Price precision and the 10 USD order floor

Tick precision and lot precision decide whether an otherwise well-funded order is valid. Perpetual prices accept up to 5 significant figures and no more than 6 minus the asset's size-decimal setting after the decimal point.

Integer prices remain valid regardless of significant-figure count, and sizes are rounded to each asset's published size-decimal value. Spot pricing uses a separate maximum of 8 decimal places, which matters when a user switches the ticket from a perpetual market to a spot pair; copying spot precision back into a perp limit order produces a tick rejection.

Perpetual order notional must reach 10 USD. Raising leverage does not repair an order below that floor because leverage changes margin, not price multiplied by size. Re-enter the price and base-asset quantity at accepted precision, then read the recalculated notional before confirming again.

What confirmation writes to HyperCore

Order confirmation submits a signed trading action to HyperCore; it does not submit another ERC-20 USDC transaction on Arbitrum. Hyper liquid confirmation therefore changes trading state, not the user's Arbitrum token balance: the action fills, rests, or returns an error. A related page goes further into Hyper liquid fees.

A filled opening order updates signed position size, average entry and margin usage. An accepted GTC limit creates an open-order record and reserves the required margin; a partial fill produces both a position change and a smaller resting remainder. IOC cancels any unmatched remainder, while ALO cancels an instruction that would match immediately.

Reduce Only adds a state constraint: execution must decrease the existing position rather than expand it or reverse direction. Rejections leave neither a new position nor a resting order, so the absence of a fill is not evidence that a limit remains live. Trading actions consume no Arbitrum ETH; the earlier deposit transaction is the separate EVM event that paid gas.

Verify filled, resting and rejected states

Order verification starts with the position table, open-orders table and trade history, because each view answers a different state question. A filled response records total size and average price, an open response proves successful placement, and a rejection records no working order.

Check position size and entry price first when the ticket was meant to execute immediately. For a limit instruction, match the contract, side, remaining size, limit price, margin flag, reduce-only flag and time in force against the submitted ticket. A partial fill belongs in both places: executed quantity appears in the position or fill history, while the remainder stays under open orders only when its instruction permits resting.

Canceled and margin-canceled states also need separation. A user cancellation ends a working order, whereas margin cancellation records that available collateral could not support execution; neither state should be treated as filled merely because the original confirmation modal closed.

Recovering an insufficient-margin setup error

An insufficient-margin message means the selected account cannot reserve the order's required initial margin at execution. Visible USDC elsewhere does not change that state, so recovery begins with account mode, subaccount and available balance rather than repeating the same confirmation.

In Standard mode, move USDC from the spot balance into the perps balance; Unified mode already uses one balance, so inspect cross-margin losses, isolated allocations and other opening orders. Cancel only orders no longer intended, add collateral to the relevant balance, reduce notional size, or choose a higher permitted leverage when a smaller initial-margin fraction matches the operating plan.

Then rebuild the ticket instead of assuming its old figures survived the balance change. Confirm contract, side, size and margin mode again, and check that the 10 USD minimum notional and the asset's tick rules still pass. If a subaccount is selected, the master account signs for it; reading the agent wallet address as the trading account produces an empty account view rather than usable collateral.

Who benefits from a repeatable confirmation review?

A repeatable confirmation review fits operations that reuse the same wallet across several contracts, subaccounts or margin modes. The value comes from catching state drift between orders: working limits reserve USDC, fills alter position size, funding changes account value every hour, and cancellations release capacity.

Keep the review compact enough to run every time. Read the selected account and available USDC, then contract and side, then notional size and leverage, then margin mode, price instruction, time in force and reduce-only state; after confirmation, reconcile the position and open-order views before preparing another ticket.

Hyper liquid works best here as a controlled sequence rather than a memory test. BTC, ETH, SOL and HYPE have different size precision and leverage ceilings, yet the preparation-execution-verification loop stays the same. That consistency matters most when several resting orders remain active, because the next ticket inherits the collateral consequences of every order already on HyperCore.

Before you start with Hyper liquid

Can the confirmation modal be hidden after the first order?

Yes. The order modal includes a "Don't show this again" option after Place Order, which removes the extra confirmation step for later tickets. Hiding the modal does not remove protocol validation, margin checks, tick-size checks, or order-status reporting. The ticket still submits the selected side, size, leverage and instruction, so operators who disable it should keep the same pre-submit field review on the main trading panel.

Which price activates a take-profit or stop-loss order?

The mark price activates take-profit and stop-loss orders. It is distinct from the last trade and combines protocol price inputs, so a trigger can activate without filling at the displayed last price. After activation, a TP/SL market order uses its 10% slippage tolerance, while a TP/SL limit order posts or matches only at its limit price or better.

How are attached TP and SL orders handled after a partial parent fill?

Attached TP and SL children remain untriggered while their parent order is not fully filled. A full parent fill places the children immediately; canceling an entirely unfilled parent cancels them. If a partially filled parent is canceled manually, its attached children are also canceled, so protection for the executed portion must be placed separately. A margin cancellation after a partial fill follows a different rule and places the children as if the parent had filled.

Why did my own crossing order cancel the resting order?

Self-trade prevention cancels the resting order when a new order from the same address would trade against it. No fill occurs between the two instructions, and the crossing order continues through eligible liquidity behind the canceled maker order up to its limit. Verification should therefore show a cancellation rather than a self-fill, with no trading fee deducted for that canceled interaction.

Does a subaccount sign its own order confirmation?

No. A subaccount has no private key, so the master account signs trading actions on its behalf while the action identifies the selected subaccount. The position, balance and open orders belong to that subaccount, not to the agent wallet used only for signing. Confirm the subaccount label before submission because the same master wallet can control several separate trading states.

When does transaction delay protection reject an order?

Transaction delay protection rejects an order when HyperCore has not accepted the action within 15 seconds. The limit prevents an old instruction from arriving after conditions have moved. Disabling that setting permits delayed delivery, which also means repeated submissions can arrive later as separate orders. If the error appears, inspect order status before resubmitting so an accepted action is not duplicated.

Are Arbitrum ETH fees charged when placing a perpetual order?

No. Placing and canceling perpetual orders consumes no Arbitrum ETH because trading actions settle on HyperCore without user-paid gas. ETH is required when the wallet deposits native USDC through the Arbitrum bridge, since that deposit is an EVM transaction. Once USDC is credited, order confirmation draws margin from the HyperCore balance rather than sending another ERC-20 transaction.

How many agent wallets can an account approve for order signing?

One account can approve 1 unnamed agent wallet and up to 3 named agent wallets. Each subaccount permits 2 additional named agents, giving separate signing identities to distinct sessions or processes. An agent wallet signs only; balances and positions remain attached to the master account or chosen subaccount. Replacing an existing unnamed agent approval deregisters the previous unnamed agent.