FacebookTwitterLinkedInTelegramCopy LinkEmail
Fintech

Hyperliquid Opens the Door to Permissioned Perpetual Markets

Hyperliquid Opens the Door to Permissioned Perpetual Markets

Hyperliquid is testing an optional way for individual perpetual markets to admit approved wallets only, while leaving the protocol’s existing open markets unchanged.

Key Takeaways

  • HIP-3* adds optional wallet-level market access.
  • Existing HIP-3 markets remain open.
  • Deployers manage approved wallets on-chain.
  • An allowlist is not regulatory approval.
  • The first version remains on testnet.

HIP-3* does not close Hyperliquid’s existing markets

“Permissioned markets” can sound like a plan to restrict Hyperliquid itself. HIP-3* is more limited. It gives the operator of one perpetual market the option to restrict that market to approved wallets, without applying the same rule to every venue on the protocol.

Under HIP-3’s existing design, qualified third parties can deploy perpetual venues on HyperCore. They set the contract specifications, choose the oracle methodology, establish leverage parameters and operate the market.

HIP-3* would add a further choice to that setup: the deployer could keep a market open to every wallet or apply an on-chain allowlist. Existing HIP-3 venues would not be converted into restricted products, and new deployers could still choose the original open model.

What HIP-3* adds

A deployer can limit trading in a chosen market to wallets included on its approved list.

What remains the same

The protocol stays open, and HIP-3 markets that do not activate the option continue without wallet restrictions.

The access decision sits with the deployer

HIP-3 already separates Hyperliquid’s infrastructure from the markets built on it. Hyperliquid supplies the on-chain order books, margining and trade execution; the deployer is responsible for the product it introduces. HIP-3* extends that division of responsibilities to entry rules.

Who controls what under HIP-3*

Hyperliquid

Provides HyperCore’s order books, margining and trade execution.

Deployer

Defines and operates the product, then chooses whether to apply wallet access controls.

Trader

Can use a restricted product only after the operator approves the relevant wallet.

One operator could therefore create a market for approved participants while another offers a fully open market on the same underlying infrastructure. That flexibility, rather than permissioning itself, is the central change.

An approved wallet does not equal a verified investor

An allowlist answers one narrow question on-chain: may this wallet trade this market? It does not prove who controls the wallet, why that person is eligible or whether the product complies with the rules in a particular jurisdiction.

Any operator that wants to serve verified or institution-only clients would still need an off-chain process for eligibility, customer checks, disclosures and legal compliance. HIP-3* could enforce the outcome of that process at the wallet level, but it does not replace the process itself.

This is why the proposal should not be presented as a U.S. launch or as regulatory approval for Hyperliquid. That distinction also matters after Hyperliquid-related representatives met the SEC Crypto Task Force: the meeting showed regulatory engagement, not permission for HIP-3 markets to serve U.S. traders.

What the change could mean for traders

Restricted access may make some markets possible that would otherwise require an operator to build its own exchange infrastructure. A specialist venue could use HyperCore’s execution layer while applying its own customer or risk requirements around a particular product.

For an approved trader, the potential advantage is access to that market through the same on-chain environment instead of moving collateral and activity to a separate platform. The benefit is availability, however, not an automatic improvement in execution.

Permissioned access cannot create liquidity

A restricted market can still have wide spreads, a shallow order book or a weak oracle design. It can also carry the same leverage and liquidation risks as any other perpetual product. An approved wallet should therefore never be mistaken for a quality signal.

In practice, the trader still needs to assess the operator, the contract’s reference price, the leverage available and the market’s liquidity. Those factors determine whether a position can be entered and exited efficiently, especially when price volatility rises.

What traders should check before using a restricted market

If HIP-3* reaches mainnet, access status will become another market condition to understand before trading. It should sit alongside familiar checks such as leverage, funding, liquidity and the quality of the underlying price feed.

  • The approved wallet: Confirm that the address holding collateral is the address the operator has authorised.
  • The operator: Read its market documentation and understand who controls the contract and price inputs.
  • Access-rule changes: Check how the operator handles updates to its list, particularly when users have open orders or positions.
  • Available liquidity: Limited participation can affect order-book depth, spreads and the ability to close during volatility.
  • The underlying exposure: A perpetual tracks a price; it does not confer ownership, dividends or shareholder rights in a referenced asset.

That final point is particularly important for non-crypto markets. A contract can reference a stock, commodity or index without giving its holder the rights attached to the underlying security or physical asset.

Testnet will show whether the model is workable

The first HIP-3* version is live on testnet. That shows the idea has reached implementation, but it is not a completed mainnet rollout and does not identify a launch partner or a specific restricted market.

The next questions are operational: how deployers will update allowlists, how interfaces will explain access limits, and whether markets that choose the option can build dependable liquidity.

HIP-3 made perpetual-market deployment permissionless. HIP-3* adds a more targeted decision, allowing each deployer to keep a market open to every wallet or set its own boundary around participation.


The article is provided for informational purposes only and does not constitute investment advice.

Author
Kosta Gushterov, journalist in Coindoo.com

Reporter at Coindoo

Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work at Coindoo has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.

Learn more about crypto and blockchain technology.

Glossary