Fundraising, Pricing, Market Making All in One Click: HIP-6 Aims to Make Hyperliquid the Go-to Platform for Token Launches

Author: James Evans (@jimbo_evans)

Compiled by: TechFlow

Introduction: This is a comprehensive Hyperliquid Improvement Proposal (HIP) that proposes introducing a Continuous Clearing Auction mechanism at the protocol layer. This allows new token projects to complete the entire process of capital fundraising and liquidity bootstrapping on-chain, without relying on centralized exchanges or third-party platforms.

The author draws inspiration from Uniswap's Continuous Clearing Auction model and redesigns it for Hyperliquid's order book environment. The proposal's technical details are extremely thorough, covering every aspect from configuration to settlement and security considerations.

Full text is as follows:

Special thanks to @fiegemax for providing ideas, guidance, and feedback, and also to @arnx813, @0xBroze, @0xOmnia, @xenoflux, @happenwah, @const_hom, and @DougieDeLuca for their review and comments.

Disclosure: I hold $HYPE in a personal account. I am employed by @recvcx, but this article represents my personal views only 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 natively issuing tokens on @HyperliquidX. This mechanism adapts @Uniswap's Continuous Clearing Auction (CCA) to Hyperliquid's native Central Limit Order Book (CLOB) environment. Projects select a quote asset (e.g., USDH) from protocol-approved aligned quote assets at auction registration, creating new demand and utility sources for these assets. Auction proceeds go to the project, with a configurable portion automatically seeding HIP-2 liquidity at the Volume-Weighted Average Price (VWAP) discovered during the final auction window. All auction logic runs within HyperCore's block transition, requiring no external operators.

Motivation

HIP-1 and HIP-2 support permissionless token deployment and automated liquidity but offer insufficient support for capital formation and price discovery for new tokens. Teams natively issuing tokens on @HyperliquidX are still largely forced to raise funds off-chain, manually seed HIP-2 with their own capital, and/or launch on thin order books. Due to these frictions, Hyperliquid has not yet achieved product parity with other high-performance ecosystems and exchanges in terms of ICO capabilities. @solana has @metadao, @base has @Uniswap's Liquidity Launchpad and @dopplerprotocol, @coinbase has @echodotxyz. HIP-6 is optional, but by enabling more efficient capital formation and price discovery, HIP-6 supports founders who wish to build a complete project lifecycle on Hyperliquid and advances Hyperliquid's goal of becoming the blockchain for all finance.

HIP-6 improves Hyperliquid by:

On-chain Capital Formation: Teams can natively raise funds on Hyperliquid in a single process, with proceeds split between the project and automatic HIP-2 liquidity seeding.

Fair Price Discovery: The Continuous Clearing Auction discovers the market price across multiple blocks, minimizing the time-gaming effects common in traditional auctions.

Aligned Quote Asset Growth: Creates utility for aligned quote assets, thereby increasing their TVL and generating revenue for the Aid Fund.

Attracting Builders: Teams can complete the full token lifecycle on Hyperliquid. More tokens launching on Hyperliquid means more trading fees for the Aid Fund.

Participant Protection: Committed funds are escrowed by HyperCore's state during the auction, not held in the project's custody or by a trusted third party.

On Naming: This proposal is numbered HIP-6 because HIP-5 was previously assigned to a separate, independent proposal.

What We Are Building On

HIP-6 adapts @Uniswap's Continuous Clearing Auction to Hyperliquid's native CLOB environment. A CCA breaks down a large auction into N sequential mini-auctions. Each block, the protocol releases a batch of tokens and calculates a uniform clearing price. Price discovery happens gradually, not at a single moment, incentivizing bidders to participate earlier rather than wait.

Various alternatives have clear drawbacks:

Fixed-Price Sale: Poor price discovery because someone must guess the correct price at launch. Price set too low, the project loses the spread; price set too high, the sale fails.

Capped Proportional Sale: Fixes value leakage but creates an oversubscription spiral. In practice, if a sale is 2x oversubscribed, rational participants will deposit 2x the target allocation, making it even more oversubscribed, and so on. This is a poor user experience.

Uncapped Sale: Avoids the spiral but leads to overfunding. A project that could be built with $5 million raises $50 million because nothing stops it. The 2017 ICO wave demonstrated the consequences of this.

Traditional Auction: Lets the market discover the price but creates time gaming. The optimal strategy is to wait as long as possible. This creates a worse user experience for non-institutional participants.

Dynamic Bonding Curve: Combines a Dutch auction with a demand-responsive bonding curve. This works well in an AMM-native environment but is not suitable for Hyperliquid's CLOB-native environment.

What Can Be Built on Top of HIP-6

HIP-6 addresses capital formation and price discovery: how new projects raise funds and bootstrap liquidity on Hyperliquid. It does not address value accrual mechanisms for specific tokens, protections for token holders, or governance for specific projects. These are separate issues, and we expect teams to build on top of HIP-6 to solve them.

Examples of what future projects could build on top of HIP-6:

Value Accrual Mechanisms: Dictate 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 mechanisms, imposing locks on both buyer and team allocations.

HIP-6 aims to make the initial auction as fair and efficient as possible. What happens after the auction is a design space for the Hyperliquid community. HIP-6 does not prevent teams from working with market makers to strengthen their project's order book liquidity.

Public Documentation Draft

Below is a draft of how HIP-6 could be presented in Hyperliquid's public documentation. It is included here to give reviewers a preview of the user-facing description.

HIP-6: Token Issuance Auction

HIP-6 introduces a permissionless token issuance auction for HIP-1 assets. Projects offer a portion of their token supply for sale via a Continuous Clearing Auction. Bidders commit funds in an aligned quote asset (currently USDH). Bidders specify their total budget and the maximum price they are willing to pay per token. The auction then spreads that bid across the remaining auction blocks. Each block of the auction, the protocol releases tokens at a fixed rate. The protocol then matches the released token supply with bidders' demand to find a uniform clearing price for each block. At settlement, a protocol fee is sent to the Aid Fund, a portion of the proceeds automatically seeds HIP-2 Hyperliquidity at the price discovered in the final auction window, and the remainder goes to the project. All auction logic runs within HyperCore's block transition.

Deploying an Auction

A project calls registerAuction after completing the standard HIP-1 deployment steps (registerToken2, userGenesis (if any), genesis, and registerSpot). The project specifies the following parameters:

auctionSupply: Total tokens to be sold. Transferred from the project's spot account to protocol escrow at registration.

duration: Auction length in blocks, maximum 3,024,000 (~1 week at 0.2 sec/block).

floorPx: Minimum clearing price, defaults to 0.

startDelay: Number of blocks between registration and the first clearing block, minimum 1, defaults to 1.

minRaise: Minimum quote asset raise required for the auction to succeed, defaults to 0.

quoteAsset: Must be a protocol-approved aligned quote asset (e.g., USDH).

hip2Seed: Basis points of net proceeds (after protocol fee) automatically seeded into HIP-2. Range 2,000 to 10,000, defaults to 2,000.

hip2OrderSz and hip2NOrders: HIP-2 order size and number of orders, required.

All parameters are immutable once registered. The token's transfer freeze is activated at registration, blocking all spot orders, transfers, and HyperEVM operations for that token until settlement. The project can cancel the auction via cancelAuction before the auction's startBlock (i.e., during the startDelay period).

Bidding

A bidder calls submitBid, specifying a budget (minimum 100 units of the quote asset) and maxPx (maximum price per token, rounded down to the auction tick grid). The budget is escrowed upon submission. A non-refundable fee of 1 quote asset is charged per bid. The budget is automatically spread evenly across the remaining auction blocks. A bid submitted in block h becomes eligible for clearing starting from block h+1. Bids submitted during the startDelay period activate at the first clearing block.

Bidders can submit multiple bids with different maxPx to express a demand curve, but there is a limit of 100,000 bids per auction. Bidders may only withdraw a bid if its 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 calculates a uniform clearing price by traversing occupied price ticks from highest to lowest until cumulative demand meets supply. Bids with a price strictly above the clearing price receive their full allocation. Bids at the clearing price share the remainder proportionally to their per-block budget. Bids below the clearing price receive nothing. The auction price grid uses a geometric tick spacing of 1.003, consistent with HIP-2.

Settlement, HIP-2 Activation, and Claiming

In the first block after the auction ends, if minRaise is set but not met, the auction fails. All aligned quote assets are refunded, all tokens are returned to the project, and the freeze is lifted. If totalQuoteSpent is zero, the auction fails regardless of minRaise.

On success, the protocol atomically:

Deducts a 500 bp protocol fee from the total quote spent, sending it to the Aid Fund.

Allocates hip2Seed for HIP-2 activation.

Transfers the remainder to the project's wallet.

Returns unsold tokens to the project.

Lifts the token freeze, resuming spot trading, transfers, and EVM operations.

Activates HIP-2 using the project-specified hip2OrderSz and hip2NOrders. hip2Seed is used to seed nSeededLevels levels. The starting price is seedPx, calculated as the Volume-Weighted Average Price (VWAP) over the last 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. A 500 bp protocol fee is charged on total proceeds at settlement. All fees flow to the Aid Fund. The project's existing setDeployerTradingFeeShare applies as usual to spot trading post-auction.

What We Are Building On

HIP-6 Hy-CO is a Continuous Clearing Auction embedded within HyperCore's block transition logic. Bidders submit bids in an aligned quote asset (e.g., USDH), with each bid specifying a budget and a maximum price. Each block, the protocol releases a batch of tokens and calculates a uniform clearing price for that block. Bidders whose maximum price is strictly above the clearing price receive their full allocation; bidders exactly at the clearing price receive the remainder, potentially partially filled. At auction end, the protocol takes a fee sent to the Aid Fund, seeds a configurable portion of the remaining proceeds into HIP-2 Hyperliquidity at the VWAP calculated over the final auction window, and sends the rest to the project's wallet. Settlement at auction end is atomic.

Hy-CO Lifecycle

Hy-CO has three phases:

Pre-Auction: Configuration. The project calls registerAuction after completing standard HIP-1 deployment steps. The protocol validates parameters, escrows the token supply and seller supply, activates the token freeze, and assigns an auction ID.

During Auction: Bidding. Bidders can submit bids via submitBid during the startDelay period or at any point during the auction. Budgets are escrowed upon submission, regardless of when the bid is submitted. Clearing. Each block during the auction, starting from startBlock, the protocol releases tokens and calculates a uniform clearing price.

Post-Auction: Settlement. In the first block after endBlock, the protocol assesses auction success and allocates proceeds. HIP-2 Activation. Upon successful settlement, HIP-2 is automatically activated using seedPx and the project-specified order parameters. Claiming. After settlement, bidders claim purchased tokens and unused quote assets via claimAuction. Normal trading can proceed during the claiming period.

Cancellation: cancelAuction can be executed at any time before startBlock. It returns auctionSupply and hip2AskSupply to the project, lifts the freeze, and frees the auction slot. If bids were submitted during the startDelay period, the auction enters the failure path: bidders retrieve their escrowed quote assets via claimAuction (same pull-based refund path as a failed auction). The auctionRegistrationFee is non-refundable. Once clearing begins, the auction is irrevocable.

Key Design Decisions

Why a New HIP and Not a Third-Party Product: Token issuance is infrastructure, not an application. If every team builds its own issuance mechanism, the ecosystem fragments. An HIP means every token launched on Hyperliquid (if it chooses to use HIP-6) gets the same fair price discovery and automatic HIP-2 seeding, with no external dependencies. It also means the mechanism is secured by validator consensus, not a third party.

Why HyperCore and Not HyperEVM: Everything needed for HIP-6 already exists on HyperCore. Building on HyperEVM would introduce unnecessary complexity, degrading the user experience by adding steps and latency.

Why a Continuous Clearing Auction: Traditional auctions create time gaming that rewards speed over valuation; bonding curves are path-dependent; fixed-price sales require guessing the correct price. A CCA spreads bids over time, clearing at a uniform price per block, converging over thousands of blocks rather than resolving at a single moment.

Why Only Allow Aligned Quote Assets: Auctions are denominated in aligned quote assets (currently USDH). Each auction locks up the quote asset for its duration, growing TVL and generating yield for the ecosystem. Supporting non-aligned assets like USDC would dilute this effect for marginal adoption gain. Bidders holding USDC can convert via standard interfaces.

Why Only a Linear Release Schedule by Default: Linearity ensures the clearing price is