Protocol Standards

Hyperliquid Improvement Proposals

HIPs define the standards and mechanisms that power Hyperliquid's native asset and liquidity systems. There are currently three ratified HIPs plus a set of client-side frontend validation checks.

HIP-1: Native Token Standard

HIP-1 defines the standard for deploying native tokens directly on Hyperliquid L1. All tokens automatically receive a spot USDC trading pair on the native order book.

name

Human-readable, max 6 characters. Not required to be unique.

weiDecimals

Minimal unit decimals (e.g. 18 for ETH, 8 for BTC). Range: 0–8.

szDecimals

Minimum tradable decimals on the spot order book. Must satisfy: szDecimals + 5 ≤ weiDecimals.

maxSupply

Maximum and initial supply. Supply may decrease over time from fees or burns.

initialWei

Optional: genesis balances for multisig treasuries or bridge mints.

anchorTokenWei

Optional: distribute genesis supply proportionally to existing HIP-1 holders. Minimum 100,000 token allocation required.

Gas Auction

Deployment uses a 31-hour Dutch auction. Price decreases linearly from an initial price down to 500 HYPE. If the previous auction failed, the starting price is 500 HYPE; otherwise it is 2× the last gas price. The deployer pays once — subsequent steps have no time constraints.

Fee Structure

  • Base token fees: Deployer receives 100% by default. Configurable within 0–100%. Can only decrease over time. Unallocated fees are burned.
  • Quote token fees: Directed to the Assistance Fund. Deployer cannot configure these.
  • Dust settlement: Automatic daily at 00:00 UTC. Balances below 1 lot size with notional ≤$1 USD are aggregated and market-sold. Proceeds are returned proportionally.

The initial deployment step (setting name, szDecimals, weiDecimals) is time-sensitive and irreversible. Always validate on testnet first. Gas cannot be refunded for stuck deployments.


HIP-2: Hyperliquidity

HIP-2 is a fully decentralized, on-chain automated market-making strategy embedded in Hyperliquid's block transition logic. It bootstraps liquidity for HIP-1 tokens during early price discovery — inspired by Uniswap but integrated directly with the native CLOB. It requires no operators; the strategy logic is secured by the same consensus that runs the order book.

spot

The HIP-1 asset being quoted against USDC.

startPx

Initial price for the range.

nOrders

Total number of orders spread across the range.

orderSz

Size of each individual order.

nSeededLevels

Number of bid-side orders funded at launch. Each extra level costs px × sz USDC and reduces genesis supply.

Operational Mechanics

  • Prices are set recursively, each level approximately 0.3% higher than the last.
  • Strategy updates every block after at least 3 seconds have elapsed.
  • Maintains a 0.3% spread every 3 seconds with minimal maintenance requirements.
  • Currently operates only for spot pairs denominated in USDC.

Hyperliquidity Configuration Constraints

0.003
Minimum price gap
4,000
Max orders
100B
USDC ceiling
1B
USDC floor
$10M USDC
Max starting mkt cap
10
Min orders required

Hyperliquidity must represent more than 1% of total supply and require sufficient USDC availability.


HIP-3: Builder-Deployed Perpetuals

HIP-3 enables builders to deploy and operate their own permissionless perpetual DEXs on Hyperliquid L1, with full control over listing assets, fee structures, and market parameters. Builder-deployed perp DEXs share the same high-performance order book infrastructure as the native Hyperliquid exchange.

Permissionless Listing

List any asset as a perpetual without waiting for core team approval.

Custom Fee Recipient

Builders set their own fee recipient address and trading fee share.

OI Caps

Open interest caps per asset protect the overall system from over-exposure.

Shared Liquidity

Operates on the same L1 order book and HyperBFT consensus as the native exchange.


Frontend Checks (Spot Deploy)

These are client-side validation rules that prevent invalid configurations before submitting a spot token deployment. Always test on testnet before deploying to mainnet.

Token Deployment Validation

  • szDecimals must be between 0 and 2.
  • weiDecimals must be between 0 and 8.
  • weiDecimals must be at least szDecimals + 5 (precision requirement).

Deployer Trading Fee Share

  • Must be specified.
  • Must be within 0–100%.

User & Anchor Token Genesis

  • Blacklist user operations cannot be combined with other parameters.
  • Amount entries are limited to 19 digits maximum.
  • Total supply cannot exceed half of MAX_UINT_64 (18,446,744,073,709,551,615).
  • Market cap at minimum Hyperliquidity price cannot exceed $10,000,000 USDC.
  • Cannot assign genesis balances to the Hyperliquidity user.
  • Exactly one of: user address OR existing token must be specified.
  • Existing tokens used as anchors require a minimum 100,000 token allocation.