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.
nameHuman-readable, max 6 characters. Not required to be unique.
weiDecimalsMinimal unit decimals (e.g. 18 for ETH, 8 for BTC). Range: 0–8.
szDecimalsMinimum tradable decimals on the spot order book. Must satisfy: szDecimals + 5 ≤ weiDecimals.
maxSupplyMaximum and initial supply. Supply may decrease over time from fees or burns.
initialWeiOptional: genesis balances for multisig treasuries or bridge mints.
anchorTokenWeiOptional: 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.
spotThe HIP-1 asset being quoted against USDC.
startPxInitial price for the range.
nOrdersTotal number of orders spread across the range.
orderSzSize of each individual order.
nSeededLevelsNumber 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
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.