Skip to content
DFUHL Docs
DeployStart here1 page
Start here: deploying marketsFoundationWhere a market deployer sits in the house, what you stake, operate and earn under HIP-1, HIP-3 and HIP-4, and a reading order from the standards to running a venue.
DeployThe HIPs6 pages
What a HIP isFoundationA HIP (Hyperliquid Improvement Proposal) lets anyone deploy one kind of market on HyperCore, paid for by auction or backed by a slashable HYPE stake.HIP-1: native token standardPractitionerHIP-1 is the native token standard: a capped-supply token born with a USDC spot order book, paid for through a 31-hour Dutch auction in HYPE.HIP-2: HyperliquidityPractitionerHIP-2, Hyperliquidity, is a market-making strategy built into HyperCore that quotes a new HIP-1 token against USDC on a fixed ladder of 0.3 per cent steps.HIP-3: builder-deployed perpetualsPractitionerHIP-3 lets anyone staking 500k HYPE run a perp dex on HyperCore and publish its oracle, the stake slashed and burned if the deployer's inputs harm the protocol.HIP-4: outcome marketsPractitionerHIP-4 lets a staked deployer list fully collateralised contracts settling between 0 and 1, built from validator-approved templates, which it then settles.How the HIPs composeExpertThe hlPerp keyword lets a HIP-4 band price off any HIP-3 perp, even one its deployer does not own, joining free oracles to bounded payoffs.
DeployDeploy markets7 pages
Deploying a spot token (HIP-1 and HIP-2)ExpertA HIP-1 token deploys in 5 spotDeploy actions: win the gas auction, set genesis balances, fix the supply, register the USDC pair, configure Hyperliquidity.Deploying a perp dex (HIP-3)ExpertA HIP-3 perp dex is created by one signed registerAsset2 action with a non-null schema, from an account with 500k HYPE in its own staking account.Operating a perp dex: oracles, caps, halts and allowlistsExpertRunning a HIP-3 dex means pushing prices every 3 seconds, never faster than every 2.5, and managing caps, funding, margin, fees, halts and sub-deployers.Becoming an outcome deployer (HIP-4)ExpertAn outcome deployer is a Standard-mode account with 500k HYPE in its own staking account that has irreversibly claimed a venue with activateOutcomeDeployer.Outcome templates and keywordsExpertEvery deployer-created HIP-4 market fills a validator-voted template that fixes its wording, side names and typed keywords, one value per keyword.Settling outcomesExpertA deployer settles its outcomes with settleOutcome or settleQuestion2, copying names exactly from outcomeMeta; settled outcomes are pruned but stay readable.Deployer economics and riskExpertA deployer earns a fee share against 500k HYPE locked at least 183 days, slashable and burned, in its own account, which a multi-sig quorum can control.
LearnWhat Hyperliquid is and how it works
Start here
First principles
Consensus and validators
HyperCore
Research
For the press
TradeMarkets, margin and risk
Start here
Trading fundamentals
Perpetuals
Spot
Outcome markets
Accounts and credit
Advanced trading
Incentives
BuildApps, bots and contracts
Start here
Build on HyperCore
Build on the HyperEVM
DeployLaunch and run markets
Start here
The HIPs
Deploy markets
ReferenceEvery number, action and term
Look up
Protocol tables

HIP-2: Hyperliquidity

Practitioner

HIP-2, Hyperliquidity, is a market-making strategy built into HyperCore that quotes a new HIP-1 token against USDC on a fixed ladder of 0.3 per cent steps.

Hyperliquidity gives a new token a market before any market maker arrives. HLP quotes perps off outside prices, and a new token has none. So the protocol posts ordinary orders on the HyperCore book itself.

It runs in the block transition, secured by the same consensus, with no pool, operator, keeper or user transaction; the docs call it inspired by Uniswap. Anyone can quote tighter alongside it.

Say you launch with startPx 0.5, orderSz 10,000, nOrders 400 and nSeededLevels 5. The lowest 5 levels start as USDC bids you fund (the first costs 0.5 x 10,000 = 5,000 USDC), and the other 395 as asks from supply reserved at genesis.

The ladder takes 5 parameters

Section titled “The ladder takes 5 parameters”
Parameter Meaning
spot The token’s spot pair against USDC
startPx The lowest price of the ladder
nOrders How many price levels the ladder has
orderSz The size of one full order, in tokens
nSeededLevels How many of the lowest levels start as bids instead of asks

The ladder starts at px_0 = startPx and spans about 1.003 ** nOrders: 400 levels cover about 3.3x, 1,000 about 20x. For a fixed nOrders, each extra seeded level reduces total supply.

SEEDED BIDS, USDC ASKS, FROM THE TOKEN BALANCE bid bid bid ask ask ask ask ask ask ask px0 px1 px2 px3 px4 px5 px6 px7 px8 px9 x 1.003
At launch the lowest levels are bids, the rest asks. A filled ask at px3 is re-posted as a bid at px3, so best bid and ask stay one 0.3 per cent step apart.

It re-quotes every 3 seconds

Section titled “It re-quotes every 3 seconds”

It updates on the first block at least 3 seconds after its last update. Each update:

  1. Targets floor(balance / orderSz) full asks plus a partial ask of balance % orderSz if non-zero (balance is its token balance). Unless the post-only (ALO) orders are rejected, these asks are guaranteed on the book.
  2. Replaces each fully filled tranche with an orderSz order on the other side: a filled ask becomes a bid, and vice versa.

The docs call it a guaranteed 0.3 per cent spread, refreshed every 3 seconds.

The numbers

Section titled “The numbers”
Parameter Value
Level spacing px_i = round(px_{i-1} * 1.003), 0.3% per level
Update cadence at most once per 3 seconds
Pairs supported spot pairs against USDC only
Cost of one seeded level px * sz USDC
Frontend check: minimum levels 10 orders
Frontend check: share of supply Hyperliquidity must exceed 1% of total supply
Frontend check: smallest order first order worth at least 1 USDC
Frontend check: market cap at startPx at most 10M USDC
Frontend check: market cap at the top level between 1B and 100B USDC

Frontend checks are client-side validations published for deployment tools; the protocol validates separately on submission.

Trading against a predictable counterparty

Section titled “Trading against a predictable counterparty”

For you as a trader, Hyperliquidity is visible and deterministic (trading against it):

  • Its next quote after a fill is predictable from the deployment parameters.
  • A level taken within 3 seconds stays empty until the next update.
  • Once its token balance is bought out, it quotes only bids until someone sells back.
  • Anyone can quote inside its spread.

Configuring it with registerHyperliquidity

Section titled “Configuring it with registerHyperliquidity”

The fifth deployment action sets it up (deploying a spot token):

  • spot is the spot pair index, not the token index; orderSz is in tokens, not wei.
  • With noHyperliquidity at genesis, pass nOrders: 0. Bridged assets usually opt out this way, per the docs.
  • Seeded bids are debited in USDC at registration.
  • With the top price computed as startPx * ceil(1.003 ** nOrders), the two market cap checks require at least 1,535 levels.
  • The Hyperliquidity account cannot be named in userGenesis; its allocation comes from its parameters, or is zeroed by noHyperliquidity.
  • Incompatible supply and Hyperliquidity parameters leave a deployment stuck, gas unrefunded. Rehearse on testnet.

For the token it quotes, see HIP-1: native token standard.