HIP-3 & HIP-4 Explained: Hyperliquid Builder Markets

Hyperliquid’s builder and outcome-market layers matter because they blur the boundary between an exchange, an app, and a market created on shared infrastructure. The editorial mistake is treating every builder deployment as if it were the base Hyperliquid venue.

The current official HIP index documents HIP-3 as builder-deployed perpetuals. It does not, by itself, establish a generic HIP-4 product specification. Treat “HIP-4” as a label that needs deployment-specific documentation until Hyperliquid publishes a definitive specification or the product’s operator explains the contract.

What HIP-3 actually changes

HIP-3 lets a builder deploy a separate perpetuals DEX on HyperCore. The official specification says the deployer defines the market and oracle, operates the market, sets leverage limits, and can settle trading. Each HIP-3 DEX has independent margining, order books, and deployer settings, so shared Hyperliquid infrastructure does not make every builder venue one common risk pool.

The practical checks follow directly from that design:

• Operator: who controls the deployment and its market settings?
• Collateral: which quote asset supports the DEX, and can it lose quote-asset status?
• Margin: is the market isolated or cross-margin, and which positions share risk?
• Oracle: who sets the price and what happens if the feed is stale or manipulated?
• Settlement: can the deployer halt trading, cancel orders, and settle positions at the mark price?
• Backstop: what liquidation and bad-debt process applies to that specific DEX?

The specification also requires builder stake and gives validators a slashing mechanism for certain harmful market operations. That is a protocol-level backstop, not a guarantee that the builder’s market is liquid, well-designed, or suitable for a particular trader.

What the HIP-4 label does not prove

Outcome or prediction-style markets can look similar to perps in a trading interface while using different resolution, oracle, expiry, and dispute rules. A label, reserved ticker, or social announcement does not prove that a market is live, that Hyperliquid operates it, or that a position can be exited on demand.

For a claimed HIP-4 market, find the operator’s own rules and answer: what is the binary or event condition, which source resolves it, when does resolution occur, who can challenge it, what collateral is locked, and what happens if the source is delayed or unavailable?

The questions that settle the category

Is it live? Who operates it? Which contracts or markets are theirs? Is liquidity shared or independent? What collateral, oracle, margin, resolution, and dispute rules apply? Does the product inherit the base venue’s security assumptions or add a separate layer?

Use the HIP-3 apps shortlist for builder leads, the HIP-4 prediction-market page for the event-market category, and the Hyperliquid review for the base venue. These pages answer different jobs; do not collapse them into one product.