Summary
- HIP-3 lets qualifying independent deployers create and operate their own perpetual-futures DEXs on HyperCore.
- The documented mainnet staking requirement is 500,000 HYPE, with one perp DEX per qualifying deployer under the current specification.
- Deployers define important market parameters, including the asset, oracle, leverage limits, fees, and settlement process.
- HIP-3 adds an optional access-control layer: deployers or their sub-deployers can manage on-chain allowlists for selected markets.
- The permissioned feature is additive. Open HIP-3 markets can remain open, and existing HIP-3 deployments are not automatically converted into restricted markets.
- The initial HIP-3 version is on testnet, so readers should not treat its current behavior as the final mainnet specification.
What is the Hyperliquid HIP-3 upgrade?
HIP-3 is Hyperliquid’s builder-deployed perpetuals framework: it moves market creation from a centrally controlled listing process toward independent, permissionless deployment on HyperCore.
Under the current documentation, the deployer is not merely submitting a token for listing. The deployer defines the market and operates it. That includes selecting the oracle design, setting contract specifications, publishing oracle prices, configuring leverage limits, and settling the market when necessary.
HIP-3 markets use HyperCore’s underlying margining and order-book infrastructure. Trading actions are integrated with the broader HyperCore API; the asset identifier is the main market-specific input required by trading software.
Independent deployer
|
| defines market, oracle, contract terms, leverage and fees
v
HIP-3 perp DEX on HyperCore
|
| uses HyperCore order books and margining
v
Trader interacts with the market
|
| deployer continues to operate, update oracle inputs and settle
v
Market remains subject to deployer duties and protocol safeguards
What does the optional HIP-3 permissioned-market feature add?
HIP-3 adds an optional deployer-controlled allowlist, allowing a particular market to require permission before an address can participate.
The key distinction is between the underlying infrastructure and the access policy. Hyperliquid provides the on-chain market infrastructure, while the independent deployer or an appointed sub-deployer manages the list of permitted traders for a market that uses the feature.
- Optional: A deployer can use the existing open-market model if access restrictions are unnecessary.
- Market-specific: The access control applies to markets configured for permissioned participation, not automatically to every Hyperliquid market.
- On-chain: The permission list is designed to be enforced through on-chain configuration rather than an off-chain promise.
- Deployer-managed: The deployer or its sub-deployers control who is added to or removed from the relevant allowlist.
- Additive: The announced feature does not alter existing HIP-3 deployments.
- Preliminary: The first version is on testnet and can change after testing and feedback.
Key insight: HIP-3* does not make Hyperliquid as a whole permissioned. It gives individual deployers the option to create permissioned markets within the broader HIP-3 framework.
How are open HIP-3 markets different from optional permissioned markets?
The central difference is "Who can access the market": an open HIP-3 market is designed for permissionless participation, while a permissioned HIP-3 market can require an address to appear on a deployer-managed allowlist.
| Feature | Open HIP-3 market | Optional permissioned HIP-3* market |
|---|---|---|
| Market creation | Independent deployer can create a perp DEX after meeting the protocol requirements. | Uses the same HIP-3 deployment model, with an additional access-control option. |
| Trader access | Designed for permissionless participation, subject to the platform’s ordinary availability and technical rules. | Participation can require approval through an on-chain allowlist. |
| Who sets access policy? | No market-specific allowlist is required. | The deployer or its sub-deployer manages the allowlist. |
| Underlying trading system | HyperCore order books, margining, and unified trading API. | The same underlying HyperCore infrastructure. |
| Effect on existing HIP-3 markets | Existing open deployments continue under their current configuration. | The announced design does not automatically convert existing deployments. |
| Current status | Documented HIP-3 framework. | Initial release available on testnet; specifications are preliminary. |
Why would a deployer want a permissioned market?
A deployer may need controlled access when the market is intended for a defined user group or when its operating model requires eligibility rules that an open market cannot enforce by itself.
The public announcement gave U.S. investors and institutions with strict trading rules as examples of potential use cases. That example should not be read as a guarantee that U.S. users can trade Hyperliquid markets, nor as confirmation that any regulatory approval has been granted.
- Eligibility management: an operator can limit participation to approved addresses for a specific market.
- Institutional operating rules: a venue serving institutions may need a controlled participant set rather than unrestricted access.
- Separate market policies: a deployer can apply stricter access rules to one market without imposing the same rules on every other HIP-3 deployment.
- Infrastructure neutrality: the protocol supplies the trading rails while the independent operator remains responsible for its own market policy.
Warning: “Permissioned” describes market access, not regulatory approval. An allowlist can control which addresses may interact with a market, but it does not by itself establish that the market, deployer, product, or participant is legally authorized in any jurisdiction.
What are the core HIP-3 economic and operational requirements?
The current HIP-3 specification places substantial responsibility and economic exposure on the market deployer rather than presenting deployment as a risk-free listing tool.
| Area | Documented requirement or mechanism | Why it matters |
|---|---|---|
| Stake | 500,000 HYPE for mainnet under the documented specification. | Creates an economic commitment from the deployer. |
| Deployment count | One perp DEX per qualifying deployer under the current design. | Each DEX has independent margining, order books, and deployer settings. |
| Collateral | A quote asset can be used as collateral, subject to quote-asset rules and validator decisions. | Collateral selection affects market design and trading conditions. |
| Market launches | The first three assets on a perp DEX do not require auction participation; additional assets use a shared Dutch-auction process. | Deployment is permissionless within protocol conditions, but later listings have auction mechanics. |
| Settlement | The deployer can use haltTrading to cancel orders and settle positions at the current mark price, and the same action can resume trading. |
Allows a market to be halted and potentially recycled, including for dated contracts. |
| Fees | Standard discounts apply; deployers can configure an additional fee share within documented limits. | Users must inspect each DEX’s fee configuration rather than assume every market has identical fees. |
What responsibilities and risks remain with HIP-3 deployers?
HIP-3 does not remove market-design risk. The deployer remains responsible for the quality of the oracle, the contract specification, market operation, and settlement decisions.
- Oracle risk: a perp makes the most mathematical sense when the underlying asset or data feed is economically meaningful and difficult to manipulate. A poorly chosen index can create serious pricing problems.
- Operational risk: the deployer controls important market actions, including oracle updates, leverage limits, and settlement.
- Slashing risk: validators can slash the deployer’s stake through a stake-weighted vote for malicious or irregular behavior that harms protocol correctness, uptime, or performance.
- Key-compromise risk: the documented slashing framework does not distinguish between malicious conduct, incompetence, a poor contract specification, or compromised deployer keys when the effect on the protocol is relevant.
- Cross-margin risk: enabling cross margin is irreversible. Eligibility requires sufficient observable liquidity, a reliable external oracle, and resilience to manipulation.
- Liquidation risk: cross-margin assets can use an on-chain backstop liquidator, while the system retains ADL as a mathematical solvency fallback.
Reader checkpoint: A permissioned market may reduce who can participate, but it does not eliminate leverage, oracle, liquidation, smart-contract, operational, or counterparty risks.
Does HIP-3 make Hyperliquid a regulated exchange?
No. HIP-3 is an access-control feature, not a regulatory classification or approval.The feature may help an independent deployer design a market around particular eligibility requirements, but the legal status of a market depends on the product, operator, users, jurisdiction, and applicable rules. Any proposed U.S. access arrangement discussed alongside the announcement remains separate from the HIP-3* testnet feature and requires its own regulatory analysis and approvals.
What should traders check before using a HIP-3 market?
Traders should evaluate the individual DEX and market configuration rather than treating the Hyperliquid name as a substitute for market-level due diligence.
- Confirm the market status: determine whether it is an open HIP-3 market, a permissioned testnet market, or a future configuration that is not yet live.
- Read the market specification: check the underlying asset, contract terms, oracle source, leverage limits, collateral, funding, and fees.
- Review access rules: if the market is permissioned, understand who controls the allowlist and what eligibility process applies.
- Check liquidity: thin order books can increase slippage and liquidation risk even when the underlying infrastructure is shared.
- Understand settlement: identify how a halt, settlement, or market recycling event affects open positions.
- Use testnet carefully: preliminary testnet behavior is not a promise of final mainnet functionality.
What is the current status of HIP-3?
The first HIP-3 release is available on Hyperliquid’s testnet, while the specifications are still preliminary and may change after feedback.
- The feature has been described as a future network-upgrade capability.
- It is optional rather than mandatory for HIP-3 deployers.
- Existing HIP-3 deployments are not changed by the announced design.
- No statement in the current announcement should be treated as confirmation that a particular regulated product, U.S. market, or institutional venue is already live.
Frequently Asked Questions (FAQs)
Q: What is HIP-3 on Hyperliquid?
A: HIP-3 is the builder-deployed perpetuals framework that lets qualifying independent deployers create and operate perpetual markets on HyperCore under defined staking, auction, oracle, and risk rules.
Q: Will all Hyperliquid markets become permissioned?
A: No. The announced feature is optional and market-specific. Existing HIP-3 deployments are not automatically changed.
Q: Is HIP-3 live on mainnet?
A: The initial version is being tested on testnet, and its specifications are preliminary. Do not assume that testnet behavior is the final mainnet design.
Q: Who controls a permissioned HIP-3 market’s allowlist?
A: The deployer or its appointed sub-deployer manages the allowlist under the announced design.
Q: Does a permissioned market guarantee regulatory compliance?
A: No. An allowlist can control technical access, but compliance depends on the market operator, product structure, participants, and applicable jurisdictional requirements.
Disclaimer: This content is for informational purposes only, not financial advice. Crypto trading involve substantial risk, including loss of the capital committed. Review the official Site before trading crypto.
