HIP-1: Hyperliquid's Native Token Standard
How native spot assets are created and indexed inside HyperCore.
HIP 1 is Hyperliquid's permissionless standard for creating native spot tokens inside HyperCore. These assets live in the native financial state machine rather than as ERC 20 contracts on HyperEVM.
That distinction affects how the token is created, identified, traded, and integrated with HyperCore spot markets.
A HIP 1 token is native HyperCore state
An ERC 20 defines balances and transfer rules through EVM contract code. A HIP 1 token is represented directly in HyperCore's native token system.
That makes it suitable for assets whose primary purpose is native spot trading and integration with HyperCore market structure.
The two models can coexist on Hyperliquid. A project may need a native HyperCore asset for order book trading, an EVM representation for smart contract composability, or both depending on product design.
Deployment defines the token's core parameters
A deployer submits a HIP 1 deployment action with token parameters such as name, supply precision, maximum supply, and genesis related settings.
HyperCore assigns a unique token identity used by the protocol to index the asset. Builders should treat that identity as the canonical protocol reference rather than assuming a display ticker alone is globally unique.
This matters for integrations because frontends and APIs need to map human readable symbols to the correct protocol asset.
Deployment capacity is priced through an auction
Hyperliquid does not use a fixed permanent fee for every new HIP 1 deployment. The current design uses a Dutch auction for deployment gas.
The price declines over the auction window toward a floor, while the result of one auction influences the starting level of the next. This makes deployment capacity scarce and market priced without requiring a centralized listing committee.
The exact timing and floor are protocol parameters and should be checked against current documentation before deployment.
Genesis can encode distribution logic
HIP 1 supports genesis balance creation and anchor token mechanics that can reference holders of an existing native token.
That allows a deployment to create proportional distributions based on prior onchain ownership without forcing every project to build a separate claims contract.
Technical transparency does not guarantee economic fairness. A token can be deployed permissionlessly while still having concentrated ownership, poor distribution, or weak market demand.
Creating a token does not create a healthy market
A token becomes tradeable when a spot pair and order book are established. HIP 2 Hyperliquidity can provide automated baseline liquidity for supported pairs.
Independent market makers and users can then quote alongside that liquidity.
Market quality still depends on spread, depth, inventory, demand, and professional liquidity provision. The token standard solves asset creation, not durable price discovery.
HIP 1 versus ERC 20
Use HIP 1 when native HyperCore spot state is the priority. Use ERC 20 style contracts on HyperEVM when arbitrary smart contract behavior and EVM composability are central.
The choice should follow where the asset needs to live and which systems need to interact with it.
Continue reading
Read HIP 2 Hyperliquidity Explained for market bootstrapping and How a Token Launches on HyperCore for the complete deployment sequence.