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, HIP-3 made perpetual futures deployment permissionless for builders who meet the staking requirement, and HIP-4 introduces outcome contracts — binary markets that settle to 0 or 1 in USDH based on whether a specified real-world event occurs.
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 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.
What are Hyperliquid HIPs?
A Hyperliquid Improvement Proposal is a formal, on-chain protocol upgrade mechanism for the Hyperliquid blockchain. Proposals are authored by builders, reviewed by the community, and implemented directly into HyperCore. Governance is HYPE token weighted — any eligible participant can submit a proposal, HYPE holders vote proportional to their stake, and approved changes are integrated into the protocol stack.
This design keeps protocol evolution modular. Each HIP targets one specific domain rather than bundling broad changes into a single upgrade. The chain never forks — the protocol extends.
Hyperliquid architecture overview
HyperCore is the fully on-chain central limit order book (CLOB) at the heart of Hyperliquid. All order books, trades, and liquidations are recorded on-chain with one-block finality. There is no off-chain matching layer. The consensus mechanism is HyperBFT, running on a dual-layer design: HyperCore and HyperEVM.
HyperEVM is an EVM-compatible execution environment on the same L1. 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.
The public API exposes two primary endpoints. The /info endpoint handles all read-only queries: market metadata, order book depth, user state, and fills. The /exchange endpoint handles all signed write operations: order placement, cancellation, leverage updates, and market deployment actions.
Why HIPs matter for builders
HIPs extend HyperCore in a structured way, adding new market types directly into the core matching and settlement engine. Spot markets, perpetuals, and outcome contracts all run on the same CLOB, price-time priority matching engine, account and margin system, and API structure.
This creates a stable integration surface. 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. Differences between HIPs show up as metadata 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. The PURR memecoin was the first live deployment of HIP-1 infrastructure.
Querying spot metadata uses the /info endpoint:
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));
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.
The mechanism operates continuously for supported tokens, contributing to a stable spread and reducing impact cost for early traders. From a builder's perspective, HIP-2 markets are indistinguishable from any other spot market at the API level — 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 this threshold can deploy one perpetual DEX and control market operation: setting oracle prices, configuring leverage limits, and settling markets if needed.
HIP-3 markets have already reached $1B in open interest and $4.8B in 24-hour volume. Silver and Gold commodity perpetuals launched under HIP-3 reached ~$3B and ~$700M weekly volume respectively. The NVDA equity perpetual accumulated over $1.2B in cumulative volume.
💡 Want the full HIP-4 breakdown — outcome contract mechanics, the opening auction, continuous trading, settlement, builder considerations, and code examples? Read the complete article on Chainstack Blog →
HIP-4: Outcome contracts (preview)
HIP-4 was announced February 2, 2026, with testnet infrastructure active from the announcement date. It introduces outcome contracts: fully collateralized binary instruments that settle to exactly 0 or 1 in USDH based on whether a specified real-world event occurs.
Unlike spot and perpetual markets, outcome contracts have no continuous underlying price process, no incremental oracle-driven pricing, and no funding or basis mechanics. Price discovery occurs entirely through the order book during trading; external input appears only at resolution. The staking requirement for deployment is 1,000,000 HYPE — double the HIP-3 requirement. HIP-4 mainnet launches in two phases: curated canonical markets first, permissionless builder deployment second. No date for either phase has been confirmed.
The full article covers the complete HIP-4 mechanics — outcome contract lifecycle (deployment, opening auction, continuous trading, settlement), payoff math, code examples for fetching outcome metadata, and key builder considerations including oracle dependency, expiry-driven load, and staking concentration.
Read the full article on Chainstack Blog → https://chainstack.com/hyperliquid-hips-explained/
Top comments (0)