Hyperliquid tests allowlists that let operators restrict access to their own markets

In a Sept. 3 developer update, Hyperliquid API Announcements said the onchain derivatives exchange was adding optional wallet allowlists to builder-run perpetual markets. The testnet-only extension, called HIP-3*, would let a market deployer decide which wallets may trade on its venue without imposing the same access policy across Hyperliquid.

HIP-3 is Hyperliquid's framework for perpetual markets deployed by independent builders. The current API reference says a new venue can be designated HIP-3* when it is created, enabling an onchain allowlist and proxied user actions. Hyperliquid described the feature as optional and strictly additive, with existing markets unchanged. The specification is preliminary, available only on testnet and has no announced mainnet date.

How HIP-3* wallet allowlists work

A HIP-3* deployer can act for a user in five defined ways: add or remove allowlist approval, cancel specified resting orders, cancel all of the user's resting orders and time-weighted average price orders on the venue, place reduce-only orders, and move collateral to another account on the same venue.

Each power is limited by the venue boundary. The documented bulk-cancellation tool leaves orders on other DEXs untouched, the collateral-transfer function is venue-scoped, and every proxied order must be reduce-only. That last restriction allows an operator to reduce a position but not increase one through the proxy function.

A deployer may use all five tools itself or delegate them one by one to approved sub-deployers. One address could administer the allowlist while another handles cancellations, without receiving every available permission.

The reference does not enumerate every action a wallet outside the allowlist may still perform on its own. HIP-3* should therefore be understood as access control and operator powers for one newly created venue, not as a wallet freeze across Hyperliquid.

The design could give firms with customer or jurisdiction restrictions a technical way to build gated perpetual markets while other deployers continue using ordinary HIP-3. It does not amount to regulatory approval, protocol-wide know-your-customer checks or evidence that an institution has adopted HIP-3*. Hyperliquid said the tools are intended to help independent deployers operate under requirements applicable to them, leaving legal and operational choices with each deployer.

That separation also leaves the economic responsibility with the market operator. Under the existing HIP-3 specification, deployers define contracts, maintain oracles, set leverage limits and settle markets. Each deployer DEX has independent margining, order books and settings.

A mainnet HIP-3 deployer must currently maintain 500,000 HYPE in stake. Validators can slash that stake for irregular inputs that jeopardize protocol correctness, uptime or performance. HIP-3* adds access controls to that operator model; it does not shift responsibility for a restricted venue to Hyperliquid or alter permissionless markets elsewhere on the network.