Hyperliquid Tests Wallet Allowlists for Builder-Run Perpetual Markets (Testnet)
What is HIP-3* and what’s new?
Hyperliquid is experimenting with a testnet-only tweak called HIP-3*, which lets independent market builders put optional wallet allowlists on their own perpetual markets. Think of it like a VIP rope: the market operator gets to decide which wallets can trade on that specific venue, without changing access rules for every other market on the network.
This is an add-on to the existing HIP-3 framework (the system builders use to deploy perpetual markets). It’s optional, currently only available on testnet, and still in draft form — so don’t expect it to show up on mainnet just yet.
How it works, limits, and why it matters
When a market is flagged as HIP-3*, its deployer gains five narrowly defined powers they can use directly or hand off to approved sub-deployers: approve or revoke wallet allowlist entries; cancel specific resting orders; cancel all resting orders and time-weighted average price orders on that venue; submit reduce-only orders on behalf of a user; and move collateral between accounts within the same venue. Yes, that’s a lot of buttons — but they’re purposely scoped.
Boundaries matter here. Those cancel and collateral functions only affect orders and funds on that particular venue — they won’t go hunting on other DEXs. And proxied orders must be reduce-only, so an operator can shrink someone’s position via the proxy but can’t pump it up. In short: it’s venue-level access control, not a global wallet freeze.
A single deployer can hold all permissions or split them up: one address could manage the allowlist while another handles cancellations, for example. The spec doesn’t attempt to list every thing a non-allowlisted wallet might still do on its own, so think of HIP-3* as a toolbox for venue operators rather than an exhaustive access policy.
Why add this? It gives firms or builders who face customer restrictions or jurisdictional rules a technical way to run gated perpetual markets while other deployers keep using the standard HIP-3. It’s not a stamp of regulatory approval, KYC, or an institutional endorsement — those legal and operational choices remain up to each deployer.
Finally, the usual responsibilities still apply: deployers remain economically on the hook for their markets. Mainnet deployers currently need to stake a substantial amount (500,000 HYPE) and can be penalized by validators for behavior that harms protocol correctness, uptime, or performance. HIP-3* adds access controls on top of that model, but it doesn’t shift liability to the protocol or change the permissionless nature of other markets on the network.
