Hyper liquid is a trading blockchain for USDC-margined perpetuals

Hyper liquid is a trading blockchain where perpetuals - futures without expiry - use USDC as collateral and orders meet in a public onchain book. HyperCore processes spot and derivative orders, liquidations, and funding under HyperBFT consensus, while wallet signatures keep account control with the trader. The interface resembles a centralized exchange, yet matching and settlement belong to the layer-one state rather than a private database.

Updated on 24 July 2026

Bottom line: It is a layer-one trading blockchain with onchain spot and USDC-margined perpetual order books.

Liquidation follows the mark price, not the last trade

More broadly, Hyper liquid perpetual positions liquidate when account equity falls below maintenance margin, using a mark price that combines validator oracle inputs with order-book state. The last traded price alone does not determine the event. Cross margin shares one USDC collateral pool across cross positions, whereas isolated margin confines the allocated collateral and liquidation consequences to one position.

Assets support maximum leverage from 3x to 40x, and users select an integer from 1x up to that market's limit. Maintenance margin equals half the initial margin required at maximum leverage: it is 1.25% for a 40x market and about 16.7% for a 3x market. If book execution cannot restore compliance and equity falls below two-thirds of maintenance margin, the liquidator vault becomes the backstop. Positions above 100,000 USDC receive an initial 20% partial-liquidation order, followed by a 30-second cooldown.

From a signed order to one-block settlement

HyperCore is the chain's matching, margin, spot, and perpetual execution engine. A signed action reaches an API server, passes to a node, and enters the transaction order agreed through HyperBFT, a proof-of-stake consensus design derived from HotStuff. Every accepted order, cancellation, trade, and liquidation receives one-block finality in the layer-one state.

This architecture preserves the familiar bids, asks, spreads, resting limit orders, and market orders of an exchange order book. It differs mechanically from an automated market maker, where a trader exchanges against a pool and a pricing function. Because the book itself is onchain, market makers and traders observe the same committed sequence rather than relying on an operator's private matching record.

Directional trades, hedges, spot purchases, and market making

Once that is set, HyperCore spot and perpetual markets serve several distinct trading jobs. A perpetual changes exposure without transferring ownership of the referenced asset, while a spot fill exchanges one token balance for another. Perpetual profit, loss, margin, and funding for the main markets are accounted in USDC.

• Open a long perpetual when seeking positive exposure to BTC, ETH, SOL, or another listed market.
• Open a short perpetual to express negative exposure without borrowing the underlying token.
• Hedge spot holdings with an opposing perpetual position, while accounting for basis and funding.
• Pair spot and perpetual positions for a market-neutral basis or funding strategy.
• Quote resting bids and asks through the API as an onchain market maker.

A hedge is not static. Funding changes the carrying cost, spot and perpetual prices can diverge, and position size must be rebalanced when the underlying holding changes. Spot purchases also behave differently from perpetual exposure: the buyer receives a token balance, while a perpetual records a margined contract position with no expiry date.

Funding, trading fees, and the cost of holding a position

Perpetual trading costs combine execution fees, spread or price impact, and periodic funding. The base perpetual tier charges 0.045% for taker fills and 0.015% for maker fills. Tier qualification uses rolling 14-day weighted volume, with spot volume counting at 2x its nominal amount. Funding is separate from protocol trading fees and moves directly between long and short position holders.

Funding is exchanged every hour, while the formula computes an eight-hour rate and applies one eighth at each hourly interval. The fixed interest component is 0.01% per eight hours, equivalent to 0.00125% per hour, before the premium adjustment. The premium is sampled every 5 seconds from the difference between impact prices and the oracle price. Positive funding makes longs pay shorts; negative funding reverses the direction. The protocol caps funding at 4% per hour.

A hypothetical position from margin to net profit

A perpetual example makes the moving parts concrete without using a live market quote. Every changing input in this example is hypothetical: an isolated long uses 1,000 USDC of collateral, 4x leverage, a $200 entry, a $205 exit, a 0.04% fee on each fill, two positive hourly funding payments of 0.002% paid by the long, a $200 oracle price for both payments, and zero slippage.

Hypothetical calculation

The opening notional is 4,000 USDC, so the position contains 20 units. Closing at $205 produces a gross gain of $100. The entry fee is $1.60, the exit fee on 4,100 USDC is $1.64, and two funding payments total $0.16. Subtracting $3.40 in combined costs leaves $96.60 in net profit, producing a hypothetical closing balance of 1,096.60 USDC.

Move native USDC from Arbitrum before the first order

The canonical Hyper liquid entry path deposits native USDC from Arbitrum into the trading account. A trader connects an EVM wallet such as Rabby, MetaMask, or Coinbase Wallet, or uses a wallet reached through WalletConnect; email-based access is another supported route. Enabling trading requires a gasless signature. The external wallet needs native USDC plus ETH for the Arbitrum deposit transaction, and the canonical bridge enforces a minimum deposit of 5 USDC.

After the balance appears, select a perpetual market, enter the size, choose cross or isolated margin, set leverage, and use a market or limit order. The resulting position panel shows entry price, margin, unrealized profit or loss, funding, and liquidation price. A reduce-only order closes exposure without opening an opposite position. Returning USDC through the canonical Arbitrum withdrawal route costs 1 USDC and requires no ETH from the user; more than two-thirds of validator staking power must sign the withdrawal.

Order controls that determine execution

On a practical level, HyperCore order controls decide whether an instruction takes liquidity, rests on the book, triggers later, or only reduces an existing position. Market and limit orders cover immediate and price-constrained execution. Good Til Cancel orders remain available until filled or canceled, Immediate or Cancel orders discard any unfilled quantity, and Post Only orders cancel rather than taking liquidity on arrival.

Stop Market, Stop Limit, Take Market, and Take Limit instructions activate at a chosen trigger price. Scale orders distribute multiple limits across a range. TWAP divides a larger instruction into suborders submitted every 30 seconds, with each suborder constrained to 3% maximum slippage. When execution falls behind schedule, a catch-up slice remains capped at 3x the normal suborder size. Reduce Only prevents a closing instruction from reversing the position.

Two execution environments under HyperBFT

Across most deployments, HyperCore and HyperEVM are the chain's two execution components, and both inherit the same HyperBFT consensus. HyperCore contains the native order books, clearinghouse, bridge accounting, staking, and vault logic. HyperEVM supplies an Ethereum-compatible smart-contract environment alongside that trading engine, allowing Solidity applications to share the broader chain state.

The HyperEVM mainnet uses chain ID 999, and its native HYPE balance has 18 decimal places. Its execution target is Ethereum's Cancun specification without blobs, including the EIP-1559 fee mechanism. HYPE pays HyperEVM gas, while both base fees and priority fees are burned. These responsibilities are separate from USDC margin in HyperCore perpetual markets, so the trading collateral and smart-contract gas asset serve different purposes.

dYdX Chain, GMX, Drift, and Jupiter use different liquidity designs

dYdX Chain, GMX, Drift, and Jupiter Perpetuals are established onchain alternatives with different execution primitives. dYdX Chain operates a decentralized order book on an application-specific Cosmos SDK chain using CometBFT. GMX routes trades against GM and GLV liquidity pools on networks including Arbitrum and Avalanche, using Chainlink Data Streams rather than a central limit order book.

On Solana, Drift represents resting orders through its decentralized limit order book and routes unmatched flow toward an automated market maker. Jupiter Perpetuals uses liquidity supplied through the JLP pool. Choosing Hyper liquid makes the most sense when native onchain bids and asks, USDC margin, resting maker orders, and direct API interaction are the deciding mechanisms. A pooled-liquidity venue instead suits a trader who prefers oracle-priced execution against shared reserves.

Hyper liquid questions worth asking