Author: James Evans (@jimbo_evans)

Compiled by: Deep Tide TechFlow

Deep Dive: This is a complete Hyperliquid improvement proposal that suggests introducing a continuous liquidation 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 drew inspiration from Uniswap's continuous clearing auction model and redesigned it for Hyperliquid's order book environment. The proposal is extremely comprehensive in its technical details, 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 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 work for @recvcx, but this article represents my personal views only and does not represent the position of Reciprocal Ventures.

summary

HIP-6 introduces a permissionless token issuance auction mechanism for HIP-1 assets, designed specifically for teams natively issuing tokens on @HyperliquidX. This mechanism adapts @Uniswap's Continuous Liquidation Auction (CCA) to Hyperliquid's native Order Book (CLOB) environment. When registering for the auction, projects select a quote asset (such as USDH) from the protocol-approved aligned quote assets, creating new demand and utility sources for these assets. Auction proceeds belong to the project team, with a configurable portion automatically injecting liquidity into HIP-2 at the auction close window using a volume-weighted average price. All auction logic operates within HyperCore's block transitions, requiring no external operator.

motivation

HIP-1 and HIP-2 support permissionless token deployment and automated liquidity, but offer 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 inject liquidity into HIP-2 with their own funds, and/or complete the listing on a thin order book. 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, and @coinbase has @echodotxyz. HIP-6 is optional, but by enabling more efficient capital formation and price discovery, HIP-6 supports founders who want to build a complete project lifecycle on Hyperliquid and advance Hyperliquid's goal of becoming the blockchain that carries all finance.

HIP-6 improves Hyperliquid in the following ways:

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

Fair price discovery: Continuous clearing auctions discover market prices across multiple blocks, minimizing the impact of time-based games common in traditional auctions.

Alignment of Quoted Asset Growth: Create utility for aligned quoted assets, thereby increasing their TVL and generating returns for the aid fund.

Attracting builders: Teams can complete the entire token lifecycle on Hyperliquid. Issuing more tokens on Hyperliquid means the aid fund earns more transaction fees.

Participant protection: Committed funds are held in escrow by HyperCore during the auction period, and are not held in escrow by the project team or by a trusted third party.

Regarding the naming: This proposal is numbered HIP-6 because HIP-5 was previously assigned to a separate proposal.

On what basis do we build?

HIP-6 adapts Uniswap's continuous liquidation auctions to Hyperliquid's native CLOB environment. CCA breaks down a large auction into N progressively smaller auctions. At 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.

All alternative solutions have obvious drawbacks:

Fixed-price sales: Price discovery is poor because someone needs to guess the correct opening price. If the price is set too low, the project loses the difference; if the price is set too high, the sale will fail.

Capped, pro rata sales: This fixes the value leak, but creates an oversubscription spiral. In practice, if a sale is oversubscribed by 2x, rational participants will deposit 2x the target allocation, making it even more oversubscribed, and so on. This results in a poor user experience.

Unlimited sales: Avoids the spiral, but leads to over-fundraising. A project that could be built with $5 million raised $50 million because nothing stopped it. The 2017 ICO wave demonstrated the consequences of this approach.

Traditional auctions allow the market to determine prices, but this creates a time-consuming game. The optimal strategy is to wait until the very end as much as possible. This results in a worse user experience for non-institutional participants.

Dynamic Union Curves: Combines Dutch auctions with demand-response union curves. This works well in native AMM environments but is not suitable for Hyperliquid's native CLOB environments.

What can be built on top of HIP-6?

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

Examples of future projects that can be built on top of HIP-6:

Value accumulation mechanism: stipulates how protocol revenue flows back to token holders (such as fee allocation, buybacks, and staking rewards).

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

Token holder protection: Provides tools such as vault locking, on-chain reporting requirements, and/or vesting mechanisms to lock up both buyer and team quotas.

HIP-6 aims to make the initial auction as fair and efficient as possible. What happens after the auction ends is left to the Hyperliquid community to design. HIP-6 does not prevent teams from collaborating with market makers to enhance order book liquidity for their projects.

Public document draft

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

HIP-6: Token Issuance Auction

HIP-6 introduces permissionless token issuance auctions for HIP-1 assets. Projects offer a portion of their token supply for sale through continuous liquidation auctions. Bidders commit funds in an aligned offer asset (currently USDH). Bidders specify their total budget and the highest price they are willing to pay per token. The auction then distributes this bid across the remaining blocks. For each block, the protocol releases tokens at a fixed rate. The protocol then matches the released token supply with bidder demand, finding a uniform liquidation price for each block. At settlement, protocol fees are sent to the aid fund, a portion of the proceeds is automatically used to inject liquidity into HIP-2 Hyperliquidity based on the price found at the final auction window, and the remainder goes to the project. All auction logic operates within HyperCore's block transitions.

Deploy bidding

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's spot account to protocol escrow during registration.

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

floorPx: Minimum liquidation price, defaults to 0.

startDelay: The number of blocks between the registration and the first liquidation block, with a minimum of 1 and a default value of 1.

minRaise: The minimum amount of assets required to successfully bid for an auction; the default value is 0.

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

hip2Seed: The number of basis points of net earnings (after deducting protocol fees) automatically injected into HIP-2. Range: 2,000 to 10,000, default is 2,000.

hip2OrderSz and hip2NOrders: HIP-2 order size and order quantity, required fields.

All parameters cannot be changed once registered. A transfer freeze for each token is activated upon registration, blocking all spot orders, transfers, and HyperEVM operations on that token until settlement. Project teams can cancel their bids via cancelAuction before the startBlock auction (i.e., during the startDelay period).

bid

Bidders invoke `submitBid`, specifying a budget (minimum 100 units of the bid asset) and `maxPx` (the maximum price per token, rounded down to the auction grid). The budget is held in escrow upon submission. Each bid incurs a non-refundable fee of 1 unit of the bid asset. The budget is automatically and evenly distributed across the remaining auction blocks. Bids submitted in block `h` are valid for liquidation starting from block `h+1`. Bids submitted during `startDelay` are activated in the first liquidation block.

Bidders can submit multiple bids with different maximum prices to represent the demand curve, but each auction can have a maximum of 100,000 bids. A bidder may withdraw its bid only if the bid's maxPx is strictly below the most recent liquidation price.

liquidation

During each block of the auction period, the protocol releases tokens at a fixed rate (auctionSupply / duration per block) and calculates a uniform liquidation price by traversing the occupied price scale from highest to lowest until accumulated demand meets supply. Bids above the liquidation price receive the full quota. Bids at the liquidation price share the remaining portion proportionally to the per-block budget. Bids below the liquidation price receive nothing. The auction price grid uses a geometric scale spacing of 1.003, consistent with HIP-2.

Settlement, HIP-2 activation and claiming

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

Upon success, the protocol is atomic:

A 500 bp protocol fee will be deducted from the total cost quote and sent to the aid fund.

Allocate hip2Seed for HIP-2 activation.

The remaining amount was transferred to the project's wallet.

Unsold tokens will be returned to the project team.

The token freeze has been lifted, and spot trading, transfers, and EVM operations have resumed.

Activate HIP-2 using the project-specified hip2OrderSz and hip2NOrders. hip2Seed is used to inject nSeededLevels levels. The starting price is seedPx, calculated as the volume-weighted average price of the last 5% of trades during the auction period.

After settlement, bidders can claim their purchased tokens and unused bid assets through claimAuction.

cost

A 10 HYPE registration fee is charged upon registration. A fee of 1 unit of quoted asset is charged for each submitted Bid. A 500 bp protocol fee is charged on total proceeds at settlement. All fees flow into the aid fund. The project's existing setDeployerTradingFeeShare remains available for spot trading after the auction.

On what basis do we build?

HIP-6 Hy-CO is a continuous liquidation auction embedded in the HyperCore block transition logic. Bidders submit bids in aligned offer assets (such as USDH), each specifying a budget and a maximum price. At the end of each block, the protocol releases a batch of tokens and calculates a uniform liquidation price for that block. Bidders whose maximum price is strictly above the liquidation price receive the full allocation; bidders whose price is exactly at the liquidation price receive the remainder, which may be partially traded. At the end of the auction, the protocol collects fees and sends them to an aid fund, injects a configurable proportion of the remaining proceeds into HIP-2 Hyperliquidity based on the volume-weighted average price calculated at the final auction window, and sends the remainder to the project's wallet. Settlement at the end of the auction is atomic.

Hy-CO Life Cycle

Hy-CO has three stages:

Pre-auction: Configuration. After completing the standard HIP-1 deployment steps, the project team calls registerAuction. This verifies protocol parameters, manages escrow token supply and seller supply, activates token freeze, and assigns auction IDs.

During the auction: Bidding. Bidders can submit their bids via submitBid at any time during the startDelay period or during the auction. The budget is held in escrow upon submission, regardless of when the bid is submitted. Liquidation. At each block during the auction period, starting from startBlock, the protocol releases tokens and calculates a uniform liquidation price.

Post-auction: Settlement. In the first block after `endBlock`, the protocol evaluates the success of the auction and distributes the proceeds. HIP-2 Activation. After successful settlement, HIP-2 is automatically activated using `seedPx` and the order parameters specified by the project team. Claiming. After settlement, bidders claim their purchased tokens and unused quoted assets via `claimAuction`. Normal trading can continue during the claiming period.

Cancellation: A cancellationAuction can be executed at any time before startBlock. It returns the auctionSupply and hip2AskSupply to the project team, unfreezes the auction, and releases the auction slot. If a bid was submitted during startDelay, the auction enters a failed path: the bidder retrieves the escrowed bid assets via claimAuction (the same withdrawable refund path as a failed bid). The auctionRegistrationFee is non-refundable. Once liquidation begins, the auction is irrevocable.

Key design decisions

Why the 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 will become fragmented. HIP means that every token issued on Hyperliquid (e.g., choosing HIP-6) will receive the same fair price discovery and automatic HIP-2 injections, without external dependencies. It also means that the mechanism is guaranteed by validator consensus, not a third party.

Why choose HyperCore over HyperEVM? Everything needed for HIP-6 already exists on HyperCore. Building on HyperEVM introduces unnecessary complexity, degrading the user experience by adding steps and latency.

Why choose continuous liquidation auctions? Traditional auctions reward speed rather than valuation through time-based games; bonding curves are path-dependent; fixed-price sales require guessing the correct price. CCA distributes bids over time, liquidates at a uniform price per block, and converges over thousands of blocks, rather than resolving at a single moment.

Why only aligned quote assets are allowed: Auctions are denominated in aligned quote assets (currently USDH). Each auction locks the quote asset for its duration, increasing TVL and generating revenue for the ecosystem. Supporting non-aligned assets like USDC would dilute this effect with marginal adoption revenue. Bidders holding USDC can convert it through the standard interface.

Why only pre-determine a linear release plan? Linearity ensures the liquidation price monotonically does not decrease, which enables efficient claim-time accounting through cumulative checkpoints. Non-linear plans (post-weighted, pre-weighted) could cause the liquidation price to decrease as the supply jumps with each block, complicating bid-level accounting. These may be introduced in future HIPs, provided the accounting scheme is expanded.

Safety considerations

Project self-trading: Project teams can bid in their own auctions using independent wallets to inflate liquidation prices and VWAP, then reclaim unsold tokens after settlement. Mitigation measures include: protocol fees make self-trading costly across all self-trading volumes; seedPx calculates within the VWAP window covering the last 5% of the auction, requiring continuous spending to manipulate; minRaise causes auctions to fail when real demand is insufficient; all bids are visible on-chain, making self-trading detectable. Quantitatively, a project team running a 1 million USDH auction (protocolFee = 500, hip2Seed = 2000) bids 400,000 USDH (40% of the total supply) through an independent wallet: approximately 20,000 USDH is lost to the aid fund (5% protocol fee, irrecoverable), and approximately 76,000 USDH is locked in the HIP-2 injection (not returned to the project team). The total deadweight loss is approximately 96,000 USDH, or 24% of the self-trading funds. Costs increase linearly with the volume of self-trading.

Seed price manipulation: HIP-2's seedPx uses a windowed VWAP covering approximately the last 5% of the auction duration, instead of the liquidation price of the last block. Manipulating VWAP requires continuous spending over multiple blocks within the window, rather than a single late injection, making the cost proportional to the total volume of the window.

Fund security: Bidders' bid assets and auction tokens are held in escrow by the protocol throughout the entire process. Funds are never held in escrow by the project team. In the event of failure, all bid assets are refunded via claimAuction, and all tokens are returned to the project team.

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

Bid activation delay: Bids are only included in the liquidation process on the next block after the commit. 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 on all parties

Token project teams: Hy-CO provides projects with a native way to raise funds and inject liquidity in a single process. Projects configure auctions along with HIP-1 deployments, receive rewards in their wallets (minus the hip2Seed portion allocated to HIP-2), and receive automatic liquidity injections 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 projects upon 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 level playing field with uniform pricing and decentralized bidding, accessible through the same interface they are already using. After settlement, bidders must invoke claimAuction to transfer purchased tokens and unused quoted assets to their spot account before trading. Tokens are not automatically distributed. The spot order book opens only with HIP-2 liquidity, and there is no organic limit order depth before market makers and other participants place orders. If many bidders sell immediately after claiming, the HIP-2 buy tier can quickly run out. This is expected behavior for any new listing, not unique to HIP-6, but the front end should clearly display claim status and set the expectation that early bid spreads will be wider 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 driving activity to Hyperliquid's order book. Second, auctions denominated in aligned pricing assets (such as USDH) increase its usability and reserves, serving as a recurring revenue stream to supplement Hyperliquid transaction fees through an aid fund.

Liquidity providers and market makers: Following the auction, the order book launches with deep buying power backed by the auction proceeds (via hip2Seed), rather than a thin injection of 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 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 a few thousand ticks, but in practice most auctions will have a few hundred occupied ticks. At maxActiveAuctions = 16, the worst-case workload per block is 16 × O(T). Each operation is a comparison and addition of the aggregated tick budget, comparable in cost to matching an existing spot order book. No new cryptographic operations or external reads are required.

Future Work Projects

The following are beyond the scope of this HIP, but are natural extensions that should be evaluated as HIP-6 matures: governance review of protocol constants; bulk liquidation (liquidation once every K blocks); non-linear release plan; batch HIP-2 injection; HIP-2 reserve mechanism; claim expiration and state cleanup; UI integration.

Paidun: kHYPE/WHYPE hit a low of 0.8802 a few days ago and has now restored the anchor exchange rate

Popular Articles