Hyperliquid opens the door to licensed perpetual contract market

Highlights

HIP-3* adds optional transaction-to-level market access controls
Existing HIP-3 markets remain open
Deployers manage approved addresses on-chain
Whitelist does not equal regulatory approval
First version is still in the testnet stage

HIP-3* will not close Hyperliquid's existing markets

"Permissioned Markets" Sounds like a plan to limit Hyperliquid itself. But the scope of HIP-3* is more limited. It allows the operator of a perpetual contract trading pair to choose to restrict the trading pair to an approved range of addresses without having to impose the same rules on all trading venues on the agreement.

Under the current design of HIP-3, qualified third parties can deploy perpetual contract trading pairs on HyperCore. They set contract specifications, choose oracle methods, establish leverage parameters and operate the market. HIP-3* will add an additional option to this setting: deployers can keep transaction pairs open to all addresses, or whitelist the application chain. Existing HIP-3 transaction pairs will not be transformed into restricted products, and new deployers can still choose the original open model.

What is added to HIP-3*

Deployers can restrict transactions for selected transaction pairs to addresses on the approved list.

What remains the same

The protocol remains open, and HIP-3 markets without this option activated will continue to operate without address restrictions.

Access decisions are in the hands of the deployer

HIP-3 has separated Hyperliquid's infrastructure from the markets it is built on. Hyperliquid provides on-chain order books, margins and trade execution; deployers are responsible for the products it introduces. HIP-3* extends this division of responsibilities to access rules.

Who controls what under HIP-3*

Hyperliquid: Provides HyperCore's order book, margin and trade execution.
Deployer : Define and operate the product, and then choose whether to apply address admission control.
Trader : Restricted products can only be used after the operator approves the relevant address.

Thus, one operator can create trading pairs for approved participants, while another operator can provide a fully open market on the same infrastructure. This flexibility-not the licensing system itself-is the core change.

Approved addresses do not equal certified investors

Whitelist answers a narrow question on the chain: Can this address trade this market? It cannot prove who controls the address, why that person is qualified, or whether the product meets the rules of a particular jurisdiction. Any operator who wishes to serve certified or institutional customers only will still need to go through off-chain processes for qualification review, customer due diligence, information disclosure and legal compliance. HIP-3* can enforce the results of the process at the address level, but it cannot replace the process itself.

That's why the proposal should not be advertised as Hyperliquid's U.S. launch or regulatory approval. This distinction was equally important after Hyperliquid representatives met with the SEC Crypto Working Group: that meeting indicated regulatory engagement rather than a license for the HIP-3 market to serve U.S. traders.

What this change means for traders

Restricted access may make certain markets possible, otherwise operators would need to build their own exchange infrastructure. A professional trading venue can use HyperCore's execution layer while applying its own customer or risk requirements for specific products.

For approved traders, the potential advantage is the ability to enter the market through the same on-chain environment without having to transfer collateral and activities to another platform. But the benefit lies in usability rather than automated improvement in execution quality.

Licensing access does not create liquidity

A restricted market may still experience large price spreads, insufficient order book depth, or weak oracle design. It may also bear the same leverage and liquidation risks as other sustainable products. Therefore, an approved address should never be mistaken for a quality signal.

In practice, traders still need to evaluate the operator, the reference price of the contract, available leverage, and market liquidity. These factors determine whether positions can be opened efficiently, especially when price fluctuations intensify.

What should traders check before using restricted markets

If HIP-3* is launched on the main network, access status will become another market condition that needs to be understood before trading. It should be juxtaposed with common checks such as leverage, funding rates, liquidity and underlying price oracle quality.

Approved address : Confirm that the address at which the collateral is held is the address authorized by the operator.
Operator : Read its market documentation to learn who controls contract and price inputs.
Access rule changes : Check how operators handle updates to their list, especially when users have open orders or positions.
Available liquidity : Limited participants may affect order book depth, spreads, and the ability to close positions during periods of volatility.
Under-level exposure : Perpetual contracts track a price and do not confer ownership, dividends, or shareholder rights on the reference asset.

This last point is particularly important for non-crypto markets. Contracts can track stocks, commodities or indices, but do not confer rights on the holder in the underlying securities or physical assets.

Testnet will verify whether the model is feasible

The first version of HIP-3* has been launched on Testnet. This indicates that the idea has entered the implementation stage, but it is not a completed mainnet deployment, nor has online partners or specific restricted markets been identified.

The next questions are operational: how do deployers update the whitelist, how the interface interprets access restrictions, and whether markets that choose this option can establish reliable liquidity.

HIP-3 enables persevering contract trading pairs to be deployed without permission. HIP-3* adds a more targeted decision, allowing each deployer to keep transaction pairs open to all addresses or set its own participation boundaries.