Author: James Evans (@jimbo_evans)

Translation: Deep Tide TechFlow

Deep Tide Guide: This is a complete Hyperliquid Improvement Proposal proposing the introduction of a continuous liquidation auction mechanism at the protocol layer, allowing new token project teams to complete the entire process of capital raising and liquidity launch on-chain, without relying on centralized exchanges or third-party platforms.

The author drew from Uniswap's continuous liquidation auction model and redesigned it for Hyperliquid's order book environment, with the proposal's technical details being extremely comprehensive, covering every aspect from configuration to settlement to security considerations.

The full text is as follows:

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

Disclosure: I hold $HYPE in my personal account. I am employed by @recvcx, but this article only represents my personal views and does not reflect the position of Reciprocal Ventures.

Abstract

HIP-6 introduces a permissionless token issuance auction mechanism for HIP-1 assets, specifically designed for teams issuing tokens natively on @HyperliquidX. This mechanism adapts @Uniswap's Continuous Liquidation Auction (CCA) to Hyperliquid's Central Limit Order Book (CLOB) native environment. Project teams select one aligning quote asset (such as USDH) from a protocol-approved list of assets during auction registration, creating new sources of demand and utility for these assets. The auction proceeds belong to the project team, a configurable portion of which will automatically inject liquidity into HIP-2 through a volume-weighted average price at the end of the auction window. All auction logic runs within the block transitions of HyperCore, without the need for external operators.

Motivation

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

HIP-6 improves Hyperliquid in the following ways:

On-chain capital formation: Teams can raise funds natively on Hyperliquid in a single process, with proceeds distributed between the project team and automatic liquidity injection into HIP-2.

Fair price discovery: Continuous liquidation auctions discover market prices across multiple blocks, minimizing the influence of time games commonly found in traditional auctions.

Growth of aligning quote asset utility: Creating utility for aligning quote assets increases their TVL and generates revenue for the aid fund.

Attracting builders: Teams can complete the full lifecycle of tokens on Hyperliquid. Issuing more tokens on Hyperliquid means the aid fund receives more transaction fees.

Participant protection: Committed funds are held in custody by HyperCore's state during the auction, not under the control of project teams or trusted third parties.

Regarding naming: This proposal is numbered HIP-6 because HIP-5 was previously assigned to another independent proposal.

What We Are Building On

HIP-6 adapts @Uniswap's Continuous Liquidation Auction to Hyperliquid's CLOB native environment. CCA decomposes a large auction into N smaller progressively interdependent auctions. Each block, the protocol releases a batch of tokens and calculates a uniform liquidation price. Price discovery occurs gradually, rather than at a single moment, incentivizing bidders to participate earlier rather than waiting.

There are significant flaws in various alternatives:

Fixed price sales: Poor price discovery because someone has to guess the correct opening price. If the price is set too low, the project loses the spread; if set too high, the sale fails.

Proportional allocation sales with caps: Fixes value leakage but creates a spiral of oversubscription. In practice, if the sale is oversubscribed by 2x, rational participants will deposit 2x the target quota, leading to further oversubscription, and so on. This results in a poor user experience.

Unlimited sales: Avoids the spiral but leads to over-funding. A project that could be built for 5 million raises 50 million because nothing prevents it. The 2017 ICO boom showcased the consequences of this approach.

Traditional auctions: Allow market price discovery but create time games. The optimal strategy is to wait as long as possible. This results in a worse user experience for non-institutional participants.

Dynamic combined curves: Combine Dutch-style auctions with demand-responsive combined curves. This works well in AMM native environments but is unsuitable for Hyperliquid's CLOB native environment.

What Can Be Built on HIP-6

HIP-6 addresses capital formation and price discovery issues: how new projects can raise funds and inject liquidity on Hyperliquid. It does not involve mechanisms for value accumulation of specific tokens, protections for token holders, or governance for specific projects. These are separate issues, and we look forward to teams building on HIP-6 to address them.

Future projects that could be built on HIP-6 include:

Value accumulation mechanisms: Specify how protocol revenues are cycled back to token holders (e.g., fee distributions, buybacks, staking rewards).

Governance frameworks: Grant token holders voting rights over treasury allocation, parameter changes, and/or protocol upgrades.

Protections for token holders: Provide tools like treasury locking, on-chain reporting requirements, and/or vesting mechanisms to place locks on both buyers' and team quotas.

The goal of HIP-6 is to make the initial auction as fair and efficient as possible. What happens after the auction ends is the design space for the Hyperliquid community. HIP-6 does not prevent teams from cooperating with market makers to enhance their project's order book liquidity.

Draft of Public Documentation

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

HIP-6: Token Issuance Auction

HIP-6 introduces permissionless token issuance auctions for HIP-1 assets. Project teams offer to sell a portion of their token supply through continuous liquidation auctions. Bidders commit funds in aligning quote assets (currently USDH). Bidders specify their total budget and the maximum price they are willing to pay for each token. The auction then distributes that bid across the remaining auction blocks. For each auction block, the protocol releases tokens at a fixed rate. The protocol then matches the supply of released tokens with the demand of bidders, finding a uniform liquidation price for each block. Upon settlement, protocol fees are sent to the aid fund, and a portion of the proceeds automatically injects liquidity into HIP-2 Hyperliquidity at the price discovered in the final auction window, with the remainder going to the project team. All auction logic runs within the block transitions of HyperCore.

Deploying the Auction

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

auctionSupply: Total amount of tokens for sale. Transferred from the project team's spot account to protocol custody at registration.

duration: The duration of the auction in blocks, up to a maximum of 3,024,000 (approximately 1 week at 0.2 seconds/block).

floorPx: Minimum liquidation price, default is 0.

startDelay: Number of blocks between registration and the first liquidation block, with a minimum of 1, default is 1.

minRaise: Minimum amount of quote asset required for a successful auction, default is 0.

quoteAsset: Must be a protocol-approved aligning quote asset (such as USDH).

hip2Seed: Basis points of net proceeds (after protocol fees) automatically injected into HIP-2. Range from 2,000 to 10,000, default is 2,000.

hip2OrderSz and hip2NOrders: Size and quantity of HIP-2 orders, required fields.

All parameters once registered cannot be changed. Transfers of each token are frozen upon registration, preventing any spot orders, transfers, and HyperEVM operations related to that token until settlement. The project team can cancel the auction via cancelAuction before the auction's startBlock (during the startDelay period).

Bidding

Bidders call submitBid, specifying the budget (minimum of 100 units of the quote asset) and maxPx (the highest price per token, rounded down to the auction tick grid). The budget is held at submission. Each bid incurs a non-refundable fee of 1 quote asset. The budget is evenly distributed across the remaining auction blocks at submission. Bids submitted in block h are valid starting in block h+1. Bids submitted during the startDelay period activate in the first liquidation block.

Bidders can submit multiple bids with different maximum prices to express a demand curve, but up to 100,000 bids per auction. Bidders may only withdraw their bids if the bid's maxPx is strictly below the latest liquidation price.

Liquidation

During each block of the auction, the protocol releases tokens at a fixed rate (auctionSupply / duration per block) and calculates a uniform liquidation price by traversing occupied price ticks from highest to lowest until accumulated demand meets supply. Bids above the liquidation price receive their full quota. Bids at the liquidation price share the remaining portion proportionally to their budgets per block. Bids below the liquidation 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 aligning quote assets are refunded, and all tokens are returned to the project team, with frozen status lifted. If totalQuoteSpent is zero, the auction fails irrespective of minRaise.

If successful, the protocol atomically:

Deducts 500bp protocol fees from total quote spent, sent to the aid fund.

Allocates hip2Seed for HIP-2 activation.

Transfers the remaining portion to the project team wallet.

Returns unsold tokens to the project team.

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

Activates HIP-2, using project team-specified hip2OrderSz and hip2NOrders. hip2Seed is used to inject into nSeededLevels levels. The starting price is calculated using the volume-weighted average price over the last 5% of auction duration.

After settlement, bidders claim purchased tokens and unused quote assets via claimAuction.

Fees

A registration fee of 10 HYPE is charged upon registerAuction. Each submitBid incurs a fee of 1 quote asset. A protocol fee of 500bp is charged on total proceeds at settlement. All fees flow into the aid fund. The project team's existing setDeployerTradingFeeShare applies to spot trading following the auction.

What We Are Building On

HIP-6 Hy-CO is a continuous liquidation auction embedded in HyperCore's block transition logic. Bidders submit bids in aligning quote assets (such as USDH), with each bid specifying a budget and maximum price. For each block, the protocol releases a batch of tokens and calculates a uniform liquidation price for that block. Bidders with maximum prices strictly higher than the liquidation price receive their full quota; bidders at the liquidation price receive the remainder, which may be partially filled. At the end of the auction, the protocol collects fees sent to the aid fund and injects a configurable portion of the remaining proceeds into HIP-2 Hyperliquidity at the volume-weighted average price calculated during the final auction window, with the remainder sent to the project team wallet. The settlement at the end of the auction is atomic.

Hy-CO Lifecycle

Hy-CO has three stages:

Pre-auction: Configuration. The project team calls registerAuction after completing the standard HIP-1 deployment steps. The protocol verifies parameters, holds token supply and seller's supply in custody, activates token freeze, and assigns auction ID.

During the auction: Bidding. Bidders can submit bids at any point during the startDelay period or throughout the auction via submitBid. Budgets are held at submission, regardless of when bids are submitted. Liquidation. For each block starting from startBlock during the auction, the protocol releases tokens and calculates the uniform liquidation 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 project team-specified order parameters. Claiming. After settlement, bidders claim purchased tokens and unused quote assets via claimAuction. Normal trading is permitted during the claiming period.

Cancellation: cancelAuction can be executed at any time before startBlock. It returns auctionSupply and hip2AskSupply to the project team, lifts the freeze, and releases auction slots. If bids were submitted during the startDelay period, the auction enters the failure path: bidders retrieve the held quote assets via claimAuction (same withdrawal process as for failed auctions). The auctionRegistrationFee is non-refundable. Once liquidation begins, the auction is irrevocable.

Key Design Decisions

Why a new HIP instead of third-party products: Token issuance is infrastructure, not an application. If each team builds their own issuance mechanism, the ecosystem will become fragmented. HIP means that every token issued on Hyperliquid (if opting to use HIP-6) can achieve the same fair price discovery and automatic HIP-2 injection without external dependencies. It also means the mechanism is secured by validator consensus, not third parties.

Why choosing HyperCore rather than HyperEVM: Everything required for HIP-6 already exists on HyperCore. Building on HyperEVM would introduce unnecessary complexity and decrease user experience by adding steps and delays.

Why continuous liquidation auctions: Traditional auctions create time games rewarding speed rather than valuation; combined curves are path-dependent; fixed price sales require guessing the right price. CCA spreads bids over time, liquidating at a uniform price for each block and converging over thousands of blocks, rather than solving it all at a single moment.

Why only allowing aligning quote assets: Auctions are priced in aligning quote assets (currently USDH). Each auction locks quote assets for its duration, growing TVL and generating revenue for the ecosystem. Supporting non-aligning assets like USDC would dilute this effect. Bidders holding USDC can convert through standard interfaces.

Why only preset linear release plans: Linear ensures that liquidation prices do not decrease, achieving efficient accounting at the time of claim. Non-linear plans (post-weighted, pre-weighted) may cause liquidation prices to drop when supply spikes at each block, complicating accounting for bid levels. These could be introduced in future HIPs, provided there's an expanded accounting scheme.

Security Considerations

Self-trading by project teams: Project teams can bid in their own auctions through independent wallets to inflate liquidation prices and VWAP, then reclaim unsold tokens after settlement. Mitigations include: protocol fees making self-trading costly on all self-traded volumes; seedPx calculated using the covered VWAP window of roughly the last 5% of the auction needs continuous expenditure to manipulate; minRaise leading to auction failures when genuine demand is insufficient; all bids being visible on-chain makes self-trading detectable. Quantitatively, a project team runs a 1 million USDH auction (protocolFee = 500, hip2Seed = 2000), bidding 400,000 USDH through an independent wallet (40% of total): loses approximately 20,000 USDH to the aid fund (5% protocol fee, non-recoverable), approximately 76,000 USDH locked into HIP-2 injection (not returned to the project). Total unnecessary losses amount to about 96,000 USDH, or 24% of self-trading funds. Costs increase linearly with self-traded volumes.

Seed price manipulation: The seedPx for HIP-2 uses the covered VWAP for roughly the last 5% of the auction duration, not the last block's liquidation price. Manipulating VWAP requires sustained expenditure across multiple blocks within the window, rather than a one-time later injection, making costs proportional to the total volume during the window.

Fund security: Bidders' quote assets and auction tokens are held in custody by the protocol throughout. Funds are never under the control of the project team. If a failure occurs, all quote assets are refunded via claimAuction, and all tokens are returned to the project team.

Token freeze enforcement: All token transfers (spot order book, peer-to-peer, HyperEVM) are frozen during active auctions. This prevents insiders holding userGenesis quotas or retaining project supplies from selling tokens through non-auction channels during price discovery.

Bidding activation delay: Bids participate in liquidation starting from the next block after submission. This prevents block proposers or low-latency participants from observing pending bids and inserting reactive bids within the same block to influence the liquidation price.

Impact Analysis for Stakeholders

Token project teams: Hy-CO provides project teams with a native way to raise funds and inject liquidity in a single process. Project teams configure the auction alongside HIP-1 deployment, receive proceeds in their wallet (minus the portion allocated to HIP-2 for hip2Seed), and gain automatic liquidity injection at the market-discovered price. The trade-off is reduced control over the initial price.

Hyperliquid users: Users gain direct participation in the issuance of new team tokens being 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 has been injected. Hy-CO provides users with a fair entry opportunity with uniform pricing and bid dispersion through the same interface they are already using. After settlement, bidders must call claimAuction to move purchased tokens and unused quote assets into their spot accounts before trading. Tokens are not automatically distributed. The spot order book only opens with HIP-2 liquidity; there is no organic limit order depth until market makers and other participants place orders. If many auction participants sell immediately after claiming, buyer liquidity levels in HIP-2 may quickly deplete. This is expected behavior for any new listing, not unique to HIP-6, but the front end should clearly display the claiming status and set the expectation that spreads will be wider in early auctions than in mature markets.

HYPE holders: Hy-CO benefits HYPE holders in two ways. First, the native issuance mechanism incentivizes new teams to build and issue on Hyperliquid rather than competing chains, growing the ecosystem and directing activity toward Hyperliquid's order book. Second, auctions priced in aligning quote assets (such as USDH) increase utility and reserves, serving as a cyclical revenue source to supplement Hyperliquid trading fees through the aid fund.

Liquidity providers and market makers: After the auction, the order book is launched with genuine buyer depth funded by auction proceeds (through hip2Seed), rather than thin HIP-2 injections. 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 liquidation cost per block for a single auction is O(T), where T is the number of occupied price ticks. At tickSpacingFactor = 1.003, T is limited to thousands of ticks, but in practice, most auctions will have hundreds of occupied ticks. With maxActiveAuctions = 16, in the worst case, workload per block is 16 × O(T). Each operation is a comparison and addition of aggregated tick budgets, comparable in cost to matching the existing spot order book. No new cryptographic operations or external reads are required.

Future Work Items

The following are outside the scope of this HIP but are natural extensions that should be evaluated as HIP-6 matures: governance reviews of protocol constants; batch liquidations (settling every K blocks); non-linear release plans; batch HIP-2 injections; HIP-2 reserve mechanisms; claiming expiration and state cleanup; UI integration.