Hyper liquid is easier to use when wallet setup is verified before order confirmation

Hyper liquid is ready for a trader only when the connected address owns the funded HyperCore balance, trading has been enabled, and the order preview reflects the intended market, side, size, margin mode, and leverage. Before confirmation, connect one supported EVM wallet or use email login, fund the displayed address with accepted collateral, and read the modal line by line. Confirmation then submits an order; a fill changes the position, while an unfilled resting limit order appears under Open Orders.

Updated on 28 July 2026

Do not fund the address hidden behind another browser account

The connected EVM address is the account key that owns balances, orders, and positions. The most common setup error is reading one browser account while funding another. An EVM address contains 20 bytes and is displayed as 0x followed by 40 hexadecimal characters, for 42 characters in total. Match the complete address shown in the trading interface with the receiving address in the wallet before moving collateral.

Rabby and MetaMask display the same account state when both hold the same key and derive the same address. Merely changing the wallet extension does not move a HyperCore balance. Selecting a different account inside either extension does. Coinbase Wallet and a WalletConnect session follow the same address rule, so the first and last characters alone should serve as a quick visual cue, not the final comparison.

Two ways to connect to Hyper liquid before funding

The connection route decides who manages the signing key, not which order book receives the trade. A direct EVM wallet keeps the account in Rabby, MetaMask, Coinbase Wallet, or another WalletConnect-compatible client. Email login creates a blockchain address after a 6-digit code is entered, with Privy handling that login path. Both routes end at an address that owns its own HyperCore account state.

The direct route fits an existing EVM account and makes address comparison straightforward. The email route removes the extension prerequisite, yet its generated address remains a real account with independent balances. A BIP-39 recovery phrase, where the wallet uses that standard, has 12, 15, 18, 21, or 24 words. Those words belong to the wallet setup rather than the trading confirmation.

Fund the displayed address through Arbitrum without mixing tokens

The native Arbitrum route moves Circle-issued USDC into the HyperCore balance owned by the sending address. Arbitrum One uses chain ID 42161, and native USDC uses 6 decimal places. ETH pays the Arbitrum transaction fee for the deposit. Later trading actions use HyperCore signatures, so they consume zero Arbitrum ETH.

The native Arbitrum bridge accepts deposits of at least 5 USDC and credits them to the sending address. A transfer below 5 USDC is not credited. The asset must be native USDC on Arbitrum, not USDT, ARB, ETH, or the older bridged token commonly labeled USDC.e. The token symbol, network, amount, and destination address should all agree before the wallet confirms the deposit transaction.

Arrival on Arbitrum is only the first state change. The bridge deposit then becomes a HyperCore account balance for the same address. Wait until that balance appears in the interface before preparing an order; an Arbitrum token balance and a credited trading balance describe different ledgers.

What Enable Trading authorizes

The Enable Trading control on Hyper liquid requests a gas-less signature for the connected account. This authorization opens the order-submission path; it does not transfer USDC, change the selected market, or create a perpetual position. The wallet should display a signing request rather than an Arbitrum gas charge.

The signing format follows Ethereum typed-data conventions such as EIP-712. HyperCore also supports API wallets, called agent wallets, which sign for a master account or subaccount. An agent is a signer only. Account queries still use the actual master or subaccount address, and balances never migrate to the agent address. The distinction matters when a trader sees an enabled session but an apparently empty account in another tool.

One successful authorization is separate from each order decision. The interface can submit trading actions without asking Arbitrum to process a token transaction every time, which explains why ETH is needed for the native deposit yet not consumed by ordinary HyperCore order placement.

Five fields that determine the order preview

The order ticket turns wallet funding into a specific instruction for the onchain order book. Before opening its confirmation modal, the ticket needs a market, direction, order type, size, and margin setting. HyperCore rejects a perpetual order below 10 USDC of notional value, even when enough collateral is present.

• Market: the selected contract, such as BTC or ETH perpetuals.
• Direction: Buy moves exposure in the long direction; Sell moves it in the short direction.
• Order type: Market seeks immediate execution, while Limit adds a price condition.
• Size: the quantity of the underlying unit, subject to that asset's lot precision.
• Margin: Cross or Isolated determines which collateral supports the position.

Leverage completes the size-and-margin relationship. Position notional equals collateral multiplied by leverage, while initial margin equals notional divided by leverage. A 4x setting therefore assigns one quarter of the intended notional as initial margin. Read the notional and margin together; the size field alone does not reveal the collateral committed to a leveraged position.

Cross margin and isolated margin before the preview appears

Margin mode decides how the preview sources collateral. Cross margin shares account collateral across cross positions. Isolated margin confines assigned collateral and profit or loss to one position, and the interface permits margin to be added or removed after that position opens. Some contracts are isolated-only, so Cross is unavailable for them.

Leverage is selected as a whole number from 1x up to the asset's protocol maximum. Published maxima span 3x through 40x across perpetual markets, with the exact ceiling attached to the chosen asset and, for tiered markets, position notional. Initial margin follows 1 divided by selected leverage. Maintenance margin is set at half the initial margin rate calculated at maximum leverage.

The confirmation view should match the intended mode before submission. Under cross margin, unrelated cross positions influence available collateral. Under isolated margin, the allocation belongs to that position. Switching this choice changes the margin state created by a fill, even if the market, direction, and quantity stay identical.

Market, limit, and the three time-in-force choices

Order behavior determines whether confirmation seeks a fill now or creates a resting instruction. A Market order executes against available book liquidity. A Limit order executes only at its limit price or better, and the time-in-force setting controls what happens when that instruction first reaches the book.

Good Til Cancel, or GTC, leaves the unfilled quantity resting. Immediate or Cancel, or IOC, cancels whatever cannot fill immediately. Add Liquidity Only, or ALO, is the post-only choice; it cancels rather than taking liquidity at submission. Reduce Only adds a separate constraint: the order may decrease an existing position, but it cannot enlarge the exposure or open the opposite side.

Price formatting is protocol-defined. Non-integer 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. Size is rounded to the asset's own size decimals. These limits explain a rejected preview when the economic intent is valid but the entered precision is not.

What confirmation changes in account state

The confirmation modal is the final interface gate before an order action reaches HyperCore. It should restate the selected market, side, quantity, order behavior, leverage, margin mode, and the margin implied by those inputs. Closing the modal leaves the account unchanged. Pressing Confirm submits the signed instruction.

A fully filled perpetual order changes the position size and margin accounting for the connected address. An additional fill in the same direction updates the displayed entry price as a size-weighted average. A closing fill preserves the entry price used for the remaining position. If a GTC limit order does not fill, the state change is an open order with reserved requirements rather than a new position.

Partial execution creates both kinds of state at once: the filled quantity affects the position, while the remaining GTC quantity stays in Open Orders. IOC removes the unfilled remainder. ALO either rests as maker liquidity or cancels when it would match immediately.

Verify the fill, resting order, or rejection

Order verification uses three interface records: Positions, Open Orders, and trade history. A market fill belongs in trade history and changes the relevant position row. An unfilled GTC instruction belongs under Open Orders. A rejected order changes neither the position nor the open-order list, so the rejection message is the record to read first.

HyperCore assigns a numeric order ID, while API users may add a 128-bit client order ID represented by 16 bytes of hexadecimal data. Either identifier can locate order status. Useful status values include open, filled, canceled, triggered, and rejected. Partial fills require checking both executed size and remaining size instead of treating the initial quantity as one indivisible event. A sibling page deals with Using Hyper liquid.

Entry price and unrealized profit or loss are interface calculations built from fills, mark price, direction, and position size. The sign convention uses 1 for a long and -1 for a short. Balance and trade records are the underlying accounting state, so a successful confirmation is verified by the resulting record rather than the disappearance of the modal.

Recover from an Establish Connection loop

An Establish Connection loop is a browser-to-wallet session problem before order submission. The funded address and its HyperCore state remain intact while the interface repeatedly asks for connection. First update and enable the wallet extension. Then use Ctrl+Shift+R on Windows or Cmd+Shift+R on macOS for a hard refresh, disconnect the session, and reconnect the intended address.

If the loop continues during an Arbitrum deposit setup, switch the wallet to Ethereum and back to Arbitrum before reconnecting. Rabby, MetaMask, and Coinbase Wallet expose network state differently, so this reset clears a stale network request without changing the address. Importing the same account into another compatible extension also preserves orders, history, and balances because the 42-character address, not the extension brand, identifies the account.

After reconnection, compare the full address again, confirm the HyperCore balance, and check that Enable Trading no longer appears as an unfinished step. Only then rebuild the order ticket. Re-entering its fields avoids carrying an old market, side, or margin choice from the interrupted session into a fresh confirmation.

Questions and answers about Hyper liquid