Hyper liquid is a fast on-chain perpetuals market with liquidation risk

Liquidation begins at the maintenance-margin boundary

Liquidation on Hyper liquid begins when account equity, calculated with the mark price, falls below the required maintenance margin. HyperCore first routes liquidation orders through its public order book; if equity drops below two-thirds of maintenance margin before the book restores the account, the HLP liquidator vault becomes the backstop. There is no separate liquidation clearance fee when an order-book close succeeds.

Maximum leverage varies by asset from 3× to 40×, while a trader selects an integer setting from 1× up to that asset's limit. Maintenance margin equals half the initial margin required at maximum leverage, producing a range from 16.7% of notional for a 3× market to 1.25% for a 40× market. A 10× position backed by 1,000 USDC controls 10,000 USDC of notional, so a 5% adverse move removes 500 USDC before trading fees and funding, as documented in Hyper liquid 101.

The related steps are listed in Hyper liquid guide. Cross margin shares collateral among cross positions, allowing one losing market to consume equity supporting another. Isolated margin confines that exposure to the collateral assigned to one position. For a liquidatable position larger than 100,000 USDC, the first market liquidation order covers 20% of the position; a 30-second cooldown follows, during which later liquidation orders target the entire remaining position.

Trading fees and hourly funding determine carrying cost

Hyper liquid trading costs combine execution fees, order-book price impact, and hourly funding on perpetual positions. At the base tier, perpetual taker and maker rates are 0.045% and 0.015%, while spot taker and maker rates are 0.070% and 0.040%. A 10,000-USDC perpetual fill therefore costs 4.50 USDC as a taker or 1.50 USDC as a maker, before funding and price impact.

Fee tiers use rolling 14-day weighted volume, with spot volume counting twice in the calculation. Funding is a peer-to-peer transfer between long and short positions rather than protocol revenue: the fixed interest component is 0.01% per eight hours, applied as 0.00125% each hour, while the premium component reflects the gap between the contract and oracle prices. The final rate is capped at 4% per hour. HyperCore orders carry no separate network gas charge, and a native USDC withdrawal to Arbitrum costs 1 USDC.

HyperCore turns signed orders into final on-chain trades

On a practical level, HyperCore matches bids and asks by price-time priority, resembling a conventional exchange book while keeping order, cancellation, fill, margin, and liquidation state on-chain. Prices must be integer multiples of each market's tick size, and quantities must respect its lot size. Every order, cancellation, trade, and liquidation settles with one-block finality under HyperBFT.

Eight core order types cover market, limit, stop market, stop limit, take market, take limit, scale, and time-weighted average price orders. Good Til Cancel orders remain until filled or canceled, Add Liquidity Only orders post without immediately crossing, and Immediate or Cancel orders discard any unfilled quantity. A time-weighted order sends a suborder every 30 seconds with 3% maximum slippage; catch-up suborders are limited to three times the normal suborder size.

Validators publish oracle prices approximately every three seconds using weighted market data that includes Binance, OKX, Bybit, and Kraken. The mark price combines three groups of inputs, including the oracle plus a 150-second exponential moving average, internal book and trade data, and external perpetual-market prices. That mark price governs margin, liquidations, unrealized profit and loss, and trigger orders.

Spot, perpetuals, HLP, and HyperEVM serve different purposes

More broadly, HyperCore spot trading exchanges native HIP-1 assets, whereas perpetuals create leveraged long or short exposure without an expiration date. Spot buyers receive the traded asset; perpetual traders hold a derivative whose profit and loss track the underlying oracle index. The order-book model supports limit-price control and visible depth, while hourly funding keeps perpetual prices connected to spot markets.

HLP supplies market-making liquidity, handles backstop liquidations, supplies USDC to Earn, and receives a portion of trading fees. Its deposit lock lasts four days from the latest deposit, and returns reflect the strategies' actual profit and loss. Separate user-created vaults permit managed trading strategies and assign 10% of total profits to the vault owner, while protocol vaults charge no manager profit share.

In most cases, HyperEVM adds Ethereum-compatible applications to the same consensus state. It follows the Cancun execution rules without blob transactions and uses HYPE for gas, while HyperCore supplies the native trading primitives. Builders therefore gain an EVM environment beside a purpose-built order book rather than deploying the matching engine inside a general smart contract.

A wallet, supported collateral, and one deliberate first order

Starting on HyperCore requires an EVM wallet or an email-based account, followed by supported collateral and an enabled trading account. Rabby, MetaMask, WalletConnect, and Coinbase Wallet connect to the trading interface, while email access uses a six-digit sign-in code. The native Arbitrum bridge accepts deposits of at least 5 USDC, and a wallet needs ETH on Arbitrum to pay the deposit transaction's gas.

Decision checklist

• Choose spot when ownership is the objective; choose a perpetual for long or short price exposure without expiry.
• Use isolated margin when collateral must remain confined to one position, or cross margin when several positions should share equity.
• Compare the order size with visible book depth before selecting a market order; use a limit order to set the worst acceptable price.
• Set leverage from 1× upward only after comparing the mark price, maintenance margin, and displayed liquidation price.
• Apply Reduce Only to an exit order when it must shrink exposure without opening a position in the opposite direction.

After a fill, the position panel records size, average entry, mark price, unrealized profit or loss, margin use, and estimated liquidation price. Deposits through the native bridge are credited only after the bridge threshold is met, while withdrawals return to Arbitrum after validator processing, typically within three to four minutes.

HYPE connects staking, fee discounts, and HyperEVM gas

HYPE secures HyperBFT through delegated proof of stake, pays HyperEVM gas, and unlocks trading-fee discounts when staked. Delegating to a validator imposes a one-day lock, while moving unstaked HYPE back to the spot balance takes seven days. Rewards accrue every minute, distribute daily, and automatically compound. An active validator supplies at least 10,000 HYPE in self-delegation, locked for one year.

The staking discount starts at 5% above 10 HYPE, rises to 10% above 100 HYPE, 15% above 1,000 HYPE, and 20% above 10,000 HYPE. The higher thresholds are 30% above 100,000 HYPE and 40% above 500,000 HYPE. On HyperEVM, HYPE uses 18 decimal places and network chain ID 999; both base and priority fees are burned under its EIP-1559 design. The assistance fund also converts allocated trading fees into HYPE and burns the acquired tokens.

dYdX Chain, GMX, and Jupiter Perps make different design choices

The closest decentralized alternatives separate chiefly by their liquidity and execution models. dYdX Chain uses Cosmos SDK and CometBFT, with validators maintaining an in-memory order book before matched trades enter blocks. GMX routes positions against oracle-priced liquidity pools on networks including Arbitrum and Avalanche. Jupiter Perps uses the JLP pool and oracle execution on Solana rather than a central limit order book.

In the usual case, Hyper liquid fits traders who value price-time-priority orders, transparent book depth, one-block finality, and an EVM environment beside the exchange engine. dYdX Chain offers another application-specific blockchain with an order-book interface, while GMX and Jupiter Perps suit users who prefer pool-backed execution. The decisive trade-off is whether resting orders should compete with other traders or execute against protocol liquidity governed by oracle and pool constraints.