Hyperliquid tests venue allowlists to restrict trading access

Hyperliquid is testing HIP-3*, a testnet-only extension that adds venue-scoped wallet allowlists so deployers can limit which wallets trade and perform venue-only actions.

Hyperliquid announced a testnet feature called HIP-3* in a Sept. 3 developer update. The extension lets builders who deploy new HIP-3 perpetual markets enable an onchain wallet allowlist that restricts which wallets may trade on a specific venue and permits certain venue-only operator actions.

When a deployer designates a venue HIP-3*, the venue operator gains five narrowly defined authorities that apply only inside that venue. Those powers include approving or removing wallets from the allowlist, canceling specified resting orders, canceling all of a user’s resting and time-weighted average price orders on that venue, placing reduce-only orders on behalf of a user to shrink positions, and transferring collateral between accounts within the same venue.

Each authority is limited by the venue boundary. Bulk cancellations do not affect orders on other decentralized exchanges, collateral transfers are confined to the venue, and proxied orders must be reduce-only so an operator can lower but not increase a user’s position through proxy actions.

Deployers can exercise all five tools themselves or delegate individual permissions to approved sub-deployers. The model allows one address to manage the allowlist while another handles cancellations, without giving a single controller every permission. The specification does not list all actions available to wallets excluded from an allowlist; it is an access-control mechanism for individual venues, not a network-wide wallet freeze.

Hyperliquid described HIP-3* as a way for independent market operators to meet legal, compliance or customer requirements that apply to their specific venues while leaving other HIP-3 markets permissionless. Operational and economic responsibility remains with the deployer: under the existing HIP-3 framework deployers define contracts, run oracles, set leverage limits, manage margining and settle their own markets.

A current HIP-3 mainnet deployer must hold 500,000 HYPE as stake, and validators may slash that stake for inputs that threaten protocol correctness, uptime or performance. HIP-3* adds venue-level access controls to that operator model but does not change deployer responsibility or the permissionless character of markets created by other builders on the Hyperliquid network.

Hyperliquid emphasized the HIP-3* specification is preliminary, available only on testnet and has no announced mainnet timetable. The company said the feature is optional and additive, and may be adjusted before any mainnet release.

Articles by this author