Author: James Evans (@jimbo_evans)
Compiled by: Deep Tide TechFlow
Deep Tide Guide: This is a complete Hyperliquid Improvement Proposal that suggests introducing a Continuous Clearing Auction mechanism at the protocol layer, allowing new token projects to complete the entire process of capital raising and liquidity launch 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 is extremely detailed in its technical aspects, covering every step from configuration to settlement to security considerations.
Full text 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 my 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 order book (CLOB) environment. During auction registration, project parties select a quote asset from protocol-approved aligned quote assets (such as USDH), creating new demand and utility sources for these assets. Auction proceeds belong to the project party, with a configurable portion automatically providing liquidity for HIP-2 at the Volume Weighted Average Price (VWAP) at the end of the 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 provide insufficient support for capital formation and price discovery of new tokens. Teams natively issuing tokens on @HyperliquidX are still largely forced to raise funds off-chain, manually provide liquidity for HIP-2 with their own capital, and/or list 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 the complete project lifecycle on Hyperliquid and advances Hyperliquid's goal of becoming the blockchain that hosts all finance.
HIP-6 improves Hyperliquid through:
On-Chain Capital Formation: Teams can natively raise capital on Hyperliquid in a single process, with proceeds distributed between the project and automatic HIP-2 liquidity injection.
Fair Price Discovery: The Continuous Clearing Auction discovers the market price over multiple blocks, minimizing the impact of time gaming 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 issued 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 custody by the project party or a trusted third party.
Regarding Naming: This proposal is numbered HIP-6 because HIP-5 was previously assigned to another independent proposal.
What We Are Building Upon
HIP-6 adapts @Uniswap's Continuous Clearing Auction to Hyperliquid's native CLOB environment. A CCA breaks down a large auction into N successive smaller 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, and bidders are incentivized to participate earlier rather than wait.
Various alternatives have significant flaws:
Fixed Price Sales: Poor price discovery because someone must guess the correct price at launch. If the price is set too low, the project loses the spread; if set too high, the sale fails.
Capped Proportional Sales: Fixes value leakage but creates an oversubscription spiral. In practice, if a sale is 2x oversubscribed, rational participants deposit 2x the target allocation, making it even more oversubscribed, and so on. This is a poor user experience.
Uncapped Sales: Avoids the spiral but leads to overfunding. A project that could be built for $5 million raises $50 million because nothing stops it. The 2017 ICO wave showed the consequences of this.
Traditional Auctions: Let the market discover the price but create time gaming. The optimal strategy is to wait as long as possible. This creates a worse user experience for non-institutional participants.
Dynamic Bonding Curves: Combine Dutch auctions with demand-responsive bonding curves. This works well in AMM-native environments but is not suitable for Hyperliquid's CLOB-native environment.
What Can Be Built on Top of HIP-6
HIP-6 solves the capital formation and price discovery problems: how new projects raise funds and inject liquidity on Hyperliquid. It does not address specific token value accumulation mechanisms, token holder protections, or project-specific governance. These are separate issues, and we look forward to teams building on top of HIP-6 to address them.
Examples of what future projects can build on top of HIP-6:
Value Accumulation Mechanisms: Stipulate how protocol revenue flows back to token holders (e.g., fee distribution, buybacks, staking rewards).
Governance Frameworks: Give token holders voting rights over treasury allocation, parameter changes, and/or protocol upgrades.
Token Holder Protections: Provide tools like treasury locks, on-chain reporting requirements, and/or vesting mechanisms, applying locks to both buyer and team allocations.
The goal of HIP-6 is 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 enhance their project's order book liquidity.
Draft Public Documentation
Below is a draft of how HIP-6 might 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. Project parties offer a portion of their token supply for sale through a Continuous Clearing Auction. Bidders commit funds in aligned quote assets (currently USDH). Bidders specify their total budget and the maximum price they are willing to pay per token. The auction then spreads this bid across the remaining blocks. Each block of the auction, the protocol releases tokens at a fixed rate. The protocol then matches the supply of released tokens with the bidders' demand, finding a uniform clearing price for each block. At settlement, a protocol fee is sent to the Aid Fund, a portion of the proceeds is automatically used to provide liquidity for HIP-2 Hyperliquidity at the price discovered in the final window of the auction, and the remainder goes to the project party. All auction logic runs within HyperCore's block transition.
Deploying an Auction
After completing the standard HIP-1 deployment steps (registerToken2, userGenesis (if any), genesis, and registerSpot), the project party calls registerAuction. The project party specifies the following parameters:
auctionSupply: The total amount of tokens to be sold. Transferred from the project party's spot account to protocol escrow at registration.
duration: The auction duration in blocks, maximum 3,024,000 (approx. 1 week at 0.2 sec/block).
floorPx: The minimum clearing price, defaults to 0.
startDelay: The number of blocks between registration and the first clearing block, minimum 1, defaults to 1.
minRaise: The minimum amount of quote asset that must be raised for the auction to be successful, defaults to 0.
quoteAsset: Must be a protocol-approved aligned quote asset (e.g., USDH).
hip2Seed: The basis points of net proceeds (after protocol fees) automatically injected 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 this token until settlement. The project party can cancel the auction via cancelAuction before the auction startBlock (i.e., during the startDelay period).
Bidding
Bidders call submitBid, specifying a budget (minimum 100 units of the quote asset) and maxPx (the 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. Bids submitted in block h become active for clearing starting from block h+1. Bids submitted during the startDelay period activate in the first clearing block.
Bidders can submit multiple bids with different maximum prices to express a demand curve, but there is a maximum of 100,000 bids per auction. Bidders can only withdraw a bid if its maxPx is strictly lower than 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 the cumulative demand meets the supply. Bids with a maxPx strictly above the clearing price receive their full allocation. Bids exactly 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 reached, the auction fails. All aligned quote assets are refunded, all tokens are returned to the project party, and the freeze is lifted. If totalQuoteSpent is zero, the auction fails regardless of minRaise.
Upon 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 party's wallet.
Returns unsold tokens to the project party.
Lifts the token freeze, resuming spot trading, transfers, and EVM operations.
Activates HIP-2 using the project party-specified hip2OrderSz and hip2NOrders. hip2Seed is used to inject 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 the totalQuoteSpent at settlement. All fees flow to the Aid Fund. The project party's existing setDeployerTradingFeeShare applies as usual to spot trading after the auction.
What We Are Building Upon
HIP-6 Hy-CO is a Continuous Clearing Auction embedded in HyperCore's block transition logic. Bidders submit bids in aligned quote assets (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 maxPx is strictly higher than the clearing price receive their full allocation; bidders exactly at the clearing price receive the remainder, potentially getting partially filled. At the end of the auction, the protocol collects fees sent to the Aid Fund, injects a configurable proportion of the remaining proceeds into HIP-2 Hyperliquidity at the VWAP calculated for the final window of the auction, and sends the rest to the project party's wallet. Settlement at the end of the auction is atomic.
Hy-CO Lifecycle
Hy-CO has three phases:
Pre-Auction: Configuration. The project party 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. The budget is escrowed upon submission, regardless of when the bid is submitted. Clearing. Each block from startBlock during the auction, the protocol releases tokens and calculates the uniform clearing price.
Post-Auction: Settlement. In the first block after endBlock, the protocol assesses whether the auction was successful and allocates proceeds. HIP-2 Activation. Upon successful settlement, HIP-2 is automatically activated using seedPx and the order parameters specified by the project party. Claiming. After settlement, bidders claim purchased tokens and unused quote assets via claimAuction. Trading proceeds normally during the claiming period.
Cancellation: cancelAuction can be executed any time before startBlock. It returns auctionSupply and hip2AskSupply to the project party, lifts the freeze, and releases 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 (the same pull-based refund path as a failed auction). The auctionRegistrationFee is non-refundable. After 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. A HIP means every token issued on Hyperliquid (if it chooses to use HIP-6) gets the same fair price discovery and automatic HIP-2 injection, with no external dependencies. It also means the mechanism is guaranteed 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 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. CCA spreads bids over time, clearing at a uniform price per block and 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 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 gains. Bidders holding USDC can convert via standard interfaces.
Why only pre-set linear release schedule: Linearity ensures the clearing price is monotonically non-decreasing, enabling efficient claim-time accounting through cumulative checkpoints. Non-linear schedules (back-weighted, front-weighted) could cause the clearing price to drop when per-block supply jumps, complicating bid-level accounting. These could be introduced in future HIPs, contingent on extending the accounting scheme.
Security Considerations
Project Party Self-Trading: A project party could bid in its own auction via independent wallets to inflate the clearing price and VWAP, then retrieve unsold tokens after settlement. Mitigations include: Protocol fees make self-trading costly across all self-traded volume; seedPx is calculated over a VWAP window covering the last ~5% of the auction, requiring sustained spending to manipulate; minRaise causes the auction to fail if genuine demand is insufficient; all bids are visible on-chain, making self-trading detectable. Quantitatively, a project party running a 1M USDH auction (protocolFee = 500, hip2Seed = 2000), bidding 400k USDH (40% of total) via independent wallets: loses ~20k USDH to the Aid Fund (5% protocol fee, unrecoverable), ~76k USDH is locked into HIP-2 injection (not returned to the project party). Total deadweight loss is ~96k USDH, or 24% of the self-traded capital. Cost scales linearly with self-trade volume.
Seed Price Manipulation: HIP-2's seedPx uses a windowed VWAP covering roughly the last 5% of the auction duration, not the last block's clearing price. Manipulating the VWAP requires sustained spending over multiple blocks within the window, not a single late injection, making the cost proportional to the window's total volume.
Fund Safety: Bidders' quote assets and auction tokens are escrowed by the protocol throughout the process. Funds are never in the custody of the project party. Upon failure, all quote assets are refunded via claimAuction, and all tokens are returned to the project party.
Token Freeze Enforcement: All token transfers (spot order book, peer-to-peer, HyperEVM) are frozen during an active auction. This prevents insiders holding userGenesis allocations or retained project supply from selling tokens via non-auction channels during price discovery.
Bid Activation Delay: Bids only participate in clearing starting 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 on Various Parties
Token Project Parties: Hy-CO provides project parties with a native way to raise capital and inject liquidity in a single process. Project parties configure the auction alongside HIP-1 deployment, receive proceeds into their wallet (minus the hip2Seed portion allocated to HIP-2), and get automatic liquidity injection at the market-discovered price. The trade-off is reduced control over the initial price.
Hyperliquid Users: Users gain the ability to directly participate in the issuance of new team tokens built on Hyperliquid. Currently, there is no native way to buy into projects at launch; users either miss the initial distribution or buy on the public order book after HIP-2 is injected. Hy-CO provides users with a fair entry point with uniform pricing and bid spreading, accessible through the same interface they already use. After settlement, bidders must call claimAuction to move purchased tokens and unused quote assets into their spot account before they can trade. Tokens are not distributed automatically. The spot order book opens only with HIP-2 liquidity; there is no organic limit order depth before market makers and other participants place orders. If many auction participants sell immediately after claiming, HIP-2's buy-side levels may deplete quickly. This is expected behavior for any new listing, not unique to HIP-6, but frontends should clearly show claim status and set the expectation that early post-auction spreads will be wider than in mature markets.
HYPE Holders: Hy-CO benefits HYPE holders in two ways. First, a native issuance mechanism incentivizes new teams to build and issue on Hyperliquid rather than competing chains, growing the ecosystem and directing activity to Hyperliquid's order books. Second, auctions denominated in aligned quote assets (e.g., USDH) grow their utility and reserves, serving as a recurring revenue source supplementing Hyperliquid's trading fees via the Aid Fund.
Liquidity Providers and Market Makers: Post-auction, the order book launches with real buy-side depth funded by auction proceeds (via hip2Seed), not a thinly injected HIP-2. This provides LPs and market makers with a more credible starting price and deeper liquidity to trade from day one.
Validators and State Growth: The clearing cost per block for a single auction is O(T), where T is the number of occupied price ticks. With tickSpacingFactor = 1.003, T is limited to a few thousand ticks, but in practice most auctions will have a few hundred occupied ticks. With maxActiveAuctions = 16, the per-block workload in the worst case is 16 × O(T). Each operation is a comparison and addition on aggregated tick budgets, comparable to the cost of existing spot order book matching. No new cryptographic operations or external reads are required.
Future Work Items
The following are out of scope for this HIP but are natural extensions to evaluate as HIP-6 matures: Governance review of protocol constants; Batch clearing (clearing every K blocks); Non-linear release schedules; Staggered HIP-2 injection; HIP-2 reserve mechanisms; Claim expiration and state cleanup; UI integration.
