Hyperliquid Docs
  • About Hyperliquid
    • Core contributors
  • Onboarding
    • How to start trading
    • How to use the HyperEVM
    • Connect mobile via QR code
    • Export your email wallet
    • Testnet faucet
  • HyperCore
    • Overview
    • Bridge
    • API servers
    • Clearinghouse
    • Oracle
    • Order book
    • Staking
    • Vaults
      • Protocol vaults
      • For vault leaders
      • For vault depositors
    • Multi-sig
  • HyperEVM
    • Tools for HyperEVM builders
  • Hyperliquid Improvement Proposals (HIPs)
    • HIP-1: Native token standard
    • HIP-2: Hyperliquidity
    • HIP-3: Builder-Deployed Perpetuals
    • Frontend checks
  • Trading
    • Perpetual assets
    • Contract specifications
    • Margin tiers
    • Fees
    • Builder codes
    • Order book
    • Order types
    • Take profit and stop loss orders (TP/SL)
    • Margining
    • Liquidations
    • Entry price and pnl
    • Funding
    • Miscellaneous UI
    • Auto-deleveraging
    • Robust price indices
    • Self-trade prevention
    • Portfolio graphs
    • Hyperps
    • Market making
  • Validators
    • Running a validator
    • Delegation program
  • Referrals
    • Staking referral program
  • Points
  • Historical data
  • Risks
  • Bug bounty program
  • Audits
  • Brand kit
  • For developers
    • API
      • Notation
      • Asset IDs
      • Tick and lot size
      • Nonces and API wallets
      • Info endpoint
        • Perpetuals
        • Spot
      • Exchange endpoint
      • Websocket
        • Subscriptions
        • Post requests
        • Timeouts and heartbeats
      • Error responses
      • Signing
      • Rate limits
      • Bridge2
      • Deploying HIP-1 and HIP-2 assets
      • Deploying HIP-3 assets
    • HyperEVM
      • Dual-block architecture
      • Raw HyperEVM block data
      • Interacting with HyperCore
      • HyperCore <> HyperEVM transfers
      • Wrapped HYPE
      • JSON-RPC
    • Nodes
      • L1 Data Schemas
Powered by GitBook
On this page
  1. Hyperliquid Improvement Proposals (HIPs)

HIP-2: Hyperliquidity

Motivation

Though HIP-1 is sufficient as a permissionless token standard, in practice it is often crucial to bootstrap liquidity. One of Hyperliquid's core design principles is that liquidity should be democratized. For perps trading, HLP can quote deep and tight liquidity based on CEX perp and spot prices, but a new model is needed for HIP-1 tokens that are in early phases of price discovery.

Hyperliquidity is inspired by Uniswap, while interoperating with a native onchain order book to support sophisticated order book liquidity from end users. HIP-2 is a fully decentralized onchain strategy that is part of Hyperliquid's block transition logic. Unlike conventional automated order book strategies, there are no operators. The strategy logic is secured by the same consensus that operates the order book itself.

Hyperliquidity is parametrized by

  1. spot: a spot order book asset with USDC quote returned by a deployment of HIP-1

  2. startPx: the initial price of the range

  3. nOrders: the number of orders in the range

  4. orderSz: the size of a full order in the range

  5. nSeededLevels: the number of levels that begin as bids instead of asks. Note that for each additional bid level added by incrementing nSeededLevels the deployer needs to fund Hyperliquidity with px * sz worth of USDC. For fixed nOrders, increasing seeded levels decreases the total supply because it reduces the genesis supply of Hyperliquidity.

Each Hyperliquidity strategy has a price range defined recursively px_0 = startPx, px_i = round(px_{i-1} * 1.003). The strategy updates on every block where the block time is at least 3 seconds since the previous update block. After each update:

  1. Strategy targets nFull = floor(balance / orderSz) full ask orders and a balance % orderSz partial ask order if the partial order is nonzero. To the extent that ALO orders are not rejected, these orders are ensured.

  2. Each fully filled tranche is modified to an order of side orderSz on the side with available balance, with the exception of the single partial order from (1) if it exists.

The resulting strategy guarantees a 0.3% spread every 3 seconds. Like smart-contract based pools on general purpose chains, Hyperliquidity requires no maintenance in the form of user transactions. One key improvement is that Hyperliquidity participates in a general purpose order book. Active liquidity providers can join in liquidity provision alongside Hyperliquidity at any time, allowing markets to adapt to increasing demand for liquidity.

PreviousHIP-1: Native token standardNextHIP-3: Builder-Deployed Perpetuals

Last updated 2 months ago