Skip to main content
HIP-3 is HyperLiquid’s permissionless token listing system. It covers spot token registration, hyperliquidity seeding, perp deployment, and the Dutch auction gas fee mechanism. This page documents the full deployment pipeline and the TWAP engine used for large order execution.

SpotDeploy sub-actions

The spotDeploy action is a top-level action containing 13 sub-actions that cover the entire token deployment lifecycle:
Token registration requires winning a gas auction first. See the gas auction section below.

TokenInfo struct

Each deployed token carries comprehensive metadata:
Additional abbreviated fields track deployer permissions, growth modes, and market parameters.

Genesis distribution

Token genesis controls the initial token distribution:
The genesis process is two-step:
  1. userGenesis — set the distribution list with per-address allocations
  2. genesis — finalize and lock the supply, making the token live
Once genesis is called, the supply is locked and cannot be modified.

Hyperliquidity seeding

After registering a spot pair, deployers seed initial liquidity through registerHyperliquidity:
The startPx sets the initial market price. nOrders and nSeededLevels control the depth of the initial order book — more orders at more levels provides tighter spreads and deeper liquidity for early traders.

HLP ensure-orders system

After initial seeding, the HLP system (hyperliquidity_ensure_orders) maintains ongoing liquidity:
The ensure-orders system continuously monitors and replaces filled HLP orders to maintain book depth around the current price.

Gas auctions

All deployments require winning a Dutch auction for gas. Three separate auctions exist:

Dutch auction mechanics

Each auction follows a declining price curve:
The gas price starts high and decays over time. Deployers can execute at any point by paying the current gas price. The decay is constrained by assertion: decay <= 1.0, ensuring the price only decreases.

Auction parameters

Auction status is queryable via the API:
Perp deployment auctions typically start at 1,000 HYPE and spot pair auctions at 500 HYPE. With a 31-hour duration and no floor, patient deployers can get significantly cheaper gas by waiting.

Auction lifecycle

Validators control auction lifecycle through voting:

Token schema

The full token schema (Hip3Schema) defines the market configuration:

Trading limits

Each deployed token has configurable trading limits:

Sub-deployer system

Deployers can authorize sub-deployers with granular permissions:
Sub-deployer operations:
A deployer cannot set themselves as a sub-deployer, and duplicate sub-deployers are rejected. Sub-deployers are limited to the operations explicitly granted in their permission set.

Deployer restrictions

Several validation rules constrain deployer behavior:
  • Growth mode cannot be set when deployer fee scale exceeds 1
  • Growth mode can be blocked by validators
  • Deployer cannot have a staking link
  • Deployer cannot have more than $1M volume traded
  • Deployer must have sufficient stake

Growth modes

Growth modes control how a newly deployed market scales up:

Backstop liquidation

Thin or new markets use a backstop liquidator to ensure positions can always be liquidated:
Validators can vote on backstop parameters via VoteGlobalAction::SetHip3BackstopLiquidatorParams and allow growth modes via ValidatorL1VoteAction::AllowHip3GrowthMode.

Perp deployment

Perpetual markets are deployed separately via perpDeploy:
Deployers can manage perps through SetGlobalAction with variant indices covering operations like registerAsset, setOracle, haltTrading, insertMarginTable, setFeeRecipient, setOpenInterestCaps, setFundingMultipliers, and setFundingInterestRates.

EVM integration

Tokens can be linked to EVM contracts for cross-layer functionality:
  • requestEvmContract — request contract linkage during deploy
  • FinalizeEvmContractAction — finalize the contract binding
  • evmExtraWeiDecimals — additional precision for EVM-side amounts
  • AlignedQuoteSupplyDelta — mint/burn aligned quote token supply (restricted to linked EVM contract)
  • Deployers can send tokens to EVM for frozen users via DeployerSendToEvmForFrozenUserAction

Deployer fee share

Deployers earn a configurable share of trading fees on their markets:
Growth mode cannot be set when deployer_fee_scale is greater than 1. This prevents deployers from simultaneously extracting outsized fees and manipulating growth parameters.

Token registry

The SpotClearinghouse maintains the global token registry:

TWAP engine

HyperLiquid includes a native TWAP (Time-Weighted Average Price) engine for splitting large trades into smaller slices executed over time.

TWAP order format

TWAP state

Each active TWAP order maintains live state:

Execution schedule

The randomize flag adds timing jitter to make TWAP execution less predictable to front-runners.

Slice execution

Each slice produces a TwapSlice — a market order placed into the book:
Slice sizes can be dynamically adjusted via TwapSliceWindowUpdate based on market conditions.

Scheduler

Active TWAP slices are managed in a min-heap (TwapHeapKey) ordered by next_slice_time, allowing efficient O(log n) scheduling of the next slice across all active TWAP orders. Two separate trackers exist in the clearinghouse:
  • twap_tracker — perp TWAP orders
  • spot_twap_tracker — spot TWAP orders

Constraints and validation

Cancellation

TWAP orders can be cancelled via TwapCancelAction:

Query endpoints

Deployment-related data is available through several API endpoints: