HIP-2 Hyperliquidity Explained
How Hyperliquid bootstraps native spot liquidity with a protocol-level automated order-book strategy.
HIP 2, called Hyperliquidity, is a protocol level strategy for bootstrapping liquidity in supported HIP 1 spot markets. It automates liquidity provision but expresses that liquidity as orders inside HyperCore's central limit order book.
The design combines AMM style automation with ordinary order book execution.
HIP 2 solves the first liquidity problem
A new token can exist technically without having a usable market. If no one quotes bids and asks, price discovery is weak and even small trades can move the price sharply.
Hyperliquidity provides a deterministic baseline strategy that can seed both sides of a supported spot market. This gives the market an initial source of executable liquidity while leaving the book open to everyone else.
It does not guarantee that the market becomes deep. Independent market makers, traders, and long term demand still determine whether liquidity improves after launch.
The deployer configures a price ladder
The strategy is initialized with parameters that define the market, starting price, order distribution, and inventory.
Hyperliquidity then places a ladder of orders across prices according to the protocol's documented rules. As orders fill, inventory moves between the token and quote asset and the strategy can reposition its remaining liquidity.
The exact ladder spacing, supported quote assets, and update rules are protocol parameters. Builders should verify current documentation before designing around them.
Execution still happens on the CLOB
A trader does not enter a separate pool when trading against Hyperliquidity. The automated orders sit in the same HyperCore order book as other bids and asks.
This means independent market makers can quote tighter prices and stand ahead of HIP 2 liquidity. Retail limit orders can also join the same book.
The market therefore preserves ordinary order book competition. Hyperliquidity provides baseline inventory rather than exclusive control over the execution venue.
Why this differs from a conventional AMM
A conventional AMM holds assets in a smart contract pool and calculates a trade price directly from its pool logic.
HIP 2 uses automation to create and manage resting orders. The resulting trade still follows order book rules.
This is why AMMs vs Order Books is not a strict either or distinction on Hyperliquid. Automated liquidity can feed an order book without becoming a separate pool based venue.
Protocol execution removes an offchain operator dependency
The strategy is part of Hyperliquid's native logic rather than a market making bot that someone must keep online.
That removes one operational dependency from the baseline liquidity process. The market can still depend on external market makers for tighter spreads and deeper books, but the core HIP 2 strategy does not disappear because a specific server went offline.
Inventory risk still exists
Automated liquidity provision does not remove market risk. If the token reprices sharply, the strategy can accumulate one side of the pair as orders fill.
A deployer should therefore understand how initial inventory, price range, market demand, and later professional liquidity interact rather than treating HIP 2 as guaranteed price support.
Continue reading
Read HIP 1: Hyperliquid's Native Token Standard for token creation and How a Token Launches on HyperCore for the full sequence from deployment auction to an open market.