Hyperliquid HIPs Explained: HIP-1 to HIP-4

TL;DR

Hyperliquid Improvement Proposals (HIPs) are formal, on-chain protocol upgrades governed by HYPE token holders. Each proposal targets a specific domain: HIP-1 introduced the native token standard and spot order books, HIP-2 embedded an automated liquidity mechanism into HyperCore to solve the cold-start problem for new token launches, and HIP-3 made perpetual futures deployment permissionless for builders who meet the staking requirement.

HIP-4, announced February 2, 2026, is the most recent addition. It introduces outcome contracts, binary markets that settle to 0 or 1 in USDH based on whether a specified real-world event occurs. These markets run natively on HyperCore, sharing the same CLOB infrastructure, matching engine, and account system as spot and perpetual markets. Each market moves through a deployment phase, an opening auction, continuous trading, and a final settlement triggered by an authorized oracle.

All of this runs on HyperCore, a fully on-chain central limit order book with one-block finality, paired with HyperEVM for general smart contract execution. The two environments share state, and the public API exposes the same endpoints across all market types, making it straightforward for builders to extend existing integrations to new primitives as each HIP activates.

Prerequisite

• Basic understanding of Hyperliquid
• Familiarity with common DeFi terminologies

📖 It is recommended to read the following blogs about Hyperliquid before you dive into the blog below to get an in-depth understanding about Hyperliquid’s architecture.

What are Hyperliquid HIPs?

Hyperliquid Improvement Proposal (HIP) is a formal, on-chain protocol upgrade mechanism for the Hyperliquid blockchain. The proposals are authored by builders, reviewed by the community, and implemented directly into HyperCore, the high-performance trading engine at Hyperliquid’s core.

The governance model is HYPE token weighted. Any eligible participant can submit a proposal. HYPE holders vote on it, proportional to their stake. If a proposal crosses the approval threshold, the core team integrates it into the protocol stack.

This design keeps protocol evolution modular. Each HIP targets one specific domain like token standards, liquidity mechanisms, perpetual markets, and outcome markets rather than bundling broad changes into a single upgrade. This modularity means builders can integrate one primitive at a time without re-architecting existing systems. Hence, the chain never forks but the protocol extends.

Hyperliquid architecture overview

Before examining Hyperliquid HIPs individually, it helps to understand the execution environment: HyperCore and HyperEVM.

HyperCore and HyperEVM shared execution model

HyperCore is the fully on-chain central limit order book (CLOB) at the heart of Hyperliquid. All order books, trades, and liquidation is recorded on-chain with one-block finality. There is no off-chain matching layer. This is architecturally significant: the order book state is part of the blockchain state.

The consensus mechanism is HyperBFT providing Byzantine Fault Tolerance, runs on a dual-layer design: HyperCore and HyperEVM

HyperCore is paired with HyperEVM, an EVM-compatible execution environment on the same L1. HyperEVM allows Solidity developers to deploy contracts that interact with HyperCore primitives. Standard Ethereum tooling: ethers.js, viem, Foundry, Hardhat works without modification.

The two environments share state but are optimized for different workloads: HyperCore handles the high-frequency trading loop, HyperEVM handles general smart contract execution.

📖 For a deeper look at how Hyperliquid’s RPC and API layer works in practice, see What is Hyperliquid? RPC, API, and trading infrastructure.

API structure: /info and /exchange

The public API exposes two primary endpoints. The /info endpoint handles all read-only queries: market metadata, order book depth, user state, and fills.

const options = {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    type: 'activeAssetData',
    user: '0x31ca8395cf837de08b24da3f660e77761dfb974b',
    coin: 'BTC'
  })
};
fetch('<https://hyperliquid-mainnet.core.chainstack.com/API_KEY/info>', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

The /exchange endpoint handles all signed write operations: order placement, cancellation, leverage updates, and (for HIP-3/HIP-4) market deployment actions. To know more about authentication on Hyperliquid, read the following documentation to understand L1 actions and user signed actions for administrative operations: https://docs.chainstack.com/docs/hyperliquid-authentication-guide

Why Hyperliquid HIPs matter for builders

HIPs extend HyperCore in a structured way, adding new market types directly into the core matching and settlement engine. Each proposal introduces a new instrument class while keeping the underlying execution model unchanged.

For builders, this creates a stable integration surface. Spot markets, perpetuals, and outcome contracts all run on the same:

• central limit order book (CLOB)
• price-time priority matching engine
• account and margin system
• API structure (/info for reads, /exchange for writes)

Hyperliquid HIPs directly reduce the amount of new infrastructure you need to build every time Hyperliquid introduces a new market type.

When a new HIP goes live, that same pipeline continues to work. Supporting a new market becomes a matter of extending your data model rather than redesigning your system.

For example: A bot built for spot under HIP-1 can route orders to perpetuals under HIP-3 using the same execution logic. The same bot can trade HIP-4 outcome markets by adjusting position sizing and payoff logic, while reusing order handling, signing, and state tracking

In practice, this means a trading system built for one market type already supports the others at a structural level. Differences between HIPs show up as metadata (e.g. asset type, expiry, oracle config) rather than requiring new infrastructure.

HIP-1: Native token standard

HIP-1 established the formal fungible token standard on Hyperliquid. It introduced a governance-based process for new spot token listings and the on-chain spot order books that back them.

Querying spot metadata uses the /info endpoint:

// Fetch spot market metadata
const options = {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({type: 'spotMeta'})
};
fetch('<https://hyperliquid-mainnet.core.chainstack.com/API_KEY/info>', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

The PURR memecoin was the first live deployment of HIP-1 infrastructure. With HIP-2, native liquidity was added for full on-chain spot markets.

HIP-2: Hyperliquidity mechanism

HIP-2 introduced an on-chain liquidity mechanism embedded directly into HyperCore. When a new spot token launches, Hyperliquidity automatically places buy and sell orders around the current price, seeding the order book with depth before any human market maker participates.

When PURR/USDC launched, Hyperliquidity seeded initial depth instantly, real trades executed before any external liquidity provider connected. This solves the cold-start problem that makes new token launches illiquid at inception.

The mechanism operates continuously for supported tokens, contributing to a stable spread and reducing the impact cost for early traders. From a builder’s perspective, HIP-2 markets are indistinguishable from any other spot market at the API level. The same order book query, same asset index, same fill events.

HIP-3: Permissionless perpetuals

HIP-3 was activated on Hyperliquid mainnet in October 2025. It made the deployment of perpetual futures markets permissionless. The staking requirement for mainnet is 500k HYPE.

A builder meeting the staking requirement can deploy one perpetual DEX. Within that DEX, they control market operation: setting oracle prices, configuring leverage limits, and settling markets if needed. The stake is slashable if a builder triggers invalid state transitions or the oracle price moves more than 50% relative to the start-of-day price without a validator review.

The ecosystem tracker at trade.xyz, the primary builder deploying under HIP-3, exceeded $2B in single-day volume. Silver and Gold commodity perpetuals launched under HIP-3 reached ~$3B and ~$700M weekly volume respectively, with Hyperliquid holding the deepest on-chain liquidity for gold perpetuals. The NVDA equity perpetual accumulated over $1.2B in cumulative volume. The total market volume reached $4.8B in 24 hours.

📖 If you’re building on top of these markets, this guide walks through how to build a Hyperliquid trading bot from order book data to live execution.

HIP-4: Outcome contracts

HIP-4 was announced February 2, 2026, with testnet infrastructure active from the announcement date. It introduces a new primitive to HyperCore called outcome contracts: fully collateralized binary instruments that settle to exactly 0 or 1 in USDH based on whether a specified real-world event occurs.

Earlier Hyperliquid HIPs (HIP-1, HIP-2, HIP-3) operate on assets with continuous price discovery. Spot and perpetual markets evolve through incremental price updates, with mechanisms like liquidity provisioning (HIP-2) or oracle-guided pricing and constraints (HIP-3) ensuring smooth transitions over time. Outcome contracts follow a different structure:

• No continuous underlying price process: The instrument represents the probability of a discrete event, bounded in [0,1], rather than tracking an asset price
• No incremental oracle-driven pricing: Price discovery occurs entirely through the order book during trading; external input appears only at resolution
• Step-function settlement: The market transitions in a single update from trading price p to final outcome r ∈ {0,1}, instead of converging gradually
• No funding or basis mechanics: Valuation derives directly from expected payoff, removing the need for funding rates or index alignment

This shifts HyperCore from a purely financial trading engine into a generalized marketplace for probabilistic outcomes, while still using the same order book, matching engine, and account system.

Outcome contracts run natively in HyperCore. They share the same CLOB infrastructure, the same matching engine, and the same trading account system as spot and perpetual markets. There is no separate application, side-chain, or EVM contract handling the primary settlement path.

The contract price at any moment represents the market’s implied probability that the specified event will occur. A contract trading at 0.65 implies the market assigns a 65% probability to the event occurring.

The contract price p at any point in time is entirely order-book driven. There is no external oracle feeding the market price during trading. The price range is bounded [0.001, 0.999] throughout the trading period, representing the market’s implied probability of the YES outcome.

Buying YES at price P:

Profit if event occurs = 1 - P Loss if event does not = P

Buying NO at price P:

Profit if event does not occur = P Loss if event occurs = 1 - P

At resolution, a single authorized oracle update sets r ∈ {0, 1}. Trading halts. Resting orders are cancelled. All positions settle to their final PnL.

Every HIP-4 outcome market moves through certain phases. Let’s go through each of them from deployment of the market to settlement.

Deployment

A builder deploys an outcome market into a slot within their event DEX. The staking requirement is 1,000,000 HYPE, double the HIP-3 requirement. This stake is slashable if the builder attempts oracle manipulation or triggers invalid state transitions. Slashed HYPE is burned.

Event DEXes are designed with multiple market slots. Once a market resolves, its slot is immediately available for a new event. A single 1M HYPE stake can power a rolling series of markets without requiring re-participation in the deployment auction each time.

A recurring market for the price of $HYPE is deployed every 15 minutes. Check out one instance here:

• Hash: unique identifier for the deployment
• Block: the block where the market was created
• Time: deployment timestamp
• User: address that initiated the action
• Type: action used to register the market
• class:priceBinary: a binary outcome market (YES/NO)
• underlying:HYPE: the asset being tracked
• expiry:20260401-1845: when this specific market resolves
• targetPrice:38: the outcome condition
• period:15m: new markets are deployed every 15 minutes

Each instance (recurring, 15 mins) asks a simple question: will $HYPE be above or below the targetPrice at the specified expiry?

Opening Auction

Rather than opening into continuous trading directly, each market starts with a single-price clearing auction lasting approximately 15 minutes. This removes first-mover advantage and produces a fair opening price based on the full distribution of submitted orders.

During this window, participants submit orders but no matching happens during collection. At the end of the window, the engine runs through all candidate prices

• The opening price p*selected is the one that the one where the most contracts can trade (max matched volume)
• All orders are on the better side of p* fill first.
• Orders exactly at p* share the remaining volume pro rata. Every execution prints at p* (one opening price)
• Unfilled orders carry forward into continuous trading at their original limit prices

Continuous Trading

After the auction clears, the market enters continuous CLOB trading with price-time priority. The mark price is derived from the order book mid-price rather than an external oracle. There is no funding, and price discovery is entirely peer-driven. The valid price range is [0.001, 0.999]. No leverage is permitted.

// Fetch outcome metadata
const options = {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({type: 'outcomeMeta'})
};
fetch('<https://hyperliquid-testnet.core.chainstack.com/API_KEY/info>', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

Settlement

When the event resolves, the authorized oracle posts the final outcome via VoteGlobalAction.

Trading halts immediately upon settlement. All open positions auto-close in USDH. If a challenge window was configured, oracle outputs can be disputed before settlement finalizes. After settlement, the slot is recycled and available for a new event.

This transaction represents the settlement of an outcome market:

• outcome:2916: the specific market being settled
• settleFraction:0: the market resolves to NO (0)
• details:"price:37": the final observed price used for settlement

This was a priceBinary market: Will $HYPE be above 38 at expiry?

At resolution, the observed price was 37, which is below the target : 38.

As a result:

• NO resolves to 1 (wins)
• YES resolves to 0 (loses)

Builder tools and ecosystem

Platforms like Polymarket (built on Polygon) and Kalshi operate with collateral pools isolated from the rest of DeFi. HIP-4 enables prediction market functionality with USDH settlement, cross-margin against other Hyperliquid positions, and HyperCore execution speed.

If this excites you to build on Hyperliquid, refer the below links for core references for understanding HIPs, APIs and existing implementations:

• Hyperliquid HIPs: The official documentation by Hyperliquid to all the HIPs Overview of all Hyperliquid Improvement Proposals, including architecture and design goals
• API & SDKs: Complete API & SDKs documentation for trading, data access, and integration
• Trade.xyz: Early HIP-3 deployer for commodity and equity perpetual markets
• Outcome.xyz: Early HIP-4 builder focused on event-driven DEXs and outcome markets
• Chainstack: Dedicated RPC infrastructure with WebSocket support, optimized for trading bots, indexers, and production systems
• Liquid Terminal HIP-4 Docs: Reverse-engineered documentation from bytecode and live transactions; unofficial documentation
• HypeDexer Testnet Overview: Explorer and dataset reference for tracking outcome markets and on-chain activity

📖 For a practical example of tracking on-chain activity across these markets, see How to build a Hyperliquid on-chain activity tracker.

Key considerations for HIP-4

Integrating with HIP-4 outcome markets involves assumptions that differ from perpetuals. Builders should account for these before deploying production systems.

• Oracle dependency: Settlement depends on an authorized oracle posting a correct binary outcome. If the oracle is compromised or posts an incorrect result, traders can dispute within the challenge window, but resolution may take time. Builders constructing automated strategies around outcome markets should model dispute scenarios in their settlement logic.
• Expiry-driven load: When multiple outcome markets resolve simultaneously, HyperCore processes a burst of margin recalculations and balance updates. Production integrations should anticipate this load pattern. WebSocket subscriptions handle resolution events more reliably than polling REST endpoints during these windows.
• Staking concentration: The 1,000,000 HYPE staking requirement for HIP-4 deployment (versus 500,000 for HIP-3) reflects the additional complexity of oracle-dependent instruments. Not every team will be able to meet this threshold. Market creation will be concentrated among well-capitalized builders in the early phases.
• Validator set size: As of early 2026, Hyperliquid’s validator set has grown to 21 validators. Smaller validator sets increase the importance of monitoring governance decisions that affect validator composition.
• No official HIP-4 specification: Hyperliquid has published no formal HIP-4 spec. Community documentation at Liquid Terminal was produced by reverse-engineering bytecode and transaction data from testnet. Builders should treat this documentation as exploratory and validate behavior directly against testnet before committing to production patterns.
• Mainnet phase: HIP-4 mainnet will launch in two phases: curated canonical markets first, permissionless builder deployment second. Builders cannot deploy their own markets on mainnet until phase two. No date for either phase has been confirmed.

Conclusion

Hyperliquid HIPs represent a deliberate approach to protocol evolution: modular, governance-driven, and additive. Each proposal extends HyperCore with a focused primitive without requiring existing integrations to be rearchitected. HIP-1 laid the foundation with a native token standard, HIP-2 solved liquidity bootstrapping, HIP-3 opened perpetual market deployment to builders, and HIP-4 brings outcome contracts natively into the same execution environment.

HIP-4 in particular expands what builders can construct on Hyperliquid. Outcome contracts open the door to prediction market functionality, event-driven structured products, and cross-market arbitrage, all settled in USDH and margined within the same account as other Hyperliquid positions. Early volume data from HIP-3 deployments like commodity and equity perpetuals points to real demand for these kinds of builder-deployed primitives.

HIP-4 is still on testnet, with permissionless deployment following canonical markets in phase two. But the infrastructure is already live and the API surface is consistent with every prior HIP. Builders who start integrating now will be positioned before the market opens. Get a Hyperliquid RPC endpoint on Chainstack to start building.

FAQ

Related Reading

• What is Hyperliquid? RPC, API, and trading infrastructure
• How to build a Hyperliquid trading bot
• How to build a Hyperliquid on-chain activity tracker
• Best Hyperliquid RPC providers in 2026
• Most cost-effective Hyperliquid RPC providers in 2026
• Mastering Hyperliquid — full guide series