The Ultimate Form of On-Chain IPO? A Comprehensive Analysis of Hyperliquid’s HIP-6 Proposal
TechFlow Selected TechFlow Selected
The Ultimate Form of On-Chain IPO? A Comprehensive Analysis of Hyperliquid’s HIP-6 Proposal
Hyperliquid plans to introduce Hy-CO, a permissionless token launch auction system, fundamentally rewriting the rules for on-chain IPOs.
Navigating Web3 tides with focused insightsAuthor: James Evans (@jimbo_evans)
Translation & Editing: TechFlow
TechFlow Intro: This is a comprehensive Hyperliquid Improvement Proposal (HIP) introducing a continuous clearing auction mechanism at the protocol layer—enabling new token projects to complete their entire capital-raising and liquidity-launch workflow on-chain, without relying on centralized exchanges or third-party platforms.
The author adapts Uniswap’s Continuous Clearing Auction (CCA) model to Hyperliquid’s order-book environment, with a full technical redesign. The proposal is exceptionally detailed, covering every aspect from configuration and settlement to security considerations.
Full Text Below:
Special thanks to @fiegemax for conceptual input, guidance, and feedback—and to @arnx813, @0xBroze, @0xOmnia, @xenoflux, @happenwah, @const_hom, and @DougieDeLuca for their review and comments.
Disclosure: I hold $HYPE in my personal account. I am employed by @recvcx, but this article reflects only my personal views and does not represent the position of Reciprocal Ventures.
Abstract
HIP-6 introduces a permissionless token issuance auction mechanism for HIP-1 assets, specifically designed for teams launching tokens natively on @HyperliquidX. It adapts Uniswap’s Continuous Clearing Auction (CCA) to Hyperliquid’s native Central Limit Order Book (CLOB) environment. During auction registration, project teams select one of the protocol-approved aligned quote assets (e.g., USDH) as the quote asset, thereby creating new demand and utility for those assets. Proceeds accrue entirely to the project team, with a configurable portion automatically deployed into HIP-2 liquidity via volume-weighted average price (VWAP) over the final auction window. All auction logic executes within HyperCore’s block transition—no external operators required.
Motivation
HIP-1 and HIP-2 support permissionless token deployment and automated liquidity, yet provide insufficient support for capital formation and price discovery for new tokens. Teams launching natively on @HyperliquidX remain largely forced to raise funds off-chain, manually seed HIP-2 liquidity using their own capital, and/or launch onto thin order books. These friction points mean Hyperliquid has yet to achieve product parity with other high-performance ecosystems and exchanges on ICO capability. @solana has @metadao, @base has @Uniswap’s Liquidity Launchpad and @dopplerprotocol, and @coinbase has @echodotxyz. HIP-6 is optional—but by enabling more efficient capital formation and price discovery, it empowers founders who wish to build full project lifecycles on Hyperliquid, advancing Hyperliquid’s goal of becoming the blockchain for all finance.
HIP-6 improves Hyperliquid in the following ways:
On-chain capital formation: Teams can natively raise capital on Hyperliquid in a single workflow, with proceeds split between the team and automatic HIP-2 liquidity seeding.
Fair price discovery: Continuous clearing auctions discover market price across multiple blocks, minimizing time-based gaming common in traditional auctions.
Growth of aligned quote assets: Creates utility for aligned quote assets, increasing their TVL and generating yield for the Safety Fund.
Attracting builders: Teams can execute the full token lifecycle on Hyperliquid. More tokens launched on Hyperliquid means more trading fees flowing to the Safety Fund.
Participant protection: Committed funds are held in custody by HyperCore’s state during the auction—not by the project team nor by any trusted third party.
Naming note: This proposal is numbered HIP-6 because HIP-5 was previously assigned to another independent proposal.
What We’re Building On
HIP-6 adapts Uniswap’s Continuous Clearing Auction (CCA) to Hyperliquid’s native CLOB environment. CCA decomposes a large auction into N progressively sequential smaller auctions. Each block, the protocol releases a batch of tokens and computes a uniform clearing price. Price discovery occurs gradually—not at a single point—and bidders are incentivized to participate earlier rather than wait.
All alternative mechanisms have clear drawbacks:
Fixed-price sale: Poor price discovery—someone must guess the correct opening price. If priced too low, the project forfeits value; if too high, the sale fails.
Capped pro-rata sale: Fixes value leakage but creates an oversubscription spiral. In practice, if a sale is oversubscribed 2×, rational participants deposit 2× their target allocation—making it even more oversubscribed, ad infinitum. A poor user experience.
Uncapped sale: Avoids the spiral but leads to overfunding. A project that needs $5M to build raises $50M because nothing prevents it. The 2017 ICO boom demonstrated the consequences.
Traditional auction: Enables market-driven price discovery but induces time-based gaming. The optimal strategy is to wait until the last possible moment—worsening UX for non-institutional participants.
Dynamic bonding curve: Combines Dutch auction mechanics with demand-responsive curves. Works well in AMM-native environments but is ill-suited to Hyperliquid’s CLOB-native architecture.
What Can Be Built on Top of HIP-6
HIP-6 solves capital formation and price discovery: how new projects raise funds and seed liquidity on Hyperliquid. It does not address specific token value accrual mechanisms, token-holder protections, or governance models for individual projects. These are separate concerns—and we expect teams to build solutions atop HIP-6.
Examples of future projects built on HIP-6:
Value accrual mechanisms: Specify how protocol revenue flows back to token holders (e.g., fee distribution, buybacks, staking rewards).
Governance frameworks: Grant token holders voting rights over treasury allocations, parameter changes, and/or protocol upgrades.
Token-holder protections: Provide tools like treasury locks, on-chain reporting requirements, and/or vesting schedules—applying locks to both buyer and team allocations.
HIP-6 aims to make the initial auction as fair and efficient as possible. What happens after auction settlement is the design space of the Hyperliquid community. HIP-6 does not prevent teams from collaborating with market makers to enhance order-book liquidity for their projects.
Draft Public Documentation
Below is a draft of how HIP-6 would appear in Hyperliquid’s public documentation. Included here so reviewers can preview the user-facing description.
HIP-6: Token Issuance Auction
HIP-6 introduces a permissionless token issuance auction for HIP-1 assets. Project teams offer a portion of their token supply for sale via a continuous clearing auction. Bidders commit aligned quote assets (currently USDH). Bidders specify their total budget and maximum price per token. The bid is then spread across remaining auction blocks. Each auction block, the protocol releases tokens at a fixed rate. The protocol matches released supply against bidder demand to determine a uniform clearing price per block. At settlement, protocol fees are sent to the Safety Fund; a portion of proceeds is automatically seeded into HIP-2 Hyperliquidity at the VWAP discovered over the final auction window; the remainder goes to the project team. All auction logic runs within HyperCore’s block transitions.
Deploying an Auction
After completing standard HIP-1 deployment steps (registerToken2, userGenesis [if applicable], genesis, and registerSpot), the project team calls registerAuction, specifying the following parameters:
auctionSupply: Total tokens offered for sale. Transferred from the project’s spot account into protocol custody upon registration.
duration: Auction duration in blocks, capped at 3,024,000 (~1 week at 0.2 sec/block).
floorPx: Minimum clearing price; defaults to 0.
startDelay: Number of blocks between registration and first clearing block; minimum 1, default 1.
minRaise: Minimum quote-asset amount required for auction success; defaults to 0.
quoteAsset: Must be a protocol-approved aligned quote asset (e.g., USDH).
hip2Seed: Basis points of net proceeds (after protocol fees) automatically seeded into HIP-2. Range: 2,000–10,000; default: 2,000.
hip2OrderSz and hip2NOrders: HIP-2 order size and number of orders—both required.
All parameters are immutable once registered. Token transfers are frozen upon registration, blocking all spot orders, transfers, and HyperEVM operations for that token until settlement. The project may cancel the auction via cancelAuction before the auction’s startBlock (i.e., during startDelay).
Bidding
Bidders call submitBid, specifying a budget (minimum 100 units of the quote asset) and maxPx (maximum price per token, rounded down to the auction tick grid). Budget is placed in custody upon submission. Each bid incurs a non-refundable fee of 1 quote asset unit. Budget is automatically evenly distributed across remaining auction blocks. A bid submitted in block h becomes effective for clearing starting in block h+1. Bids submitted during startDelay activate at the first clearing block.
Bidders may submit multiple bids with different maxPx values to express a demand curve—but no more than 100,000 bids per auction. Bids may be withdrawn only if their maxPx is strictly below the most recent clearing price.
Clearing
Each block during the auction, the protocol releases tokens at a fixed rate (auctionSupply / duration per block) and computes a uniform clearing price by traversing occupied price ticks from highest to lowest until cumulative demand meets supply. Bids above the clearing price receive full allocation. Bids at the clearing price share the residual supply proportionally to their per-block budget. Bids below the clearing price receive nothing. The auction price grid uses geometric tick spacing of 1.003—consistent with HIP-2.
Settlement, HIP-2 Activation, and Claiming
In the first block after auction end, if minRaise is set but unmet, the auction fails. All aligned quote assets are refunded, all tokens returned to the project, and the freeze lifted. If totalQuoteSpent is zero, the auction fails regardless of minRaise.
Upon success, the protocol atomically:
Deducts a 500 bp protocol fee from total quote spent and sends it to the Safety Fund.
Allocates the hip2Seed portion for HIP-2 activation.
Transfers the remainder to the project’s wallet.
Returns unsold tokens to the project.
Lifts the token freeze, restoring spot trading, transfers, and EVM operations.
Activates HIP-2 using the project-specified hip2OrderSz and hip2NOrders. hip2Seed seeds nSeededLevels levels. The seed price (seedPx) is computed as the VWAP over the final 5% of the auction duration.
After settlement, bidders claim purchased tokens and unused quote assets via claimAuction.
Fees
A 10 HYPE registration fee is charged at registerAuction. Each submitBid incurs a fee of 1 quote asset unit. A 500 bp protocol fee is levied on total proceeds at settlement. All fees flow to the Safety Fund. The project’s existing setDeployerTradingFeeShare applies normally to post-auction spot trading.
What We’re Building On
HIP-6 Hy-CO is a continuous clearing auction embedded directly in HyperCore’s block transition logic. Bidders submit bids denominated in aligned quote assets (e.g., USDH), each specifying a budget and maximum price. Each block, the protocol releases a batch of tokens and computes a uniform clearing price for that block. Bidders whose max price is strictly above the clearing price receive full allocation; those exactly at the clearing price receive partial allocation of the residual supply. At auction close, the protocol charges fees to the Safety Fund, seeds a configurable portion of remaining proceeds into HIP-2 Hyperliquidity at the VWAP computed over the final auction window, and sends the rest to the project’s wallet. Settlement at auction close is atomic.
Hy-CO Lifecycle
Hy-CO has three phases:
Pre-auction: Configuration. After completing standard HIP-1 deployment steps, the project calls registerAuction. The protocol validates parameters, places auction supply and seller supply in custody, activates token freeze, and assigns an auction ID.
During auction: Bidding. Bidders may submit bids via submitBid at any time—including during startDelay or throughout the auction. Budget is placed in custody upon submission, regardless of timing. Clearing. Starting at startBlock, each block the protocol releases tokens and computes a uniform clearing price.
Post-auction: Settlement. In the first block after endBlock, the protocol evaluates auction success and allocates proceeds. HIP-2 activation. After successful settlement, HIP-2 auto-activates using seedPx and the project’s specified order parameters. Claiming. After settlement, bidders claim purchased tokens and unused quote assets via claimAuction. Normal trading remains available during claiming.
Cancellation: cancelAuction may be executed anytime before startBlock. It returns auctionSupply and hip2AskSupply to the project, lifts the freeze, and frees the auction slot. If bids were submitted during startDelay, the auction enters the failure path: bidders reclaim their custodied quote assets via claimAuction (same withdrawal-based refund path as failed auctions). The auctionRegistrationFee is non-refundable. Once clearing begins, the auction is irreversible.
Key Design Decisions
Why a new HIP instead of a third-party product: Token issuance is infrastructure—not an application. If every team builds its own issuance mechanism, the ecosystem fragments. An HIP ensures that every token launched on Hyperliquid (opting into HIP-6) receives identical fair price discovery and automatic HIP-2 seeding—without external dependencies. It also means the mechanism is secured by validator consensus—not a third party.
Why HyperCore instead of HyperEVM: Everything HIP-6 requires already exists in HyperCore. Building on HyperEVM would introduce unnecessary complexity, degrading UX through added steps and latency.
Why continuous clearing auction: Traditional auctions reward speed—not valuation—inducing time-based gaming; bonding curves are path-dependent; fixed-price sales require guessing the right price. CCA spreads bids across time, clears at a uniform price per block, and converges over thousands of blocks—not at a single instant.
Why only aligned quote assets: Auctions are priced exclusively in aligned quote assets (currently USDH). Each auction locks quote assets for its duration—growing TVL and generating ecosystem yield. Supporting non-aligned assets like USDC would dilute this effect with marginal adoption gains. Bidders holding USDC can convert via standard interfaces.
Why only linear release schedules: Linearity ensures the clearing price is monotonic non-decreasing—a property that enables efficient claim-time accounting via cumulative checkpoints. Non-linear schedules (back-weighted, front-weighted) could cause clearing prices to drop when per-block supply jumps—complicating bid-level accounting. These may be introduced in future HIPs, contingent on extended accounting schemes.
Security Considerations
Project self-trading: A project could bid in its own auction via an independent wallet to inflate the clearing price and VWAP, then reclaim unsold tokens post-settlement. Mitigations include: protocol fees impose high cost on all self-trade volume; seedPx is calculated over a VWAP window covering the final 5% of the auction—requiring sustained expenditure to manipulate; minRaise causes auction failure under insufficient real demand; all bids are on-chain and thus detectable. Quantitatively, for a $1M USDH auction (protocolFee = 500 bp, hip2Seed = 2000 bp), a project bidding $400K USDH (40% of total) would incur ~$20K USDH in Safety Fund fees (5% non-recoverable protocol fee) and ~$76K USDH locked into HIP-2 seeding (non-refundable to the project). Total deadweight loss ≈ $96K USDH—or 24% of self-trade capital. Cost scales linearly with self-trade volume.
Seed price manipulation: HIP-2’s seedPx uses a windowed VWAP covering roughly the final 5% of auction duration—not the clearing price of the last block. Manipulating VWAP requires sustained spending across multiple blocks in the window—not a single late-stage injection—making cost proportional to total volume in the window.
Fund safety: Bidder quote assets and auction tokens are held in protocol custody throughout. Funds are never held by the project. Upon failure, all quote assets are refunded via claimAuction; all tokens returned to the project.
Token freeze enforcement: All token transfers (spot order book, P2P, HyperEVM) are frozen during active auctions. This prevents insiders holding userGenesis allocations or reserved project supply from selling tokens outside the auction during price discovery.
Bid activation delay: Bids only enter clearing in the block after submission. This prevents block proposers or low-latency participants from observing pending bids and inserting reactive bids in the same block to influence the clearing price.
Impact Analysis Across Stakeholders
Token project teams: Hy-CO provides a native way to raise capital and seed liquidity in a single workflow. Teams configure the auction alongside HIP-1 deployment, receive proceeds in their wallet (net of the hip2Seed portion allocated to HIP-2), and obtain automatic liquidity seeding at the market-discovered price. The trade-off is reduced control over initial pricing.
Hyperliquid users: Users gain direct access to participate in token issuances from new teams building on Hyperliquid. Currently, there is no native way to buy tokens at launch—users either miss the initial distribution or buy on the public order book after HIP-2 liquidity is seeded. Hy-CO offers users a fair entry opportunity with uniform pricing and time-distributed bidding—accessible via the same interface they already use. Post-settlement, bidders must call claimAuction to move purchased tokens and unused quote assets into their spot account before trading. Tokens are not auto-distributed. The spot order book opens only with HIP-2 liquidity—no organic limit-order depth exists until market makers and other participants place orders. If many bidders sell immediately after claiming, HIP-2’s bid side may deplete rapidly. This is expected behavior for any new listing—not unique to HIP-6—but frontends should clearly indicate claim status and set expectations that early post-auction spreads will be wider than mature markets.
HYPE holders: Hy-CO benefits HYPE holders in two ways. First, a native issuance mechanism incentivizes new teams to build and launch on Hyperliquid instead of competing chains—growing the ecosystem and directing activity toward Hyperliquid’s order book. Second, auctions priced in aligned quote assets (e.g., USDH) increase their utility and reserves, serving as a cyclical revenue source to replenish Hyperliquid’s trading fees via the Safety Fund.
Liquidity providers and market makers: Post-auction, the order book launches with genuine bid-side depth funded by auction proceeds (via hip2Seed)—not a thin HIP-2 injection. This gives LPs and market makers a more credible starting price and deeper liquidity from day one.
Validators and state growth: Per-block clearing cost for a single auction is O(T), where T is the number of occupied price ticks. With tickSpacingFactor = 1.003, T is bounded to several thousand ticks—but in practice most auctions occupy only hundreds. With maxActiveAuctions = 16, worst-case per-block workload is 16 × O(T). Each operation involves comparisons and additions over aggregated tick budgets—comparable in cost to existing spot order-book matching. No new cryptographic operations or external reads are required.
Future Work Items
The following fall outside the scope of this HIP but represent natural extensions to evaluate as HIP-6 matures: governance review of protocol constants; batch clearing (clearing every K blocks); non-linear release schedules; phased HIP-2 seeding; HIP-2 reserve mechanisms; claim expiration and state cleanup; UI integration.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@jimbo_evans
