HIP-3: Builder-Deployed Perpetual Markets
How builders deploy independent perpetual DEXs while inheriting HyperCore's order books and margin engine.
HIP 3 lets qualified builders deploy their own perpetual DEXs on Hyperliquid while using HyperCore's native market infrastructure. The deployer defines and operates the market, while HyperCore supplies the shared execution environment, order book mechanics, margin system, and trading interfaces.
This expands the set of markets that can exist without requiring the core protocol team to operate every perpetual contract.
The deployer defines the market
A HIP 3 deployer is more than a frontend operator. The deployer specifies the contract and market configuration, operates the oracle process, sets allowed leverage within protocol constraints, and handles market lifecycle actions where required.
That makes deployer quality part of the product's risk model.
Two HIP 3 markets can use the same HyperCore infrastructure and still differ materially because their oracle design, collateral, leverage limits, liquidity, settlement rules, and operational practices are different.
HyperCore supplies common execution infrastructure
Builders do not need to create a new matching engine and margin engine for every market. HIP 3 markets inherit the native execution environment and can use the same broad API surface familiar to Hyperliquid traders and applications.
This lowers the infrastructure barrier to launching new derivatives while keeping execution under the same L1 consensus.
It also improves integration. A trading terminal that already understands Hyperliquid APIs can support builder markets without integrating an entirely unrelated exchange stack for each deployer.
Staking makes deployment economically consequential
HIP 3 uses a significant HYPE staking requirement for mainnet deployers under the current specification. The stake requirement and associated holding period are designed to make market deployment economically meaningful rather than costless experimentation.
The exact amount and duration are live protocol parameters. Builders and institutional reviewers should confirm current values from the official HIP 3 documentation before making deployment or counterparty assumptions.
Oracle responsibility moves to the builder
The oracle is one of the most important parts of a perpetual market. It influences reference pricing, risk, and settlement behavior.
In HIP 3, the deployer carries responsibility for the market's oracle operation. That means users need to evaluate data sources, update logic, stale data handling, market closures, and emergency procedures.
HIP 3 Oracles and Market Pricing covers this risk separately.
Permissionless market creation expands the design space
A builder can create markets tied to crypto assets, indices, commodities, equity references, or other instruments if the market can be specified and operated credibly under the protocol's rules.
This broadens Hyperliquid beyond the set of assets a single team would choose to list.
It also creates fragmentation. Different HIP 3 DEXs can have different collateral assets and separate margin pools, which affects capital efficiency. HIP 3 Collateral and Capital Fragmentation explains that tradeoff.
Users need market specific due diligence
Using HyperCore does not make every HIP 3 market equivalent to a validator operated market. A trader should inspect the deployer, oracle, collateral, liquidity, leverage, settlement rules, and fee structure.
An institution should also understand who operates the market and which failures belong to the deployer rather than the base execution layer.
Continue reading
Read HIP 3 Oracles and Market Pricing for reference price design and The HIP 3 DEX Landscape for the broader ecosystem of builder deployed markets.