Hyperliquid is testing an optional feature, called HIP-3*, that lets operators of builder-run perpetual markets restrict trading to a wallet allowlist. The testnet-only tool gives each market deployer control over its own venue without changing any existing market on the exchange.
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 extension, called HIP-3*, lets a market deployer decide which wallets may trade on its venue, without imposing the same access policy across the rest of Hyperliquid.
HIP-3 is Hyperliquid's existing 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, and the specification remains preliminary, available only on testnet, with no announced mainnet date.
How the allowlist works
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 a user's resting and time-weighted average price orders on the venue, place reduce-only orders, and move collateral to another account on the same venue. Every proxied order must be reduce-only, so an operator can reduce a position through the proxy function but never increase one.
Each power is also bounded by the venue itself. The bulk-cancellation tool leaves orders on other DEXs untouched, and the collateral-transfer function is scoped to the same venue. A deployer may use all five tools itself or delegate them individually to approved sub-deployers, so one address could administer the allowlist while another handles cancellations.
Access control for one venue, not a network freeze
The reference does not list every action a wallet outside the allowlist may still take on its own, so HIP-3* amounts to access control and operator powers for one newly created venue, not 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 keep using ordinary HIP-3.
It does not amount to regulatory approval, protocol-wide know-your-customer checks, or evidence that any institution has adopted HIP-3*. Hyperliquid said the tools are meant to help independent deployers operate under requirements applicable to them, leaving legal and operational choices with each deployer.
Operators still carry the risk
That separation keeps economic responsibility with the market operator. Under the existing HIP-3 specification, deployers define contracts, maintain oracles, set leverage limits and settle markets, and each deployer DEX runs independent margining, order books and settings.
A mainnet HIP-3 deployer must currently maintain 500,000 HYPE in stake, and validators can slash that stake for irregular inputs that jeopardize protocol correctness, uptime or performance. HIP-3* adds access controls on top of that operator model — it does not shift responsibility for a restricted venue to Hyperliquid or alter permissionless markets elsewhere on the network.
Source: CryptoSlate
Trading involves risk.
Risk Disclaimer
